Published: 1st April 2017 😋
OpenStreetMap is set to be the first world-wide geo database that actively tracks plate tectonics. The OSM Foundation board has given the green light for tectonic correction to be applied to the OSM database, starting today.
You won’t notice it immediately – the changes are minuscule enough to be laughed at by some. But the effects are undeniable, and our always dedicated sysadmin team has been hard at work to devise queries against our database that correct for plate tectonics.
As you know, the earth’s surface is made of tectonic plates that drift apart slightly over time. With OSM using the WGS84 coordinate reference system (as opposed to e.g. ETRS89 which also has latitudes and longitudes but defines them relative to fixed markers), our coordinates get “out of sync” with time.
This movement can amount to up to 10 centimetres per year. Luckily, models exist that tell us just how much the earth is moving at any given location. And of course our data model provides us not only with the latitude and longitude of a point, but also with the time when it was entered. Assuming the data was correct at the time of entering OpenStreetMap, we can compute exactly how much that particular point has moved in the time since it was entered, and we can update the coordinates accordingly. (This is, of course, just half of the story – where aerial imagery has been used to trace data, we rely on correct source tagging to automatically determine the date when the images were taken, to compute the applicable tectonic correction.)
A point that was entered just yesterday won’t move at all; a point entered at the same location 5 years ago may have to be moved by up to 0.5 metres.
In order not to burden our database with needless new version numbers for nearly all node objects, we’ve chosen to simply update the coordinates for all objects in-place; this means that the tectonic correction happens seamlessly, without leaving traces in the object history.
The first corrections will be applied today, and we’ll revisit the issue on the same day in the coming years.
If this all sounds like techno-babble to you – just take away one thing: OSM does everything in their power to achieve maximum data quality and accuracy.
This post is also available in: Ukrainian
“This entry was posted in geodata on March 31, 2017 by Frederik Ramm.”
Timezones are hard 😉
OK. I’ve sneakily shifted the date of the blog post. Much like the shifting of node coordinates we’re going to be doing soon
oh but now I’ve moved it back again because I realise that’s also causing wordpress to shift it to a different URL without redirect. gah!
When I posted this I wasn’t particularly trying to make sure it was posted on April 1st because after all that’s only according to UK time. It had been April 1st in Sydney for hours already. But now that I look at it (and Derick’s comment) hmm I suppose the date displayed on the blog post should really be April 1st.
Moving different aged data by different distances will be fairly complex and may result in some skewed road connections. We’ll be running some worldwide Maproulette challenges and Tasking Manager projects to get your help in fixing this.
After that we’ve given some consideration to frequency of updates. Because the process will be automated and will not result in history entries, and given the precision of OSM node coordinates we have in the database, we decided we might as well maximise tectonic alignment going forwards by running our script to move every node very slightly once every hour.
I cannot laught at it.
No one could tell me how to map the planimetric points in Belgium.
Finally, a long-awaited feature.
It is possible to review the code/scripts that will do the shift prior to execute it ?
I could not find it anywhere !
Will version be incremented for node ?
I suspect osm2pgsql will have hard time recalculating all the ways and polygon geometries… hard week-end for our tile servers 😉
Doesn’t this mechanical edit have to follow the mechanical edit policy ?
A much welcome addition to OSM, but I don’t think you’re going far enough. There should be an API to query datasets at specific times, there are vital questions to be answered such as “where exactly was the Eiffel Tower located where dinosaurs still existed? Where will it be in 10000000000000001?” In fact, based on natural soil deposition rates, it would be great to have a feature that could predict vertical depth too, eg. replying “under 300m of dirt” to the latter question. Anyway, congrats to the team!
Although this might just be an April fools joke, I think this is a serious issue.
There is a lot of progress at the moment with the Australian Datum Modernisation http://www.icsm.gov.au/geodesy/modern.html, and I’m very interested in what OSM can and should do in the context of that.
At least will allow us to maintain accurate and up-to-date maps of our fearsome Drop Bears
http://eprints.utas.edu.au/15881/1/2012_Janssen_AusGeog_journal_version.pdf
Australia is one of the most mobile places, shifting 2.7 inches a year (northward and with a slight clockwise rotation). After we’ve fixed some of these open notes, and data issues and mapped some more useful details, like all the landuse, all the buildings, all the shops, addresses on all the buildings, or maybe just mapped more of these details in places to reduce inconsistency. We’ll need to run more mapping parties and ramp up the local community there a bit more, form a OSMF local chapter and really get organised, and we’ll need to drive better usage of the map to motivate all the that, and then after that, yeah we should have a think about this.
Pingback: OpenStreetMap Blog
Pingback: weeklyOSM 350 | weekly – semanario – hebdo – săptămânal – haftalık – 週刊 – týdenÃk – edisi