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

[Hugues Wisniewski]

Hi Raven,

Are you saying that there's been a change in precision after the new multiple regression format was introduced.
A 13km shift? But only outside the system's boundary? What about inside it?
I remember Norm worked on all this. I wouldn't have much insight about that change

Hugues

From: Raven Kopelman [mailto:raven.kopelman at safe.com]
Sent: Saturday, October 05, 2013 1:24 AM
To: Hugues Wisniewski
Cc: metacrs at lists.osgeo.org
Subject: Re: [MetaCRS] CS-Map: policy for changing coordinate system/datum/transformation definitions in place

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<mailto:raven.kopelman at safe.com> | www.safe.com<http://www.safe.com>

On Fri, Oct 4, 2013 at 6:00 AM, Hugues Wisniewski <hugues.wisniewski at autodesk.com<mailto: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> [mailto: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<mailto: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<tel:604.501.9985%20x%20331>
raven.kopelman at safe.com<mailto:raven.kopelman at safe.com> | www.safe.com<http://www.safe.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/metacrs/attachments/20131008/b0d36c29/attachment-0001.html>