Definitely not a historian, and not a linguist either, but I wonder whether the reason for this could also just simply be that in English we like to arrange vowels in the order I, A, O (e.g. “tic tac toe” or “live laugh love”). By extension, the reason why we put latitude before longitude would then be that lat lon is easier to say than lon lat.
1 Like
CoordRefSystems.jl v0.1.3 has been released with all issues raised by @ettersi fixed, except for the issue on EastingNorthingUp coordinates. We will tackle it in the following months after we refactor downstream packages with real use cases.
4 Likes
Blockquote
Definitely not a historian, and not a linguist either, but I wonder whether the reason for this could also just simply be that in English we like to arrange vowels in the order I, A, O (e.g. “tic tac toe” or “live laugh love”). By extension, the reason why we put latitude before longitude would then be that lat lon is easier to say than lon lat.
It is pure coincidende
Why is the naming convention
Firstname Familyname in Western Culture
While In Chinese Culture it is
Familyname Firstname in Chinese Culture
Why do people in USA drive on the wrongside of the road while people in UK drive on the rightside of the road?
Thank you very much for your package. Does the datum/coordínate type allow to keep velocity information as well as position? If not, is it possible to extend the data types to perform full phase-space coordínate transformations if I do some reuse? I would apply to galactic dynamics. Thanks!
I believe that you can keep track of velocity with a wrapper type, right? What is the problem with
struct Object
position
velocity
end
?
2 Likes
Some writing on this topic here (from 2016):
There’s some consensus growing around longitude, latitude order for geospatial formats, but still chaos for libraries and software.
1 Like
Regarding the latlon vs. lonlat issue, that is the main reason why we didn’t use raw tuples or static vectors to represent coordinates. Instead, we defined our own structs in CoordRefSystems.jl with well-defined field names, regardless or order:
coord = LatLon(0, 0)
coord.lat
coord.lon
Same goes for Projected coordinates, which always have fields x and y.
2 Likes
Just to add my $0.02: Side-stepping the whole lat-lon vs lon-lat debate is the reason why MapMaths.jl exports both LatLon and LonLat types. In practical terms, I could imagine this being useful when you have to interact with external libraries and/or data formats, allowing you to e.g. do LonLat(coords...) instead of LatLon(reverse(coords)...).
That is something that we need to assess for sure. Right now the internal design is very clean with a single set of convert methods between LatLon and other CRS. If we add a new LonLat just to flip the coordinates, that means that we will have to duplicate all these methods, or write some wrapper code that treats both of them equally.
Alternatively, one can consider a constructor with kwargs as in LatLon(lon=0, lat=0) to swap the order.
good one.
If you include altitude in your position, then latitude-first gives you YXZ, which is nonsense.
and this one:
Almost all open source software uses longitude, latitude ordering. The only current exception is Leaflet3, which owes its ordering decision to the early-on goal of being very similar to the Google Maps SDK.
thanks for sharing.
I think the tricky bit here is that any unification attempts go beyond matching the APIs and gets into the differences in how each discipline handles things. CoordRefSystems.jl seems to be matching PROJ, while SkyCoords.jl tries to match astropy.SkyCoords. So trying to unify the APIs within Julia them may take away the benefit of unifying between the respective Julia and Python packages. Maybe there is work under-the-hood that could be matched, but it may not make sense to alter the APIs.
This also makes sense because there is typically very little need for heavy coordinate system transforms in much of astronomy, no datums (data?), no altitudes, etc. (Note I’m talking astronomy, not satellite astrodynamics which is a different ballgame.)
Astronomy is also (lon, lat), it’s just called (right ascension, declination) 
.
I don’t have strong feelings about which ordering is allegedly superior, but once the data is encoded into a struct with named fields lat and lon there really ceases to be any concept of ordering. There doesn’t seem to be any concept of a lonlat[1] and, other than the constructors, I don’t see any exported functions or anything else for which ordering is relevant.
If people actually do feel strongly about constructing in a desired order, I wonder if this could be addressed with a convenience function like LonLat(lon, lat) = LatLon(lat, lon). This wouldn’t require the introduction of a new type, and once created there’s little functional impact. My only hesitation with something like this is whether it introduces an unnecessary source of potential confusion since LonLat is really only a Function and not a Type, and can now be typo’d by a user who did intend to use LatLon.
2 Likes
On the lon/lat lat/lon question, EPSG codes actually specify this order - its not fixed either way in modern data sources.
Proj version 6 and onwards and R packages like sf follow this specification, but not everyone does and we are certainly not consistent with following it in julia.
So a problem we need to solve is reading/writing data from/to formats like Shapefile / GeoArrow etc and correcting the point order based on the projection.
Then maybe that function could just be called lonlat to be clear.
2 Likes
Currently, SkyCoords.jl implements n^2 transforms manually. Astropy does some fancy thing with finding any existing path in the coordinate system/transformation graph, that only requires defining O(n) transforms.
Would be nice to have stuff like this, especially if/when then number of implemented systems grows.
Not sure if these are comparable things to Earth systems, but in astronomy there are definitely many coordinate systems that differ by some parameter – typically, indexed by a kind of a date.
Well, there are distances from the Earth, in addition to coordinates on the sphere. And it does make total sense to take two coordinates that include distances, and compute the actual distance between them. Sounds similar to latitude, I guess…
SkyCoords.jl doesn’t implement this though.
2 Likes
(Without wanting to digress too far from the OP) Yeah, there is definitely a little overlap. I have worked both in the pure astronomy realm where everything is light-years away and the pure geospatial realm where everything is tied to locations on the Earth. It just seems to me that the conventions and needs of each discipline differ enough that it may not be worth the effort to think too deeply about a unified API.
Yeah, I could see that being a possible use.