3 ms·

Do you have a citation for that? The only standard I can find is 6709. https://en.m.wikipedia.org/wiki/ISO_6709 https://en.m.wikipedia.org/wiki/ISO_6709 By go

Do you have a citation for that? The only standard I can find is 6709. https://en.m.wikipedia.org/wiki/ISO_6709 https://en.m.wikipedia.org/wiki/ISO_6709 By government systems do you mean US government systems?

jandrewrogers 5y ago
ISO 19125 is the governing standard for representing geospatial data. This is used in government systems globally, which is the basic purpose of ISO standards, and in many countries (e.g. Western Europe) government systems are required to conform to these standards. This standard is ubiquitous in all of the software tooling for dealing with geospatial data. Because the storage and interoperability of data is specified to use lon/lat, it strongly influences things that may not be specified by standard. Human user interfaces can do whatever they want, but software systems expect everything in lon/lat order.
- grey-area 5y ago
  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

ISO 19125 is the governing standard for representing geospatial data. This is used in government systems globally, which is the basic purpose of ISO standards, and in many countries (e.g. Western Europe) government systems are required to conform to these standards. This standard is ubiquitous in all of the software tooling for dealing with geospatial data. Because the storage and interoperability of data is specified to use lon/lat, it strongly influences things that may not be specified by standard. Human user interfaces can do whatever they want, but software systems expect everything in lon/lat order.

grey-area 5y ago
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.