[MetaCRS] CS-Map: policy for changing coordinate system/datum/transformation definitions in place

[Raven Kopelman]

Hi Hugues,

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.

In the long run, we will be able to stay closer to the CS-Map trunk if grid
transformations are not changed in place.

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?

Cheers,

--
Raven Kopelman | Software Developer

Safe Software Inc.
T 604.501.9985 x 331
raven.kopelman at safe.com | www.safe.com


On Fri, Oct 4, 2013 at 6:00 AM, Hugues Wisniewski <
hugues.wisniewski at autodesk.com> wrote:

>  Hi Raven,****
>
> ** **
>
> Some digging was needed to answer this one in detail.****
>
> ** **
>
> The transformation definition NAD83_to_HARN/02 was introduced in October
> 2010 for the implementation of RFC 2, which introduced the new
> GeodeticTransformation dictionary****
>
> http://trac.osgeo.org/csmap/changeset/1926****
>
> It was referencing the Hawaiian grid file Usa/Harn/hihpgn.l?s, which is
> not in UTM-2****
>
> ** **
>
> I was branched and released that way in CS-Map 13.00 and CS-Map 13.10****
>
> 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****
>
> http://trac.osgeo.org/csmap/changeset/2193****
>
> ** **
>
> The reasons why this happened are:****
>
> **-        **The definition was wrong, the grid file was not covering the
> area****
>
> **-        **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.
> GDC files are the ancestors of the GeodeticTransformation dictionary file.
> 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.
> 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 3rd party UI exercising that API.
> 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.
>
> ****
>
> Comments about this are welcome of course. We could think of a different
> option going forward if that’s an issue.****
>
> ** **
>
> Thanks****
>
> ** **
>
> Hugues
>
> ****
>
> ** **
>
> *From:* metacrs-bounces at lists.osgeo.org [mailto:
> metacrs-bounces at lists.osgeo.org] *On Behalf Of *Raven Kopelman
> *Sent:* Tuesday, October 01, 2013 11:03 PM
> *To:* metacrs at lists.osgeo.org
> *Subject:* [MetaCRS] CS-Map: policy for changing coordinate
> system/datum/transformation definitions in place****
>
> ** **
>
> Hi all,****
>
> ** **
>
> In r2193 NAD83_to_HARN/02 was changed in place to use the correct grid
> files.****
>
> ** **
>
> 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.****
>
> ** **
>
> Was NAD83_to_HARN/02 an oversight or should I expect more in-place changes
> like this?****
>
> ** **
>
> Thanks,****
>
> --
> Raven Kopelman | Software Developer
>
> Safe Software Inc.
> T 604.501.9985 x 331
> raven.kopelman at safe.com | www.safe.com****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/metacrs/attachments/20131004/84bb66e8/attachment.html>