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

Tue Oct 8 09:29:10 PDT 2013

Hi Hugues,

Yes, in r2193 the validation value on all multiple regression
transformations was decreased.

I only closely examined a single transformation: NAD27-48_to_WGS84.  Most
of Canada used to be considered inside the boundaries of the
transformation; afterwards most of Canada is not inside.  That results in
the datum fallback being used in more cases, with significant changes to
some coordinate locations.  The worst I found was 13 kilometers.

All the other multiple regression transformations had similar adjustments
around their boundaries, but I didn't look at them as closely.

Cheers,

--
Raven Kopelman | Software Developer

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

On Tue, Oct 8, 2013 at 8:51 AM, Hugues Wisniewski <
hugues.wisniewski at autodesk.com> wrote:

>  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 | 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/20131008/5a6d4c09/attachment.html>