20 ms·
Lon Lat Lon Lat
- Rebelgecko 5y agoIf you're trying to point things, this is right up there with the azimuth and elevation debate. Some industries/sciences use an ElAz convention, and some prefer AzEl.
- originate 5y agoAgreed. lon, lat is x, y.
- fomine3 5y agoChilean prefer lat/lon?
- ohnoNotAgain321 5y agohttps://xkcd.com/2577/ https://xkcd.com/2577/
- allannienhuis 5y agoI think Latitude historically comes first when spoken or written because of the rule of ablaut reduplication, which makes it more natural for the 'a' sound to come before the 'o' sound when using phrases like this. For instance, 'bish, bash, bosh' sound natural/correct, but 'bosh, bash, bish' sounds wrong. I get the order wrong when working with geojson with embarrassing frequency... http://www.macmillandictionaryblog.com/a-hotchpotch-of-reduplication http://www.macmillandictionaryblog.com/a-hotchpotch-of-redup...
- gmiller123456 5y agoI doubt this holds up in other languages though.
- Miiko 5y agoCannot tell about all other languages, but it does hold up in Russian: широта (latitude) coming before долгота (longitude), 'i' before 'o'
- mongol 5y agoHow does a clock sound in other languages? In Swedish: tick tack
- eCa 5y agoTick tock.. But I’d argue it’s not the same thing. The ’tick’ sound comes first, it’s onomatopoetic.
- mongol 5y agoIs it not just the way we prefer to order it in our heads?
- Fiahil 5y agoFrench : tic tac
- albert_e 5y agoIndian: tick tick
- sundarurfriend 5y agoTamil (in India): tik tik tik Citation: https://en.m.wikipedia.org/wiki/Tik_Tik_Tik_(1981_film) https://en.m.wikipedia.org/wiki/Tik_Tik_Tik_(1981_film)
- cozzyd 5y agoIn every language I know the words are essentially the same...
- Hendrikto 5y agoIn German, they are called Längengrad and Breitengrad.
- IshKebab 5y agoWe should rename them to langitude and lotitude. Much clearer!
- jillesvangurp 5y agoThere's also the notion that determining the longitude is much harder than determining the latitude. Figuring out latitude is easy if you can measure angles to stars or the sun at noon and is something that people have been doing for quite long. Figuring out the longitude requires an accurate clock and was something that had a lot of strategic value in the seventeenth century. To the point where multiple kings and goverments at the time created rewards to incentivize scientists of the day to work on that problem.
- Gwypaas 5y agoMore importantly, it needed to be accurate even when jumbled around in a storm crossing an ocean. Which ruled out for example pendulum like clocks.
- amelius 5y agoI think we should just ask GPT-3 what is the correct order.
- gmiller123456 5y agoWorse, I've seen a lot of code that just uses the variable name "ll" as an array of two numbers and make no attempt to clarify which is which. Saved a whole 4 characters by not making it "latlon". Then you get to guess what units they're in.
- catillac 5y agoIf it’s a variable there’s a reasonable chance it’s used more than once and thus saves more than four characters.
- djbusby 5y agoMaybe your text is grey cause saving a few chars on variable names doesn't save any RAM. And also confuses sober-you from reading your own code.
- feupan 5y agoThis is also why I avoid indentation; programming is all about saving those precious bytes like it’s 1988.
- seattle_spring 5y agoOn top of this, I feel like `ll` is quite verbose and memory intensive. A simple `l` would suffice with half the space.
- WorldMaker 5y ago`l` needs practically twice as many hole punches as `a` for "array" in my EBCDIC punch cards and fewer punches is less likely a card gets shredded in the reader.
- itsjustme2 5y agoI wonder how much time has been wasted by devs who get the order wrong. I know I've been guilty of it so many times. It'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.
- danbr 5y agoI’ve ended up in the middle of the ocean more times than I’d like to admit. Mixing up lat/long really reminds you how much of the world is water.
- jillesvangurp 5y agoHaving a nice modern language helps. I'm maintaining a small library with some geospatial algorithms and geojson support for Kotlin called geogeometry. 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).
- wereHamster 5y agoThe issue really exists only at I/O boundaries, where if there is a format mismatch you have to convert, which incurs some costs (CPU mostly, and memory bandwidth). Most languages can inline the data such that there isn't much overhead in accessing the raw bytes. Arrays with aliases for indexes (like you did, or in JS maybe I'd do something like `const LAT = 0, LON = 1; point[LAT]`, C-family languages can pack the bytes into tight structs where field names act as aliases to the memory location, Haskell has the UNPACK pragma etc. Btw, give that you have a PointCoordinates type, why not f(p: PointCoordinates)?
- jillesvangurp 5y agoThe issue is code readability while dealing with memory efficient arrays of DoubleArrays, which are used by geojson to represent geometries. You are right about the function call :-). Actually you can also do fun PointCoordinates.f() {...}. The reason I have function calls with latitude and longitude in there as equivalents for their point coordinate variants is just convenience. If you have some other library using its own point representation, having to first convert to my representation before you can use my functions is a bit verbose. And of course, people into OO programming usually get a bit carried away reinventing their own Point classes. It's one of the reasons I stayed away from using object hierarchies in this library. The geojson classes are an exception to this and were actually bolted on fairly recently so I can support geojson compatible serialization/deserialization.
- jmwilson 5y agoThe author says neither is right, but clearly prefers lon, lat ordering. "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.
- trothamel 5y agoWhen plotted on a mercator-style map, longitude corresponds to X and latitude corresponds to Y, with X, Y being the usual order for coordinates. (That's my guess, anyway.)
- labster 5y agoThe X and Y you describe are also conventions based on putting north at the top of a map, and really only map one-to-one in Mercator projection anyway.
- deleted 5y ago[deleted]
- ummonk 5y agoOne reason that comes to mind is that (longitude, latitude, altitude) is right handed, and we tend to prefer right handed coordinate systems.
- SaberTail 5y agoI agree with the point, but software has at times frustratingly used left-handed coordinates for drawing on screens. DirectX and browsers' use of `z` come to mind.
- thaumasiotes 5y agoWell, by standard convention longitude is labeled θ and latitude is labeled φ. People think more about θ because it also appears in two-dimensional polar coordinates. But in math you care far more about labeling the angles correctly than about which order you list them in.
- tomjakubowski 5y agoReading 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'd received it: "LonLat" or "LatLon". 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'd tend to say "Lat-Lon")
- geokon 5y agoLat/Lon is really the standard. The fact that some software internally represents it as Lon/Lat doesn't mean it's not a settled issue. If you look up the coordinate of a location - it's always in Lat/Long. You can't rewrite all the books and change all the maps to make it nicer for programmers 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
- nwallin 5y ago> Lat/Lon is really the standard. [...] 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. The standard is X/Y+Spatial Reference. (the SR is usually out of band) If your spatial reference maps X to "latitude" and Y to "longitude", then so be it, but in general, I would expect a spatial reference which is applicable to an area that doesn't include the poles to map +X to East-ness and +Y to North-ness. (Spatial references near the poles get... interesting...) If your data doesn't have a spatial reference, then you don't have data, you have numbers. There are several reasons for this. First of all, there's the whole XY plane and all that. Secondly, there's also the fact that lat/lon/height coordinates, if you wish to preserve the right hand rule, translate to +north/+east/-up or north/east/down[0] coordinates, where elevations above sea level are negative, and the more you climb some mountain, the more negative your Z coordinate becomes. On the other hand, lon/lat/height becomes east/north/up, and the right hand rule is preserved. Source: this is my day job. https://en.wikipedia.org/wiki/North_east_down https://en.wikipedia.org/wiki/North_east_down
- ummonk 5y agoAside from this, there are annoying abbreviations inconsistencies for named fields too, where some APIs will use "lon", while others will use "lng".
- deleted 5y ago[deleted]
- truted2 5y agoIn Cartesian coordinates we use x,y notation so lng,lat seems like the more familiar convention for math students.
- atonse 5y agoI agree with this, which is why I prefer lon/lat (x,y) but I think technically they aren't cartesian, which is why we have projections that project the spherical planes on to X,Y coords data planes.
- Helmut10001 5y agoReminds me of two days of bug fixing, after our Python mapping tool suddenly returned bogus data, without any change in the code base. 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 https://pyproj4.github.io/pyproj/stable/api/proj.html
- cozzyd 5y agoThat is awful. They should have changed the method name with such an abusive change.
- Helmut10001 5y agoLooked it up, just to prevent that the pyproj team gets blamed for this: The change in behaviour was actually introduced in the PROJ library, which is used by pyproj. This is the specific merge with some additional discussion [1]. The basic motivation was that PROJ was changed to correctly follow the axis order of EPSG codes. Anyway, it was quite confusing at that time, but over the years working with geographical data made more sense to me and I am now always aware of the specific order. See also an extended discussion here [2] [1]: https://github.com/OSGeo/PROJ/pull/1182 https://github.com/OSGeo/PROJ/pull/1182 [2]: https://pyproj4.github.io/pyproj/stable/gotchas.html#axis-order-changes-in-proj-6 https://pyproj4.github.io/pyproj/stable/gotchas.html#axis-or...
- cozzyd 5y agoAnd it looks like indeed, like proj, pyproj updated the major version number when this happened at least. Still think the API should have changed... edit: it does seem like PROJ DID introduce a new header file with a new API[0] and eventually deprecated the older one sometime later, handling the transition much more gracefully. I guess pyproj didn't do the same thing? [0]: https://proj.org/development/migration.html#api-migration https://proj.org/development/migration.html#api-migration
- lostdog 5y agoAnd images and matrices are often indexed (row, column), so clearly lat lon is right!
- pstuart 5y agoWorking 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.
- j16sdiz 5y agoThe formats that do Lon-Lat supports different SRS ( https://en.wikipedia.org/wiki/Spatial_reference_system https://en.wikipedia.org/wiki/Spatial_reference_system ). Those are actually X-Y, not Lon-Lat
- Animats 5y agoWell, there's Earth Centered Earth Fixed, which is what you actually get from GPS systems. Latitude and longitude are just for human-readable I/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. 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.
- cozzyd 5y agoYeah but usually people want to do something silly like place a point on the surface of the Earth :).
- artificialidiot 5y agoYeah, it is actually silly if you don't have a decent DEM, though you can get away with a geoid approximation if you only want to render a pretty picture for someone navigating to the nearest ATM.
- cozzyd 5y agofortunately, between SRTMv3, ASTER, ArcticDEM and REMA, a free DEM is available for practically the entire world (maybe missing some subantarctic islands?).
- 7952 5y agoBut we want to do more than that, and dealing with elevation can be surprisingly complex and fragile. Imagine you are building an offshore wind turbine. You want 20m of clearance between the sea and turbine blade. That means 20m above highest possible tide. Tidal data is only available for a port 200 miles away and will be different for you based on local gravity. So you use modelling from satellite based gravity data to make an assumption. And then give instructions to a ship out at sea who has a contractual obligation to place the turbine within 30cm of the required position. Which coordinate system do you use? And when you are modelling a microwave link from that turbine to an onshore location on the horizon that is surveyed using a local datum what coordinate system do you use? In reality geocentric coordinates are unlikely to be used. But maybe it would be easier if they could be. The world it not flat and it is not easily modelled as a sphere. A set of coordinates always carry with them a set of assumptions that may not work with your particular task. Geocentric coords can remove some of those assumptions.
- rhn_mk1 5y agoSlightly off-topic, but does anyone else have to check each time which of the words "latitude", "longitude" corresponds to which measure? Why aren't we using some self-explanatory terms? I propose "rotitude", "iclinitude". Guess which is which.
- bumbledraven 5y agoMnemonic: think of latitude and longitude as parts of a ladder. Lines of LONGitude are the LONG bars that run from South-to-North and lines of latitude are the rungs (East-to-West). h/t https://www.geographyrealm.com/remember-difference-latitude-longitude/ https://www.geographyrealm.com/remember-difference-latitude-...
- pishpash 5y agoWell you got it backwards.
- School-Cotton 5y agoNo, longitude lines indeed run north-to-south (and, therefore, the longitude number measures how far east-to-west you are).
- pishpash 5y agoI read it wrong, as in latitudes are north-to-south gradations. Wasn't thinking of level lines.
- rhn_mk1 5y agoMnemonics aren't any more self-explanatory, they just rely on clumping extra arbitrary concepts, in the hope that something will stick.
- pishpash 5y agoMake a mnemonic for yourself. The one I've heard is latitude -> ladder.
- eyelidlessness 5y agoNamed 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.
- cerved 5y agoThe problem is named named values often come with significant performance penalties in terms of storage. With data points in the billions it becomes significant
- Someone 5y agoI think that’s less of a problem than often claimed. For formats such as csv, parquet or a SQL database that store the names of fields only once, overhead is constant, regardless of number of items. So, it only can be a problem for formats such as xml or json that repeat the names of fields in every record. Those happen to be formats with variable record length, so you can’t index into such files; the only way to process them is in their entirety. If so, and storage size is a problem, you can compress the files. Your typical LZW variant will, if the files are large enough, eventually encode both the “(lat=“ and “,lon=“ parts to single codes of (typically) 12 bits each. That will happen after the fifth occurrence of such strings, so fairly soon). That’s 24 bits of overhead per item. Significant, but if you use xml or json, chances are you’re already giving up way more by storing floating point values as text strings. So, that leaves json or xml files that each store only a few items per file. With a typical file system block size of 8 kB, those already give up 4 kB on average per file.
- cerved 5y ago> If so, and storage size is a problem, you can compress the files I'm literally in the process of processing 100gb compressed spatial json and it's not enjoyable
- eyelidlessness 5y agoThat’s a fair point. In my opinion, more languages should support something like TypeScript’s labeled tuple elements[1] for use cases like that. 1: I wasn’t able to find this in the main docs for some reason? Only the release notes. https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-0.html#labeled-tuple-elements https://www.typescriptlang.org/docs/handbook/release-notes/t...
- khazhoux 5y agoMy pet peeve is that it wasn't named "lonitude" (no 'g'). Then both would be equally wide in code.
- orthoxerox 5y agoWhat about "width" and "higth"? And "topp" and "left"?
- khazhoux 5y agoTop/left aren’t the same. Width/height are similar problem but still… when you’re writing geo code you write latitude and longitude all day long and the misalignment is maddening. Pet peeve, I know.
- adrian_b 5y agoActually in the original language (Latin), the "a" in latitude was long, which is lost in the modern transcription. You can align them by restoring the vowel length and writing "laatitude" & "longitude" :-)
- timonoko 5y agoThere is no controversy IMHO. [Lat,Lon] is just different coordinate system of the same space as is [X,Y]. 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)
- jll29 5y agoThe ordering of lat/lon is not the only tricky part of working with geographic coordinates, sadly. "Between" 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 "84" is the year of the introduction of this standard) is commonly used. 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 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.
- everybodyknows 5y agoSurprisingly colorful account of ED50's origins: https://www.gim-international.com/content/article/european-datum-1950-a-history https://www.gim-international.com/content/article/european-d... Toward the end is info on ED50's relationship to WGS-84.
- everybodyknows 5y agoEach datum -- WGS-84, ED50, ... -- specifies one particular geoid, one model of the earth's surface. > Commonly an ellipsoidal model is part of a more encompassing geodetic datum. https://en.m.wikipedia.org/wiki/Earth_ellipsoid https://en.m.wikipedia.org/wiki/Earth_ellipsoid A brief history of datum-geoid pairings can be found in the section Historical earth ellipsoids. For WGS-84 datum+geoid, an authoritative reference: http://www.unoosa.org/pdf/icg/2012/template/WGS_84.pdf http://www.unoosa.org/pdf/icg/2012/template/WGS_84.pdf
- russellbeattie 5y agoIt is computed, that eleven thousand persons have, at several times, suffered death, rather than submit to break their eggs at the smaller end.
- tedgold 5y agoI have had the pleasure of fixing this silly bug in my weather app after switching location input autocomplete provider. I didn't even notice it for a while, but then Stockholm having 20 celsius in winter is unusual. It is common to see lat/long, but in fairness long/lat makes more sense as it reflects x/y axis.
- wiradikusuma 5y agoI'm a simple man. A comes before O, so Lat Lon.
- bennyp101 5y agoI was always taught in school that you "crawl before you climb" - so on graphs x is crawling, y is climbing, on maps lat is crawling, lon is climbing. 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)
- gspr 5y ago> I was always taught in school that you "crawl before you climb" - so on graphs x is crawling, y is climbing, on maps lat is crawling, lon is climbing. What does this mean?
- Rebelgecko 5y agoHorizontal coordinate comes before vertical
- gspr 5y agoBut latitude goes vertically on most maps. And they write "lat is crawling".
- orthoxerox 5y agoAre you a Tolkien dwarf? Lon is crawling, lat is climbing on regular human maps.
- somishere 5y agoOrder aside (I stick to geojson convention myself), I also prefer 'lng' to 'lon' due to the pronunciation. Longitude has an 'ong' sound, not an 'on' ...
- gspr 5y agoIn the same way that most people put the horizontal before the vertical for continuous cartesian stuff, but as soon as it's discrete, all hell breaks lose: – 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.
- gtsop 5y agoHaven't we reached a point in programming with sufficient abstractions and syntax such that ordering of parameters shouldn't matter?
- skybrian 5y agoUnfortunately, keyword arguments aren't everywhere yet. But you could pass in a struct.
- cookie_monsta 5y agoI 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
- pachico 5y agoAs a side note, in btree based database indexes, it's not the same to have a composed index on lat-lon than lon-lat.
- jdrc 5y agoLon lat, like x, y Who says "y, x"?
- SergeAx 5y ago> whether -87.73 is the longitude or latitude 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.
- cornel_io 5y agoNo, it's not always that way. There are plenty of libraries mentioned all over this thread that do it the other way, just like in graphics you can't just assume you're in a left or right handed system, and in relativity you can't assume time has the negative sign in the metric. It might be "right" by someone's definition, but it's not universal, so it has to be documented (and there are always extremely important cases you'll run into where people have made the "wrong" choice). Even when it comes to matrix math there are textbooks that treat them as (row, column) and others that go (column, row), it's always best to be explicit. And yes, negatives make sense and are "legal", by which I mean they pick out locations in a meaningful way and should not be considered out of bounds. What you probably mean is that they are not canonical, and by convention people usually wrap them to points within a certain range. Doing this wrong is a common source of bugs in maps.
- SergeAx 5y agoLatitude and longitude are geometric values. Programming libraries are secondary abstractions to Earth geometry (third degree abstractions, to be precise, there's WGS84 or other abstraction in between). Negative longitude, negative latitude and even latitude modulo above 90 degrees will produce a point on the globe, but library-wise I would not allow it to pass input validation.
- WorldMaker 5y agoProgramming libraries are also things that need to do math on data points (in a way that programmers themselves can reason about). One of the reasons many of the math focused libraries prefer [lon, lat] data is because it is (close to, in some projections) an "intuitive" approach to [x, y] order and brings the geographic abstraction closer to the Euclidean geometry abstraction to make it easier for the programmers to reason with (regardless of which projection abstractions are in between). (Needing to do a deeper dive into some of Leaflet's code at one point gave me a somewhat greater appreciation over why there is such disagreement between [lat, lon] and [lon, lat] formats. Abstractions are hard, and when you know you already need a crazy projection abstraction or three, sometimes the simplicity of [x, y, z] Euclidean approximations feels like "home" for as much as you can reason in it and expect the projection math to "just work" with it as long as you are consistent.)
- verytrivial 5y agoEnglish 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. "lat" comes first with this unwritten rule. "fi fy fo fum" "friend or foe?" etc
- noduerme 5y agoThis just drives me nuts. Lat/Lon. That's the answer. 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.
- rdtsc 5y ago> This just drives me nuts. Lat/Lon. That's the answer. In any kind of graphic design work if you're communicating with printers, pre-press, etc. you say Width x Height. To me that would make (lon,lat) preferable, then? Longitude would be the width/left-right/x-axis coordinate, and latitude be the height/up-down/y-axis coordinate? Or maybe I misunderstood, and you just highlighted that we every discipline should have it’s standard and as opposed to stating that geographical coordinates should match the printing and other domains?
- efxhoy 5y agoI found a bug once in one of our geospatial pipelines. We were removing all points with invalid coordinates, i.e those with abs(longitude)>90 and abs(latitude)>180. Problem is, it'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's a really easy mistake to make. 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-rules-we-know-but-dont-know-we-know 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).
- Scarblac 5y agoThere 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 "CRS" parameter instead of "SMS".
- harshreality 5y agoLon Lat makes more sense when the programmer organizes the way they think about geography by timezone or east/west hemisphere first; or if they consider a typical cylindrical projection and think to represent that very human-centric representation of earth's surface 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/night cycle, and more broadly whether it's the eastern or western hemisphere. 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.
- sampo 5y ago> Math and software prefer lon, lat. 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 https://en.wikipedia.org/wiki/Spherical_coordinate_system But then again: Where does math even use spherical coordinates that is not physics related?
- indymike 5y agoI don't care which order, but for the love of all things precious, please tell me the order before you give me 60,52.
- mintone 5y agoMy 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: https://thoeni.io/images/hnlondon/pundstretcher.png https://thoeni.io/images/hnlondon/pundstretcher.png
- OliverJones 5y agoLatitude and longitude are, in fact, real-world data items. As a guy who sometimes uses them for stuff like store-finders. I'm lucky to live in a region with latitude about 45 (temperate northern hemisphere) and longitude about -70 (west of the prime meridian). 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.
- hprotagonist 5y agorelated: there are a truly shocking 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! 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 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.
- shireboy 5y agoI’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.”
- dekerta 5y agoThere actually is a standard. Lat, lon is the correct order https://en.m.wikipedia.org/wiki/ISO_6709 https://en.m.wikipedia.org/wiki/ISO_6709
- kloch 5y agoWhile Lat/Lon (or Lon/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.
- WorldMaker 5y agoProbably something a lot more like the Earth-centered, Earth-fixed coordinate systems [1] that are for instance the native reasoning tools of things like GPS services. [1] https://en.m.wikipedia.org/wiki/Earth-centered,_Earth-fixed_coordinate_system https://en.m.wikipedia.org/wiki/Earth-centered,_Earth-fixed_...
- dTal 5y agoNothing springs to mind. The problem is that location on any surface is a 2 dimensional parameter. However, two coordinates before any kind of "processing" define location on a plane. All spherical coordinate systems are therefore isomorphic to map projections, where the coordinates are simply a cartesian location on the flat map. And no map projection avoids singularities.
- zajio1am 5y agoUTM: https://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system https://en.wikipedia.org/wiki/Universal_Transverse_Mercator_... with UPS for poles: https://en.wikipedia.org/wiki/Universal_polar_stereographic_coordinate_system https://en.wikipedia.org/wiki/Universal_polar_stereographic_...
- webtopf 5y agoWhenever I worked with lat/lon pairs in the past I stumbled over those issues at some point. That's why at my last startup we used Geohashes everywhere. It's one string and so much more convenient to handle. There are libraries to convert from Geohashes to lat/lon pairs for every platform for those times you need them. You can even shorten them when accuracy isn't needed or you'd like to group similar locations.
- n8cpdx 5y agoI’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/datums/coordinate systems the deviation in library choices isn’t surprising. 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_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/coordinate-systems-difference/ https://www.esri.com/arcgis-blog/products/arcgis-pro/mapping...
- nailer 5y agoSince nobody has commented yet, in 3D land, Unreal the game used y for depth and z for height. So to this day in UE5 y is depth and z is height. This causes fun inconsistencies with all other 3D apps.
- mlindner 5y agoLat Lon is how it's always been. I didn't know people used anything else. If you're using Lon Lat you've learned something historically incorrect. > 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.
- kazinator 5y ago> Geographical tradition favors lat, lon. 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.
- sega_sai 5y agoLon/lat it should be. First because of x/y, but also because in astronomy, it is right ascension, declination. (Obviously it is just matter of convention, but certainly for an astronomer lat/Lon is very unnatural)