<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-NZ" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Martin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Your comments below address what I was much less precisely referring to as a "philosophical" question of whether a coordinate transformation (involving a datum
shift) should be uniquely defined and invertible. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">While I agree that these transformations do involve some error in their definition what I'm mainly interested, in this discussion thread, is how they are defined
and implemented within GIS systems. In these systems most spatial definitions are not stochastically defined and most users may expect well defined transformations, eg from national datums to global datums. This certainly can be provided by late binding,
but it is not guaranteed by late binding alone - it also requires constraints on the conversions database (including the one you specify, for reversing a transformation).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">None the less I agree that there are issues in trying to define these transformation uniquely. Even between global systems there are multiple published versions
of transformations (eg ITRF96-ITRF2008) and no "right" answer.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Cheers<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Chris<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Martin Desruisseaux [mailto:martin.desruisseaux@geomatys.fr]
<br>
<b>Sent:</b> Saturday, 10 January 2015 8:46 a.m.<br>
<b>To:</b> Chris Crook; metacrs@lists.osgeo.org<br>
<b>Subject:</b> Re: [MetaCRS] Fwd: Re: [Proj] Time dependent coordinate transformations<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Hello Chris<o:p></o:p></p>
<p>Le 09/01/15 18:46, Chris Crook a écrit :<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>The ambiguity I was hinting at was not just to do with converting from one coordinate system to another. It also relates to converting a data set from one coordinate system to another, and then to a third versus converting directly from the first to the third, or for that matter from one to another and then back again.<o:p></o:p></pre>
</blockquote>
<p>Indeed a <tt><span style="font-size:10.0pt">CRS_A</span></tt> → <tt><span style="font-size:10.0pt">WGS84</span></tt> →
<tt><span style="font-size:10.0pt">CRS_B</span></tt> <i><u>transformation</u></i> may not produce the same results than a
<tt><span style="font-size:10.0pt">CRS_A</span></tt> → <tt><span style="font-size:10.0pt">CRS_B</span></tt> transformation. But this may actually be an issue of the pivot system. Coordinate
<i><u>transformations</u></i> (not to be confused with coordinate <i><u>conversions</u></i> in ISO 19111 terminology) are valid only in some domain of validity, and have a limited accuracy (not related to the computer floating point precision). So the
<tt><span style="font-size:10.0pt">CRS_A</span></tt> → <tt><span style="font-size:10.0pt">WGS84</span></tt> transformation may be valid only in some area with an accuracy "<tt><span style="font-size:10.0pt">error_A</span></tt>", and the
<tt><span style="font-size:10.0pt">WGS84</span></tt> → <tt><span style="font-size:10.0pt">CRS_B</span></tt> transformation may be valid only in some other area with accuracy "<tt><span style="font-size:10.0pt">error_B</span></tt>". Naively (I may be wrong)
I would presume that the <tt><span style="font-size:10.0pt">CRS_A</span></tt> → <tt>
<span style="font-size:10.0pt">WGS84</span></tt> → <tt><span style="font-size:10.0pt">CRS_B</span></tt> transformation would be valid only in the intersection of the
<tt><span style="font-size:10.0pt">CRS_A</span></tt> → <tt><span style="font-size:10.0pt">WGS84</span></tt> and
<tt><span style="font-size:10.0pt">WGS84</span></tt> → <tt><span style="font-size:10.0pt">CRS_B</span></tt> domains of validity with a precision not better than
<tt><span style="font-size:10.0pt">max(error_A, error_B)</span></tt>, or maybe <tt><span style="font-size:10.0pt">error_A + error_B</span></tt>. This may not be the same domain of validity and precision than a direct
<tt><span style="font-size:10.0pt">CRS_A</span></tt> → <tt><span style="font-size:10.0pt">CRS_B</span></tt> transformation.<o:p></o:p></p>
<p>On the reversibility, the EPSG database usually stores a (<i>sourceCRS</i>, <i>
targetCRS</i>) pairs only in one way, for example <tt><span style="font-size:10.0pt">CRS_A</span></tt> →
<tt><span style="font-size:10.0pt">CRS_B</span></tt> but not <tt><span style="font-size:10.0pt">CRS_B</span></tt> →
<tt><span style="font-size:10.0pt">CRS_A</span></tt>. Instead they explain in their documentation how to reverse the operation. For a
<i>Molodensky</i> transformation we just need to reverse the sign of parameter values. For map projections this is more complicated, but there is no ambiguity. So I don't think that the consistency concern applies to the conversions or transformations back
to the original CRS.<o:p></o:p></p>
<p><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>Depending on how the late binding tables are constructed there would be no assurance that these transformations would give consistent results. Indeed, I suspect that if mathematically if both these were enforced then that would be equivalent to using an arbitrary pivot coordinate system (...snip...)<o:p></o:p></pre>
</blockquote>
<p>I think they would be mathematically equivalent (ignoring numerical errors) for coordinate
<i>conversions</i>, but I would be very surprised if they were equivalent for coordinate
<i>transformations</i> (i.e. a coordinate operation involving a datum shift) because of the stochastic nature of the process. This is the discussion in my previous paragraphs.<o:p></o:p></p>
<p>But in addition to all the above, I don't see how coordinate transformations through a pivot could address the problem mentioned in my previous email, regarding the transformation steps not being the method specified by authoritative mapping agencies...<o:p></o:p></p>
<p><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>Of course there is a philosophical question as to whether coordinate transformations should give unique or consistent results.<o:p></o:p></pre>
</blockquote>
<p>I'm not sure what "uniqueness" means in the context of coordinate transformations (not conversions). As mentioned in my previous email, there is many possible transformation methods between two CRS. Even if you give me explicit Bursa-Wolf parameters (the
numbers in the - now deprecated - <tt><span style="font-size:10.0pt">TOWGS84</span></tt> element), assuming the rotation parameters are zero, there is at least 3 different ways to use those parameters:
<i>Geocentric translation</i>, <i>Molodensky</i> and <i>Abridged Molodensky</i>. Each way will give slightly different results, and there is absolutely nothing in the
<tt><span style="font-size:10.0pt">TOWGS84</span></tt> element or elsewhere in the
<tt><span style="font-size:10.0pt">WKT</span></tt> telling us which method to use. The method to use if often specified by the national mapping agency for a particular country, so just saying "I unconditionally use the most accurate method" is not necessarily
appropriate from an interoperability point of view...<o:p></o:p></p>
<p><o:p> </o:p></p>
<p>Regards,<o:p></o:p></p>
<p> Martin<o:p></o:p></p>
<p><o:p> </o:p></p>
</div>
</div>
<br>
<hr>
<font face="Verdana" color="Black" size="2">This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If
you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from
LINZ. Thank You.<br>
</font>
</body>
</html>