4 ms·

No, it's not always that way. There are plenty of libraries mentioned all over this thread that do it the other way, just like in graphics you can't just assume

No, it's not always that way. There are plenty of libraries mentioned all over this thread that do it the other way, just like in graphics you can't just assume you're in a left or right handed system, and in relativity you can't assume time has the negative sign in the metric. It might be "right" by someone's definition, but it's not universal, so it has to be documented (and there are always extremely important cases you'll run into where people have made the "wrong" choice). Even when it comes to matrix math there are textbooks that treat them as (row, column) and others that go (column, row), it's always best to be explicit. And yes, negatives make sense and are "legal", by which I mean they pick out locations in a meaningful way and should not be considered out of bounds. What you probably mean is that they are not canonical, and by convention people usually wrap them to points within a certain range. Doing this wrong is a common source of bugs in maps.

SergeAx 5y ago
Latitude and longitude are geometric values. Programming libraries are secondary abstractions to Earth geometry (third degree abstractions, to be precise, there's WGS84 or other abstraction in between). Negative longitude, negative latitude and even latitude modulo above 90 degrees will produce a point on the globe, but library-wise I would not allow it to pass input validation.
- WorldMaker 5y ago
  Programming libraries are also things that need to do math on data points (in a way that programmers themselves can reason about). One of the reasons many of the math focused libraries prefer [lon, lat] data is because it is (close to, in some projections) an "intuitive" approach to [x, y] order and brings the geographic abstraction closer to the Euclidean geometry abstraction to make it easier for the programmers to reason with (regardless of which projection abstractions are in between). (Needing to do a deeper dive into some of Leaflet's code at one point gave me a somewhat greater appreciation over why there is such disagreement between [lat, lon] and [lon, lat] formats. Abstractions are hard, and when you know you already need a crazy projection abstraction or three, sometimes the simplicity of [x, y, z] Euclidean approximations feels like "home" for as much as you can reason in it and expect the projection math to "just work" with it as long as you are consistent.)

SergeAx 5y ago

Latitude and longitude are geometric values. Programming libraries are secondary abstractions to Earth geometry (third degree abstractions, to be precise, there's WGS84 or other abstraction in between). Negative longitude, negative latitude and even latitude modulo above 90 degrees will produce a point on the globe, but library-wise I would not allow it to pass input validation.

WorldMaker 5y ago
Programming libraries are also things that need to do math on data points (in a way that programmers themselves can reason about). One of the reasons many of the math focused libraries prefer [lon, lat] data is because it is (close to, in some projections) an "intuitive" approach to [x, y] order and brings the geographic abstraction closer to the Euclidean geometry abstraction to make it easier for the programmers to reason with (regardless of which projection abstractions are in between). (Needing to do a deeper dive into some of Leaflet's code at one point gave me a somewhat greater appreciation over why there is such disagreement between [lat, lon] and [lon, lat] formats. Abstractions are hard, and when you know you already need a crazy projection abstraction or three, sometimes the simplicity of [x, y, z] Euclidean approximations feels like "home" for as much as you can reason in it and expect the projection math to "just work" with it as long as you are consistent.)