<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<p class="x_MsoNormal" style="background-color: rgb(255, 255, 255); margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif">
<span lang="EN-GB" style="margin: 0px"><br class="Apple-interchange-newline">
</span></p>
<blockquote class="quotableTextTraining" style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex; color: rgb(102, 102, 102);">
<p class="x_MsoNormal" style="background-color: rgb(255, 255, 255); margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif">
<span lang="EN-GB" style="margin: 0px">3. Even wrote:</span></p>
<p class="x_MsoNormal" style="background-color: rgb(255, 255, 255); margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif">
<span lang="EN-GB" style="margin: 0px">> I don't think the last sentence matches what the authors of standard have in mind (I don't think a datum can be *defined* by a transformation to another datum. a datum exists as such. one may establish transformations
to others, but they are not defining. at least for geodetic datums. for vertical datums, some of them are indeed defined by a geoid model that applies to a given geodetic datum).</span></p>
<p class="x_MsoNormal" style="background-color: rgb(255, 255, 255); margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif">
<span lang="EN-GB" style="margin: 0px"> </span></p>
<p class="x_MsoNormal" style="background-color: rgb(255, 255, 255); margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif">
<span lang="EN-GB" style="margin: 0px">The National CRS of the Netherlands (EPSG crs: 28992) has its own has datum (EPSG datum: 6289). Since 2000, this Dutch datum IS defined as the transformation from ETRS89 (ETRF2000). EPSG mentions for the origin of the
datum: "Originally defined through fundamental point Amersfoort, latitude 52°09'22.178"N, longitude 5°23'15.478"E (of Greenwich). Since 2000-10-01 has been redefined as derived from ETRS89 by application of the official transformation RDNAPTRANS(TM)."</span></p>
</blockquote>
Similarly in NZ, NZGD2000 has been defined since 2000.0 as based on ITRF96 by deformation model transformation from ITRF96 (and now by additional transformations from ITRFxxxx as ITRF96 is no longer directly accessible). Which is not to say it isn't what the
authors of the standard had in mind - but it is a geodetic reality.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regards</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Chris</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
<hr tabindex="-1" style="color: inherit; font-family: inherit; font-size: inherit; font-style: inherit; font-variant-ligatures: inherit; font-variant-caps: inherit; font-weight: inherit; background-color: ; display: inline-block; width: 98%;">
<br>
</div>
<div>
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> PROJ <proj-bounces@lists.osgeo.org> on behalf of Lesparre, Jochem <Jochem.Lesparre@kadaster.nl><br>
<b>Sent:</b> 11 October 2020 05:41<br>
<b>To:</b> Even Rouault <even.rouault@spatialys.com>; Greg Troxel <gdt@lexort.com><br>
<b>Cc:</b> proj@lists.osgeo.org <proj@lists.osgeo.org><br>
<b>Subject:</b> Re: [PROJ] EPSG v10 update status</font>
<div> </div>
</div>
<div lang="NL">
<div class="x_WordSection1">
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">Hi list,</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">I would like to add some comments on 4 unrelated remarks by Greg and Even.
</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">1. Greg wrote:</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">> "I know this is in some flavor of WGS84 but I don't know which."</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">The label WGS84 is often also used for data in ITRS or ETRS89 (and I suppose this happens for NADxx too), so it often is "<i>I know this is in some kind of latlon but I don't know which</i>", or even worse: "<i>I know this data is
in ETRF2000 but the data format I'm using forces me to call it WGS84</i>".</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">2. Greg wrote:</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">> I would also expect an ensemble to implicitly declare a low-accuracy transform (perhaps that accuracy is or should be carried in the ensemble definition) among any two members.</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">The EPSG registry has a precision parameter for each transformation (not for a CRS). The transformation to/from a datum ensemble has lower precision than the transformation to a specific realisation of that ensemble. It would be
nice if PROJ could propagate this precision as a 5th value (after the 4 values for the 3D coordinates and time).</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">3. Even wrote:</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">> I don't think the last sentence matches what the authors of standard have in mind (I don't think a datum can be *defined* by a transformation to another datum. a datum exists as such. one may establish transformations to others,
but they are not defining. at least for geodetic datums. for vertical datums, some of them are indeed defined by a geoid model that applies to a given geodetic datum).</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">The National CRS of the Netherlands (EPSG crs: 28992) has its own has datum (EPSG datum: 6289). Since 2000, this Dutch datum IS defined as the transformation from ETRS89 (ETRF2000). EPSG mentions for the origin of the datum: "Originally
defined through fundamental point Amersfoort, latitude 52°09'22.178"N, longitude 5°23'15.478"E (of Greenwich). Since 2000-10-01 has been redefined as derived from ETRS89 by application of the official transformation RDNAPTRANS(TM)."</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">4. Greg wrote:</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">> My guesstimate would be that it must be at least one-full time geodesist to maintain and enchance it [EPSG].</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style="">In fact, there are two geodesists at IOGP for this, but I believe that EPSG is just one of their tasks.</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span lang="EN-GB" style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span style="">Regards, Jochem</span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span style=""> </span></p>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<span style=""> </span></p>
<div>
<div style="border:none; border-top:solid #E1E1E1 1.0pt; padding:3.0pt 0cm 0cm 0cm">
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
<b><span lang="EN-US">From:</span></b><span lang="EN-US"> PROJ <proj-bounces@lists.osgeo.org>
<b>On Behalf Of </b>Even Rouault<br>
<b>Sent:</b> zaterdag 10 oktober 2020 17:25<br>
<b>To:</b> Greg Troxel <gdt@lexort.com><br>
<b>Cc:</b> proj@lists.osgeo.org<br>
<b>Subject:</b> Re: [PROJ] EPSG v10 update status</span></p>
</div>
</div>
<p class="x_MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">
</p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">Greg,</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> I interpet that as one of:</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> </span>
</p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> datums defined by a set of station coordinates at a reference epoch</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> and station velocities</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> </span>
</p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> datums defined by a time-dependent transformation to another datum.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">I don't think the last sentence matches what the authors of standard have in mind (I don't think a datum can be *defined* by a transformation to another datum. a datum exists as
such. one may establish transformations to others, but they are not defining. at least for geodetic datums. for vertical datums, some of them are indeed defined by a geoid model that applies to a given geodetic datum).</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">It is not because there's a known time-dependent transformation between DatumYYYY and ITRFxxxx that DatumYYYY is a dynamic datum. The time-dependency comes from the fact that ITRFxxxx
is a dynamic datum, so when changing coordinates between crust-fixed DatumYYYY and ITRFxxxx, you need to specify the epoch of coordinates in ITRFxxxx.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> It looks like GDA2020 is defined in terms of ITRF2014 and a</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> time-dependent transformation. Thus it seems squarely a dynamic datum</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> based on the above definition.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">GDA2020 is intended to be a 'static' datum. Coordinates of an object attached to the Australian plate don't change over time in GDA2020.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> Part of what I'm having trouble understanding is that as an example,</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> when you get a solution out of NRCAN PPP as IRTRF2014, it is "epoch of</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> data", meaning the ITF2014 coordinates of the station at that moment.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> ITRF2014's reference epoch is the date at which the published stations</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> had the published coordinates. So data in IRF2014 may be of an epoch</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> that is not the reference epoch, and I think proj doesn't yet deal with</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> that.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">That's not true. PROJ isn't able to deal properly (at least easily) with "point motion operation", that is transformations in the same dynamic datum, where coordinate epoch changes.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">But it can transform coordinates from a plate-fixed/static datum (let's say GDA2020) to a dynamic datum (let's say ATRF2014/ITRF2014), or the reverse. When the transformation is
published of course.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">Demo:</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">$ projinfo -s GDA2020 -t ITRF2014 -o PROJ -q</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=cart +ellps=GRS80 +step +inv +proj=helmert +x=0 +y=0 +z=0 +rx=0 +ry=0 +rz=0
+s=0 +dx=0 +dy=0 +dz=0 +drx=0.00150379 +dry=0.00118346 +drz=0.00120716 +ds=0 +t_epoch=2020 +convention=coordinate_frame +step +inv +proj=cart +ellps=GRS80 +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">You can see in the above a time-dependent Helmert transformation with the reference epoch being 2020 (since GDA2020 and ITRF2014 are concidered coincident for all practical purposes
at epoch 2020.0)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">Now let's try at 2020, the reference epoch of the transformation:</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">$ echo -30 120 0 2020 | cct $(projinfo -d 8 -s GDA2020 -t ITRF2014 -o PROJ -q)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">-30.00000000 120.00000000 0.00000000 2020.0000</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">And in 2030:</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">$ echo -30 120 0 2030 | cct $(projinfo -d 8 -s GDA2020 -t ITRF2014 -o PROJ -q)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">-29.99999472 120.00000379 -0.00169912 2030.0000</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> > I don't know why the NAD83 family isn't there. Probably depends on NOAA</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> > deciding on how it wants to deal with that.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> </span>
</p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> Interesting concept that they would decide :-) Did NGA really weigh in</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> on what EPSG is doing, for WGS84?</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">Well, it **IS** the responsibility of geodetic agencies to speak actively with IOGP to make their data conveniently available to users. Each party might have their views on the best
solution, but from exchanges I've been copied to, such discussions are done in a constructive way. If an agency doesn't speak with IOGP, their data might be just ignored, or if it is needed, IOGP or submitters to IOGP will make their own decisions. As an individual
you can also talk with IOGP and submit change requests:</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""><a href="https://epsg.org/dataset-change-requests.html">https://epsg.org/dataset-change-requests.html</a></span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">Let be realist: the PROJ team isn't staffed to do the job that IOGP does with the EPSG dataset. My guesstimate would be that it must be at least one-full time geodesist to maintain
and enchance it.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> I guess that's the big point. As I see it, in an ideal world, we</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> wouldn't need datum ensembles because data would be labeled in the</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> actual realization it is in. We need ensembles because of all the data</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> that is "I know this is in some flavor of WGS84 but I don't know which."</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">There's a practical reason for datum ensembles to be used. It is to avoid the proliferation of "derived objects". A projected CRS points to a geographic CRS which points to a datum/datum
ensemble. Currently you have 120 projected UTM CRS over WGS84. If you wanted to have them for each of the realizations, you'd have to multiply that by 6. The database would grow unwidely.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> > Datasets referenced to the various</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> > realizations may be merged without change of coordinates.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> </span>
</p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> The last sentence is interesting and surprising.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> </span>
</p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> I would expect that if there is a high-quality transform between two</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> members of an ensemble, and data is expressed in those members, that</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> transform will be used.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">Yes, there are definitely transformations that exist between ITRF realizations. It is just that if you've data referenced to a datum ensemble and not a given realization, this is
game over: you don't know which realization, so no high accuracy transformation possible.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> I would also expect an ensemble to implicitly declare a low-accuracy</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> transform (perhaps that accuracy is or should be carried in the ensemble</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">> definition) among any two members.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">Such transformations exist in the database as said above. They are just not exposed in the datum ensemble itself (it would be quite messy !)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">$ sqlite3 data/proj.db "select code, name from coordinate_operation_view where (name LIKE '%ITRF%to%ITRF%' or name LIKE '%WGS 84 (G%)%to%WGS 84 (G%)%') and auth_name = 'EPSG' and
deprecated = 0 order by name"</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6302|ITRF2000 to ITRF2005 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6300|ITRF2000 to ITRF2008 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">8078|ITRF2000 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9080|ITRF2000 to ITRF96 (2)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6389|ITRF2005 to ITRF2008 (2)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">8079|ITRF2005 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9081|ITRF2005 to ITRF96 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">7790|ITRF2008 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9082|ITRF2008 to ITRF96 (2)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9083|ITRF2014 to ITRF96 (2)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6281|ITRF88 to ITRF2000 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6291|ITRF88 to ITRF2008 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">8069|ITRF88 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9020|ITRF88 to ITRF89 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">7814|ITRF89 to ITRF2000 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6292|ITRF89 to ITRF2008 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">8070|ITRF89 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9021|ITRF89 to ITRF90 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6283|ITRF90 to ITRF2000 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6293|ITRF90 to ITRF2008 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">8071|ITRF90 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9022|ITRF90 to ITRF91 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6284|ITRF91 to ITRF2000 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6294|ITRF91 to ITRF2008 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">8072|ITRF91 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9023|ITRF91 to ITRF92 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6285|ITRF92 to ITRF2000 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6295|ITRF92 to ITRF2008 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">8073|ITRF92 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9024|ITRF92 to ITRF93 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6286|ITRF93 to ITRF2000 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6296|ITRF93 to ITRF2008 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">8074|ITRF93 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9025|ITRF93 to ITRF94 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6287|ITRF94 to ITRF2000 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6297|ITRF94 to ITRF2008 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">8075|ITRF94 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9026|ITRF94 to ITRF96 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6288|ITRF96 to ITRF2000 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6298|ITRF96 to ITRF2008 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">8076|ITRF96 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9027|ITRF96 to ITRF97 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6289|ITRF97 to ITRF2000 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">6299|ITRF97 to ITRF2008 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">8077|ITRF97 to ITRF2014 (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">9079|ITRF97 to ITRF96 (2)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">7668|WGS 84 (G1150) to WGS 84 (G1762) (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">7667|WGS 84 (G1674) to WGS 84 (G1762) (1)</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">Some of them are time-dependent, some sone.</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">$ projinfo "ITRF2000 to ITRF2005 (1)" -o PROJ</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">+proj=helmert +x=-0.0001 +y=0.0008 +z=0.0058 +rx=0 +ry=0 +rz=0 +s=-0.0004 +dx=0.0002 +dy=-0.0001 +dz=0.0018 +drx=0 +dry=0 +drz=0 +ds=-8e-05 +t_epoch=2000 +convention=position_vector</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">$ projinfo "WGS 84 (G1150) to WGS 84 (G1762) (1)" -o PROJ</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">+proj=helmert +x=-0.006 +y=0.005 +z=0.02 +rx=0 +ry=0 +rz=0 +s=-0.0045 +convention=coordinate_frame</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">Even</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""> </span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">--
</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New"">Spatialys - Geospatial professional services</span></p>
<p style="margin:0cm"><span style="font-size:9.0pt; font-family:"Courier New""><a href="http://www.spatialys.com">http://www.spatialys.com</a></span></p>
</div>
<br>
<br>
<font size="2">Disclaimer:<br>
De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.<br>
Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster<br>
is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u<br>
dit direct te melden aan de verzender en het bericht te vernietigen.<br>
Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.<br>
<br>
Disclaimer:<br>
The content of this message is meant to be received by the addressee only.<br>
Use of the content of this message by anyone other than the addressee without the consent<br>
of the Kadaster is unlawful. If you have received this message, but are not the addressee,<br>
please contact the sender immediately and destroy the message.<br>
No rights can be derived from the content of this message.<br>
</font></div>
</div>
<br>
<hr>
<font face="Verdana" color="Black" size="2"><br>
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 info@linz.govt.nz) 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.<br>
</font>
</body>
</html>