There's no explanation in your rant,
Whoa there! This is a technical forum, not about religion. Sounds like I hit a nerve by mentioning a technical error in gpkg that produces symptoms similar to those in the problem that launched this thread. By the way, I didn't slam gpkg or point out the technical error that gpkg commits. I simply pointed out that a file which gpkg provides on their web site is, indeed, inaccurate in that it wrongly claims the wrong EPSG code for the data. Getting latitude and longitude backwards is a big error. I respectfully point out I did provide an explanation. That would be this bit: So the world is full of data sets which claim to be in EPSG:4326 or other (Y,X) systems but which in fact use the wrong, (X,Y) ordering.
GPKG does indeed ignore EPSG-required coordinate ordering and it really does write what it claims to be EPSG:4326 in X,Y order instead of the required Y,X order. That is simply a technical mistake, nothing more and nothing less. In layman's terms, it gets latitude and longitude backwards when using that code. Noting that GPKG gets that wrong or that a file published on their site as a "known good" test sample is indeed in error, is a simple technical observation, not a commentary on religion, politics, decency, etc. I still don't understand if the order you talk about is a visible convention
No, it's not a convention, it is part of the EPSG standard that gpkg claims to use. As noted in my post it is what EPSG *insists* must be respected in their standard. Errors like misapplying EPSG codes are exactly the sort of errors which result in data sets appearing flipped in various ways, the problem in this thread, hence the particular example. I know you are a fan of gpkg but getting angry at the messenger who points out a simple technical mistake in gpkg is not what this forum is about. But if you believe I stated something that is technically incorrect you can check that for yourself by comparing what GPKG does to what the standard says it should do. Read the EPSG standard, study what gpkg does and you'll see how it gets it wrong. Not too difficult in this case given the obvious blunder of getting latitude and longitude backwards. Use the sample data set they provide that I cited as a test case so others can help you or duplicate your work. I have no idea why gpkg doesn't fix this error but it is not my cross to bear to fix errors in other people's programs. Instead, my cross to bear is to provide technical means so people can use Manifold to deal with errors in broken data, like flipped coordinate ordering. As I recall, Radian added a dataport for gpkg at your request, only to discover in testing, using gkpg's own sample data, that gpkg uses EPSG incorrectly. Instead of simply dropping gpkg, Manifold looked into the matter and learned that it is very common for people to misuse the EPSG standard, and that as a result the world's data archives contain much data that claims to be in EPSG:4326 but is not. It's a real problem. There are many people who would take a more rigorous approach to standards and say that if the data is broken it is best not to import it. But that's not what Manifold did in this case. Instead,Radian added an option to flip coordinate ordering for data that gets it wrong. That's doing a good turn for users so they can deal with errors in data, which we all know happen all of the time, and convert the data into correct EPSG ordering. That's a perfectly fair technical solution to a simple technical problem. Nothing to get heated up about.
|