Hacker News Reader

Comment by geokon | Hacker News Reader

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

View on HN

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.

When I look up ISO, I find ISO 6709, which specifies latitude before longitude by default.

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

Thus the need for the One True Standard, which surely will be perfected this time around.

Just prefix the Longitude with L, for Longitude, that will clear up any ambiguity

Yep. Maybe use a small l for latitude. Judicious font choices should ensure little room for confusion.

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.

Congratulations, you’ve just (re)invented projections.

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.

> remap to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around

:-/

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 :(

Sub-cm resolution everywhere with only 32 bits.

> 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

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++.

I actually think it's a really neat idea. It gives off a hacky vibe, but as long as it's well-documented it should work well.

> 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.

Do you have a citation for that? The only standard I can find is 6709.

https://en.m.wikipedia.org/wiki/ISO_6709

By government systems do you mean US government systems?

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.

Thanks.

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...

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 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).

Aren't m/s the correct unit for wind speed? https://en.m.wikipedia.org/wiki/Wind_speed

> 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

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.

Well, if the aircraft speed is in knots (which is generally the case), you'd rather have wind speeds in the same unit.

It's easier to store and process everything in SI units and then convert to the user's preferred unit in the presentation layer.

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.

This is one of those amusing areas where folks learn that SI units have only been adopted for elementary topics. Storage in a hard drive? Not SI.

Kind of interesting, as well, to consider this when talking about lat/lon. Do those attempt to be SI?

>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.

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.)

16ths and even 32nds are common wrench increments.

>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.

Sounds like you and I would be in violent agreement. :D

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 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...

This is how I think about coordinates.

(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.

* 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...

> 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.

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.

Thanks for the sanity check

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

I tend to roll with GeoJSON and the language's equivalent of a map/dict.

>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.

https://www.ngs.noaa.gov/ https://geodesy.noaa.gov/NCAT/ https://geodesy.noaa.gov/INFO/datums-transformations.shtml

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.

> 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).

yes, typo. Thanks for catching that. edited it to match

Cool.. So now I can finally remember. Longitude is LONGer because it goes all the way around.. LATitude I dunno.. is like a latte filling up?

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.

Latitude

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...

The lateral line on a fish goes from head to tail. :)

lat is swedish for lazy, so I remember it as laying down, ie horizontal

LATitude is from the LATin for sideways.

I always say "Latitude? More like flatitude."

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)

Why not signed?

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

That's what I'm saying, you map the negative latitude and longitude to negative numbers

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".

Indeed. I appreciate the self-deprecation of the person recognizing they aren't an expert but are in the space anyhow.

Usually Dunning-Kruger is present.

> 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

> "Lat/Lon is really the standard." [citation needed]

ISO 6709 for starters.

I learnt something today. It does indeed appear to be a nearly universal standard. Thank you!

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...

Lat/Lon

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)

Just a small detail, but longitude goes from -180 to 180. Or, if you use the hemisphere abbreviations, 180W to 180E.

The numbers in British National Grid references are eastings then northings, so lat lon isn’t universal in national mapping standards.

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).

plays around in QGIS

yeah, you're completely right!

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.)

lat also sorts before lon, alphabetically. So easy to remember.

Reply on news.ycombinator.com