3 ms·

Thanks. There does still seem to be controversy on this point in tooling though? Popular tools like proj and pyproj now confusingly return different ordering f

Thanks. There does still seem to be controversy on this point in tooling though? Popular tools like proj and pyproj now confusingly return different ordering for a different CRS, and a diff between UI conventions and code etc is really unfortunate and likely to cause bugs, so it doesn’t seem completely settled. e.g. https://github.com/pyproj4/pyproj/issues/225 https://github.com/pyproj4/pyproj/issues/225 https://github.com/OSGeo/PROJ/commit/6a7e24dce79f93b73f4919f267df2fdf3ee95713 https://github.com/OSGeo/PROJ/commit/6a7e24dce79f93b73f4919f...

jandrewrogers 5y ago
Those issues are specific to cartography, which used a mess of non-standardized conventions for centuries. Like with calendars, there is an almost unbounded set of edge cases when writing software to support it. Geospatial data from modern systems, which rounds to "all data", is virtually always presented as EPSG:4326 + ISO 19125 so the experience is pleasantly consistent, and as a practical matter you can't avoid this representation. The vast majority of geospatial data is not intrinsically cartographic in nature and the primary use case is not making maps even if maps are sometimes used as a presentation layer. Consequently, cartographic conventions are correctly treated as legacy interfaces that require conversion into a modern standard; it wouldn't make sense for a modern software system to speak legacy standards natively. Most modern geospatial data systems use an internal spatial reference system derived from WGS84 (not even straight EPSG:4326) that is optimized for efficient data processing. Remember, the vast majority of this data is primarily consumed by machines and virtually all of the data is required to be interoperable with machines. There is a very thin long tail of people using myriad legacy cartographic formats but they don't influence how geospatial data is handled because it is such a negligible percentage of the computing done on geospatial data these days.

jandrewrogers 5y ago

Those issues are specific to cartography, which used a mess of non-standardized conventions for centuries. Like with calendars, there is an almost unbounded set of edge cases when writing software to support it. Geospatial data from modern systems, which rounds to "all data", is virtually always presented as EPSG:4326 + ISO 19125 so the experience is pleasantly consistent, and as a practical matter you can't avoid this representation. The vast majority of geospatial data is not intrinsically cartographic in nature and the primary use case is not making maps even if maps are sometimes used as a presentation layer. Consequently, cartographic conventions are correctly treated as legacy interfaces that require conversion into a modern standard; it wouldn't make sense for a modern software system to speak legacy standards natively. Most modern geospatial data systems use an internal spatial reference system derived from WGS84 (not even straight EPSG:4326) that is optimized for efficient data processing. Remember, the vast majority of this data is primarily consumed by machines and virtually all of the data is required to be interoperable with machines. There is a very thin long tail of people using myriad legacy cartographic formats but they don't influence how geospatial data is handled because it is such a negligible percentage of the computing done on geospatial data these days.