Hi All, I thought this a good place to start this discussion.
At NearMap we have been investigating ways to improve the accuracy of our imagery, in particular in respect to Land Agency cadaster and other imagery suppliers, but it also has impacts on our use of OSM data. Basically the issue at hand is Datum Epochs. Let me explain. GPS data is generally captured in WGS84/Geodetic LL coordinates. WGS84 was tied to ITRF several years ago so is essitntially equivalent to ITRF, and its a "static" datum, ie the datum point is essentially fixed wrt the Earth. We capture all our data using ITRF datum, and this is used for the website using WGS84/Mercator (so called WebMercator, using a shperoidal geoid, as used by OSM, GMaps, Bing, Yahoo). So far so good. The "problem" with this is that the ground is actually moving due to continental drift relative to the ITRF datum point. In Australia this movement is in the order of 7cm a year in a NNE direction. Issue 1: As we have currently implemented it, this drift means NearMap photos will move over time ie, they are shown where they were at the capture date rather than moved to a common epoch, so you will see the drift over time for each new survey, something we're not sure is useful despite being "correct". Issue 2: Several countries have "fixed" local Datums based on WGS84, so that data does not move relative to the local datum over time. In Australia the standard is GDA94, which was fixed from WGS84 at epoch 1994.0. The current ITRF is ITRF2000, which itself differs from ITRF1992 (what WGS84 was based on at 1994.0 when GDA94 was fixed) by approximately 2cm. Due to drift, GDA94 now differs from WGS84 by approximately 1.05m. It seems basically no GIS software I am aware of takes this epoch conversion into account when performing GDA94->WGS84 datum changes, meaning Cadastre maintained in GDA94, converted to WGS84/Mercator, and overlayed on our imagery is actually shifted systematically to the SSW (as the drift is NNE) by approximately 1.05m (ie, it's shown where it was in 1994, rather than where it is today), which customers are obviously having issues dealing with despite it really being a problem with their software not doing GDA94->WGS84 using correct epoch conversions. Issue 3: OSM data is captured and stored in WGS84, sometimes with the capture epoch, other times not. This means OSM data is increasingly "wrong" as it ages compared to where features are on the ground as the ground moves beneath it. From what I gather Mapnik does not do any sort of epoch correction on the OSM data when rendering, so if you have a collection of features in a tile captured over say a decade there will be up to 70cm error in them compared to "current" imagery. Issue 4: Other imagery sources used GCP points (often just locations of roundabouts etc in the Cadastre) and reproject everything to that. So although they line up with the cadaster, they are actually moving everything from where it really is. The bottom line is we're not really sure what the best solution is. If we covert the imagery to a fixed epoch (say 1994.0 in Australia, to match GDA94 and make the cadaster people happy), then OSM data will move relative to our current imagery by 1.05m. It also means we are not showing things where they really are/were. The other option is try to educate customers on doing correct GDA94->WGS84 conversions, but it's going to be a hard exercise convincing people they are doing it wrong. Does OSM have a policy on epochs? Any plans to do epoch correction? I'm guessing since OSM came out of Europe where drift is only 1cm/year the answer is probably no but I'm interested on any input anyone has. thanks Simon Cope CTO - NearMap -- View this message in context: http://old.nabble.com/OSM%2C-NearMap-and-datum-epochs-tp26910919p26910919.html Sent from the OpenStreetMap - Australian Talk mailing list archive at Nabble.com. _______________________________________________ Talk-au mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-au
