You thought OpenStreetMap data uses the WGS84 datum? No it doesn't
openstreetmap.org
openstreetmap.org
We should inform data consumers, so that they can decide to convert the coordinates to WGS84 if they want to.
As someone who works in the GIS space, if we get data without this crucial information it’s sometimes very difficult to find the original datum to perform transformations and usually amounts to some form of educated guesswork based on the warp from WGS84 and the origin of the data “what datum/projection would I have used if I was the data creator?”
I always push for detailed metadata, preferably in the same location/artifact. I'm regularly surprised by people who don't understand why it's important and just think "it's too much hassle".
People, even the ones who ought to know better, don't even seem to think it's necessary to specify their datum. It's bizarrely common to get a giant spreadsheet with coordinates in it and no datum. I've never seen data with its vertical datum specified.
Don't get me started on the situation in China. https://en.wikipedia.org/wiki/Restrictions_on_geographic_dat...
The problem would be taken a lot more seriously if continental drift was 10m per year instead of a few cm.
Edit: Someone has downvoted this. It's an important point to remember when using OSM. Many GIS datasets are developed in a way that the accuracy and precision of the data is consistent across the entire dataset. OSM doesn't bother with this, because it's really hard to do, especially globally. That doesn't make OSM less useful for making consumer maps (there's no problem if data is off by 2 or 4 meters or whatever), but it can be a problem if say you were trying to make a legal determination about property ownership. OSM isn't a useful source for the latter task and would have to fundamentally change to become so.
Different datum -> different lat/long/alt.
Disclaimer: Trimble alum
That's incredible
https://slate.com/news-and-politics/2011/03/japanese-earthqu...
I think this alone means the question in the blog post is answered.
OSM should pick a datum time, used for persistent storage, and then store a time-varying deformation model to adjust the way things are displayed. That deformation model needs to allow all kinds of warping etc.
Any idea how the different plate motion models behave near plate boundaries? There are a few plate boundaries in areas that are interesting for human users. The East African Rift Valley is famous, but there are others as well.
For example, a polygon that becomes self-intersecting because some of it's points are on different plates.
Thats bad for linters and database constraints...
For anyone using these kind of transformations, the boundary between the preferred models for two countries may well be discontinuous!
Ultimately the correct way to deal with this is to use a global time dependent deformation model. Some countries with large internal deformation have already gone to the effort of producing local versions. For example New Zealand: https://www.linz.govt.nz/data/geodetic-system/datums-project....
I guess there will eventually be a high quality global deformation map available but I wasn't aware of any such thing in general use as of two years ago.
But then other coordinate systems are based on something on the ground? So it is what, the based on the vector between some reference object on the (moving) plate and a local point on it? But then there are also smaller distortions of the plate that can make the plate-local coordinates inaccurate?
And I'm guessing normal GPS coordinates are from the non-moving sky coordinates?
As for the timestamp, this is probably the easiest solution no? OSM keeps track of all modifications.
Anybody who is paying attention already knows that OpenStreetMap isn't all that precise, which is all the post is really saying.
There is a lot of data out there that is effectively user generated. What this means is that someone with a phone goes to a some place and than posts some content (photo, tweet, restaurant check in, etc) with some kind of coordinate. All this stuff ends up in databases. This stuff was never very accurate. If you collect POI data from different sources about the same POI, the coordinates are going to vary by tens of meters. Worse if users manually enter the coordinates because people lie. Also, real world places are not points but have geometry, sometimes that can be tens to hundred of meters. E.g. the coordinate of the Louvre in Paris is meaningless because the place is huge. Also the whole of open street maps is basically many different users contributing what they think should be the coordinates of things.
Proximity is a good signal when de-duplicating POIs but not reliable by itself. E.g. in many Japanese cities, some bars are on the n-th floor of some sky scraper and there may be dozens of restaurants and bars in the same building. Also, they close and re-open as something new regularly; so there's a lot of stale GEO data out there like reviews of restaurants that no longer exist or that just opened and get tagged to the wrong POI, buildings that got demolished, or new buildings and streets that got constructed recently in what formerly was a field.
So, GIS data is messy and the coordinate system is helpful for getting close enough that you can figure it out once you are near enough to see the signs but generally not very precise.
But then, there are more elaborate things like indoor maps that are geo-referenced; or 3D building models that are shown on a map. These things are usually modeled separately and then manually or automatically aligned with a map. Most data sets specifying coordinates have no notion of anything else than a pair of doubles that are generally referred to as the WGS 84 coordinates. This includes open street maps; which mostly consists of user generated data by users with no clue about this issue using inaccurate gps signals and either some local knowledge about stuff is relative to other stuff in OSM or some satellite imagery.
So, the implication of this article is that most of that data is only valid in the context of whatever it was geo-referenced to. Which, in most cases is simply unknown since it is typically not recorded in datasets or even known by whoever records the data.
This explains a lot of things about some stuff I've been seeing in 3D scenery for flight simulators like x-plane where if you have e.g. some satellite imagery and 3D objects for real world buildings, airports, etc. it is quite common for them to be slightly misaligned since the data comes from lots of different sources, all lacking meta information about what their coordinate system actually is supposed to be, that are combined automatically.