[MetaCRS] Fwd: Re: [Proj] Time dependent coordinate transformations

Martin Desruisseaux martin.desruisseaux at geomatys.fr
Fri Jan 9 11:45:33 PST 2015


Hello Chris

Le 09/01/15 18:46, Chris Crook a écrit :

> The ambiguity I was hinting at was not just to do with converting from one coordinate system to another.  It also relates to converting a data set from one coordinate system to another, and then to a third versus converting directly from the first to the third, or for that matter from one to another and then back again.

Indeed a CRS_A → WGS84 → CRS_B _/transformation/_ may not produce the
same results than a CRS_A → CRS_B transformation. But this may actually
be an issue of the pivot system. Coordinate _/transformations/_ (not to
be confused with coordinate _/conversions/_ in ISO 19111 terminology)
are valid only in some domain of validity, and have a limited accuracy
(not related to the computer floating point precision). So the CRS_A →
WGS84 transformation may be valid only in some area with an accuracy
"error_A", and the WGS84 → CRS_B transformation may be valid only in
some other area with accuracy "error_B". Naively (I may be wrong) I
would presume that the CRS_A → WGS84 → CRS_B transformation would be
valid only in the intersection of the CRS_A → WGS84 and WGS84 → CRS_B
domains of validity with a precision not better than max(error_A,
error_B), or maybe error_A + error_B. This may not be the same domain of
validity and precision than a direct CRS_A → CRS_B transformation.

On the reversibility, the EPSG database usually stores a (/sourceCRS/,
/targetCRS/) pairs only in one way, for example CRS_A → CRS_B but not
CRS_B → CRS_A. Instead they explain in their documentation how to
reverse the operation. For a /Molodensky/ transformation we just need to
reverse the sign of parameter values. For map projections this is more
complicated, but there is no ambiguity. So I don't think that the
consistency concern applies to the conversions or transformations back
to the original CRS.


> Depending on how the late binding tables are constructed there would be no assurance that these transformations would give consistent results.  Indeed, I suspect that if mathematically if both these were enforced then that would be equivalent to using an arbitrary pivot coordinate system (...snip...)

I think they would be mathematically equivalent (ignoring numerical
errors) for coordinate /conversions/, but I would be very surprised if
they were equivalent for coordinate /transformations/ (i.e. a coordinate
operation involving a datum shift) because of the stochastic nature of
the process. This is the discussion in my previous paragraphs.

But in addition to all the above, I don't see how coordinate
transformations through a pivot could address the problem mentioned in
my previous email, regarding the transformation steps not being the
method specified by authoritative mapping agencies...


> Of course there is a philosophical question as to whether coordinate transformations should give unique or consistent results.

I'm not sure what "uniqueness" means in the context of coordinate
transformations (not conversions). As mentioned in my previous email,
there is many possible transformation methods between two CRS. Even if
you give me explicit Bursa-Wolf parameters (the numbers in the - now
deprecated - TOWGS84 element), assuming the rotation parameters are
zero, there is at least 3 different ways to use those parameters:
/Geocentric translation/, /Molodensky/ and /Abridged Molodensky/. Each
way will give slightly different results, and there is absolutely
nothing in the TOWGS84 element or elsewhere in the WKT telling us which
method to use. The method to use if often specified by the national
mapping agency for a particular country, so just saying "I
unconditionally use the most accurate method" is not necessarily
appropriate from an interoperability point of view...


Regards,

    Martin


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


More information about the MetaCRS mailing list