11 ms·

Lat/Lon is really the standard. The fact that some software internally represents it as Lon/Lat doesn't mean it's not a settled issue. If you look up the coordi

by geokon 5y ago

Lat/Lon is really the standard. The fact that some software internally represents it as Lon/Lat doesn't mean it's not a settled issue. If you look up the coordinate of a location - it's always in Lat/Long. You can't rewrite all the books and change all the maps to make it nicer for programmers As the linked post says, Lon/Lat is generally easier to deal with b/c it matches to X/Y (and the North/Up way we look at maps). But you still have annoyances. For instance Lon goes 0-360 but Lat goes -90 to 90. This is also mathematically inconvenient Add on top of that the X-Y coordinate on images generally have the X flipped and starting at the top left corner. So changing to Lon/Lat doesn't fix everything. What I personally lean towards now is converting everything on read-in to a South/East coordinate system so it matches the flipped X-Y of images (like GeoTIFFs) and just always working in that system. Image manipulation, drawing to screen, output etc. - those systems/libraries I can't really modify myself. Everything else I can manipulate in whatever coordinate system I want. So it makes sense to choose the most convenient. Plus only dealing with positive coordinates is a big plus. That all said, I'm a total noob and I have no "geospatial" background (just writing some software to deal with rain data right now) So this isn't pro advice. I'd just be curious what others think

nwallin 5y ago
> Lat/Lon is really the standard. [...] That all said, I'm a total noob and I have no "geospatial" background (just writing some software to deal with rain data right now) So this isn't pro advice. The standard is X/Y+Spatial Reference. (the SR is usually out of band) If your spatial reference maps X to "latitude" and Y to "longitude", then so be it, but in general, I would expect a spatial reference which is applicable to an area that doesn't include the poles to map +X to East-ness and +Y to North-ness. (Spatial references near the poles get... interesting...) If your data doesn't have a spatial reference, then you don't have data, you have numbers. There are several reasons for this. First of all, there's the whole XY plane and all that. Secondly, there's also the fact that lat/lon/height coordinates, if you wish to preserve the right hand rule, translate to +north/+east/-up or north/east/down[0] coordinates, where elevations above sea level are negative, and the more you climb some mountain, the more negative your Z coordinate becomes. On the other hand, lon/lat/height becomes east/north/up, and the right hand rule is preserved. Source: this is my day job. https://en.wikipedia.org/wiki/North_east_down https://en.wikipedia.org/wiki/North_east_down
iampivot 5y ago
lat also sorts before lon, alphabetically. So easy to remember.
rendall 5y ago
> "Lat/Lon is really the standard." [citation needed]
- K0balt 5y ago
  ISO 6709 for starters.
  - rendall 5y ago
    I learnt something today. It does indeed appear to be a nearly universal standard. Thank you!
- smaudet 5y ago
  I think culturally lat/lon is the standard - it is what looked right to me before I started working with geocoords. Cartographically, in terms of standards, that seems to be the case. I don't think because libraries have been written which are backwards, that there should be some popularity contest - that's too small a bubble, just makes programmers sound like entitled asshats... Even a govt. standard should not be the measuring stick - govts change policy with the wind, or different govts. The lon/lat programmers with the pitchforks are the upstart rebels here... Lat/Lon
srl 5y ago
> For instance Lat goes 0-180 but Lon goes -90 to 90 Surely this is several typos? Longitude, which marks east-west, must span 360 degrees (-180 to 180, perhaps? although 0 to 360 is just as reasonable). Latitude, marking north-south, spans only 180 degrees, and therefore is presumably -90 to 90 (so that 0 is the equator).
- geokon 5y ago
  yes, typo. Thanks for catching that. edited it to match
- jbverschoor 5y ago
  Cool.. So now I can finally remember. Longitude is LONGer because it goes all the way around.. LATitude I dunno.. is like a latte filling up?
  - jounker 5y ago
    The lateral line on a fish goes from head to tail. :)
  - nieve 5y ago
    Try thinking of it like latitude being like a ladder's rungs. Though this does have the horrifying side effect that sometimes you'll pronounce it laddertude in your head.
  - jrib 5y ago
    Latitude Altitude Vertical If I ever need to confirm which is which, I use the the mnemonic above. I usually imagine latitude corresponding to rings on the earth moving up and down along the surface. This image is triggered by thinking about "altitude" in the context of latitude for me. The latitude defines which of these "rings" the point is on. https://cdn.britannica.com/07/64907-050-7ACA69C8/Facts-parallels-Lines-of-Latitude-angles-direction.jpg https://cdn.britannica.com/07/64907-050-7ACA69C8/Facts-paral...
  - cerved 5y ago
    lat is swedish for lazy, so I remember it as laying down, ie horizontal
tomjakubowski 5y ago
It's not just about internal representations. Web APIs and geospatial data formats specify them either way. You can't get away from the ambiguity unless you carefully choose the API and data format to match the order you like. (and pray that anyone providing you with data is aware of the choice made by your preferred formats)
- deleted 5y ago
  [deleted]
tomrod 5y ago
Hey I've been working on geodata in several contexts for about 5 years now and I completely agree with you! You may be "noob" but your observations match mine to a T.
- geokon 5y ago
  Thanks for the sanity check I have a dirty prototype I need to rewrite soon so I was considering a coordinate system change. It'd make debugging much easier if the values drawn and the values of the coordinates had the same "directions" I was a bit apprehensive to just yolo my own internal coordinate system bc it's a design decision you end up having to live with
  - tomrod 5y ago
    I tend to roll with GeoJSON and the language's equivalent of a map/dict.
cozzyd 5y ago
yeah, lat/lon/alt is more common, but I like lon/lat for the same reason you do (you can plot lon=x, lat=y and get a crappy Mercator projection). I also often work with stereographic coordinates a lot which uses x-y, and that also colors my perception.
- geokon 5y ago
  My point was that simply flipping lat/lon to be lon/lat is a cheap fix that still leaves you with problems. What I propose is to go "all the way" and make an internal positive/unsigned South/East coordinate system that naturally matches the display coordinate system (the inverted X-Y). It's sufficiently different that you'll never get confused and flip things at API boundaries. It's also sufficiently weird that you won't expose it to others :)
  - cozzyd 5y ago
    Well, display coordinates are different from typical plot coordinates in any standard plotting package (of course, many plotting packages also support GIS, sort of making this a moot point). Yeah, if you're going to display coordinates you'll have extra problems.
    - geokon 5y ago
      It's not a moot point because you wanna debug stuff :) If things are looking weird or wrong on your display then you need to go back to your internal values to inspect what's wrong. When the internal value covary with th display values then this makes life significantly easier Not to mention things have a tendency to blow up when you start testing in the southern hemisphere haha That said.. I don't personally use any magic plotting packages. I just generate my own graphics with svg. It's quite easy and everything is debuggable
- xvedejas 5y ago
  lon=x, lat=y is not Mercator at all, it gives the "equirectangular" projection. This has none of the nice properties of Mercator (angles are heavily distorted).
GauntletWizard 5y ago
Graphics libraries and windowing systems almost universally map (x, -y) - That is, Y=0 is at the top of your screen and Y=MAX is at the bottom, making Y coordinates backwards from conventional plotting graphs. X is standard. But talking about it is hard, even graphics programmers I know regularly make the same polarity mistakes one time out of ten, like you post originally had lat and long reversed in ranges (but used correctly elsewhere). Just be glad we don't universally use Minecraft XYZ coordinates.
- geokon 5y ago
  right，an internal rezeroed south east system makes it match the graphics system. So pixel positions and coordinates covary and are always positive. It makes debugging a million times easier More radical would be to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around. You'd have the range wrap around naturally. But it's nice to have degrees for debugging and it's not tied to a type so you can have arbitrary precision. I also think you'd still have corner cases to deal with (but I'll have to think about this some more)
  - iopq 5y ago
    Why not signed?
    - geokon 5y ago
      yeah, good question. My limited experience has shown me that you end up coding in assumptions that make the sign flip problematic :). There are all those infamous cases of systems crashing on planes and ships when they cross the equator. Ideally you'd test in all four quadrants of the globe but this ends up being cumbersome. There is also the convenience of having your coordinates change in the same way as your display coordinates. So if something displays off of where it should then you can easily diagnose the problem. Everything is always in units of degrees relative to the top left corner (with maybe a scale factor) - whether you're looking at the whole globe or just a region. With a signed coordinate you'd be relative to the image center which is not how your display works. You need to track offsets and image widths/heights. Debugging gets nastier and you have off by one problems and whatnot. That's just been my experience so far
jandrewrogers 5y ago
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).
bjeds 5y ago
I think you are thinking about this in the wrong way. Sure Lat/Lon is the common presentation format for this particular coordinate system. Right now in Sweden the time is 10:41 (it would be great if it was a couple of hours later, then I could say it's 14:41 to demonstrate the 24 hour time format). Yet, in software, I would represent that as time in UTC. Only when presenting to the user would I convert that to the users time zone. My last name contain the letter "ö". In software, I would use an unicode string internally, then when writing out I would encoded that to utf-8. (20 years ago, I would have used an old character encoding called ISO/IEC 8859-1 or something like that, but you get my point). For some damn reason I till don't understand, the decimal separator in Sweden is the comma and not the period. Still I would represent numbers internally as an integer or maybe float, and then when printing to to the user would I convert that to "123,4" (123.4) or something like that. In Sweden, WGS84 is not the only common coordinate system. There are many others: SWEREF and SWEREF TM for example. Yes internally, depending on usecase, I would probably use a representation of WGS84 as reference, then convert that to present to the user... This is how I think about coordinates.
- Pinus 5y ago
  (Fellow Swede here). I really want to agree with you, but in practice, the difference between "internal" and "external" is not always clear. For example, if I was producing a printed document in Swedish, I would definitely use decimal commas. (By the way, the time now is not 10:54 — it's 10.54, if you are to believe "Svenska Skrivregler" :-) ) However, when printing output in a terminal window, a comma means that I can't copy-paste that number into that interactive Python session in another window. Coordinates as lat, lon means I can't copy-paste into PostGIS. Makes one long for those LISP systems of the legends, where the system kept track of where things on screen came from, so if the program printed a coordinate and you copied it from the terminal, it was copied as a coordinate, not as text...
- geokon 5y ago
  So this is sorta above my pay grade but I think this is a tangential issue. Even if you are reading exotic data in some parochial format you internally probably wanna use one consistent format. If you have some massive data sets and don't wanna convert on read-in then there are way around that (you can setup a memoization system to convert and cache on as-needed basis). This format should be intuitive and convenient. I proposed a South/East format.. but you're free to choose whatever you want here. But the point is that Lon/Lat is likely never a good choice at this junction. It still has issues and you generally can do better. At the interface the default we've arrived to as a society Lat/Lon WGS84 :) The merits here are irrelevant. If you want to support other i/o formats then you may. That really depends on your usecases - but they shouldn't map to whatever format you've decided on internally. And even if they did, you probably shouldn't be using Lon/Lat internally anyway
fanf2 5y ago
The numbers in British National Grid references are eastings then northings, so lat lon isn’t universal in national mapping standards.
harshreality 5y ago
Internal representation isn't the issue. Software can internally represent coordinates any way that's consistent (and so bug-free). The conflict is about interfaces, specifically interfaces using unlabeled number pairs, between software and humans, or software and other software. It's unfortunate that anyone would implement software with lat/long inputs/outputs, and think that they have the privilege of defining that order however suits them; what they obviously should do, and should have done, is take a moment to think, "How have people communicated earth coordinates in the past? Are there any standards that might be applicable?" and used that order. Of course, if tradition and standards were bad for some objective reason, that might justify it. But not just because some programmer wants to export their way of dealing with coordinates in x, y coordinate order from a cylindrical projection. That's not sufficient reason to upend tradition and introduce confusion and ambiguity in cases of |longitude| <= 90°.
webreac 5y ago
I work as contractor for EUROCONTROL. 90% of the time, the usual order (Lat/long) is used in software. When this is not the case, it is a good indicator that I need to be careful about the conventions used to represent all data. I have already encountered the reversed wind direction and more frequently the use of m/s instead of knots (for wind speed).
- supergarfield 5y ago
  Aren't m/s the correct unit for wind speed? https://en.m.wikipedia.org/wiki/Wind_speed https://en.m.wikipedia.org/wiki/Wind_speed > Meters per second (m/s) is the SI unit for velocity and the unit recommended by the World Meteorological Organization for reporting wind speeds > Since 2010 the International Civil Aviation Organization (ICAO) also recommends meters per second for reporting wind speed when approaching runways
  - ocyj 5y ago
    A typical case of the governing body decides one thing but in practice the "since-always" used convention is still preferred I guess? At least this is my experience with dealing with reqs from customers within aviation.
  - Leherenn 5y ago
    Well, if the aircraft speed is in knots (which is generally the case), you'd rather have wind speeds in the same unit.
    - icholy 5y ago
      It's easier to store and process everything in SI units and then convert to the user's preferred unit in the presentation layer.
      - nemetroid 5y ago
        As a rule, yes, but not necessarily and not everywhere. The important part is to have a coherent set of units, which usually is going to be SI units, but not always. If the user's preferred unit never is going to be SI, does it make sense to base your program on SI units? For example, aviation deals heavily in flight levels (multiples of 100 ft). If flight levels are a first-class concept in your program, then you're already using non-SI units below the presentation layer. At this point you've established that some altitudes in your program are expressed in feet, and it might be a better idea to use feet for altitudes everywhere rather than introducing a lot of unit conversions. Or it might not be.
marcosdumay 5y ago
Just a small detail, but longitude goes from -180 to 180. Or, if you use the hemisphere abbreviations, 180W to 180E.
NelsonMinar 5y ago
It is striking that the top response to a thoughtful, nuanced article about coordinates written by an expert in geospatial systems is someone who boldly declares "X is the standard" and concludes with "I'm a total noob".
- tomrod 5y ago
  Indeed. I appreciate the self-deprecation of the person recognizing they aren't an expert but are in the space anyhow. Usually Dunning-Kruger is present.
deleted 5y ago
[deleted]
beerandt 5y ago
>Add on top of that the X-Y coordinate on images generally have the X flipped and starting at the top left corner. So changing to Lon/Lat doesn't fix everything. Oversimplified... but: Most raw/original geo-referenced imagery in the US are projected in a SPCS (state plane coordinate system) in survey-feet, which aren't defined in x,y but n,e (Northing, Easting) or sometimes e,n. This order isn't as universal as x,y, for various reasons. (UTM in meters is also common for larger areas.) SPCSs aren't all the same type of projections, so Lambert conic (parallel defined) vs Transverse Mercator (meridian defined) (the two most common) means the "first" measurement traversed isn't always the same. (On a sphere, if I tell you to go 100 miles north, then 100 miles east, you get to a different point than 100 miles east, then 100 miles north.) Being grid systems, this shouldn't matter, but surveyors who used to do manual transformations would get in the habit of the order they regularly used. So "flipped" is a matter of perspective. It's one of those things that's a tell for someones educational background and localisms. Surveyor/Geographer/Geodesist vs Scientist/Mathematician/Software Developer. Did a progammer-first person develop a particular file format, or did a cartography/geography-first person? Or some combination of a compromise? >I have no "geospatial" background Checks out. If you're a learn-by-doing person, I recommend looking up the transformations for a few common CRS/datums/projections and going through the equations manually, either with a quick script or in excel. Check/compare to results from the NGS tools page. The transform steps and math will reveal where order of operations matter. https://www.ngs.noaa.gov/ https://www.ngs.noaa.gov/ https://geodesy.noaa.gov/NCAT/ https://geodesy.noaa.gov/NCAT/ https://geodesy.noaa.gov/INFO/datums-transformations.shtml https://geodesy.noaa.gov/INFO/datums-transformations.shtml
- geokon 5y ago
  Err, sorry I have a typo in my original post. The Y is "flipped" (not X). I feel a Northing Easting system should appeal to both surveyors and mathematicians b/c it matches the X-Y plane we're used to in math class. But unfortunately it doesn't match display coordinates which conventionally start in the upper left corner. If I output say an SVG and it's got some weird artifact or things are cropped strange due to some off-by-one errors then it's much easier to debug if your internal geographic coordinates are aligned to the final display coordinates. You don't need to do any mental translation and offsetting to figure out how the values correspond between the two systems In fact I go so far as to output SVGs with degrees values (degrees relative to the upper left point) and then there is a global scale factor for the final image to fit whatever size I want - so the image units are in real degrees - this makes life a lot easier. After reading all the responsese here my argument would be that you should use whatever internal representation is most convenient programmatically - and then you expose in your API or UI or whatever a system based on other criteria (though it's hard to see how lon/lat would ever be sensible here). Your internal and external systems don't have to have any relation. As you've deduced my problem space isn't too concerned with projections at the moment. Both precipitation and elevation data comes in a GeoTIFF (ie. lat/lon grid). In fact doing any kind of projections would distort by grid and greatly complicate my life :) But it's something I will keep in mind. When you start looking at large areas then you effectively have different data densities at different ends of the region and this is not great (poleward things have disproportionately more data). Thanks for the extra information and references - it may come in handy eventually.

by geokon 5y ago

nwallin 5y ago

> Lat/Lon is really the standard. [...] That all said, I'm a total noob and I have no "geospatial" background (just writing some software to deal with rain data right now) So this isn't pro advice. The standard is X/Y+Spatial Reference. (the SR is usually out of band) If your spatial reference maps X to "latitude" and Y to "longitude", then so be it, but in general, I would expect a spatial reference which is applicable to an area that doesn't include the poles to map +X to East-ness and +Y to North-ness. (Spatial references near the poles get... interesting...) If your data doesn't have a spatial reference, then you don't have data, you have numbers. There are several reasons for this. First of all, there's the whole XY plane and all that. Secondly, there's also the fact that lat/lon/height coordinates, if you wish to preserve the right hand rule, translate to +north/+east/-up or north/east/down[0] coordinates, where elevations above sea level are negative, and the more you climb some mountain, the more negative your Z coordinate becomes. On the other hand, lon/lat/height becomes east/north/up, and the right hand rule is preserved. Source: this is my day job. https://en.wikipedia.org/wiki/North_east_down https://en.wikipedia.org/wiki/North_east_down

iampivot 5y ago

lat also sorts before lon, alphabetically. So easy to remember.

rendall 5y ago

> "Lat/Lon is really the standard." [citation needed]

K0balt 5y ago
ISO 6709 for starters.
- rendall 5y ago
  I learnt something today. It does indeed appear to be a nearly universal standard. Thank you!
smaudet 5y ago
I think culturally lat/lon is the standard - it is what looked right to me before I started working with geocoords. Cartographically, in terms of standards, that seems to be the case. I don't think because libraries have been written which are backwards, that there should be some popularity contest - that's too small a bubble, just makes programmers sound like entitled asshats... Even a govt. standard should not be the measuring stick - govts change policy with the wind, or different govts. The lon/lat programmers with the pitchforks are the upstart rebels here... Lat/Lon

srl 5y ago

> For instance Lat goes 0-180 but Lon goes -90 to 90 Surely this is several typos? Longitude, which marks east-west, must span 360 degrees (-180 to 180, perhaps? although 0 to 360 is just as reasonable). Latitude, marking north-south, spans only 180 degrees, and therefore is presumably -90 to 90 (so that 0 is the equator).

geokon 5y ago
yes, typo. Thanks for catching that. edited it to match
jbverschoor 5y ago
Cool.. So now I can finally remember. Longitude is LONGer because it goes all the way around.. LATitude I dunno.. is like a latte filling up?
- jounker 5y ago
  The lateral line on a fish goes from head to tail. :)
- nieve 5y ago
  Try thinking of it like latitude being like a ladder's rungs. Though this does have the horrifying side effect that sometimes you'll pronounce it laddertude in your head.
- jrib 5y ago
  Latitude Altitude Vertical If I ever need to confirm which is which, I use the the mnemonic above. I usually imagine latitude corresponding to rings on the earth moving up and down along the surface. This image is triggered by thinking about "altitude" in the context of latitude for me. The latitude defines which of these "rings" the point is on. https://cdn.britannica.com/07/64907-050-7ACA69C8/Facts-parallels-Lines-of-Latitude-angles-direction.jpg https://cdn.britannica.com/07/64907-050-7ACA69C8/Facts-paral...
- cerved 5y ago
  lat is swedish for lazy, so I remember it as laying down, ie horizontal

tomjakubowski 5y ago

It's not just about internal representations. Web APIs and geospatial data formats specify them either way. You can't get away from the ambiguity unless you carefully choose the API and data format to match the order you like. (and pray that anyone providing you with data is aware of the choice made by your preferred formats)

deleted 5y ago
[deleted]

tomrod 5y ago

Hey I've been working on geodata in several contexts for about 5 years now and I completely agree with you! You may be "noob" but your observations match mine to a T.

geokon 5y ago
Thanks for the sanity check I have a dirty prototype I need to rewrite soon so I was considering a coordinate system change. It'd make debugging much easier if the values drawn and the values of the coordinates had the same "directions" I was a bit apprehensive to just yolo my own internal coordinate system bc it's a design decision you end up having to live with
- tomrod 5y ago
  I tend to roll with GeoJSON and the language's equivalent of a map/dict.

cozzyd 5y ago

yeah, lat/lon/alt is more common, but I like lon/lat for the same reason you do (you can plot lon=x, lat=y and get a crappy Mercator projection). I also often work with stereographic coordinates a lot which uses x-y, and that also colors my perception.

geokon 5y ago
My point was that simply flipping lat/lon to be lon/lat is a cheap fix that still leaves you with problems. What I propose is to go "all the way" and make an internal positive/unsigned South/East coordinate system that naturally matches the display coordinate system (the inverted X-Y). It's sufficiently different that you'll never get confused and flip things at API boundaries. It's also sufficiently weird that you won't expose it to others :)
- cozzyd 5y ago
  Well, display coordinates are different from typical plot coordinates in any standard plotting package (of course, many plotting packages also support GIS, sort of making this a moot point). Yeah, if you're going to display coordinates you'll have extra problems.
  - geokon 5y ago
    It's not a moot point because you wanna debug stuff :) If things are looking weird or wrong on your display then you need to go back to your internal values to inspect what's wrong. When the internal value covary with th display values then this makes life significantly easier Not to mention things have a tendency to blow up when you start testing in the southern hemisphere haha That said.. I don't personally use any magic plotting packages. I just generate my own graphics with svg. It's quite easy and everything is debuggable
xvedejas 5y ago
lon=x, lat=y is not Mercator at all, it gives the "equirectangular" projection. This has none of the nice properties of Mercator (angles are heavily distorted).

GauntletWizard 5y ago

Graphics libraries and windowing systems almost universally map (x, -y) - That is, Y=0 is at the top of your screen and Y=MAX is at the bottom, making Y coordinates backwards from conventional plotting graphs. X is standard. But talking about it is hard, even graphics programmers I know regularly make the same polarity mistakes one time out of ten, like you post originally had lat and long reversed in ranges (but used correctly elsewhere). Just be glad we don't universally use Minecraft XYZ coordinates.

geokon 5y ago
right，an internal rezeroed south east system makes it match the graphics system. So pixel positions and coordinates covary and are always positive. It makes debugging a million times easier More radical would be to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around. You'd have the range wrap around naturally. But it's nice to have degrees for debugging and it's not tied to a type so you can have arbitrary precision. I also think you'd still have corner cases to deal with (but I'll have to think about this some more)
- iopq 5y ago
  Why not signed?
  - geokon 5y ago
    yeah, good question. My limited experience has shown me that you end up coding in assumptions that make the sign flip problematic :). There are all those infamous cases of systems crashing on planes and ships when they cross the equator. Ideally you'd test in all four quadrants of the globe but this ends up being cumbersome. There is also the convenience of having your coordinates change in the same way as your display coordinates. So if something displays off of where it should then you can easily diagnose the problem. Everything is always in units of degrees relative to the top left corner (with maybe a scale factor) - whether you're looking at the whole globe or just a region. With a signed coordinate you'd be relative to the image center which is not how your display works. You need to track offsets and image widths/heights. Debugging gets nastier and you have off by one problems and whatnot. That's just been my experience so far

jandrewrogers 5y ago

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).

bjeds 5y ago

I think you are thinking about this in the wrong way. Sure Lat/Lon is the common presentation format for this particular coordinate system. Right now in Sweden the time is 10:41 (it would be great if it was a couple of hours later, then I could say it's 14:41 to demonstrate the 24 hour time format). Yet, in software, I would represent that as time in UTC. Only when presenting to the user would I convert that to the users time zone. My last name contain the letter "ö". In software, I would use an unicode string internally, then when writing out I would encoded that to utf-8. (20 years ago, I would have used an old character encoding called ISO/IEC 8859-1 or something like that, but you get my point). For some damn reason I till don't understand, the decimal separator in Sweden is the comma and not the period. Still I would represent numbers internally as an integer or maybe float, and then when printing to to the user would I convert that to "123,4" (123.4) or something like that. In Sweden, WGS84 is not the only common coordinate system. There are many others: SWEREF and SWEREF TM for example. Yes internally, depending on usecase, I would probably use a representation of WGS84 as reference, then convert that to present to the user... This is how I think about coordinates.

Pinus 5y ago
(Fellow Swede here). I really want to agree with you, but in practice, the difference between "internal" and "external" is not always clear. For example, if I was producing a printed document in Swedish, I would definitely use decimal commas. (By the way, the time now is not 10:54 — it's 10.54, if you are to believe "Svenska Skrivregler" :-) ) However, when printing output in a terminal window, a comma means that I can't copy-paste that number into that interactive Python session in another window. Coordinates as lat, lon means I can't copy-paste into PostGIS. Makes one long for those LISP systems of the legends, where the system kept track of where things on screen came from, so if the program printed a coordinate and you copied it from the terminal, it was copied as a coordinate, not as text...
geokon 5y ago
So this is sorta above my pay grade but I think this is a tangential issue. Even if you are reading exotic data in some parochial format you internally probably wanna use one consistent format. If you have some massive data sets and don't wanna convert on read-in then there are way around that (you can setup a memoization system to convert and cache on as-needed basis). This format should be intuitive and convenient. I proposed a South/East format.. but you're free to choose whatever you want here. But the point is that Lon/Lat is likely never a good choice at this junction. It still has issues and you generally can do better. At the interface the default we've arrived to as a society Lat/Lon WGS84 :) The merits here are irrelevant. If you want to support other i/o formats then you may. That really depends on your usecases - but they shouldn't map to whatever format you've decided on internally. And even if they did, you probably shouldn't be using Lon/Lat internally anyway

fanf2 5y ago

The numbers in British National Grid references are eastings then northings, so lat lon isn’t universal in national mapping standards.

harshreality 5y ago

Internal representation isn't the issue. Software can internally represent coordinates any way that's consistent (and so bug-free). The conflict is about interfaces, specifically interfaces using unlabeled number pairs, between software and humans, or software and other software. It's unfortunate that anyone would implement software with lat/long inputs/outputs, and think that they have the privilege of defining that order however suits them; what they obviously should do, and should have done, is take a moment to think, "How have people communicated earth coordinates in the past? Are there any standards that might be applicable?" and used that order. Of course, if tradition and standards were bad for some objective reason, that might justify it. But not just because some programmer wants to export their way of dealing with coordinates in x, y coordinate order from a cylindrical projection. That's not sufficient reason to upend tradition and introduce confusion and ambiguity in cases of |longitude| <= 90°.

webreac 5y ago

I work as contractor for EUROCONTROL. 90% of the time, the usual order (Lat/long) is used in software. When this is not the case, it is a good indicator that I need to be careful about the conventions used to represent all data. I have already encountered the reversed wind direction and more frequently the use of m/s instead of knots (for wind speed).

supergarfield 5y ago
Aren't m/s the correct unit for wind speed? https://en.m.wikipedia.org/wiki/Wind_speed https://en.m.wikipedia.org/wiki/Wind_speed > Meters per second (m/s) is the SI unit for velocity and the unit recommended by the World Meteorological Organization for reporting wind speeds > Since 2010 the International Civil Aviation Organization (ICAO) also recommends meters per second for reporting wind speed when approaching runways
- ocyj 5y ago
  A typical case of the governing body decides one thing but in practice the "since-always" used convention is still preferred I guess? At least this is my experience with dealing with reqs from customers within aviation.
- Leherenn 5y ago
  Well, if the aircraft speed is in knots (which is generally the case), you'd rather have wind speeds in the same unit.
  - icholy 5y ago
    It's easier to store and process everything in SI units and then convert to the user's preferred unit in the presentation layer.
    - nemetroid 5y ago
      As a rule, yes, but not necessarily and not everywhere. The important part is to have a coherent set of units, which usually is going to be SI units, but not always. If the user's preferred unit never is going to be SI, does it make sense to base your program on SI units? For example, aviation deals heavily in flight levels (multiples of 100 ft). If flight levels are a first-class concept in your program, then you're already using non-SI units below the presentation layer. At this point you've established that some altitudes in your program are expressed in feet, and it might be a better idea to use feet for altitudes everywhere rather than introducing a lot of unit conversions. Or it might not be.

marcosdumay 5y ago

Just a small detail, but longitude goes from -180 to 180. Or, if you use the hemisphere abbreviations, 180W to 180E.

NelsonMinar 5y ago

It is striking that the top response to a thoughtful, nuanced article about coordinates written by an expert in geospatial systems is someone who boldly declares "X is the standard" and concludes with "I'm a total noob".

tomrod 5y ago
Indeed. I appreciate the self-deprecation of the person recognizing they aren't an expert but are in the space anyhow. Usually Dunning-Kruger is present.

deleted 5y ago

[deleted]

beerandt 5y ago

>Add on top of that the X-Y coordinate on images generally have the X flipped and starting at the top left corner. So changing to Lon/Lat doesn't fix everything. Oversimplified... but: Most raw/original geo-referenced imagery in the US are projected in a SPCS (state plane coordinate system) in survey-feet, which aren't defined in x,y but n,e (Northing, Easting) or sometimes e,n. This order isn't as universal as x,y, for various reasons. (UTM in meters is also common for larger areas.) SPCSs aren't all the same type of projections, so Lambert conic (parallel defined) vs Transverse Mercator (meridian defined) (the two most common) means the "first" measurement traversed isn't always the same. (On a sphere, if I tell you to go 100 miles north, then 100 miles east, you get to a different point than 100 miles east, then 100 miles north.) Being grid systems, this shouldn't matter, but surveyors who used to do manual transformations would get in the habit of the order they regularly used. So "flipped" is a matter of perspective. It's one of those things that's a tell for someones educational background and localisms. Surveyor/Geographer/Geodesist vs Scientist/Mathematician/Software Developer. Did a progammer-first person develop a particular file format, or did a cartography/geography-first person? Or some combination of a compromise? >I have no "geospatial" background Checks out. If you're a learn-by-doing person, I recommend looking up the transformations for a few common CRS/datums/projections and going through the equations manually, either with a quick script or in excel. Check/compare to results from the NGS tools page. The transform steps and math will reveal where order of operations matter. https://www.ngs.noaa.gov/ https://www.ngs.noaa.gov/ https://geodesy.noaa.gov/NCAT/ https://geodesy.noaa.gov/NCAT/ https://geodesy.noaa.gov/INFO/datums-transformations.shtml https://geodesy.noaa.gov/INFO/datums-transformations.shtml

geokon 5y ago
Err, sorry I have a typo in my original post. The Y is "flipped" (not X). I feel a Northing Easting system should appeal to both surveyors and mathematicians b/c it matches the X-Y plane we're used to in math class. But unfortunately it doesn't match display coordinates which conventionally start in the upper left corner. If I output say an SVG and it's got some weird artifact or things are cropped strange due to some off-by-one errors then it's much easier to debug if your internal geographic coordinates are aligned to the final display coordinates. You don't need to do any mental translation and offsetting to figure out how the values correspond between the two systems In fact I go so far as to output SVGs with degrees values (degrees relative to the upper left point) and then there is a global scale factor for the final image to fit whatever size I want - so the image units are in real degrees - this makes life a lot easier. After reading all the responsese here my argument would be that you should use whatever internal representation is most convenient programmatically - and then you expose in your API or UI or whatever a system based on other criteria (though it's hard to see how lon/lat would ever be sensible here). Your internal and external systems don't have to have any relation. As you've deduced my problem space isn't too concerned with projections at the moment. Both precipitation and elevation data comes in a GeoTIFF (ie. lat/lon grid). In fact doing any kind of projections would distort by grid and greatly complicate my life :) But it's something I will keep in mind. When you start looking at large areas then you effectively have different data densities at different ends of the region and this is not great (poleward things have disproportionately more data). Thanks for the extra information and references - it may come in handy eventually.