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

[Raven Kopelman]

Hi Hugues,

Thanks for the feedback.  I was unaware that Paths were intended to serve
this "preferred transformation" purpose in addition to allowing the
definition of multistep transformations.

When I upgraded FME to CS-Map 13 I assumed that we would want the ability
to define multiple Paths for a single datum pair, and so avoided using the
CS-Map algorithm for transformation selection.  Instead I added a
"preferred transformation" layer that allows us to have multiple
xforms/paths and still maintain stability in our transformation choice (if
desired).

Cheers,

--
Raven Kopelman | Software Developer

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

<http://www.safe.com/learning/events/>


On Mon, Jan 20, 2014 at 12:53 AM, Hugues Wisniewski <
hugues.wisniewski at autodesk.com> wrote:

>  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 | www.safe.com
>
>
>
> <http://www.safe.com/learning/events/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/metacrs/attachments/20140120/761df2a5/attachment.html>