Lon Lat Lon Lat

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

Turns out, we did not pin the pyproj library [1] and they introduced a switch from lon-lat to lat-lon order, per default.

It was possible to retain the old behavior with `always_xy: bool = False`. I saw hundrets of similar reports, who knows how many users were effected. Conclusions, a) Always pin your dependencies, b) explicit is better than implicit.

Besides, I have a personal, subjective preference for lon-lat, but I understood the lat-lng order to be the officially accepted norm.

[1]: https://pyproj4.github.io/pyproj/stable/api/proj.html

I get the order wrong when working with geojson with embarrassing frequency...

http://www.macmillandictionaryblog.com/a-hotchpotch-of-redup...

This is converted to latitude and longitude from GPS using the WGS-84 standard, at least for the western world. Russia uses the PZ-90 reference frame for GLONASS. China uses the BeiDou coordinate system. There's also an obfuscated latitude and longitude used by China for public consumption, GCJ-02. This introduces an error of 100 to 700 meters. Not that anyone is fooled; the obfuscation algorithm is known.

But everybody uses the same ECEF 3D coordinates, and combining satellite data is done in that frame. So if you need precise locations, there's something to be said for working in ECEF.

Furthermore there is the distinction between "geodetic" latitude ϕ (without qualification): the angle between the normal and the equatorial plane - this should be given with a specification of the ellipsoid and "geocentric" or "spherical" latitude θ (or ψ, q, ϕ′, ϕc, ϕg): the angle between the radius and the equatorial plane. (Figure below).

Quoting from https://en.wikipedia.org/wiki/Latitude :

"The importance of specifying the reference datum may be illustrated by a simple example. On the reference ellipsoid for WGS84, the centre of the Eiffel Tower has a geodetic latitude of 48° 51′ 29″ N, or 48.8583° N and longitude of 2° 17′ 40″ E or 2.2944°E. The same coordinates on the datum ED50 define a point on the ground which is 140 metres (460 feet) distant from the tower.[citation needed] A web search may produce several different values for the latitude of the tower; the reference ellipsoid is rarely specified."

Whereas confusing lat/lon order usually is noticed as a bug because some points end up in an ocean or close to the poles, use of the wrong datum (reference surface) leads to more subtle errors (as the above example shows) and is therefore more likely to go undetected. What I recommend is to use test cases with well-known points and check in your GIS processing pipelines that a few test locations are still where you expect them to be at certain check points in your process.

Is negative longitude even legal?

Jokes aside, it is always (lat, lon). Latitude is a universal value, while longitude was not just about 100 years ago: every country had its own zero meridian. When finding coordinates we are first measuring a sun angle above the horizon at local noon, that gives us a latitude. Longitude is just a time difference between zero meridian noon and local noon.

Lat Lon makes more sense when the programmer organizes the way they think about geography in a more astronomical or climate-centric way first, by sun exposure. The first thing you know when given Latitude is north/south hemisphere, what season the target is in, and roughly (although depending on land masses and bodies of water and terrain) what the climate is probably like.

Lat/Lon is the traditional and historical standard way of expressing location. Why are programmers treating it as if it's a new, unsettled question, and deciding for themselves which order to use for their software?

Interesting that both WMS and WFS changed to lat/long in later versions of their specs. Maybe more people could take the hint.

One nice feature with Kotlin is using extension functions and extension properties on type aliases. I use this a lot in my library. So, I can represent points using a DoubleArray, which is a specialized primitive array type.

I defined a typealias PointCoordinates = DoubleArray, and then have extension properties defined on like:

val PointCoordinates.latitude: Double get() = this[1]

The compiler inlines all of that of course so it's all simple array manipulation. But it looks like an object. And I get to avoid the longitude/latitude confusion. Another nice language feature that I use a lot is named parameters on functions. Nothing worse than somebody calling f(lat,lon) when they should have called f(lon,lat). Much less confusing if you call f(latitude: lat, longitude: lon).

"Geographical tradition favors lat, lon. Math and software prefer lon, lat."

But why does math and software prefer lon, lat? Unlike endianness, where it appears little-endian is the better choice at the hardware level, I'm drawing a blank why one ordering is better for computation.

is it:

  [xmin ymin xmax ymax]
  [xmin ymin width height]
  [xcenter ycenter width height]
  # all of the above but in normalized [0,1] not pixel coordinates

I had always thought math prefers lat, lon ...well not lat (which is the altitude angle) but polar angle. But anyway, this order: polar, azimuth. Turns out I have been getting all my spherical coordinates math from physics, which uses polar, azimuth. But math uses azimuth, polar.

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

But then again: Where does math even use spherical coordinates that is not physics related?

It never happens that you try to generate {X} from {Lon} alone.

    def LatLon_to_GoogleTiles(lat, lon, zoom):
        lat_rad = math.radians(lat)
        n = 2.0 ** zoom
        xtile = int((lon + 180.0) / 360.0 * n)
        ytile = int((1.0 - math.log(math.tan(lat_rad) + (1 / math.cos(lat_rad))) / math.pi) / 2.0 * n)
        return (xtile, ytile)

Aside: If you are using a modern language (like C#) you can just use parameter labels and avoid this whole mess by being explicit each time. Underscores as separators in numeric literals are also pretty neat if you ever need to hard-code a scale or lat/lon for some reason.

Some of the libraries under complaint only support WGS84 (basically what anyone using GPS thinks of when they say lat/lon). If you have never seen a coordinate from anything other than GPS or Google Maps, then it would seem strange that someone would expect coordinates in x,y.

Other libraries support a wide variety, including projected (rather than geographic) coordinate systems where x,y is more appropriate (WebMercator, for example). Libraries like Google Maps never expose the underlying xy coordinates, but others will.

State plane coordinates, for example of widely-used xy system: https://en.m.wikipedia.org/wiki/State_Plane_Coordinate_Syste...

More info on projected/Cartesian coordinates vs geographic/spherical coordinates:

https://www.esri.com/arcgis-blog/products/arcgis-pro/mapping...

So, every time I get the lat/lon order wrong around here. I get a brief trip to Antarctica.

It's important when hacking this kind of data (or any data) to develop at least some sense for what it means. If there's an error in the data, you want to be able to think, wait, that isn't right, that's in the Atlantic someplace east of Cape Hatteras (or whatever).

And, of course, when using map products like USGS quads or UK Ordnance Survey maps we use those mapping agencies' coordinate systems, be they US State Plane projects, Universal Transverse Mercator, or whatever.

I inherited one app for USA use where the original developer decided the longitude values should be positive rather than negative. Wait, what? Kazakhstan? Must be wrong.

Like any physical measurement, lat/lon makes some kind of physical sense. Unlike many measurements, lat/lon has some constraints. For example you know a priori a latitude of +130° is bogus.

I always say "lat/lon", it sounds better in english. Just like click-clack, zig-zag, criss-cross, ding dong, king kong. It feels like one of these rules but I can't put my finger on it: https://www.bbc.com/culture/article/20160908-the-language-ru...

On the other hand, if thinking about them as x and y then x is longitude so it naturally comes first.

In the military I learned the rule lon then lat and was taught to think of an elevator: first you step sideways in to the elevator (lon), then you go up or down (lat).

"fi fy fo fum" "friend or foe?" etc

Why aren't we using some self-explanatory terms?

I propose "rotitude", "iclinitude". Guess which is which.

In any kind of graphic design work if you're communicating with printers, pre-press, etc. you say Width x Height. Like paper size. 8.5" x 11". But once in awhile, a client requests something that's described in height x width. Usually the giveaway is that billboards aren't 17 feet tall.

But in some cases, if they're from the South, I know I have to ask them three times to make sure they're telling me width and height. The third time they'll get that width is the left to right size.

It is common to see lat/long, but in fairness long/lat makes more sense as it reflects x/y axis.

– Some like to think like a matrix then, usually with row, column. – Some like to keep the continuous convention. – Some like to split the difference.

Which then leads to the confusion when doing spatial stuff, as it swaps between a lot of JS libraries (for showing) and backend systems (for querying)

So to this day in UE5 y is depth and z is height. This causes fun inconsistencies with all other 3D apps.

> Do you have a preference? > Yes I do: longitude, latitude.

The author is just wrong here... and is writing this post to try to pretend that there is more difference of opinion than there actually is.

Geographical tradition and the English language. If you say "longitude and latitude", it sounds off, like "white and black" rather than "black and white".

> There's some consensus growing around longitude, latitude

Naturally, some dweebs trying to "fix" things get it backwards.

lon, lat is x, y.

Who says "y, x"?