Lon Lat Lon Lat

Lat&#x2F;Lon is really the standard. The fact that some software internally represents it as Lon&#x2F;Lat doesn&#x27;t mean it&#x27;s not a settled issue. If you look up the coordinate of a location - it&#x27;s always in Lat&#x2F;Long. You can&#x27;t rewrite all the books and change all the maps to make it nicer for programmers<p>As the linked post says, Lon&#x2F;Lat is generally easier to deal with b&#x2F;c it matches to X&#x2F;Y (and the North&#x2F;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<p>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&#x2F;Lat doesn&#x27;t fix everything.<p>What I personally lean towards now is converting everything on read-in to a South&#x2F;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&#x2F;libraries I can&#x27;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.<p>That all said, I&#x27;m a total noob and I have no &quot;geospatial&quot; background (just writing some software to deal with rain data right now) So this isn&#x27;t pro advice. I&#x27;d just be curious what others think

Reminds me of two days of bug fixing, after our Python mapping tool suddenly returned bogus data, without any change in the code base.<p>Turns out, we did not pin the pyproj library [1] and they introduced a switch from lon-lat to lat-lon order, per default.<p>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.<p>Besides, I have a personal, subjective preference for lon-lat, but I understood the lat-lng order to be the officially accepted norm.<p>[1]: <a href="https:&#x2F;&#x2F;pyproj4.github.io&#x2F;pyproj&#x2F;stable&#x2F;api&#x2F;proj.html" rel="nofollow">https:&#x2F;&#x2F;pyproj4.github.io&#x2F;pyproj&#x2F;stable&#x2F;api&#x2F;proj.html</a>

I think Latitude historically comes first when spoken or written because of the rule of ablaut reduplication, which makes it more natural for the &#x27;a&#x27; sound to come before the &#x27;o&#x27; sound when using phrases like this. For instance, &#x27;bish, bash, bosh&#x27; sound natural&#x2F;correct, but &#x27;bosh, bash, bish&#x27; sounds wrong.<p>I get the order wrong when working with geojson with embarrassing frequency...<p><a href="http:&#x2F;&#x2F;www.macmillandictionaryblog.com&#x2F;a-hotchpotch-of-reduplication" rel="nofollow">http:&#x2F;&#x2F;www.macmillandictionaryblog.com&#x2F;a-hotchpotch-of-redup...</a>

Well, there&#x27;s Earth Centered Earth Fixed, which is what you actually get from GPS systems. Latitude and longitude are just for human-readable I&#x2F;O. ECEF has the Z axis through the poles, the XY plane through the equator, and the X axis in a plane that goes through Greenwich.<p>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&#x27;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.<p>But everybody uses the same ECEF 3D coordinates, and combining satellite data is done in that frame. So if you need precise locations, there&#x27;s something to be said for working in ECEF.

The ordering of lat&#x2F;lon is not the only tricky part of working with geographic coordinates, sadly. &quot;Between&quot; the pair of numbers and a real point location on earth, there are two levels of abstraction used in the definitions of latitude and longitude: 1. physical surface is modeled by a geoid, a surface which approximates the mean sea level over the oceans and its continuation under the land masses. 2. The geoid is approximated by a reference surface, a geometric shape simpler to describe (in closed form, with few parameters). For example, an ellispoid like WGS84 (the &quot;84&quot; is the year of the introduction of this standard) is commonly used.<p>Furthermore there is the distinction between &quot;geodetic&quot; latitude ϕ (without qualification): the angle between the normal and the equatorial plane - this should be given with a specification of the ellipsoid and &quot;geocentric&quot; or &quot;spherical&quot; latitude θ (or ψ, q, ϕ′, ϕc, ϕg): the angle between the radius and the equatorial plane. (Figure below).<p>Quoting from <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Latitude" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Latitude</a> :<p>&quot;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.&quot;<p>Whereas confusing lat&#x2F;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.

&gt; whether -87.73 is the longitude or latitude<p>Is negative longitude even legal?<p>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.

Worse, I&#x27;ve seen a lot of code that just uses the variable name &quot;ll&quot; as an array of two numbers and make no attempt to clarify which is which. Saved a whole 4 characters by not making it &quot;latlon&quot;. Then you get to guess what units they&#x27;re in.

Named values are better than tuples for almost everything, but especially for tuples where order might be ambiguous. Name your values, their names might be abbreviated but they won’t be ambiguous.

Reading this gives me warm feelings. In the past, when I had the pleasure of working with geospatial data on a few projects, I tried to make a point of naming the struct holding the data in the same order as we&#x27;d received it: &quot;LonLat&quot; or &quot;LatLon&quot;. My hope was it would help the team avoid silly bugs from flipping them by mistake. (colloquially, no matter the order the coordinates were specified in the data, we&#x27;d tend to say &quot;Lat-Lon&quot;)

Lon Lat makes more sense when the programmer organizes the way they think about geography by timezone or east&#x2F;west hemisphere first; or if they consider a typical cylindrical projection and think to represent <i>that very human-centric representation of earth&#x27;s surface</i> as x, y: x, being longitude, would be specified first. The first thing you know when given Longitude is approximately how out of sync the target is in their day&#x2F;night cycle, and more broadly whether it&#x27;s the eastern or western hemisphere.<p>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&#x2F;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.<p>Lat&#x2F;Lon is the traditional and historical standard way of expressing location. Why are programmers treating it as if it&#x27;s a new, unsettled question, and deciding for themselves which order to use for their software?<p>Interesting that both WMS and WFS changed to lat&#x2F;long in later versions of their specs. Maybe more people could take the hint.

Having a nice modern language helps. I&#x27;m maintaining a small library with some geospatial algorithms and geojson support for Kotlin called geogeometry.<p>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.<p>I defined a typealias PointCoordinates = DoubleArray, and then have extension properties defined on like:<p>val PointCoordinates.latitude: Double get() = this[1]<p>The compiler inlines all of that of course so it&#x27;s all simple array manipulation. But it looks like an object. And I get to avoid the longitude&#x2F;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).

I’ve ended up in the middle of the ocean more times than I’d like to admit. Mixing up lat&#x2F;long really reminds you how much of the world is water.

I wonder how much time has been wasted by devs who get the order wrong. I know I&#x27;ve been guilty of it so many times. It&#x27;s really frustrating, but I like that someone took the time to write down which order goes for which software- this is a nice reference.

Aside from this, there are annoying abbreviations inconsistencies for named fields too, where some APIs will use &quot;lon&quot;, while others will use &quot;lng&quot;.

The author says neither is right, but clearly prefers lon, lat ordering.<p>&quot;Geographical tradition favors lat, lon. Math and software prefer lon, lat.&quot;<p>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&#x27;m drawing a blank why one ordering is better for computation.

<i>It is computed, that eleven thousand persons have, at several times, suffered death, rather than submit to break their eggs at the smaller end.</i>

My pet peeve is that it wasn&#x27;t named &quot;lonitude&quot; (no &#x27;g&#x27;). Then both would be equally wide in code.

related: there are a truly <i>shocking</i> number of ways to write down “a representation of an axis-aligned bounding box of a region of an image”, and every flipping time it’s a list of four floats; heavens no, it can’t be anything with names!<p>is it:<p><pre><code> [xmin ymin xmax ymax] [xmin ymin width height] [xcenter ycenter width height] # all of the above but in normalized [0,1] not pixel coordinates </code></pre> and so on and so forth and i swear i’ve seen at least a few deficient formats that use nonstandard (for image space) coordinate axes so the origin is somewhere else.

While Lat&#x2F;Lon (or Lon&#x2F;Lat) is intuitive, it is not an ideal system for addressing a location on a 2-sphere. It has uneven Longitude width vs Latitude and discontinuities at the poles. I wonder what system we would use if the poles were densely populated.

&gt; Math and software prefer lon, lat.<p>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.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Spherical_coordinate_system" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Spherical_coordinate_system</a><p>But then again: Where does math even use spherical coordinates that is not physics related?

Order aside (I stick to geojson convention myself), I also prefer &#x27;lng&#x27; to &#x27;lon&#x27; due to the pronunciation. Longitude has an &#x27;ong&#x27; sound, not an &#x27;on&#x27; ...

There is no controversy IMHO. [Lat,Lon] is just different coordinate system of the same space as is [X,Y].<p>It never happens that you try to generate {X} from {Lon} alone.<p><pre><code> def LatLon_to_GoogleTiles(lat, lon, zoom): lat_rad = math.radians(lat) n = 2.0 ** zoom xtile = int((lon + 180.0) &#x2F; 360.0 * n) ytile = int((1.0 - math.log(math.tan(lat_rad) + (1 &#x2F; math.cos(lat_rad))) &#x2F; math.pi) &#x2F; 2.0 * n) return (xtile, ytile)</code></pre>

I’m shocked this kind of post is written, and there are so many comments, yet no one has mentioned spatial references. Not a single time. When you understand the underlying complexity of spatial references&#x2F;datums&#x2F;coordinate systems the deviation in library choices isn’t surprising.<p>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&#x2F;lon for some reason.<p>Some of the libraries under complaint only support WGS84 (basically what anyone using GPS thinks of when they say lat&#x2F;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.<p>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.<p>State plane coordinates, for example of widely-used xy system: <a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;State_Plane_Coordinate_System" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;State_Plane_Coordinate_Syste...</a><p>More info on projected&#x2F;Cartesian coordinates vs geographic&#x2F;spherical coordinates:<p><a href="https:&#x2F;&#x2F;www.esri.com&#x2F;arcgis-blog&#x2F;products&#x2F;arcgis-pro&#x2F;mapping&#x2F;coordinate-systems-difference&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.esri.com&#x2F;arcgis-blog&#x2F;products&#x2F;arcgis-pro&#x2F;mapping...</a>

Latitude and longitude are, in fact, real-world data items. As a guy who sometimes uses them for stuff like store-finders. I&#x27;m lucky to live in a region with latitude about 45 (temperate northern hemisphere) and longitude about -70 (west of the prime meridian).<p>So, every time I get the lat&#x2F;lon order wrong around here. I get a brief trip to Antarctica.<p>It&#x27;s important when hacking this kind of data (or any data) to develop at least some sense for what it means. If there&#x27;s an error in the data, you want to be able to think, wait, that isn&#x27;t right, that&#x27;s in the Atlantic someplace east of Cape Hatteras (or whatever).<p>And, of course, when using map products like USGS quads or UK Ordnance Survey maps we use those mapping agencies&#x27; coordinate systems, be they US State Plane projects, Universal Transverse Mercator, or whatever.<p>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.<p>Like any physical measurement, lat&#x2F;lon makes some kind of physical sense. Unlike many measurements, lat&#x2F;lon has some constraints. For example you know a priori a latitude of +130° is bogus.

I found a bug once in one of our geospatial pipelines. We were removing all points with invalid coordinates, i.e those with abs(longitude)&gt;90 and abs(latitude)&gt;180. Problem is, it&#x27;s longitude that goes from -180 to 180 and latitude that goes from -90 to 90. We never noticed because all the points we were interested in were in Africa. It&#x27;s a really easy mistake to make.<p>I always say &quot;lat&#x2F;lon&quot;, 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&#x27;t put my finger on it: <a href="https:&#x2F;&#x2F;www.bbc.com&#x2F;culture&#x2F;article&#x2F;20160908-the-language-rules-we-know-but-dont-know-we-know" rel="nofollow">https:&#x2F;&#x2F;www.bbc.com&#x2F;culture&#x2F;article&#x2F;20160908-the-language-ru...</a><p>On the other hand, if thinking about them as x and y then x is longitude so it naturally comes first.<p>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).

The formats that do Lon-Lat supports different SRS ( <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Spatial_reference_system" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Spatial_reference_system</a> ). Those are actually X-Y, not Lon-Lat

English also has a preference to producing lists with vowel sounds generated with the tongue posture at the back of the mouth first, followed by those made towards the front. &quot;lat&quot; comes first with this unwritten rule.<p>&quot;fi fy fo fum&quot; &quot;friend or foe?&quot; etc

Slightly off-topic, but does anyone else have to check each time which of the words &quot;latitude&quot;, &quot;longitude&quot; corresponds to which measure?<p>Why aren&#x27;t we using some self-explanatory terms?<p>I propose &quot;rotitude&quot;, &quot;iclinitude&quot;. Guess which is which.

This just drives me nuts. Lat&#x2F;Lon. That&#x27;s the answer.<p>In any kind of graphic design work if you&#x27;re communicating with printers, pre-press, etc. you say Width x Height. Like paper size. 8.5&quot; x 11&quot;. But once in awhile, a client requests something that&#x27;s described in height x width. Usually the giveaway is that billboards aren&#x27;t 17 feet tall.<p>But in some cases, if they&#x27;re from the South, I know I have to ask them three times to make sure they&#x27;re telling me width and height. The third time they&#x27;ll get that width is the left to right size.

My favourite story about this is from when I worked at an Agritech company - we were working with two systems using different orders - we discovered a highstreet store had the same issue when we discovered a bunch of their stores just off the Seychelles on Google Maps: <a href="https:&#x2F;&#x2F;thoeni.io&#x2F;images&#x2F;hnlondon&#x2F;pundstretcher.png" rel="nofollow">https:&#x2F;&#x2F;thoeni.io&#x2F;images&#x2F;hnlondon&#x2F;pundstretcher.png</a>

Whenever I worked with lat&#x2F;lon pairs in the past I stumbled over those issues at some point. That&#x27;s why at my last startup we used Geohashes everywhere. It&#x27;s one string and so much more convenient to handle. There are libraries to convert from Geohashes to lat&#x2F;lon pairs for every platform for those times you need them. You can even shorten them when accuracy isn&#x27;t needed or you&#x27;d like to group similar locations.

I feel like mixing up your lat and lon is almost a rite of passage for working with geodata - everybody does it once and (hopefully) learns from the mistake

I have had the pleasure of fixing this silly bug in my weather app after switching location input autocomplete provider. I didn&#x27;t even notice it for a while, but then Stockholm having 20 celsius in winter is unusual.<p>It is common to see lat&#x2F;long, but in fairness long&#x2F;lat makes more sense as it reflects x&#x2F;y axis.

In Cartesian coordinates we use x,y notation so lng,lat seems like the more familiar convention for math students.

In the same way that most people put the horizontal before the vertical for continuous cartesian stuff, but as soon as it&#x27;s discrete, all hell breaks lose:<p>– 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.

I was always taught in school that you &quot;crawl before you climb&quot; - so on graphs x is crawling, y is climbing, on maps lat is crawling, lon is climbing.<p>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)

I’ve done a fair amount of geospatial work, and been caught by this sometimes. A standard would be nice, but in general it’s something you catch pretty quickly in development and can fix easily. “Why doesn’t this pin show up in the correct place? Oh, yeah, let me reverse those variables.”

There are other things like this. For instance, between WMS version 1.1.1 and 1.3.0, the order of the coordinates in bounding boxes changed, and you choose a projection with the &quot;CRS&quot; parameter instead of &quot;SMS&quot;.

Lon&#x2F;lat it should be. First because of x&#x2F;y, but also because in astronomy, it is right ascension, declination. (Obviously it is just matter of convention, but certainly for an astronomer lat&#x2F;Lon is very unnatural)

Since nobody has commented yet, in 3D land, Unreal the game used y for depth and z for height.<p>So to this day in UE5 y is depth and z is height. This causes fun inconsistencies with all other 3D apps.

If you&#x27;re trying to point things, this is right up there with the azimuth and elevation debate. Some industries&#x2F;sciences use an ElAz convention, and some prefer AzEl.

Working on a project doing geo lookups I found that storing by lat, lon made it easier to do bounded checks as distance by latitude is effectively consistent.

Haven&#x27;t we reached a point in programming with sufficient abstractions and syntax such that ordering of parameters shouldn&#x27;t matter?

I&#x27;m a simple man. A comes before O, so Lat Lon.

I don&#x27;t care which order, but for the love of all things precious, please tell me the order before you give me 60,52.

As a side note, in btree based database indexes, it&#x27;s not the same to have a composed index on lat-lon than lon-lat.

Lat Lon is how it&#x27;s always been. I didn&#x27;t know people used anything else. If you&#x27;re using Lon Lat you&#x27;ve learned something historically incorrect.<p>&gt; Do you have a preference? &gt; Yes I do: longitude, latitude.<p>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.

&gt; <i>Geographical tradition favors lat, lon.</i><p>Geographical tradition and the English language. If you say &quot;longitude and latitude&quot;, it sounds off, like &quot;white and black&quot; rather than &quot;black and white&quot;.<p>&gt; <i>There&#x27;s some consensus growing around longitude, latitude</i><p>Naturally, some dweebs trying to &quot;fix&quot; things get it backwards.

And images and matrices are often indexed (row, column), so clearly lat lon is right!

Chilean prefer lat&#x2F;lon?

Agreed.<p>lon, lat is x, y.

<a href="https:&#x2F;&#x2F;xkcd.com&#x2F;2577&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;2577&#x2F;</a>

Lon lat, like x, y<p>Who says &quot;y, x&quot;?