<div dir="ltr"><div class="gmail_default" style="font-size:small"><div class="gmail_default">Hi all,</div><div class="gmail_default"><br></div><div class="gmail_default">Scott mentioned &quot;treating WGS84 as a &#39;static&#39; or &#39;plate-fixed&#39; datum in the &quot;+towgs84 approximation error&quot; thread. I&#39;ll take that as my segue into the topic of dynamic datums and time dependent datum transformations.</div><div class="gmail_default"><br></div><div class="gmail_default">There is a good introduction/overview of the topic in <a href="http://ceur-ws.org/Vol-1142/paper6.pdf">http://ceur-ws.org/Vol-1142/paper6.pdf</a>. This was written from an Australian and New Zealand perspective, but the general issues are global. There are &quot;International Case Studies&quot; of USA and Great Britain.</div><div class="gmail_default"><br></div><div class="gmail_default">Mike Craymer has written some nice accessible material on this topic as well. See, for example, <a href="http://www.naref.org/transf/nad83_hydroscan2006.pdf">http://www.naref.org/transf/nad83_hydroscan2006.pdf</a>.</div><div class="gmail_default"><br></div><div class="gmail_default">As a community, we have managed to largely ignore the issue of dynamic datums for a long time. As precise point positioning technology becomes more and more available, and more and more users are able to access cm level positions in the ITRF, we are not going to be able to continue to ignore this issue.</div><div class="gmail_default"><br></div><div class="gmail_default">Generally, there are two classes of challenges that we face with.</div><div class="gmail_default"><br></div><div class="gmail_default">Firstly, we need to store the epoch of measurement with any position that record - if that is not implicit in the definition of the reference frame being used. That isn&#39;t a trivial challenge, if our database and/or our software architecture assumes that a coordinate has only 3 dimensions. </div><div class="gmail_default"><br></div><div class="gmail_default">Secondly, we need to use that epoch to perform a time dependent datum transformation.</div><div class="gmail_default"><br></div><div class="gmail_default">In general, transforming coordinates from ITRF to a plate-fixed datum will require a 14 parameter datum transformation, and coordinate propagation to the reference epoch for that datum.</div><div class="gmail_default"><br></div><div class="gmail_default">The 14 parameter tansformation is straight-forward (as long as you know the measurement epoch).</div><div class="gmail_default"><br></div><div class="gmail_default">Coordinate propagation is not so straight-forward. </div><div class="gmail_default"><br></div><div class="gmail_default">In GDA94 the coordinate propagation is combined with the 14 parameter datum transformation. But Australia is the &quot;lucky country&quot;, geodetically speaking.</div><div class="gmail_default"><br></div><div class="gmail_default">An Euler pole approach works well if you are not close to a plate boundary.</div><div class="gmail_default"><br></div><div class="gmail_default">For places like California or New Zealand you need a more sophisticated velocity/displacement/distortion model.</div><div class="gmail_default"><br></div><div class="gmail_default">So finally, a question for the Proj-4 community, and a plea to the wider geodetic community:</div><div class="gmail_default"><br></div><div class="gmail_default">To the Proj-4 community: Are there plans to add time-dependent datum transformations to Proj-4? (Or is that support already there?)<br></div><div class="gmail_default"><br></div><div class="gmail_default">To the wider geodetic community: Are we able to work together on developing/defining standards for representing and sharing velocity/displacement/distortion models, rather than having a &quot;tower of Babel&quot; where every national authority develops and publishes a slightly different model, and every software developer has to try to implement that model.<br></div><div class="gmail_default"><br></div><div class="gmail_default">Regards,</div><div class="gmail_default">Nick.</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div></div></div>