<div dir="ltr">Hi Hugues,<div><br></div><div>Now that GDC files are no longer used it doesn't seem like there is a meaningful distinction between the difficulty of editing grid and non-grid transformations. I had assumed the relaxed attitude about GDC edits had more to do with the pain of having to add a new datum method and GDC file to avoid editing them.</div>
<div><br></div><div>In the long run, we will be able to stay closer to the CS-Map trunk if grid transformations are not changed in place.</div><div><br></div><div>As an aside, the VALIDATION parameter changes to all the MULREG transformations (1.401->1.1) significantly reduced their effective areas of interest, resulting in datum based fallback usage in more cases. You can see 13km differences in Canadian datapoints converted via NAD27-48_to_WGS84 after the VALIDATION param change. Is that type of in-line change considered acceptable because the points are outside the official supported region?</div>
<div><br></div><div>Cheers,</div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">--<br>Raven Kopelman | Software Developer<br><br>Safe Software Inc.<br>T 604.501.9985 x 331<br><a href="mailto:raven.kopelman@safe.com" target="_blank">raven.kopelman@safe.com</a> | <a href="http://www.safe.com" target="_blank">www.safe.com</a></div>
</div>
<br><br><div class="gmail_quote">On Fri, Oct 4, 2013 at 6:00 AM, Hugues Wisniewski <span dir="ltr"><<a href="mailto:hugues.wisniewski@autodesk.com" target="_blank">hugues.wisniewski@autodesk.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Raven,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Some digging was needed to answer this one in detail.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The transformation definition NAD83_to_HARN/02 was introduced in October 2010 for the implementation of RFC 2, which introduced the new GeodeticTransformation
dictionary<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><a href="http://trac.osgeo.org/csmap/changeset/1926" target="_blank">http://trac.osgeo.org/csmap/changeset/1926</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">It was referencing the Hawaiian grid file Usa/Harn/hihpgn.l?s, which is not in UTM-2<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I was branched and released that way in CS-Map 13.00 and CS-Map 13.10<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">As you found out, it got fixed in March 2012 for CS-Map 14.00, and the correct grid files were added instead of the one for Hawaii<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><a href="http://trac.osgeo.org/csmap/changeset/2193" target="_blank">http://trac.osgeo.org/csmap/changeset/2193</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The reasons why this happened are:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>-<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The definition was wrong, the grid file was not covering the area<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>-<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Since the beginning of CS-Map history, the only dictionary changes that have been tolerated were the content of the GDC files. There’s been only a
handful of those changes. <br>
GDC files are the ancestors of the GeodeticTransformation dictionary file. <br>
They are also the only changes the end user could perform on the local machine. GDC files were text files and could be manually edited, for instance for Canada where grid files need to be downloaded by the end user from the Canadian web site.<br>
When the GeodeticTransformation dictionary file replaced the GDC files, the same logic was maintained. Editing of the grid files is only doable through the API or from a 3<sup>rd</sup> party UI exercising that API.<br>
Based on this concept the Hawaian grid file was removed and the transformation was fixed without having recourse to the logic described in your email.<br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Comments about this are welcome of course. We could think of a different option going forward if that’s an issue.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks<u></u><u></u></span></p><div class="im">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hugues<br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:metacrs-bounces@lists.osgeo.org" target="_blank">metacrs-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:metacrs-bounces@lists.osgeo.org" target="_blank">metacrs-bounces@lists.osgeo.org</a>]
<b>On Behalf Of </b>Raven Kopelman<br>
<b>Sent:</b> Tuesday, October 01, 2013 11:03 PM<br>
<b>To:</b> <a href="mailto:metacrs@lists.osgeo.org" target="_blank">metacrs@lists.osgeo.org</a><br>
<b>Subject:</b> [MetaCRS] CS-Map: policy for changing coordinate system/datum/transformation definitions in place<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div><div>
<p class="MsoNormal">Hi all,<u></u><u></u></p><div><div class="h5">
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In r2193 NAD83_to_HARN/02 was changed in place to use the correct grid files.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I was under the impression that in-place changes were not allowed; that we would always deprecate the bad definition and create a new one. Certainly this has been the recent approach when hundreds of datums/systems/transformations with
bad transformation rotation signs were replaced.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Was NAD83_to_HARN/02 an oversight or should I expect more in-place changes like this?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">--<br>
Raven Kopelman | Software Developer<br>
<br>
Safe Software Inc.<br>
T <a href="tel:604.501.9985%20x%20331" value="+16045019985" target="_blank">604.501.9985 x 331</a><br>
<a href="mailto:raven.kopelman@safe.com" target="_blank">raven.kopelman@safe.com</a> |
<a href="http://www.safe.com" target="_blank">www.safe.com</a><u></u><u></u></p>
</div>
</div>
</div>
</div></div></div>
</div>
</div>
</blockquote></div><br></div>