lat,lon argument order

[garborg]

The README has argument order mixed up (LLA(lat=x, lon=y, alt=z) and LatLon(lat=x, lon=y)). Is lon, lat a more common argument order in the external libraries we'll interface with and users will be familiar with?

[andyferris]

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?

[andyferris]

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

[c42f]

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

• "lat long" in casual situations, in my (admittedly somewhat limited) experience
• lat,lon,height as argument ordering in GeographicLib functions (which I'm generally very impressed with on a technical level), eg Geocentric::Forward.
• lon,lat,height as argument ordering to proj.4 functions (proj.4 is complete but rather old and crufty at this stage)
• lon,lat in serialization formats, eg geojson, kml (not sure about WKT I guess it's CRS-dependent)
• CRS-dependent (!) for OGC-compliant data interchange.

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!

[yeesian]

See also: http://www.macwright.org/lonlat/.

I'd argue for lonlat.

[c42f]

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:

• Somehow hide the positional LLA constructor, and replace with free functions latlonalt(lat, lon, alt) and lonlatalt(lon, lat, alt). Let people use the keyword constructor if they like.
• Hide the positional LLA constructor, and make people use keywords
• Change the name of LLA to LonLatAlt (or LatLonAlt as required).
• ... any others?

[andyferris]

ISO 6709 is an interesting read

https://en.wikipedia.org/wiki/ISO_6709