Open garborg opened 8 years ago
Hmm yes this is one we've puzzled over quite a lot.
People tend to talk about lat-lon while quite a few (certainly not all) geodesy libraries use lon-lat. Is the user more likely to be someone who has done Geodesy in other languages before? Or someone starting out or needing something relatively simple?
(The point of the keyword constructor is you can write LLA(lon=y, lat=x, alt=z)
if you prefer, and you will never need to get confused about the two "L"s in LLA
. The only potential problem is if you pass a pointer to the entire data structure).
Thoughts, @c42f?
People tend to talk about lat-lon while quite a few (certainly not all) geodesy libraries use lon-lat ... The only potential problem is if you pass a pointer to the entire data structure
Hmm... this leaves me with a thought. You might pass a pointer or data structure to a library that uses lon-lat order, but you probably won't pass a pointer to a human that thinks in lat-lon!! :) Perhaps between the field names, the keyword constructor, and the pretty REPL output a human wouldn't get confused, so there is a decent argument for switching the ordering for ABI compatibility...
Interesting point Andy, though what would we do we do about the non-keyword constructor? It's still going to be a point of confusion unless we get rid of it.
Regarding usage elsewhere, geodetic coordinates are
Geocentric::Forward
.OGC document on this: http://www.ogcnetwork.net/node/491
Basically, there's significant precedent for having it both ways; nobody can agree and it's all a bit terrible!
See also: http://www.macwright.org/lonlat/.
I'd argue for lonlat.
Right, the "just use a right handed system because math" and "serialization formats basically all do it this way" are powerful arguments in favour of lon,lat,height.
IMO the most powerful counter argument is that "lat long" is the colloquial standard.
Some (possibly bad) options to clarify the API:
latlonalt(lat, lon, alt)
and lonlatalt(lon, lat, alt)
. Let people use the keyword constructor if they like.LLA
to LonLatAlt
(or LatLonAlt
as required).ISO 6709 is an interesting read
The README has argument order mixed up (
LLA(lat=x, lon=y, alt=z)
andLatLon(lat=x, lon=y)
). Islon, lat
a more common argument order in the external libraries we'll interface with and users will be familiar with?