<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Sam,<br>
<br>
I suppose a good way to minimize datum-related systematic errors
in geographic data would be to:<br>
- specify your "storage" datum (e.g. WGS84(G1150) )
(<a class="moz-txt-link-freetext" href="http://www.geod.nrcan.gc.ca/faq_e.php#23">http://www.geod.nrcan.gc.ca/faq_e.php#23</a>)<br>
- give approved methods of transforming data from various datums
to your storage datum.<br>
<br>
On the other hand, the magnitude of non-systematic/random
positioning errors in the incoming data is about 3 to 5 meters (at
best) for navigation grade GPS receivers and 5 to 50 meters for
NAD83 CANVEC Canadian topo data, so the NAD83/WGS84 1.5m difference
would not have much of an impact.<br>
<br>
Looking at the OpenStreetMap FAQ, their attitude is "if you don't
like the accuracy, fix it", which is pragmatic. Personally I'd like
some kind of accuracy estimate on each geographic feature, but
requiring that would likely bring the crowdsourcing to screeching
halt.<br>
<br>
You might get some more opinions on the Proj4 mailing list...<br>
<pre class="moz-signature" cols="72">Best Regards,
Brent Fraser</pre>
<br>
On 3/22/2011 12:03 AM, Sam Vekemans wrote:
<blockquote
cite="mid:AANLkTi=_HctCj34ubKi9F_UBc2SwvWsnWEPQKCUX1cTK@mail.gmail.com"
type="cite">Hi, OSGeo-discussion list,
<div><br>
<div>I just wanted to forward this message from Brendan,
hopefully someone who knows enough about projections can help
with this, so to decide on which coordinates system to use,
and how to handle coordinates shifting.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Sam<br>
<br>
<div class="gmail_quote">---------- Forwarded message
----------<br>
From: <b class="gmail_sendername">Brendan Morley</b> <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:morb_au@commonmap.info">morb_au@commonmap.info</a>></span><br>
Date: Mon, Mar 21, 2011 at 5:05 AM<br>
Subject: [OSM Fork] A technical geodesic note about
CommonMap - national vs international datums<br>
To: Sam Vekemans <<a moz-do-not-send="true"
href="mailto:acrosscanadatrails@gmail.com">acrosscanadatrails@gmail.com</a>><br>
Cc: "<a moz-do-not-send="true"
href="mailto:osm-fork@googlegroups.com">osm-fork@googlegroups.com</a>"
<<a moz-do-not-send="true"
href="mailto:osm-fork@googlegroups.com">osm-fork@googlegroups.com</a>>,
<a moz-do-not-send="true"
href="mailto:friends@commonmap.info">friends@commonmap.info</a><br>
<br>
<br>
Sam etc.,<br>
<br>
I've been thinking a bit further about which datum to use
for coordinates in CommonMap. As you know it can mean 1-2
metres difference between your current national datum (
NAD83(CSRS) ) and the GPS datum ( WGS84(G1150) ~ ITRF2000 ).<br>
<br>
While WGS84 seems attractive because of direct compatibility
with the GPS system, it's actually seems to be quite horrid
from a geodesist's point of view.<br>
<br>
This is because NAD83(CSRS) coordinates are basically tied
to the North America continental plate, therefore are
expected to converge to finer coordinates over time, but
hopefully never drifting.<br>
<br>
However, WGS84 coordinates are basically tied to the average
of all continental plates. Therefore a WGS84 coordinate is,
strictly speaking, out of date as soon as you measure it.<br>
<br>
This doesn't work so well in a geo database where, once you
capture a coordinate, it's expected to be pretty much
stable. Otherwise, how often do you run through the
database to update the coordinates?<br>
<br>
So, what I'm now suggesting is to run the imports in the
current national datum, e.g. NAD83(CSRS), and make a note of
the import datum as part of the changeset. The results
should agree to 2 metres today, but will get worse over
time.<br>
<br>
Then, we set up an additional function in the rails code to
transform the national datum to the international WGS84
datum, "just in time". In other words, predict what the
WGS84 coordinates should be at the time you call the
CommonMap API. Currently this would be the Helmert
transformation from NAD83(CSRS) to WGS84(G1150) ~ ITRF2000,
then the continental drift factors from (I think) ITRF2000's
epoch 1997.0 to today. I think we would ignore tidal
factors, they are not really of any cadastral significance,
and in any case I don't think PROJ4 is set up to go that
far.<br>
<br>
Manually entered coordinates would still assume the epoch of
the time they were entered, and if they were entered in the
Canadian area, they would be transformed back into the
NAD83(CSRS) datum for stable storage of coordinates.<br>
<br>
To help classify which coordinates belong on which
continental plates (and therefore calculate drift back to
the NAD83(CSRS), GDA94 datums etc) we can take advantage of
previous work, of which this seems to be the most
comprehensive to date:<br>
<br>
<a moz-do-not-send="true"
href="http://peterbird.name/publications/2003_PB2002/2001GC000252.pdf"
target="_blank">http://peterbird.name/publications/2003_PB2002/2001GC000252.pdf</a><br>
<br>
<br>
Thanks,<br>
Brendan<br>
<br>
-- <br>
Brendan Morley<br>
President, CommonMap Inc.<br>
<a moz-do-not-send="true"
href="mailto:morb_au@commonmap.info" target="_blank">morb_au@commonmap.info</a><br>
<a moz-do-not-send="true" href="http://commonmap.org/"
target="_blank">http://commonmap.org/</a><br>
Queensland Incorporated Association 37762<br>
Also find us on Facebook, Twitter and LinkedIn<br>
<font color="#888888">
--<br>
<br>
</font></div>
<br>
</div>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.osgeo.org">Discuss@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/discuss">http://lists.osgeo.org/mailman/listinfo/discuss</a>
</pre>
</blockquote>
</body>
</html>