3 ms·

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

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.
- ramses0 2y ago
  So many things are "Typed" but don't appear to be. 3PM (time zone). "Hello" (UTF-8/ASCII). 38.8977,77.0365 (WGS84). It's effectively the "NASA Mars Metric" mistake all over the place: https://www.simscale.com/blog/nasa-mars-climate-orbiter-metric/ https://www.simscale.com/blog/nasa-mars-climate-orbiter-metr...
- zzo38computer 2y ago
  Yes, I think that including the datum is the way to do, and the datum to be included should be mapped according to the tectonic plate being mapped. The program can then include the table of conversions between them, in order to plot the data on the map correctly (e.g. in case it includes multiple tectonic plates, or to convert between GPS and map coordinates, etc; this conversion might require also knowing the correct time). If you are plotting on a map then you can either use the same datum if it is known to be the same one for the entire map (e.g. because it is a single tectonic plate being mapped and using that plate's datum), or you can convert to the proper datum if necessary. When you are mapping only one tectonic plate then you will not have to worry about the conversion because it will use that plate's datum and then it will already be correct. This is true with text as well; the character encoding can be stored with it. You can then select a suitable font if you have it, or otherwise use conversion for fallback if necessary. (In some cases, e.g. between UTF-8 and UTF-16 and UTF-32, this can be done losslessly, because they are all encodings of the same character set (this can also work if converting to a superset, e.g. ASCII to Unicode or JIS to TRON). Other times, that isn't ideal and doesn't work very well; like the example given above about maps with multiple tectonic plates, you can have text with multiple languages, too. And, again, the conversion can involve other stuff too (time in the case of WGS84, but in the case of character encodings (especially Unicode) it is much more complicated).) And then, another comment mentions "3PM (time zone)". Even in that case, converting time zones will require knowing the date as well (and in some cases it might be ambiguous); "3PM" is not good enough. In all of these cases, improved documentation is helpful because it can sometimes avoid these kind of problems. If the documentation makes it clear what map coordinates to use and what character encodings to use, then it can be helpful.

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.

ramses0 2y ago
So many things are "Typed" but don't appear to be. 3PM (time zone). "Hello" (UTF-8/ASCII). 38.8977,77.0365 (WGS84). It's effectively the "NASA Mars Metric" mistake all over the place: https://www.simscale.com/blog/nasa-mars-climate-orbiter-metric/ https://www.simscale.com/blog/nasa-mars-climate-orbiter-metr...
zzo38computer 2y ago
Yes, I think that including the datum is the way to do, and the datum to be included should be mapped according to the tectonic plate being mapped. The program can then include the table of conversions between them, in order to plot the data on the map correctly (e.g. in case it includes multiple tectonic plates, or to convert between GPS and map coordinates, etc; this conversion might require also knowing the correct time). If you are plotting on a map then you can either use the same datum if it is known to be the same one for the entire map (e.g. because it is a single tectonic plate being mapped and using that plate's datum), or you can convert to the proper datum if necessary. When you are mapping only one tectonic plate then you will not have to worry about the conversion because it will use that plate's datum and then it will already be correct. This is true with text as well; the character encoding can be stored with it. You can then select a suitable font if you have it, or otherwise use conversion for fallback if necessary. (In some cases, e.g. between UTF-8 and UTF-16 and UTF-32, this can be done losslessly, because they are all encodings of the same character set (this can also work if converting to a superset, e.g. ASCII to Unicode or JIS to TRON). Other times, that isn't ideal and doesn't work very well; like the example given above about maps with multiple tectonic plates, you can have text with multiple languages, too. And, again, the conversion can involve other stuff too (time in the case of WGS84, but in the case of character encodings (especially Unicode) it is much more complicated).) And then, another comment mentions "3PM (time zone)". Even in that case, converting time zones will require knowing the date as well (and in some cases it might be ambiguous); "3PM" is not good enough. In all of these cases, improved documentation is helpful because it can sometimes avoid these kind of problems. If the documentation makes it clear what map coordinates to use and what character encodings to use, then it can be helpful.