4 ms·

Good post, I assume this was in response to the "Every map of China is wrong" post a few weeks ago? https://news.ycombinator.com/item?id=40220072 https://news.y

by gen3 2y ago

Good post, I assume this was in response to the "Every map of China is wrong" post a few weeks ago? https://news.ycombinator.com/item?id=40220072 https://news.ycombinator.com/item?id=40220072 Its not surprising to me that there are so many competing standards, I'm curious how that ends up being rectified in the software (is it all internally translated on ingest?)

michaelt 2y ago
The standards mentioned in the article aren't really competing standards in the normal sense. It's simply that the continents drift relative to one another. So if you want to make a map of Australia and the continent is drifting by 3 inches per year relative to other continents, you often want to define your map's coordinates as relative to some fixed point on your continent.
- lxgr 2y ago
  Oh, the luxury of having a continent-sized country entirely located on (and far from the borders of) a single tectonic plate :)
  - johannes1234321 2y ago
    Sad if such a country moves about 1.5m in just 20 years and thus offsets any external reference (including satellites for GPS and imaging) https://www.sciencealert.com/australia-s-about-to-move-1-5-metres-to-the-north https://www.sciencealert.com/australia-s-about-to-move-1-5-m...
    - lxgr 2y ago
      That's true for all countries, since every single one is located on a moving tectonic plate! But some countries experience little "intra-country coordinate drift" per year, which can make local/regional geodetic datums attractive. That approach wouldn't work for the US, for example: https://en.wikipedia.org/wiki/San_Andreas_Fault https://en.wikipedia.org/wiki/San_Andreas_Fault
solardev 2y ago
This post was from 2019, and is standard mapping stuff not necessarily having to do with any Chinese obfuscation. It's not necessarily a case of "competing" standards, but choosing to apply local optimizations (or not) for better precision, at a cost of increased error (imprecision) elsewhere. The Earth isn't a perfect static sphere, it's a roundish blob with dynamic bumps that crawl and ooze along its surface over time. You can kinda try to average it out everywhere (WGS84) or if your area of concern is smaller, choose a datum that's more locally accurate but that would be inappropriate if used elsewhere. The Wiki article is a better explanation I think: https://en.wikipedia.org/wiki/Geodetic_datum?wprov=sfla1 https://en.wikipedia.org/wiki/Geodetic_datum?wprov=sfla1 The hard part for OSM (and any long lived community effort) is that their data sources are varied, and they have to first identify the source datum (sometimes it's in metadata but not always, and might need to be manually measured) and then decide what to do about it, on a case by case basis. In the article it didn't seem like they'd made a decision yet. Wikipedia talks more about the "rectification" (datum transformation) process more: https://en.wikipedia.org/wiki/Geographic_coordinate_conversion#Datum_transformations?wprov=sfla1 https://en.wikipedia.org/wiki/Geographic_coordinate_conversi... You can download the FOSS app QGIS and play around with its transformation and reprojection tools if you want to see how software handles this. The algorithms it uses under the hood are also open source CLI tools so you can check out the math there if you're interested. (I love maps but hate math, so that part is all black box magic to me lol).
- ryandrake 2y ago
  Right. The way I was taught is that a latitude/longitude cannot be accurately plotted on a map unless you know the lat/lon's datum and the map's datum, and ensure they match. Naive applications might assume a popular datum like WGS84, but not every map uses WGS84, so your locations will be plotted incorrectly if there is a mismatch. Kind of like how many developers now just assume a string of bytes called "text" is encoded in UTF-8, but if they are actually encoded differently, you may not render the string correctly. Ideally, every latitude/longitude pair entered into OSM should specify datum as metadata, but as you say, the existing data is probably very incomplete.
  - 2y ago

by gen3 2y ago

michaelt 2y ago

The standards mentioned in the article aren't really competing standards in the normal sense. It's simply that the continents drift relative to one another. So if you want to make a map of Australia and the continent is drifting by 3 inches per year relative to other continents, you often want to define your map's coordinates as relative to some fixed point on your continent.

lxgr 2y ago
Oh, the luxury of having a continent-sized country entirely located on (and far from the borders of) a single tectonic plate :)
- johannes1234321 2y ago
  Sad if such a country moves about 1.5m in just 20 years and thus offsets any external reference (including satellites for GPS and imaging) https://www.sciencealert.com/australia-s-about-to-move-1-5-metres-to-the-north https://www.sciencealert.com/australia-s-about-to-move-1-5-m...
  - lxgr 2y ago
    That's true for all countries, since every single one is located on a moving tectonic plate! But some countries experience little "intra-country coordinate drift" per year, which can make local/regional geodetic datums attractive. That approach wouldn't work for the US, for example: https://en.wikipedia.org/wiki/San_Andreas_Fault https://en.wikipedia.org/wiki/San_Andreas_Fault

solardev 2y ago

This post was from 2019, and is standard mapping stuff not necessarily having to do with any Chinese obfuscation. It's not necessarily a case of "competing" standards, but choosing to apply local optimizations (or not) for better precision, at a cost of increased error (imprecision) elsewhere. The Earth isn't a perfect static sphere, it's a roundish blob with dynamic bumps that crawl and ooze along its surface over time. You can kinda try to average it out everywhere (WGS84) or if your area of concern is smaller, choose a datum that's more locally accurate but that would be inappropriate if used elsewhere. The Wiki article is a better explanation I think: https://en.wikipedia.org/wiki/Geodetic_datum?wprov=sfla1 https://en.wikipedia.org/wiki/Geodetic_datum?wprov=sfla1 The hard part for OSM (and any long lived community effort) is that their data sources are varied, and they have to first identify the source datum (sometimes it's in metadata but not always, and might need to be manually measured) and then decide what to do about it, on a case by case basis. In the article it didn't seem like they'd made a decision yet. Wikipedia talks more about the "rectification" (datum transformation) process more: https://en.wikipedia.org/wiki/Geographic_coordinate_conversion#Datum_transformations?wprov=sfla1 https://en.wikipedia.org/wiki/Geographic_coordinate_conversi... You can download the FOSS app QGIS and play around with its transformation and reprojection tools if you want to see how software handles this. The algorithms it uses under the hood are also open source CLI tools so you can check out the math there if you're interested. (I love maps but hate math, so that part is all black box magic to me lol).

ryandrake 2y ago
Right. The way I was taught is that a latitude/longitude cannot be accurately plotted on a map unless you know the lat/lon's datum and the map's datum, and ensure they match. Naive applications might assume a popular datum like WGS84, but not every map uses WGS84, so your locations will be plotted incorrectly if there is a mismatch. Kind of like how many developers now just assume a string of bytes called "text" is encoded in UTF-8, but if they are actually encoded differently, you may not render the string correctly. Ideally, every latitude/longitude pair entered into OSM should specify datum as metadata, but as you say, the existing data is probably very incomplete.
- 2y ago