[talk-au] OSM, NearMap and datum epochs

[Simon Cope]

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.