Fwd: Re: [Proj] Time dependent coordinate transformations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Re: [Proj] Time dependent coordinate transformations

Even Rouault-2
Re-adding metacrs.

----------  Message transmis  ----------

Sujet : Re: [Proj] Time dependent coordinate transformations
Date : lundi 05 janvier 2015, 22:23:50
De : Even Rouault <[hidden email]>
À : Chris Crook <[hidden email]>
CC : "'[hidden email]'" <[hidden email]>,
"'[hidden email]'" <[hidden email]>

Le lundi 05 janvier 2015 21:13:36, Chris Crook a écrit :

> Even
>
> Thanks for the quick response and thanks for the suggestion of the MetaCRS
> list.
>
> Comments below...
>
> > -----Original Message-----
> > From: Even Rouault [mailto:[hidden email]]
> > Sent: Tuesday, 6 January 2015 12:32 a.m.
> > To: [hidden email]
> > Cc: Chris Crook
> > Subject: Re: [Proj] Time dependent coordinate transformations
> >
> > Chris,
> >
> > > This is a growing issue for which I'd like to find the right forums
> > > and process to ultimately have have widely supported in coordinate
> > > transformation implementations, so please suggest or forward other
> > > appropriate forums.
> >
> > I can imagine MetaCRS (http://trac.osgeo.org/metacrs /
> > http://lists.osgeo.org/pipermail/metacrs) could also be associated
> >
> > > The background
> > > ==============
> > >
> > >
> > > National datums are generally referenced to fixed marks within the
> > > country and provide a stable coordinate system, such that the
> > > coordinates of fixed marks are constant.
> >
> > [...]
> >
> > > However many countries also include deforming areas near tectonic
> > > plate boundaries which require more special treatment.
> >
> > When you mention those national datums with fixed marks, how does
> > NAD83 and its multiple realisations work with that ? I'm clearly not a
> > geodesist,  but looking a bit on various sites, it seems that the
> > coordinates of a fixed mark vary between the different NAD83
> > realisations, so can we speak of a national datum for the US (or New
> > Zealand) ?
>
> Sorry - the "with fixed marks" was a bit simplistic.
>
> There certainly is an issue with versions  of datums, and this is another
> area which I'm not sure is well handled with the current coordinate system
> registries.
>
> For example in New Zealand each update of the deformation model (which
> relates NZGD2000 to ITRF96) effectively defines a new version of NZGD2000.
>  Should this be treated as a new coordinate system in EPSG and other
> registries.  If so, then all 30+ projections based on NZGD2000 will also
> need to be recreated.   For most users of NZGD2000 this would just be a
> nuisance, but for some it would be preferred I think.

https://confluence.qps.nl/pages/viewpage.action?pageId=29855153 shows that
there are 5 EPSG codes for the various NAD83 realizations in geodetic
projections. Not sure that they all have associated corresponding projected
systems though.

> I have seen that, and a similar approach could be used for one-off
> transformations in New Zealand.  However that doesn't feel like the right
> approach in the long term. On the other hand any systematic change to
> handle time dependent transformations will doubtless take a long time to
> be widely implemented, so it is great to have work arounds in the mean
> time!

Agreed...

>
> > > The issues for the GIS software stack
> > > =====================================
> > >
> > > I believe there are two issues facing GIS systems in handling time
> > > based transformations.
> > >
> > > 1) Where are the parameters of time based transformations defined
> > >
> > > 2) When transforming a coordinate how is the time parameter included in
> >
> > the
> >
> > > transformation API
> > >
> > > It seems fairly straightforward to expand the definitions of coordinate
> > > systems in PROJ and the EPSG registry to include additional parameters.
> > > The to_wgs84 parameters could readily be extended to include the 14
> > > parameter plus reference epoch time dependent Bursa Wolf
> >
> > transformation.
> >
> > > Some datum transformations already include nested grids, so extending
> >
> > this
> >
> > > to include grids with associated time functions also seems feasible.
> >
> > Agreed although in the case of HTDP, the production of grids result from
> > the result of a (apparently complex) computation process where you have
> > to provide
> > src_crs, src_crs_date, dst_crs and dst_crs_date. Regarding proj.4 one
> > could have a fixed (dst_crs, dst_crs_date) by convention, but one would
> > still have varying src_crs_date for a given src_crs. Perhaps
> > pre-generate grids for each year and linearly interpolate between them ?
>
> I believe that there is just one one date for these transformations.

I meant that for HTDP, my impression with my limited testing is that you can
actually specify one date for each of the both CRS and it will use each one,
presumably using some pivot as a reference, to generate the final grid.

Transforming from NAD83(2011) at T=2014.0 into WGS84(G730) at T=1991.0 gives a
different result from NAD83(2011) at T=2011.0 into WGS84(G730) at T=1991.0, and
different from NAD83(2011) at T=2014.0 into WGS84(G730) at T=1986.0

> This
> is not about predicting where a feature might be at another time, it is
> about transforming between coordinate systems which are related by a time
> dependent function.  Of course if the feature is considered to be fixed in
> one of those coordinate systems then the effect of transforming at
> different dates is to track it's trajectory in the other.
>
> Also many national datums (including New Zealand) are defined in terms of a
> reference epoch, so calculating coordinates in terms of that datum can be
> thought of as converting coordinates to that epoch.   In New Zealand that
> is how we have described NZGD2000 until recently.
>
> I think that is a bit misleading though - after we may be defining the
> coordinates of a building that did not even exist at the reference epoch.
>   And clearly it is not possible to access the features at any time other
> than the present.
>
> I believe it is more correct to think of the reference epoch as a time at
> which the national coordinate system coincided with some international
> system it was defined in terms of.  However at other times it is offset
> from the international system by an approximately known amount
> representing the total movement of the tectonic plate on which the nation
> lies.  Hence the time dependent transformation.
>
> > > However to be widely supported this will need appropriate standards to
> > > be defined for the common parameter sets of time dependent
> >
> > transformations.
> >
> > > (There may also a question of what reference datum the transformations
> >
> > are
> >
> > > defined in terms of, if any.  The to_wgs84 parameters implies a WGS84
> > > based reference datum, but in fact WGS84 is a series of datum
> > > realisations)
> >
> > I can imagine that the "pivot" WGS84 could be an arbitrarily chosen WGS84
> > realization (hoping that the use of 2 successive shifts will not harm too
> > much precision)
>
> I think an approach like this is possibly the best that can be done
> practically. There are multiple published relationships between different
> international datums, and between them and national datums, which means
> that the relationships are not unambiguously defined.  I'm not sure how
> this could usefully be included in coordinate system registries and
> transformations.
>
> > > The second question is how a time parameter is supplied to a
> >
> > transformation
> >
> > > function.  Logically this is associated with a feature.
> >
> > Yes, if you consider that a dataset can contain a collection of features
> > whose coordinates have been collected at different times. But one could
> > also assume
> > that within a dataset, they all refer to the same time (this would be
> > similar to considering that in a dataset you don't mix features with
> > coordinates in different SRS, which is the usual practice), couldn't we
> > ? In which case the time parameter could be a property of the SRS, or
> > presumably next to the SRS
> > (since SRS can be transported by codes, and you can't code each different
> > time).
> >
> > There's also the topic of raster maps (for high precision mapping) that
> > could also be affected by time dependant transformations. But in that
> > case it is obvious that a single time must be considered for the whole
> > map.
>
> I'm not thinking that datasets will generally have different times (even if
> the data were originally collected that way).  More that the
> transformation API's ultimately work on coordinates.  So even if a
> feature's coordinates are not stored with a time, the dataset time could
> be assigned to the feature in preparation for the transformation (in the
> same way as we might set a SRS id to a feature).
>
> The question here is whether to have a separate API for transformations
> that require a time, or whether to use the same API and embed the time
> within the feature/coordinate being transformed.

Regarding proj4, there wouldn't be any particular difficulty to extend its API,
being a string, to include a "+time=XXXX.YY" parameter. The difficulty would be
more in the logic to make something usefull with that time parameter. For
Bursa-Wolf with derivatives, this should be easy. For grids, less obvious.

>
> In terms of implementation I guess there will be efficiencies in preparing
> a transformation for a specific epoch - in effect defining a
> transformation object which is used for transformations and which can
> cache prepared transformations.  I'm not sure how this will sit with
> existing API's.
>
> I'm not familiar with transforming raster maps, though I imagine the
> process would be to transform a set of reference coordinates that are used
> to morph the raster?

The naive way of transforming/warping a raster dataset is to consider the
coordinate of the center of each pixel and to transform it into the target
reference coordinate and build an image from that, which is an already solved
problem. So if we know how to do a time-dependant transform for a feature, no
particular difficulty transposing that to the raster side. But I just wanted to
mention it for the sake of completeness as a "user" of such transforms.


--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


-------------------------------------------------------
--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

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

Chris Crook
On the subject of HTDP transformations below:

> > > > It seems fairly straightforward to expand the definitions of coordinate
> > > > systems in PROJ and the EPSG registry to include additional parameters.
> > > > The to_wgs84 parameters could readily be extended to include the 14
> > > > parameter plus reference epoch time dependent Bursa Wolf
> >>
> > > transformation.
> > >
> > > > Some datum transformations already include nested grids, so extending
> >>
> > > this
> > >
> > > > to include grids with associated time functions also seems feasible.
> >>
> > > Agreed although in the case of HTDP, the production of grids result from
> > > the result of a (apparently complex) computation process where you have
> > > to provide
> > > src_crs, src_crs_date, dst_crs and dst_crs_date. Regarding proj.4 one
> > > could have a fixed (dst_crs, dst_crs_date) by convention, but one would
> > > still have varying src_crs_date for a given src_crs. Perhaps
> > > pre-generate grids for each year and linearly interpolate between them ?
> >
> > I believe that there is just one one date for these transformations.
>
> I meant that for HTDP, my impression with my limited testing is that you can
> actually specify one date for each of the both CRS and it will use each one,
> presumably using some pivot as a reference, to generate the final grid.
>
> Transforming from NAD83(2011) at T=2014.0 into WGS84(G730) at T=1991.0 gives a
> different result from NAD83(2011) at T=2011.0 into WGS84(G730) at T=1991.0, and
> different from NAD83(2011) at T=2014.0 into WGS84(G730) at T=1986.0

While this may give different results, it is not at all clear to me why it should give different
results.  The question here is what is it supposed to be doing I guess.

Perhaps this difference between HTDP and the deformation in New Zealand is that in NZ
the deformation model is defined to be part of the datum.  In effect it is a function which
defines the transformation from ITRF96 at any epoch to NZGD2000.  It isn't considered or
used as a function for computing NZGD2000 at arbitrary epochs - any such coordinates
would not be NZGD2000 at all.

By contrast HTDP transforms coordinates between different epochs (or more accurately,
predicts the moment of objects fixed to the crust over time).  But there is not a
well defined commonly used reference epoch that is used to represent coordinates, and
this deformation is not part of the datum.  NAD83 is in this sense more like a global
datum.   And features that are fixed to the crust in the western US do not have fixed
coordinates.

I wonder how this is managed by GIS users?

> > This
> > is not about predicting where a feature might be at another time, it is
> > about transforming between coordinate systems which are related by a time
> > dependent function.  Of course if the feature is considered to be fixed in
> > one of those coordinate systems then the effect of transforming at
> > different dates is to track it's trajectory in the other.
> >

This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or [hidden email]) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

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

Martin Desruisseaux

Hello all

I'm not sure if the following is relevant, but just in case:

The EPSG database already includes time-dependent coordinate transformation methods in the form of Bursa-Wolf parameters with 14 terms. They are OperationMethod EPSG:1053 and EPSG:1056 [1]. Some open source GIS software already implement (at least partially) those methods, for example Apache Spatial Information System (SIS) [2].

While EPSG recognizes that using a pivot Coordinate Reference System (WGS84 or any other) is a common approach, they recommend to avoid this approach if possible. Indeed, the TOWGS84 keyword is now deprecated in the new Well Known Text (WKT) version 2 standard, developed at OGC/ISO as the ISO 19162 international standard [3]. Attaching transformation information to a CRS is what EPSG calls "Early binding approach". EPSG recommends instead the "Late binding approach", which is to search transformation information in a database for (sourceCRS, targetCRS) pairs.

The Open Geospatial Consortium (OGC) just started recently discussions in a working group about time-dependent transformations. This discussion was trigged by meteorologists for vertical coordinate transformations between pressure (kPa) and metres, where the pressure at the ground level change every day. Maybe this discussion could be extended to the cases discussed in this thread.

        Martin



[1] http://epsg-registry.org (click on "retrieve by code" and enter "1053" in the search box)
[2] http://sis.apache.org/apidocs/org/apache/sis/referencing/datum/TimeDependentBWP.html
[3] http://www.iso.org/iso/catalogue_detail.htm?csnumber=63094


_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

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

Chris Crook
Thanks for adding this Martin ... this is indeed very relevant!  I've not yet been able to look at the WKT version 2 standard but will.

While I can see that "late binding" is an alternative to a pivot coordinate system, it seems to invite issues with non-uniqueness, depending on how it is implemented.  Are you able to point me to any references on this please?

Thanks
Chris
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Martin Desruisseaux [[hidden email]]
Sent: 07 January 2015 22:22
To: [hidden email]
Subject: Re: [MetaCRS] Fwd: Re: [Proj] Time dependent coordinate        transformations

Hello all

I'm not sure if the following is relevant, but just in case:

The EPSG database already includes time-dependent coordinate transformation methods in the form of Bursa-Wolf parameters with 14 terms. They are OperationMethod EPSG:1053 and EPSG:1056 [1]. Some open source GIS software already implement (at least partially) those methods, for example Apache Spatial Information System (SIS) [2].

While EPSG recognizes that using a pivot Coordinate Reference System (WGS84 or any other) is a common approach, they recommend to avoid this approach if possible. Indeed, the TOWGS84 keyword is now deprecated in the new Well Known Text (WKT) version 2 standard, developed at OGC/ISO as the ISO 19162 international standard [3]. Attaching transformation information to a CRS is what EPSG calls "Early binding approach". EPSG recommends instead the "Late binding approach", which is to search transformation information in a database for (sourceCRS, targetCRS) pairs.

The Open Geospatial Consortium (OGC) just started recently discussions in a working group about time-dependent transformations. This discussion was trigged by meteorologists for vertical coordinate transformations between pressure (kPa) and metres, where the pressure at the ground level change every day. Maybe this discussion could be extended to the cases discussed in this thread.

        Martin



[1] http://epsg-registry.org (click on "retrieve by code" and enter "1053" in the search box)
[2] http://sis.apache.org/apidocs/org/apache/sis/referencing/datum/TimeDependentBWP.html
[3] http://www.iso.org/iso/catalogue_detail.htm?csnumber=63094


This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or [hidden email]) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

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

Martin Desruisseaux

Hello Chris

Le 08/01/15 19:13, Chris Crook a écrit :

While I can see that "late binding" is an alternative to a pivot coordinate system, it seems to invite issues with non-uniqueness, depending on how it is implemented.  Are you able to point me to any references on this please?

The "Early binding" versus "Late binding" approaches are briefly discussed in the Geospatial Integrity of Geoscience Software (GIGS) tests:

http://www.iogp.org/geomatics#2521115-gigs part 1 section 3.4

As mentioned in the above paper, the late-binding approach is a way to resolve (not invite) the non-uniqueness problem. Indeed, my experience in comparing Proj.4 (which in my understanding uses early-binding) with a software implementing the late-binding approach shows slightly different results. Below are some 2-3 years old screenshots I did for GeoAPI (I did not verified if the numbers would be the same today):

Coordinate transformations using Proj.4 (through JNI) 3 years ago:


Same coordinate transformations using late-binding approach:

The transformation results are slightly different because there is at least 3 different ways to perform a datum shift between NTF and WGS84: Geocentric translation, Molodensky and Abridged Molodensky. If my memory serves me right, Proj.4 uses Geocentric translation, which is indeed the most accurate transformation method among those 3. But it is not the method mandated by the French mapping agency (IGN), which (if I remember correctly) rather specify that we shall use a Molodensky method. For interoperability with the maps produced by authorities, sometime we have to use the same transformation method that they use, regardless if their method is the most accurate or not.

Note that I verified that forcing the above late-binding implementation to the same transformation method than Proj.4 produced the same results.

The EPSG database contains a table that specify which transformation methods (not only the parameters) to use for various (sourceCRS, targetCRS) pairs. The method from NTF to WGS84 may not be the same than the method from NTF to another CRS. When using that EPSG table, there is no ambiguity. So I think we could summarize the difference between early-binding and late-binding approaches by saying that the late-binding approach uses that table, while the early-binding approach ignores it. Of course the table can not contain all possible (sourceCRS, targetCRS) pairs, so we have to fallback on an early-binding approach if we can not find an entry for our particular pair of CRS (or sometime on a mixed approach, trying to find another pair of CRS which exist in the database).

    Regards,

        Martin



_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

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

Chris Crook
Hi Martin

Thanks for the pointers.  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.

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, though of course there is no requirement that it is encoded this way.  A tree like heirarchy is another working option.

Of course there is a philosophical question as to whether coordinate transformations should give unique or consistent results.  But in many cases this is a practical requirement (eg on the fly transformations in GIS systems)

Cheers
Chris
______________________________________
From: Martin Desruisseaux [[hidden email]]
Sent: 09 January 2015 08:34
To: Chris Crook; [hidden email]
Subject: Re: [MetaCRS] Fwd: Re: [Proj] Time dependent coordinate transformations

Hello Chris

Le 08/01/15 19:13, Chris Crook a écrit :

While I can see that "late binding" is an alternative to a pivot coordinate system, it seems to invite issues with non-uniqueness, depending on how it is implemented.  Are you able to point me to any references on this please?



The "Early binding" versus "Late binding" approaches are briefly discussed in the Geospatial Integrity of Geoscience Software (GIGS) tests:

http://www.iogp.org/geomatics#2521115-gigs part 1 section 3.4

As mentioned in the above paper, the late-binding approach is a way to resolve (not invite) the non-uniqueness problem. Indeed, my experience in comparing Proj.4 (which in my understanding uses early-binding) with a software implementing the late-binding approach shows slightly different results. Below are some 2-3 years old screenshots I did for GeoAPI (I did not verified if the numbers would be the same today):

Coordinate transformations using Proj.4 (through JNI) 3 years ago:

[cid:[hidden email]]

Same coordinate transformations using late-binding approach:

[cid:[hidden email]]

The transformation results are slightly different because there is at least 3 different ways to perform a datum shift between NTF and WGS84: Geocentric translation, Molodensky and Abridged Molodensky. If my memory serves me right, Proj.4 uses Geocentric translation, which is indeed the most accurate transformation method among those 3. But it is not the method mandated by the French mapping agency (IGN), which (if I remember correctly) rather specify that we shall use a Molodensky method. For interoperability with the maps produced by authorities, sometime we have to use the same transformation method that they use, regardless if their method is the most accurate or not.

Note that I verified that forcing the above late-binding implementation to the same transformation method than Proj.4 produced the same results.

The EPSG database contains a table that specify which transformation methods (not only the parameters) to use for various (sourceCRS, targetCRS) pairs. The method from NTF to WGS84 may not be the same than the method from NTF to another CRS. When using that EPSG table, there is no ambiguity. So I think we could summarize the difference between early-binding and late-binding approaches by saying that the late-binding approach uses that table, while the early-binding approach ignores it. Of course the table can not contain all possible (sourceCRS, targetCRS) pairs, so we have to fallback on an early-binding approach if we can not find an entry for our particular pair of CRS (or sometime on a mixed approach, trying to find another pair of CRS which exist in the database).

    Regards,

        Martin



This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or [hidden email]) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

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

Martin Desruisseaux

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_AWGS84CRS_B transformation may not produce the same results than a CRS_ACRS_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_AWGS84 transformation may be valid only in some area with an accuracy "error_A", and the WGS84CRS_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_AWGS84CRS_B transformation would be valid only in the intersection of the CRS_AWGS84 and WGS84CRS_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_ACRS_B transformation.

On the reversibility, the EPSG database usually stores a (sourceCRS, targetCRS) pairs only in one way, for example CRS_ACRS_B but not CRS_BCRS_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



_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

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

Chris Crook

Hi Martin

 

Your comments below address what I was much less precisely referring to as a "philosophical" question of whether a coordinate transformation (involving a datum shift) should be uniquely defined and invertible. 

 

While I agree that these transformations do involve some error in their definition what I'm mainly  interested, in this discussion thread, is how they are defined and implemented within GIS systems.  In these systems most spatial definitions are not stochastically defined and most users may expect well defined transformations, eg from national datums to global datums.   This certainly can be provided by late binding, but it is not guaranteed by late binding alone - it also requires constraints on the conversions database (including the one you specify, for reversing a transformation). 

 

None the less I agree that there are issues in trying to define these transformation uniquely.  Even between global systems there are multiple published versions of transformations (eg ITRF96-ITRF2008) and no "right" answer.

 

Cheers

Chris

 

From: Martin Desruisseaux [mailto:[hidden email]]
Sent: Saturday, 10 January 2015 8:46 a.m.
To: Chris Crook; [hidden email]
Subject: Re: [MetaCRS] Fwd: Re: [Proj] Time dependent coordinate transformations

 

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_AWGS84CRS_B transformation may not produce the same results than a CRS_ACRS_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_AWGS84 transformation may be valid only in some area with an accuracy "error_A", and the WGS84CRS_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 WGS84CRS_B transformation would be valid only in the intersection of the CRS_AWGS84 and WGS84CRS_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_ACRS_B transformation.

On the reversibility, the EPSG database usually stores a (sourceCRS, targetCRS) pairs only in one way, for example CRS_ACRS_B but not CRS_BCRS_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

 



This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or [hidden email]) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.

_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs