4 ms·

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:

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.
  - jandrewrogers 5y ago
    You are arguing with the weather. The use of lat/lon is obsolete in the same way XML is obsolete. This was already settled when I was learning about geospatial two decades ago. You are asserting "common practice" that isn't actually common practice. ISO 19125 conformance requirements are ubiquitous; I've never seen a requirement for ISO 6709 conformance in real application. That ship sailed a long time ago. You are also grossly underestimating the scale of the lon/lat installed based. The lat/lon diehards are the inconsequential and insular part of the market by comparison. There is no practical way to "patch" the countless exabytes of lon/lat currently sitting in cold storage. These are the largest data sets that exist, and it would be exceedingly unrealistic to expect the world to reformat this data, which they've been happily using up to this point, because a few people don't want to remember that the order is lon/lat. You might as well decree that everyone use XML to store their data while you're at it. I literally don't care, because it doesn't actually matter. No amount of wishful thinking will cause a return to the imagined golden age of lat/lon.

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.
- jandrewrogers 5y ago
  You are arguing with the weather. The use of lat/lon is obsolete in the same way XML is obsolete. This was already settled when I was learning about geospatial two decades ago. You are asserting "common practice" that isn't actually common practice. ISO 19125 conformance requirements are ubiquitous; I've never seen a requirement for ISO 6709 conformance in real application. That ship sailed a long time ago. You are also grossly underestimating the scale of the lon/lat installed based. The lat/lon diehards are the inconsequential and insular part of the market by comparison. There is no practical way to "patch" the countless exabytes of lon/lat currently sitting in cold storage. These are the largest data sets that exist, and it would be exceedingly unrealistic to expect the world to reformat this data, which they've been happily using up to this point, because a few people don't want to remember that the order is lon/lat. You might as well decree that everyone use XML to store their data while you're at it. I literally don't care, because it doesn't actually matter. No amount of wishful thinking will cause a return to the imagined golden age of lat/lon.