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 |
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 |
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. [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 |
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 |
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:
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 |
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 |
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
_______________________________________________ MetaCRS mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/metacrs |
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]]
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 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 |
Free forum by Nabble | Edit this page |