I 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...
There'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.
Worse, 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.
`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.
I 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.
Having 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).
The 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)?
The 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.
The 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.
When 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.)
The 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.
I 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.
Well, 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.
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'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")
Lat/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
Hey I've been working on geodata in several contexts for about 5 years now and I completely agree with you! You may be "noob" but your observations match mine to a T.
I have a dirty prototype I need to rewrite soon so I was considering a coordinate system change. It'd make debugging much easier if the values drawn and the values of the coordinates had the same "directions"
I was a bit apprehensive to just yolo my own internal coordinate system bc it's a design decision you end up having to live with
> For instance Lat goes 0-180 but Lon goes -90 to 90
Surely this is several typos? Longitude, which marks east-west, must span 360 degrees (-180 to 180, perhaps? although 0 to 360 is just as reasonable). Latitude, marking north-south, spans only 180 degrees, and therefore is presumably -90 to 90 (so that 0 is the equator).
Try thinking of it like latitude being like a ladder's rungs. Though this does have the horrifying side effect that sometimes you'll pronounce it laddertude in your head.
If I ever need to confirm which is which, I use the the mnemonic above. I usually imagine latitude corresponding to rings on the earth moving up and down along the surface. This image is triggered by thinking about "altitude" in the context of latitude for me.
The latitude defines which of these "rings" the point is on.
It's not just about internal representations. Web APIs and geospatial data formats specify them either way. You can't get away from the ambiguity unless you carefully choose the API and data format to match the order you like. (and pray that anyone providing you with data is aware of the choice made by your preferred formats)
yeah, lat/lon/alt is more common, but I like lon/lat for the same reason you do (you can plot lon=x, lat=y and get a crappy Mercator projection). I also often work with stereographic coordinates a lot which uses x-y, and that also colors my perception.
My point was that simply flipping lat/lon to be lon/lat is a cheap fix that still leaves you with problems.
What I propose is to go "all the way" and make an internal positive/unsigned South/East coordinate system that naturally matches the display coordinate system (the inverted X-Y). It's sufficiently different that you'll never get confused and flip things at API boundaries. It's also sufficiently weird that you won't expose it to others :)
Well, display coordinates are different from typical plot coordinates in any standard plotting package (of course, many plotting packages also support GIS, sort of making this a moot point). Yeah, if you're going to display coordinates you'll have extra problems.
It's not a moot point because you wanna debug stuff :)
If things are looking weird or wrong on your display then you need to go back to your internal values to inspect what's wrong. When the internal value covary with th display values then this makes life significantly easier
Not to mention things have a tendency to blow up when you start testing in the southern hemisphere haha
That said.. I don't personally use any magic plotting packages. I just generate my own graphics with svg. It's quite easy and everything is debuggable
lon=x, lat=y is not Mercator at all, it gives the "equirectangular" projection. This has none of the nice properties of Mercator (angles are heavily distorted).
yeah, you're right! but for showing a relatively small part of the world, it doesn't matter (and in fact, usually I'm plotting things in Antarctica where Mercator's area explosion is an anti-feature).
The more you zoom in, the better Mercator should be. That's a big part of why Web Mercator exists: there are no other options beyond mercator if you want a projection where north is always up, and right-angle street intersections look correct at any latitude. You can't notice the scale difference when zoomed in somewhere.
Going super close to the poles should be a challenge for both mercator and equirectangular projections, but at least Mercator won't distort shapes at the same time (and neither is globally accurate for area).
To add a bit more detail: the amount you have to zoom in for shapes to look right will increase with absolute latitude. So the equator pretty much always looks good on Mercator, Europe looks good if you're looking at the continent scale, but then in Greenland and Antarctica you'll need to be zoomed in to a regional or city-size, or even closer in. So when it's really important to get a broad-scale view near the poles, map makers will switch to something like a polar stereographic projection or similar. (I've personally just used a transverse mercator projection (whatever UTM zone is most convenient) when doing data analysis near the poles.)
Graphics libraries and windowing systems almost universally map (x, -y) - That is, Y=0 is at the top of your screen and Y=MAX is at the bottom, making Y coordinates backwards from conventional plotting graphs. X is standard. But talking about it is hard, even graphics programmers I know regularly make the same polarity mistakes one time out of ten, like you post originally had lat and long reversed in ranges (but used correctly elsewhere).
Just be glad we don't universally use Minecraft XYZ coordinates.
right，an internal rezeroed south east system makes it match the graphics system. So pixel positions and coordinates covary and are always positive. It makes debugging a million times easier
More radical would be to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around. You'd have the range wrap around naturally. But it's nice to have degrees for debugging and it's not tied to a type so you can have arbitrary precision. I also think you'd still have corner cases to deal with (but I'll have to think about this some more)
yeah, good question. My limited experience has shown me that you end up coding in assumptions that make the sign flip problematic :). There are all those infamous cases of systems crashing on planes and ships when they cross the equator. Ideally you'd test in all four quadrants of the globe but this ends up being cumbersome.
There is also the convenience of having your coordinates change in the same way as your display coordinates. So if something displays off of where it should then you can easily diagnose the problem. Everything is always in units of degrees relative to the top left corner (with maybe a scale factor) - whether you're looking at the whole globe or just a region. With a signed coordinate you'd be relative to the image center which is not how your display works. You need to track offsets and image widths/heights. Debugging gets nastier and you have off by one problems and whatnot. That's just been my experience so far
While it is common to casually use the lat/lon order, the lon/lat order was decided on as a matter of international treaty via ISO. This was inconsistent a long time ago even in ISO standards, but was resolved to the lon/lat format many years ago, is required for government systems, and is essentially settled. People may not like it but that is arguing with the weather. Everything is lon/lat from here on out and all new systems are designed this way.
For people that actually work in geospatial, there is no advantage to the lat/lon order and the lon/lat order has been the standard for decades already. Arguing about the order of polar coordinates is fighting a battle that was literally settled decades ago.
EPSG:4326 doesn't really use lat/lon. Sure, it's in the spec, but that part is irrelevant. Everything is stored in lon/lat for any relevant format when the projection is EPSG:4326. There have been some unfortunate decisions lately to make common APIs expect y,x if the projection is EPSG:4326 and x,y for pretty much everything else, but that's a backwards compatibility break that's going to wreak a fair amount of havoc.
It's also worth pointing out that a lot of this is conflating display order in UIs (which usually is lat/lon, often in DMS) with storage order and API conventions (which are usually lon/lat).
The vast majority of software that stores geographic information conforms to ISO 19125, which specifies lon/lat order. If you use PostGIS, for example, you are using ISO 19125. While conflicting ISO standards such as 6709 infamously exist, which is confusing for people that don't deal with geospatial data on a routine basis, the dominance of ISO 19125 for storage has strongly influenced all downstream representations.
Many early standards conflicted (e.g. coordinate order) or were under-specified (e.g. polygon winding). The Open Geospatial Consortium (OGC), whence many of these ISO standards came, sensibly made the decision many years ago that all future standards should treat these in a consistent and fully-specified way. Because of the pervasiveness and vast quantity of data stored as ISO 19125, adopting the ISO 19125 conventions were the least costly way of resolving these conflicts.
I've been working with GIS data from every type of industry for a long time, and the only place I ever see lat/lon order is in user interfaces. At the data and software level it is always lon/lat for compatibility and interoperability.
There is little to be gained by re-litigating the lon/lat coordinate order, since no value is gained by changing it (the choice is arbitrary), virtually all modern software systems use the same conventions at this point, and in many cases these conventions are codified in law across many countries.
Unless I'm misreading, ISO 19125 (2004) is later than ISO 6709 (1983), so using 19125 as an authority is questionable to say the least.
Isn't the reality that a bunch of software engineers wrote their software to use lon/lat because x, y is the intuitive ordering in the context of a cylindrical projection way of thinking, and ISO 19125 codified that common software practice without anyone really thinking about it or the conflicts it created?
That's hardly definitive, particularly when it contradicted ISO's own earlier standard (which codified the long-standing common communication practice of lat/lon). ISO standards themselves are weak without logical and practical commonplace usage backing them up, because the standards are paywalled.
Your experience, and the table in the OP article, shows that lon/lat has more usage in the software world, but that's not sufficient. There's enough confusion, and enough major players defecting from that recent "standard" of 19125, that the issue should be looked at again, re-litigated, and re-standardized. Everyone outside the narrow field of GIS software engineers and data wranglers expects lat/long. The issue has never been litigated at all outside of that insular world.
It seems like standardizing on the common practice (outside of the digital technical realm) of lat/lon is the right way to go:
The software world has the advantage that if there was consensus to change to lat/lon universally, they could patch it once, convert any data files once, and be done. The software world has much less inertia.
In contrast, the non-software world can't be readily converted to lon/lat. It's much more difficult to change people's everyday usage. Look at the mess caused by Americans using MM/DD/YYYY, or English-inspired use of Imperial over metric. It's difficult to convince people to change even when there are significant problems with the historical choice, and objective reasons for why they should change.
You are arguing with the weather. The use of lat/lon is obsolete in the same way XML is obsolete. This was already settled when I was learning about geospatial two decades ago. You are asserting "common practice" that isn't actually common practice. ISO 19125 conformance requirements are ubiquitous; I've never seen a requirement for ISO 6709 conformance in real application. That ship sailed a long time ago.
You are also grossly underestimating the scale of the lon/lat installed based. The lat/lon diehards are the inconsequential and insular part of the market by comparison.
There is no practical way to "patch" the countless exabytes of lon/lat currently sitting in cold storage. These are the largest data sets that exist, and it would be exceedingly unrealistic to expect the world to reformat this data, which they've been happily using up to this point, because a few people don't want to remember that the order is lon/lat. You might as well decree that everyone use XML to store their data while you're at it.
I literally don't care, because it doesn't actually matter. No amount of wishful thinking will cause a return to the imagined golden age of lat/lon.
You say it like it's a done deal, but virtually every book map paper and UI disagree with you.
Outside of the programming bubble we're not in a world where you ever need to think twice about the order. I don't go to Wikipedia and think "hmm I wonder which order they wrote their coordinates". I don't need to check the publication date of a map or book. I don't see that ever changing
And as I explained the benefits are kind of half-assed. If you want a more intuitive internal system than I think you can do better. You should full-ass it and re-zero it to whatever makes sense in your situation (or even change the units, or remap to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around) - but keep the API in standard notation.
Sure. That kinda misses the point but you can think of it that way. And the mirror universe projection of lon/lat is not a great projection but you're free to choose what you want.
But maybe don't expose your projection in your API?
Well, I need to be projection aware, as there are at least 6 that I’m using on a regular basis. (Wgs 84/espg 4326, web Mercator, itm (old and new), an equal area one, and a few local area lat Lon subsets.)
None of them are more correct, they’re just more convenient.
It was a random thought I had today. Please tell me why it's a bad idea haha :))
A lot of weird bugs happen at the edges/meridians. In a South/East system the edges are at the poles and in the middle of the Pacific Ocean. So you already eliminate weird southern hemisphere blow ups. Using wraparound would solve the Pacific problem I guess
Maybe unsigned long.. for some extra precision..
EDIT: unfortunately since I'm doing everything in Clojure unsigned math is kinda clunky :(
> Using wraparound would solve the Pacific problem I guess
I worked with such a coordinate system years ago, and there's definitely some advantages (fixed resolution, speed on some processors, memory usage) and some disadvantages ( not all software is wraparound aware and needs ported, debugging outside of decimal degrees is harder for me but I know some mathematicians who are more used to radians than anything else - perhaps you get used to it).
Thanks for the sanity check! Yeah, my napkin math was showing a very high resolution without any floats needed. I'm happy to hear it's been done before. It's going to ultimately come together as a GUI (it's a set of scripts so far) so fortunately I don't need to interface with any other software.
The debugging aspect may be a bit annoying I'll admit. Before printing you'd need to constantly convert your u_ints to degrees to make sense of them.
The main problems I'm seeing so far is that lon spans 360 and wraps around cleanly, but lat spans 180.. and when you go past the pole you don't actually wrap anywhere (you don't wanna jump to the other pole :)). What actually happens is that you end up on a different longitude. I'm not sure how to work around that. But then maybe you don't need to b/c that scenario shouldn't come up - while crossing the pacific will. At the moment I'm primarily shooting to select rectangular regions and then extract data (like elevation or precipitation) in those regions. Such a region could cross a meridian/equator - but it wouldn't make sense for it to go past the pole
On the JVM unsigned code is going to be a lot clunkier to write, but I'm hoping in the end it'll save me a ton of time debugging edge cases
I've seen lat being half as large as long done two ways.
1) Double the lat resolution and use two different scaling factors for converting each axis to degrees(less fun to debug, but hey, free 2x resolution or repurpose the LSB for something else)
2) Allow intermediate results on latitudes to temporarily enter the no-mans land between 90-180(and southern equivalent), then manually wrap back.
> On the JVM unsigned code is going to be a lot clunkier to write
> or remap to go from degrees to the 0 UINT_MAX range
Some systems do this internally, it has advantages beyond the wraparound. They still export standard ISO compliant data format though since that is what everyone knows.
ISO 19125 is the governing standard for representing geospatial data. This is used in government systems globally, which is the basic purpose of ISO standards, and in many countries (e.g. Western Europe) government systems are required to conform to these standards. This standard is ubiquitous in all of the software tooling for dealing with geospatial data.
Because the storage and interoperability of data is specified to use lon/lat, it strongly influences things that may not be specified by standard. Human user interfaces can do whatever they want, but software systems expect everything in lon/lat order.
There does still seem to be controversy on this point in tooling though? Popular tools like proj and pyproj now confusingly return different ordering for a different CRS, and a diff between UI conventions and code etc is really unfortunate and likely to cause bugs, so it doesn’t seem completely settled. e.g.
Those issues are specific to cartography, which used a mess of non-standardized conventions for centuries. Like with calendars, there is an almost unbounded set of edge cases when writing software to support it. Geospatial data from modern systems, which rounds to "all data", is virtually always presented as EPSG:4326 + ISO 19125 so the experience is pleasantly consistent, and as a practical matter you can't avoid this representation.
The vast majority of geospatial data is not intrinsically cartographic in nature and the primary use case is not making maps even if maps are sometimes used as a presentation layer. Consequently, cartographic conventions are correctly treated as legacy interfaces that require conversion into a modern standard; it wouldn't make sense for a modern software system to speak legacy standards natively.
Most modern geospatial data systems use an internal spatial reference system derived from WGS84 (not even straight EPSG:4326) that is optimized for efficient data processing. Remember, the vast majority of this data is primarily consumed by machines and virtually all of the data is required to be interoperable with machines. There is a very thin long tail of people using myriad legacy cartographic formats but they don't influence how geospatial data is handled because it is such a negligible percentage of the computing done on geospatial data these days.
I think culturally lat/lon is the standard - it is what looked right to me before I started working with geocoords.
Cartographically, in terms of standards, that seems to be the case. I don't think because libraries have been written which are backwards, that there should be some popularity contest - that's too small a bubble, just makes programmers sound like entitled asshats...
Even a govt. standard should not be the measuring stick - govts change policy with the wind, or different govts. The lon/lat programmers with the pitchforks are the upstart rebels here...
I think you are thinking about this in the wrong way.
Sure Lat/Lon is the common presentation format for this particular coordinate system.
Right now in Sweden the time is 10:41 (it would be great if it was a couple of hours later, then I could say it's 14:41 to demonstrate the 24 hour time format). Yet, in software, I would represent that as time in UTC. Only when presenting to the user would I convert that to the users time zone.
My last name contain the letter "ö". In software, I would use an unicode string internally, then when writing out I would encoded that to utf-8. (20 years ago, I would have used an old character encoding called ISO/IEC 8859-1 or something like that, but you get my point).
For some damn reason I till don't understand, the decimal separator in Sweden is the comma and not the period. Still I would represent numbers internally as an integer or maybe float, and then when printing to to the user would I convert that to "123,4" (123.4) or something like that.
In Sweden, WGS84 is not the only common coordinate system. There are many others: SWEREF and SWEREF TM for example. Yes internally, depending on usecase, I would probably use a representation of WGS84 as reference, then convert that to present to the user...
(Fellow Swede here). I really want to agree with you, but in practice, the difference between "internal" and "external" is not always clear. For example, if I was producing a printed document in Swedish, I would definitely use decimal commas. (By the way, the time now is not 10:54 — it's 10.54, if you are to believe "Svenska Skrivregler" :-) ) However, when printing output in a terminal window, a comma means that I can't copy-paste that number into that interactive Python session in another window. Coordinates as lat, lon means I can't copy-paste into PostGIS. Makes one long for those LISP systems of the legends, where the system kept track of where things on screen came from, so if the program printed a coordinate and you copied it from the terminal, it was copied as a coordinate, not as text...
So this is sorta above my pay grade but I think this is a tangential issue.
Even if you are reading exotic data in some parochial format you internally probably wanna use one consistent format. If you have some massive data sets and don't wanna convert on read-in then there are way around that (you can setup a memoization system to convert and cache on as-needed basis). This format should be intuitive and convenient. I proposed a South/East format.. but you're free to choose whatever you want here. But the point is that Lon/Lat is likely never a good choice at this junction. It still has issues and you generally can do better.
At the interface the default we've arrived to as a society Lat/Lon WGS84 :) The merits here are irrelevant. If you want to support other i/o formats then you may. That really depends on your usecases - but they shouldn't map to whatever format you've decided on internally. And even if they did, you probably shouldn't be using Lon/Lat internally anyway
What you use internally really depends on the application requirements. Different projections have different properties. Depending on the area you need to cover and the questions you need to answer you may need to use multiple projections and to match performance requirements you may need to store all of these projections so you don't always need to convert on the fly
> For some damn reason I till don't understand, the decimal separator in Sweden is the comma and not the period.
I'm curious to know the history of why (some?) Euro countries went with the common and the Anglo world went with the period. Some details:
> In France, the full stop was already in use in printing to make Roman numerals more readable, so the comma was chosen.[13] Many other countries, such as Italy, also chose to use the comma to mark the decimal units position.[13] It has been made standard by the ISO for international blueprints.[14] However, English-speaking countries took the comma to separate sequences of three digits. In some countries, a raised dot or dash (upper comma) may be used for grouping or decimal separator; this is particularly common in handwriting.
> In software, I would use an unicode string internally, then when writing out I would encoded that to utf-8.
I don't understand what distinction you're drawing here? UTF-8 is Unicode. In what way would you be modifying it at the presentation layer? (Unless you're dealing with true UI code, and are saying "I would map the characters to font glyphs according to the UTF-8 standard".)
I know UTF-8 isn't the only way of encoding Unicode codepoints, for what it's worth. I'm just struggling to see how you would be using just 'Unicode', as opposed to a particular encoding, at the storage layer. It's still just bits and bytes.
I think it would be more accurate to say that UTF-8 is a Unicode Transformation Format which by its name is logically distinct from Unicode itself. There are good reasons to store and process Unicode in UTF-8 format internally in many cases, but UTF-32 / UCS-4 would probably take over for internal processing if it weren't for memory usage and efficiency issues.
Internal representation isn't the issue. Software can internally represent coordinates any way that's consistent (and so bug-free).
The conflict is about interfaces, specifically interfaces using unlabeled number pairs, between software and humans, or software and other software. It's unfortunate that anyone would implement software with lat/long inputs/outputs, and think that they have the privilege of defining that order however suits them; what they obviously should do, and should have done, is take a moment to think, "How have people communicated earth coordinates in the past? Are there any standards that might be applicable?" and used that order. Of course, if tradition and standards were bad for some objective reason, that might justify it. But not just because some programmer wants to export their way of dealing with coordinates in x, y coordinate order from a cylindrical projection. That's not sufficient reason to upend tradition and introduce confusion and ambiguity in cases of |longitude| <= 90°.
I work as contractor for EUROCONTROL. 90% of the time, the usual order (Lat/long) is used in software. When this is not the case, it is a good indicator that I need to be careful about the conventions used to represent all data. I have already encountered the reversed wind direction and more frequently the use of m/s instead of knots (for wind speed).
A typical case of the governing body decides one thing but in practice the "since-always" used convention is still preferred I guess? At least this is my experience with dealing with reqs from customers within aviation.
I took it as in the presentation layer, but I can see where you're coming from. In that case I would agree with you, and I'm not sure why GP would complain about that.
As a rule, yes, but not necessarily and not everywhere. The important part is to have a coherent set of units, which usually is going to be SI units, but not always. If the user's preferred unit never is going to be SI, does it make sense to base your program on SI units?
For example, aviation deals heavily in flight levels (multiples of 100 ft). If flight levels are a first-class concept in your program, then you're already using non-SI units below the presentation layer. At this point you've established that some altitudes in your program are expressed in feet, and it might be a better idea to use feet for altitudes everywhere rather than introducing a lot of unit conversions. Or it might not be.
Right, I knew that not all SI units were base ten. But I also knew that lat/lon is in degrees, not radians. I also saw the Wikipedia section that knots are still used in industry rather heavily due to their relation to nautical miles. Also not SI.
I recall that astronomical units are also not SI.
Mentioning computers is just a cheap shot, I admit. Still, is valid.
Cooking is an odd one. The old units that were largely defined in thirds are quite useful. Weight is, of course, more reliable for baking, but you can go very far at home quantities with cups and spoons.
To be fair, I'm a large believer that the units are arbitrary and whatever you learned will be good. Such that if you learned SI, it had advantages off the bat. But I am in less agreement that they have an intrinsic advantage.
Knots and nautical miles are interesting because the nautical mile was originally based on latitude: one minute (1/60 degree) of latitude was 1 nautical mile.
So an airplane traveling due north at 120 knots would cover 2 degrees of latitude per hour.
Most of the US Customary and British Imperial units actually have similar logical definitions or derivations, but they aren't regularly taught anymore.
Right. My point was more that in industries where there is some advantage to keeping a non SI unit, they are want to do so without major external pressure.
So, knots persist because lat lon persists. Home cooks persist with imperial in some places because nobody cares to reprint all recipes and measuring devices. Astrological units because at that scale... Nothing scales. And computers, because binary won. (Curious to consider if ternary had been the winner...)
I confess I am actually personally moved by some of the intuitive arguments for older measurements. Usually very physical based and very in tune with numbers actually used in an industry. It is odd to think of a sixteenth inch wrench, but it is just the natural result of dividing by two, four times, after all. (That is, you have a measuring rod, put a midpoint on there. Four times. Now, do the same for millimeters?). (granted, in the age of computers, any measurement is much easier to do at the machining level.)
It is striking that the top response to a thoughtful, nuanced article about coordinates written by an expert in geospatial systems is someone who boldly declares "X is the standard" and concludes with "I'm a total noob".
>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.
Oversimplified... but:
Most raw/original geo-referenced imagery in the US are projected in a SPCS (state plane coordinate system) in survey-feet, which aren't defined in x,y but n,e (Northing, Easting) or sometimes e,n. This order isn't as universal as x,y, for various reasons. (UTM in meters is also common for larger areas.)
SPCSs aren't all the same type of projections, so Lambert conic (parallel defined) vs Transverse Mercator (meridian defined) (the two most common) means the "first" measurement traversed isn't always the same. (On a sphere, if I tell you to go 100 miles north, then 100 miles east, you get to a different point than 100 miles east, then 100 miles north.)
Being grid systems, this shouldn't matter, but surveyors who used to do manual transformations would get in the habit of the order they regularly used.
So "flipped" is a matter of perspective.
It's one of those things that's a tell for someones educational background and localisms. Surveyor/Geographer/Geodesist vs Scientist/Mathematician/Software Developer.
Did a progammer-first person develop a particular file format, or did a cartography/geography-first person? Or some combination of a compromise?
>I have no "geospatial" background
Checks out.
If you're a learn-by-doing person, I recommend looking up the transformations for a few common CRS/datums/projections and going through the equations manually, either with a quick script or in excel. Check/compare to results from the NGS tools page. The transform steps and math will reveal where order of operations matter.
Err, sorry I have a typo in my original post. The Y is "flipped" (not X). I feel a Northing Easting system should appeal to both surveyors and mathematicians b/c it matches the X-Y plane we're used to in math class. But unfortunately it doesn't match display coordinates which conventionally start in the upper left corner. If I output say an SVG and it's got some weird artifact or things are cropped strange due to some off-by-one errors then it's much easier to debug if your internal geographic coordinates are aligned to the final display coordinates. You don't need to do any mental translation and offsetting to figure out how the values correspond between the two systems
In fact I go so far as to output SVGs with degrees values (degrees relative to the upper left point) and then there is a global scale factor for the final image to fit whatever size I want - so the image units are in real degrees - this makes life a lot easier.
After reading all the responsese here my argument would be that you should use whatever internal representation is most convenient programmatically - and then you expose in your API or UI or whatever a system based on other criteria (though it's hard to see how lon/lat would ever be sensible here). Your internal and external systems don't have to have any relation.
As you've deduced my problem space isn't too concerned with projections at the moment. Both precipitation and elevation data comes in a GeoTIFF (ie. lat/lon grid). In fact doing any kind of projections would distort by grid and greatly complicate my life :) But it's something I will keep in mind. When you start looking at large areas then you effectively have different data densities at different ends of the region and this is not great (poleward things have disproportionately more data). Thanks for the extra information and references - it may come in handy eventually.
> 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.
I 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.
Reminds 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.
Looked 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.
And 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?
Ah, well here comes the problem - if your dependency changes a major version but your code seems to continue to run correctly, i.e. tests pass, how much more time do you need to spend to investigate the cause for the major version change? I think this example exposes the futility of semantic versioning.
Yeah, PROJ handled this correctly, introducing a new header file and eventually deprecating the old one after a while, making it hard to do the wrong thing. But for some reason pyproj must have kept the same interface across the breaking change?
> Ah, well here comes the problem - if your dependency changes a major version but your code seems to continue to run correctly, i.e. tests pass, how much more time do you need to spend to investigate the cause for the major version change?
You need to investigate the reasons for a major version change before updating the dependency and running tests any time one occurs, to see if any documented behavior you are expecting has changed.
Indeed, this was entirely our fault and as I said, we should have correctly pinned, at least the major version. Our tests did not catch the specific issue, because all code worked - just the output looked scrambled. There are tests that could catch this issue, but we did not anticipate it and therefore had no tests prepared.
A the the time of encountering, I dislike such issues. Stress, downtime, frustration.
But a few weeks later, I love them. They are a great opportunity to learn how well a test suite is setup. How it can be improved, cleaned up, refactored, or just kept the same.
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.
Well, 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.
Yeah, 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.
fortunately, between SRTMv3, ASTER, ArcticDEM and REMA, a free DEM is available for practically the entire world (maybe missing some subantarctic islands?).
But 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.
> In reality geocentric coordinates are unlikely to be used. But maybe it would be easier if they could be
I agree. When objects interact with each other, having everything as (x,y,z) makes many things a lot easier.
So in your example, ideally, you send the ship the (x,y,z) coordinates. Internally, we would have to worry about tides and figuring out exactly what the coordinates should be, but crew installing it would know exactly where to place it.
Not even counting the tides, sea level is not flat across the globe. We live on a spheroid with varying densities and other things which goes around bigger sphere and has big sphere next to it. In the end real world is quite messy.
I am with you, https://en.m.wikipedia.org/wiki/Earth-centered,_Earth-fixed_... would be my preference, too. Especially if we’re talking internal representation. My background is having to track objects that fly or go below the surface. Though as others have mentioned, asking “is this object on the ground currently” is a tiny bit complicated.
Mnemonic: 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).
I used to get it wrong. But at some point I started to remember that latitude tells something about the climate at a location and then it clicked for me. Or if it was that latitude determined which stars cover the night sky. Either of these. They are more permanent, longitude is just a matter of time.
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.
The problem is named named values often come with significant performance penalties in terms of storage. With data points in the billions it becomes significant
I 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.
Yeah, it's a API communication issue that tools like Typescript are designed to solve with "type information". Typescript's labeled tuples are a relatively recent addition, but an extremely welcome one especially here in this specific [lat, lon] versus [lon, lat] communication problem.
It’s also super handy for preserving parameter names when dealing with rest/spread in both runtime and static type positions, and even for naming new ones in static types for composition.
Top/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.
The 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).
"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.
I 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.
> 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.
228 comments
[ 4.2 ms ] story [ 317 ms ] threadI get the order wrong when working with geojson with embarrassing frequency...
http://www.macmillandictionaryblog.com/a-hotchpotch-of-redup...
tik tik tik
Citation: https://en.m.wikipedia.org/wiki/Tik_Tik_Tik_(1981_film)
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).
Btw, give that you have a PointCoordinates type, why not f(p: PointCoordinates)?
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.
"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.
But in math you care far more about labeling the angles correctly than about which order you list them in.
> Do you have a preference? Yes I do: longitude, latitude.
http://macwright.org/2016/07/15/longitude-latitude-is-the-ri...
The bullet points:
* Almost every geospatial format puts longitude first
* Almost all open source software uses longitude, latitude ordering
* longitude-first is the equivalent of XY ordering
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
I have a dirty prototype I need to rewrite soon so I was considering a coordinate system change. It'd make debugging much easier if the values drawn and the values of the coordinates had the same "directions"
I was a bit apprehensive to just yolo my own internal coordinate system bc it's a design decision you end up having to live with
Surely this is several typos? Longitude, which marks east-west, must span 360 degrees (-180 to 180, perhaps? although 0 to 360 is just as reasonable). Latitude, marking north-south, spans only 180 degrees, and therefore is presumably -90 to 90 (so that 0 is the equator).
Altitude
Vertical
If I ever need to confirm which is which, I use the the mnemonic above. I usually imagine latitude corresponding to rings on the earth moving up and down along the surface. This image is triggered by thinking about "altitude" in the context of latitude for me.
The latitude defines which of these "rings" the point is on.
https://cdn.britannica.com/07/64907-050-7ACA69C8/Facts-paral...
What I propose is to go "all the way" and make an internal positive/unsigned South/East coordinate system that naturally matches the display coordinate system (the inverted X-Y). It's sufficiently different that you'll never get confused and flip things at API boundaries. It's also sufficiently weird that you won't expose it to others :)
If things are looking weird or wrong on your display then you need to go back to your internal values to inspect what's wrong. When the internal value covary with th display values then this makes life significantly easier
Not to mention things have a tendency to blow up when you start testing in the southern hemisphere haha
That said.. I don't personally use any magic plotting packages. I just generate my own graphics with svg. It's quite easy and everything is debuggable
Going super close to the poles should be a challenge for both mercator and equirectangular projections, but at least Mercator won't distort shapes at the same time (and neither is globally accurate for area).
yeah, you're completely right!
Just be glad we don't universally use Minecraft XYZ coordinates.
More radical would be to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around. You'd have the range wrap around naturally. But it's nice to have degrees for debugging and it's not tied to a type so you can have arbitrary precision. I also think you'd still have corner cases to deal with (but I'll have to think about this some more)
There is also the convenience of having your coordinates change in the same way as your display coordinates. So if something displays off of where it should then you can easily diagnose the problem. Everything is always in units of degrees relative to the top left corner (with maybe a scale factor) - whether you're looking at the whole globe or just a region. With a signed coordinate you'd be relative to the image center which is not how your display works. You need to track offsets and image widths/heights. Debugging gets nastier and you have off by one problems and whatnot. That's just been my experience so far
For people that actually work in geospatial, there is no advantage to the lat/lon order and the lon/lat order has been the standard for decades already. Arguing about the order of polar coordinates is fighting a battle that was literally settled decades ago.
https://en.wikipedia.org/wiki/ISO_6709#Order,_sign,_and_unit...
EPSG:4326 also uses lat/long: https://epsg.org/crs_4326/WGS-84.html
It's also worth pointing out that a lot of this is conflating display order in UIs (which usually is lat/lon, often in DMS) with storage order and API conventions (which are usually lon/lat).
Many early standards conflicted (e.g. coordinate order) or were under-specified (e.g. polygon winding). The Open Geospatial Consortium (OGC), whence many of these ISO standards came, sensibly made the decision many years ago that all future standards should treat these in a consistent and fully-specified way. Because of the pervasiveness and vast quantity of data stored as ISO 19125, adopting the ISO 19125 conventions were the least costly way of resolving these conflicts.
I've been working with GIS data from every type of industry for a long time, and the only place I ever see lat/lon order is in user interfaces. At the data and software level it is always lon/lat for compatibility and interoperability.
There is little to be gained by re-litigating the lon/lat coordinate order, since no value is gained by changing it (the choice is arbitrary), virtually all modern software systems use the same conventions at this point, and in many cases these conventions are codified in law across many countries.
Isn't the reality that a bunch of software engineers wrote their software to use lon/lat because x, y is the intuitive ordering in the context of a cylindrical projection way of thinking, and ISO 19125 codified that common software practice without anyone really thinking about it or the conflicts it created?
That's hardly definitive, particularly when it contradicted ISO's own earlier standard (which codified the long-standing common communication practice of lat/lon). ISO standards themselves are weak without logical and practical commonplace usage backing them up, because the standards are paywalled.
Your experience, and the table in the OP article, shows that lon/lat has more usage in the software world, but that's not sufficient. There's enough confusion, and enough major players defecting from that recent "standard" of 19125, that the issue should be looked at again, re-litigated, and re-standardized. Everyone outside the narrow field of GIS software engineers and data wranglers expects lat/long. The issue has never been litigated at all outside of that insular world.
It seems like standardizing on the common practice (outside of the digital technical realm) of lat/lon is the right way to go:
The software world has the advantage that if there was consensus to change to lat/lon universally, they could patch it once, convert any data files once, and be done. The software world has much less inertia.
In contrast, the non-software world can't be readily converted to lon/lat. It's much more difficult to change people's everyday usage. Look at the mess caused by Americans using MM/DD/YYYY, or English-inspired use of Imperial over metric. It's difficult to convince people to change even when there are significant problems with the historical choice, and objective reasons for why they should change.
You are also grossly underestimating the scale of the lon/lat installed based. The lat/lon diehards are the inconsequential and insular part of the market by comparison.
There is no practical way to "patch" the countless exabytes of lon/lat currently sitting in cold storage. These are the largest data sets that exist, and it would be exceedingly unrealistic to expect the world to reformat this data, which they've been happily using up to this point, because a few people don't want to remember that the order is lon/lat. You might as well decree that everyone use XML to store their data while you're at it.
I literally don't care, because it doesn't actually matter. No amount of wishful thinking will cause a return to the imagined golden age of lat/lon.
Outside of the programming bubble we're not in a world where you ever need to think twice about the order. I don't go to Wikipedia and think "hmm I wonder which order they wrote their coordinates". I don't need to check the publication date of a map or book. I don't see that ever changing
And as I explained the benefits are kind of half-assed. If you want a more intuitive internal system than I think you can do better. You should full-ass it and re-zero it to whatever makes sense in your situation (or even change the units, or remap to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around) - but keep the API in standard notation.
But maybe don't expose your projection in your API?
None of them are more correct, they’re just more convenient.
:-/
A lot of weird bugs happen at the edges/meridians. In a South/East system the edges are at the poles and in the middle of the Pacific Ocean. So you already eliminate weird southern hemisphere blow ups. Using wraparound would solve the Pacific problem I guess
Maybe unsigned long.. for some extra precision..
EDIT: unfortunately since I'm doing everything in Clojure unsigned math is kinda clunky :(
> Using wraparound would solve the Pacific problem I guess
I worked with such a coordinate system years ago, and there's definitely some advantages (fixed resolution, speed on some processors, memory usage) and some disadvantages ( not all software is wraparound aware and needs ported, debugging outside of decimal degrees is harder for me but I know some mathematicians who are more used to radians than anything else - perhaps you get used to it).
The debugging aspect may be a bit annoying I'll admit. Before printing you'd need to constantly convert your u_ints to degrees to make sense of them.
The main problems I'm seeing so far is that lon spans 360 and wraps around cleanly, but lat spans 180.. and when you go past the pole you don't actually wrap anywhere (you don't wanna jump to the other pole :)). What actually happens is that you end up on a different longitude. I'm not sure how to work around that. But then maybe you don't need to b/c that scenario shouldn't come up - while crossing the pacific will. At the moment I'm primarily shooting to select rectangular regions and then extract data (like elevation or precipitation) in those regions. Such a region could cross a meridian/equator - but it wouldn't make sense for it to go past the pole
On the JVM unsigned code is going to be a lot clunkier to write, but I'm hoping in the end it'll save me a ton of time debugging edge cases
1) Double the lat resolution and use two different scaling factors for converting each axis to degrees(less fun to debug, but hey, free 2x resolution or repurpose the LSB for something else)
2) Allow intermediate results on latitudes to temporarily enter the no-mans land between 90-180(and southern equivalent), then manually wrap back.
> On the JVM unsigned code is going to be a lot clunkier to write
Wikipedia has a comparison: https://en.m.wikipedia.org/wiki/Binary_angular_measurement
Having x-y=5 and y-x=-5 can be quite handy, but there's also some concerns about integer overflow in C/C++.
Some systems do this internally, it has advantages beyond the wraparound. They still export standard ISO compliant data format though since that is what everyone knows.
https://en.m.wikipedia.org/wiki/ISO_6709
By government systems do you mean US government systems?
Because the storage and interoperability of data is specified to use lon/lat, it strongly influences things that may not be specified by standard. Human user interfaces can do whatever they want, but software systems expect everything in lon/lat order.
There does still seem to be controversy on this point in tooling though? Popular tools like proj and pyproj now confusingly return different ordering for a different CRS, and a diff between UI conventions and code etc is really unfortunate and likely to cause bugs, so it doesn’t seem completely settled. e.g.
https://github.com/pyproj4/pyproj/issues/225 https://github.com/OSGeo/PROJ/commit/6a7e24dce79f93b73f4919f...
The vast majority of geospatial data is not intrinsically cartographic in nature and the primary use case is not making maps even if maps are sometimes used as a presentation layer. Consequently, cartographic conventions are correctly treated as legacy interfaces that require conversion into a modern standard; it wouldn't make sense for a modern software system to speak legacy standards natively.
Most modern geospatial data systems use an internal spatial reference system derived from WGS84 (not even straight EPSG:4326) that is optimized for efficient data processing. Remember, the vast majority of this data is primarily consumed by machines and virtually all of the data is required to be interoperable with machines. There is a very thin long tail of people using myriad legacy cartographic formats but they don't influence how geospatial data is handled because it is such a negligible percentage of the computing done on geospatial data these days.
Cartographically, in terms of standards, that seems to be the case. I don't think because libraries have been written which are backwards, that there should be some popularity contest - that's too small a bubble, just makes programmers sound like entitled asshats...
Even a govt. standard should not be the measuring stick - govts change policy with the wind, or different govts. The lon/lat programmers with the pitchforks are the upstart rebels here...
Lat/Lon
Sure Lat/Lon is the common presentation format for this particular coordinate system.
Right now in Sweden the time is 10:41 (it would be great if it was a couple of hours later, then I could say it's 14:41 to demonstrate the 24 hour time format). Yet, in software, I would represent that as time in UTC. Only when presenting to the user would I convert that to the users time zone.
My last name contain the letter "ö". In software, I would use an unicode string internally, then when writing out I would encoded that to utf-8. (20 years ago, I would have used an old character encoding called ISO/IEC 8859-1 or something like that, but you get my point).
For some damn reason I till don't understand, the decimal separator in Sweden is the comma and not the period. Still I would represent numbers internally as an integer or maybe float, and then when printing to to the user would I convert that to "123,4" (123.4) or something like that.
In Sweden, WGS84 is not the only common coordinate system. There are many others: SWEREF and SWEREF TM for example. Yes internally, depending on usecase, I would probably use a representation of WGS84 as reference, then convert that to present to the user...
This is how I think about coordinates.
Even if you are reading exotic data in some parochial format you internally probably wanna use one consistent format. If you have some massive data sets and don't wanna convert on read-in then there are way around that (you can setup a memoization system to convert and cache on as-needed basis). This format should be intuitive and convenient. I proposed a South/East format.. but you're free to choose whatever you want here. But the point is that Lon/Lat is likely never a good choice at this junction. It still has issues and you generally can do better.
At the interface the default we've arrived to as a society Lat/Lon WGS84 :) The merits here are irrelevant. If you want to support other i/o formats then you may. That really depends on your usecases - but they shouldn't map to whatever format you've decided on internally. And even if they did, you probably shouldn't be using Lon/Lat internally anyway
I'm curious to know the history of why (some?) Euro countries went with the common and the Anglo world went with the period. Some details:
> In France, the full stop was already in use in printing to make Roman numerals more readable, so the comma was chosen.[13] Many other countries, such as Italy, also chose to use the comma to mark the decimal units position.[13] It has been made standard by the ISO for international blueprints.[14] However, English-speaking countries took the comma to separate sequences of three digits. In some countries, a raised dot or dash (upper comma) may be used for grouping or decimal separator; this is particularly common in handwriting.
* https://en.wikipedia.org/wiki/Decimal_separator
ISO seems to say use a comma:
* https://en.wikipedia.org/wiki/ISO/IEC_80000#Part_2:_Mathemat...
I don't understand what distinction you're drawing here? UTF-8 is Unicode. In what way would you be modifying it at the presentation layer? (Unless you're dealing with true UI code, and are saying "I would map the characters to font glyphs according to the UTF-8 standard".)
I know UTF-8 isn't the only way of encoding Unicode codepoints, for what it's worth. I'm just struggling to see how you would be using just 'Unicode', as opposed to a particular encoding, at the storage layer. It's still just bits and bytes.
The conflict is about interfaces, specifically interfaces using unlabeled number pairs, between software and humans, or software and other software. It's unfortunate that anyone would implement software with lat/long inputs/outputs, and think that they have the privilege of defining that order however suits them; what they obviously should do, and should have done, is take a moment to think, "How have people communicated earth coordinates in the past? Are there any standards that might be applicable?" and used that order. Of course, if tradition and standards were bad for some objective reason, that might justify it. But not just because some programmer wants to export their way of dealing with coordinates in x, y coordinate order from a cylindrical projection. That's not sufficient reason to upend tradition and introduce confusion and ambiguity in cases of |longitude| <= 90°.
> Meters per second (m/s) is the SI unit for velocity and the unit recommended by the World Meteorological Organization for reporting wind speeds
> Since 2010 the International Civil Aviation Organization (ICAO) also recommends meters per second for reporting wind speed when approaching runways
For example, aviation deals heavily in flight levels (multiples of 100 ft). If flight levels are a first-class concept in your program, then you're already using non-SI units below the presentation layer. At this point you've established that some altitudes in your program are expressed in feet, and it might be a better idea to use feet for altitudes everywhere rather than introducing a lot of unit conversions. Or it might not be.
Kind of interesting, as well, to consider this when talking about lat/lon. Do those attempt to be SI?
Time for SI is still seconds.
Which isn't base-10, yet is SI. So depends on if you accept adopted SI, or want to jump on the base-10 SI clock/time bandwagon.
And lat/lon is based on angles, not distance, with lon coming from time (delta time between solar noon in two locations).
But the SI unit(less) for angles is radians.
So... no, but it depends on how you interpret multiple SI inconsistencies.
I recall that astronomical units are also not SI.
Mentioning computers is just a cheap shot, I admit. Still, is valid.
Cooking is an odd one. The old units that were largely defined in thirds are quite useful. Weight is, of course, more reliable for baking, but you can go very far at home quantities with cups and spoons.
To be fair, I'm a large believer that the units are arbitrary and whatever you learned will be good. Such that if you learned SI, it had advantages off the bat. But I am in less agreement that they have an intrinsic advantage.
So an airplane traveling due north at 120 knots would cover 2 degrees of latitude per hour.
Most of the US Customary and British Imperial units actually have similar logical definitions or derivations, but they aren't regularly taught anymore.
So, knots persist because lat lon persists. Home cooks persist with imperial in some places because nobody cares to reprint all recipes and measuring devices. Astrological units because at that scale... Nothing scales. And computers, because binary won. (Curious to consider if ternary had been the winner...)
I confess I am actually personally moved by some of the intuitive arguments for older measurements. Usually very physical based and very in tune with numbers actually used in an industry. It is odd to think of a sixteenth inch wrench, but it is just the natural result of dividing by two, four times, after all. (That is, you have a measuring rod, put a midpoint on there. Four times. Now, do the same for millimeters?). (granted, in the age of computers, any measurement is much easier to do at the machining level.)
>Usually very physical based
Land records in the US are all feet, acres, furlongs, arpents, sections, and townships.
That's not changing.
And they all divide easily from townships of 36-square miles to 10-acre quarter-quarter-quarter-sections to 66x660ft-acres.
66 ft is a gunter's (surveyors) chain = 100 links
10 chains = 660ft = 1 furlong = 1/8 mile
It's a brilliantly thought out system, but most people promoting SI won't take the time to see the benefits.
Personally, I find it much easier to make blunders with SI, because a decimal shift one place over isn't always an obvious mistake.
Usually Dunning-Kruger is present.
Oversimplified... but:
Most raw/original geo-referenced imagery in the US are projected in a SPCS (state plane coordinate system) in survey-feet, which aren't defined in x,y but n,e (Northing, Easting) or sometimes e,n. This order isn't as universal as x,y, for various reasons. (UTM in meters is also common for larger areas.)
SPCSs aren't all the same type of projections, so Lambert conic (parallel defined) vs Transverse Mercator (meridian defined) (the two most common) means the "first" measurement traversed isn't always the same. (On a sphere, if I tell you to go 100 miles north, then 100 miles east, you get to a different point than 100 miles east, then 100 miles north.)
Being grid systems, this shouldn't matter, but surveyors who used to do manual transformations would get in the habit of the order they regularly used.
So "flipped" is a matter of perspective.
It's one of those things that's a tell for someones educational background and localisms. Surveyor/Geographer/Geodesist vs Scientist/Mathematician/Software Developer.
Did a progammer-first person develop a particular file format, or did a cartography/geography-first person? Or some combination of a compromise?
>I have no "geospatial" background
Checks out.
If you're a learn-by-doing person, I recommend looking up the transformations for a few common CRS/datums/projections and going through the equations manually, either with a quick script or in excel. Check/compare to results from the NGS tools page. The transform steps and math will reveal where order of operations matter.
https://www.ngs.noaa.gov/ https://geodesy.noaa.gov/NCAT/ https://geodesy.noaa.gov/INFO/datums-transformations.shtml
In fact I go so far as to output SVGs with degrees values (degrees relative to the upper left point) and then there is a global scale factor for the final image to fit whatever size I want - so the image units are in real degrees - this makes life a lot easier.
After reading all the responsese here my argument would be that you should use whatever internal representation is most convenient programmatically - and then you expose in your API or UI or whatever a system based on other criteria (though it's hard to see how lon/lat would ever be sensible here). Your internal and external systems don't have to have any relation.
As you've deduced my problem space isn't too concerned with projections at the moment. Both precipitation and elevation data comes in a GeoTIFF (ie. lat/lon grid). In fact doing any kind of projections would distort by grid and greatly complicate my life :) But it's something I will keep in mind. When you start looking at large areas then you effectively have different data densities at different ends of the region and this is not great (poleward things have disproportionately more data). Thanks for the extra information and references - it may come in handy eventually.
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
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
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
[2]: https://pyproj4.github.io/pyproj/stable/gotchas.html#axis-or...
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
You need to investigate the reasons for a major version change before updating the dependency and running tests any time one occurs, to see if any documented behavior you are expecting has changed.
But a few weeks later, I love them. They are a great opportunity to learn how well a test suite is setup. How it can be improved, cleaned up, refactored, or just kept the same.
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.
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.
I agree. When objects interact with each other, having everything as (x,y,z) makes many things a lot easier.
So in your example, ideally, you send the ship the (x,y,z) coordinates. Internally, we would have to worry about tides and figuring out exactly what the coordinates should be, but crew installing it would know exactly where to place it.
Why aren't we using some self-explanatory terms?
I propose "rotitude", "iclinitude". Guess which is which.
h/t https://www.geographyrealm.com/remember-difference-latitude-...
https://www.google.com/search?hl=en&q=vertitude
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.
I'm literally in the process of processing 100gb compressed spatial json and it's not enjoyable
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/t...
You can align them by restoring the vowel length and writing "laatitude" & "longitude" :-)
It never happens that you try to generate {X} from {Lon} alone.
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.
https://www.gim-international.com/content/article/european-d...
Toward the end is info on ED50's relationship to WGS-84.
> Commonly an ellipsoidal model is part of a more encompassing geodetic datum.
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
It is common to see lat/long, but in fairness long/lat makes more sense as it reflects x/y axis.
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)
What does this mean?