[MetaCRS] CS-Map policy on multiple transformations per datum

[Hugues Wisniewski]

Hi Raven,

The reason why there's only one transformation is only because when the decoupling occurred, the dictionaries where implemented in order to provide the same level of functionality as before the decoupling (i.e. before the creation the transformation dictionary).
The goal was that the new engine would not impact any existing results. It would also not provide any new system definition. For the end user, changes were seamless.

It doesn't mean that we cannot have more than one transformation for a given datum.
It's actually one of the goals of the decoupling.

If we have more than one transformation, the engine needs to make a choice between the different options.
How could this happen?
A possible solution to this issue could be that each time the system encounters this situation, ask the user to choose which one to use.
This solution, however, presents big problems:


1>    The dialog asking the user for import would have to be inserted in tons of places, and the engine could not run smoothly without user interaction.

2>    The user probably wouldn't know which one to pick, and just make a guess.

3>    If all users in a shop don't pick the same one, the data will start to creep.

For that reason the concept of transformation path was introduced.
For instance, if we have DATUM1 and want to have a Geodetic Transformation to WGS84 for instance, and have multiple Geodetic Transformations for this, called GT1, GT2, GT3, a Geodetic Transformation Path has to be created, GTP_DATUM1_TO_WGS84, inside which, you specify which geodetic transformation has to be used.
If you don't do that, the engine will have to pick one transformation and that might not be the one you'd like to use. I think it would be the first one the engine finds in the dictionary (not sure, to be dbl checked).

You cannot have more than one Geodetic Transformation Path for a given source => target datum.

In case of complex transformations involving multiple datums here is how it works.
The building of a complex transformation from one datum to another is a four phase process:


1>    Check the Path Dictionary.  If a path from Source to Target is defined, it is used and the process is complete.

2>    Check the Transformation Dictionary for a transformation which converts directly from the source to the target.  If such exists, it is used and the process is complete.

3>    Using a specific pivot datum, examine the transformation dictionary for two complementary transformations: source to the pivot and, pivot to target.  If this is successful, a path of two transformations is generated and this path is used and the process stops.  (The code will work through a prioritized list of pivot datums.  Currently, this list consists of a single datum: "WGS84".)

4>    If we still don't have a transformation path after all of this, we examine the transformation dictionary for transformations from the source datum, and transformations to the target datum.  These definitions are considered if, and only if, there is a single transformation in the dictionary which references that datum.  These unique transformations replace the current source and target datums and the whole process starts over at phase one.  That is, if there is only one transformation in the entire transformation dictionary that converts from Datum1 (the source datum), then clearly, any valid path will need to start with this transformation.  Similarly, with the target datum.  If there is only one transformation in the entire dictionary that produces target datum coordinates, than that datum must indeed be the last transformation in the path.

This process fails if:

A>    A path from the source to target is not found, or

B>    More than one path definition from the source to the target is found.

Back to your question, we can therefore "start seeing multiple transformations attached to the same datum"
The only important thing this makes me think about though, is that if we do that, we cannot really add a path to choose this new transformation and risk to impact an existing user out there. This would change users' result and we always work CS-Map changes around that so that this doesn't occur.
Such path would have to be customized locally after install to choose this new transformation.

Hugues




From: metacrs-bounces at lists.osgeo.org [mailto:metacrs-bounces at lists.osgeo.org] On Behalf Of Raven Kopelman
Sent: Friday, January 17, 2014 9:02 PM
To: metacrs at lists.osgeo.org
Subject: [MetaCRS] CS-Map policy on multiple transformations per datum

Hi all,

I'm noticing that in spite of the effort to decouple datums from transformations, most (all?) datums still only have a single transformation defined.  This includes the new JGD2011 datum (http://trac.osgeo.org/csmap/ticket/153), of which the related systems seem to have been very carefully tailored to use a combination of two datums to avoid adding multiple transformations for the datum.

My suspicion is that this all ties into the transformation picking algorithm that fails if there are multiple valid choices.

Going forward, are we likely to start seeing multiple transformations attached to the same datum?  This is interesting to me as it will impact how compatible the FME specific definition changes I am making are going to be with the mainline development.

Thanks,
--
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>

[http://i943.photobucket.com/albums/ad276/Safe_Software/FME-UCampWT-email-signature-2_zpsc0db77c5.png]<http://www.safe.com/learning/events/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/metacrs/attachments/20140120/cfd43d11/attachment-0001.html>