5 ms·

While it is common to casually use the lat/lon order, the lon/lat order was decided on as a matter of international treaty via ISO. This was inconsistent a long

While it is common to casually use the lat/lon order, the lon/lat order was decided on as a matter of international treaty via ISO. This was inconsistent a long time ago even in ISO standards, but was resolved to the lon/lat format many years ago, is required for government systems, and is essentially settled. People may not like it but that is arguing with the weather. Everything is lon/lat from here on out and all new systems are designed this way. For people that actually work in geospatial, there is no advantage to the lat/lon order and the lon/lat order has been the standard for decades already. Arguing about the order of polar coordinates is fighting a battle that was literally settled decades ago.

kstenerud 5y ago
When I look up ISO, I find ISO 6709, which specifies latitude before longitude by default. https://en.wikipedia.org/wiki/ISO_6709#Order,_sign,_and_units https://en.wikipedia.org/wiki/ISO_6709#Order,_sign,_and_unit... EPSG:4326 also uses lat/long: https://epsg.org/crs_4326/WGS-84.html https://epsg.org/crs_4326/WGS-84.html
- bottled_poe 5y ago
  Thus the need for the One True Standard, which surely will be perfected this time around.
  - tornato7 5y ago
    Just prefix the Longitude with L, for Longitude, that will clear up any ambiguity
    - quinndexter 5y ago
      Yep. Maybe use a small l for latitude. Judicious font choices should ensure little room for confusion.
- jofer 5y ago
  EPSG:4326 doesn't really use lat/lon. Sure, it's in the spec, but that part is irrelevant. Everything is stored in lon/lat for any relevant format when the projection is EPSG:4326. There have been some unfortunate decisions lately to make common APIs expect y,x if the projection is EPSG:4326 and x,y for pretty much everything else, but that's a backwards compatibility break that's going to wreak a fair amount of havoc. It's also worth pointing out that a lot of this is conflating display order in UIs (which usually is lat/lon, often in DMS) with storage order and API conventions (which are usually lon/lat).
- jandrewrogers 5y ago
  The vast majority of software that stores geographic information conforms to ISO 19125, which specifies lon/lat order. If you use PostGIS, for example, you are using ISO 19125. While conflicting ISO standards such as 6709 infamously exist, which is confusing for people that don't deal with geospatial data on a routine basis, the dominance of ISO 19125 for storage has strongly influenced all downstream representations. Many early standards conflicted (e.g. coordinate order) or were under-specified (e.g. polygon winding). The Open Geospatial Consortium (OGC), whence many of these ISO standards came, sensibly made the decision many years ago that all future standards should treat these in a consistent and fully-specified way. Because of the pervasiveness and vast quantity of data stored as ISO 19125, adopting the ISO 19125 conventions were the least costly way of resolving these conflicts. I've been working with GIS data from every type of industry for a long time, and the only place I ever see lat/lon order is in user interfaces. At the data and software level it is always lon/lat for compatibility and interoperability. There is little to be gained by re-litigating the lon/lat coordinate order, since no value is gained by changing it (the choice is arbitrary), virtually all modern software systems use the same conventions at this point, and in many cases these conventions are codified in law across many countries.
  - harshreality 5y ago
    Unless I'm misreading, ISO 19125 (2004) is later than ISO 6709 (1983), so using 19125 as an authority is questionable to say the least. Isn't the reality that a bunch of software engineers wrote their software to use lon/lat because x, y is the intuitive ordering in the context of a cylindrical projection way of thinking, and ISO 19125 codified that common software practice without anyone really thinking about it or the conflicts it created? That's hardly definitive, particularly when it contradicted ISO's own earlier standard (which codified the long-standing common communication practice of lat/lon). ISO standards themselves are weak without logical and practical commonplace usage backing them up, because the standards are paywalled. Your experience, and the table in the OP article, shows that lon/lat has more usage in the software world, but that's not sufficient. There's enough confusion, and enough major players defecting from that recent "standard" of 19125, that the issue should be looked at again, re-litigated, and re-standardized. Everyone outside the narrow field of GIS software engineers and data wranglers expects lat/long. The issue has never been litigated at all outside of that insular world. It seems like standardizing on the common practice (outside of the digital technical realm) of lat/lon is the right way to go: The software world has the advantage that if there was consensus to change to lat/lon universally, they could patch it once, convert any data files once, and be done. The software world has much less inertia. In contrast, the non-software world can't be readily converted to lon/lat. It's much more difficult to change people's everyday usage. Look at the mess caused by Americans using MM/DD/YYYY, or English-inspired use of Imperial over metric. It's difficult to convince people to change even when there are significant problems with the historical choice, and objective reasons for why they should change.
geokon 5y ago
You say it like it's a done deal, but virtually every book map paper and UI disagree with you. Outside of the programming bubble we're not in a world where you ever need to think twice about the order. I don't go to Wikipedia and think "hmm I wonder which order they wrote their coordinates". I don't need to check the publication date of a map or book. I don't see that ever changing And as I explained the benefits are kind of half-assed. If you want a more intuitive internal system than I think you can do better. You should full-ass it and re-zero it to whatever makes sense in your situation (or even change the units, or remap to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around) - but keep the API in standard notation.
- post-it 5y ago
  > remap to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around :-/
  - geokon 5y ago
    It was a random thought I had today. Please tell me why it's a bad idea haha :)) A lot of weird bugs happen at the edges/meridians. In a South/East system the edges are at the poles and in the middle of the Pacific Ocean. So you already eliminate weird southern hemisphere blow ups. Using wraparound would solve the Pacific problem I guess Maybe unsigned long.. for some extra precision.. EDIT: unfortunately since I'm doing everything in Clojure unsigned math is kinda clunky :(
    - rsaxvc 5y ago
      Sub-cm resolution everywhere with only 32 bits. > Using wraparound would solve the Pacific problem I guess I worked with such a coordinate system years ago, and there's definitely some advantages (fixed resolution, speed on some processors, memory usage) and some disadvantages ( not all software is wraparound aware and needs ported, debugging outside of decimal degrees is harder for me but I know some mathematicians who are more used to radians than anything else - perhaps you get used to it).
grey-area 5y ago
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.

kstenerud 5y ago

When I look up ISO, I find ISO 6709, which specifies latitude before longitude by default. https://en.wikipedia.org/wiki/ISO_6709#Order,_sign,_and_units https://en.wikipedia.org/wiki/ISO_6709#Order,_sign,_and_unit... EPSG:4326 also uses lat/long: https://epsg.org/crs_4326/WGS-84.html https://epsg.org/crs_4326/WGS-84.html

bottled_poe 5y ago
Thus the need for the One True Standard, which surely will be perfected this time around.
- tornato7 5y ago
  Just prefix the Longitude with L, for Longitude, that will clear up any ambiguity
  - quinndexter 5y ago
    Yep. Maybe use a small l for latitude. Judicious font choices should ensure little room for confusion.
jofer 5y ago
EPSG:4326 doesn't really use lat/lon. Sure, it's in the spec, but that part is irrelevant. Everything is stored in lon/lat for any relevant format when the projection is EPSG:4326. There have been some unfortunate decisions lately to make common APIs expect y,x if the projection is EPSG:4326 and x,y for pretty much everything else, but that's a backwards compatibility break that's going to wreak a fair amount of havoc. It's also worth pointing out that a lot of this is conflating display order in UIs (which usually is lat/lon, often in DMS) with storage order and API conventions (which are usually lon/lat).
jandrewrogers 5y ago
The vast majority of software that stores geographic information conforms to ISO 19125, which specifies lon/lat order. If you use PostGIS, for example, you are using ISO 19125. While conflicting ISO standards such as 6709 infamously exist, which is confusing for people that don't deal with geospatial data on a routine basis, the dominance of ISO 19125 for storage has strongly influenced all downstream representations. Many early standards conflicted (e.g. coordinate order) or were under-specified (e.g. polygon winding). The Open Geospatial Consortium (OGC), whence many of these ISO standards came, sensibly made the decision many years ago that all future standards should treat these in a consistent and fully-specified way. Because of the pervasiveness and vast quantity of data stored as ISO 19125, adopting the ISO 19125 conventions were the least costly way of resolving these conflicts. I've been working with GIS data from every type of industry for a long time, and the only place I ever see lat/lon order is in user interfaces. At the data and software level it is always lon/lat for compatibility and interoperability. There is little to be gained by re-litigating the lon/lat coordinate order, since no value is gained by changing it (the choice is arbitrary), virtually all modern software systems use the same conventions at this point, and in many cases these conventions are codified in law across many countries.
- harshreality 5y ago
  Unless I'm misreading, ISO 19125 (2004) is later than ISO 6709 (1983), so using 19125 as an authority is questionable to say the least. Isn't the reality that a bunch of software engineers wrote their software to use lon/lat because x, y is the intuitive ordering in the context of a cylindrical projection way of thinking, and ISO 19125 codified that common software practice without anyone really thinking about it or the conflicts it created? That's hardly definitive, particularly when it contradicted ISO's own earlier standard (which codified the long-standing common communication practice of lat/lon). ISO standards themselves are weak without logical and practical commonplace usage backing them up, because the standards are paywalled. Your experience, and the table in the OP article, shows that lon/lat has more usage in the software world, but that's not sufficient. There's enough confusion, and enough major players defecting from that recent "standard" of 19125, that the issue should be looked at again, re-litigated, and re-standardized. Everyone outside the narrow field of GIS software engineers and data wranglers expects lat/long. The issue has never been litigated at all outside of that insular world. It seems like standardizing on the common practice (outside of the digital technical realm) of lat/lon is the right way to go: The software world has the advantage that if there was consensus to change to lat/lon universally, they could patch it once, convert any data files once, and be done. The software world has much less inertia. In contrast, the non-software world can't be readily converted to lon/lat. It's much more difficult to change people's everyday usage. Look at the mess caused by Americans using MM/DD/YYYY, or English-inspired use of Imperial over metric. It's difficult to convince people to change even when there are significant problems with the historical choice, and objective reasons for why they should change.

geokon 5y ago

You say it like it's a done deal, but virtually every book map paper and UI disagree with you. Outside of the programming bubble we're not in a world where you ever need to think twice about the order. I don't go to Wikipedia and think "hmm I wonder which order they wrote their coordinates". I don't need to check the publication date of a map or book. I don't see that ever changing And as I explained the benefits are kind of half-assed. If you want a more intuitive internal system than I think you can do better. You should full-ass it and re-zero it to whatever makes sense in your situation (or even change the units, or remap to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around) - but keep the API in standard notation.

post-it 5y ago
> remap to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around :-/
- geokon 5y ago
  It was a random thought I had today. Please tell me why it's a bad idea haha :)) A lot of weird bugs happen at the edges/meridians. In a South/East system the edges are at the poles and in the middle of the Pacific Ocean. So you already eliminate weird southern hemisphere blow ups. Using wraparound would solve the Pacific problem I guess Maybe unsigned long.. for some extra precision.. EDIT: unfortunately since I'm doing everything in Clojure unsigned math is kinda clunky :(
  - rsaxvc 5y ago
    Sub-cm resolution everywhere with only 32 bits. > Using wraparound would solve the Pacific problem I guess I worked with such a coordinate system years ago, and there's definitely some advantages (fixed resolution, speed on some processors, memory usage) and some disadvantages ( not all software is wraparound aware and needs ported, debugging outside of decimal degrees is harder for me but I know some mathematicians who are more used to radians than anything else - perhaps you get used to it).

grey-area 5y ago

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.