[PROJ] National CRS to ITRS

[Even Rouault]

Le 22/02/2023 à 21:15, Lesparre, Jochem a écrit :
>
> JL wrote:
>
> > the route trough ETRF2000 should be the default […]
>
> > Thus ETRS89 -> ETRF2000 -> ITRF2000 -> ITRF2014 instead of ETRS89 -> ETRF2014 -> ITRF2014. What makes 
> PROJ choose the latter?
>
> ER wrote:
>
> > PROJ has no idea of what is recommended/preferred by European geodestists ;-) It only trusts 
> records in its database.
>
> > PROJ can only infer pipelines with at most one intermediate CRS. If you want ETRS89 -> ETRF2000 -> ITRF2000 -> 
> ITRF2014, you need an explicit concatenated operation chaining the 3 
> individual steps.
>
> In fact, in PROJ the ETRS89 -> ETRF2000 -> ITRF2000 -> ITRF2014 route 
> gives identical results to ETRS89 -> ETRF2000 -> ITRF2014, and this 
> also has only one intermediate CRS:
>
ETRF2000 -> ITRF2000 is EPSG:7941

+proj=pipeline
   +step +proj=axisswap +order=2,1
   +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m
   +step +proj=cart +ellps=GRS80
   +step +inv +proj=helmert +x=0.054 +y=0.051 +z=-0.048 +rx=0.000891 
+ry=0.00539
         +rz=-0.008712 +s=0 +dx=0 +dy=0 +dz=0 +drx=8.1e-05 +dry=0.00049
         +drz=-0.000792 +ds=0 +t_epoch=2000 +convention=position_vector
   +step +inv +proj=cart +ellps=GRS80
   +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m
   +step +proj=axisswap +order=2,1

and ITRF2000 -> ITRF2014 is EPSG:8078

+proj=pipeline
   +step +proj=axisswap +order=2,1
   +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m
   +step +proj=cart +ellps=GRS80
   +step +proj=helmert +x=-0.0007 +y=-0.0012 +z=0.0261 +rx=0 +ry=0 +rz=0
         +s=-0.00212 +dx=-0.0001 +dy=-0.0001 +dz=0.0019 +drx=0 +dry=0 +drz=0
         +ds=-0.00011 +t_epoch=2010 +convention=position_vector
   +step +inv +proj=cart +ellps=GRS80
   +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m
   +step +proj=axisswap +order=2,1

And ETRF2000 -> ITRF2014 is EPSG:8405

+proj=pipeline
   +step +proj=axisswap +order=2,1
   +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m
   +step +proj=cart +ellps=GRS80
   +step +inv +proj=helmert +x=0.0547 +y=0.0522 +z=-0.0741 +rx=0.001701
         +ry=0.01029 +rz=-0.016632 +s=0.00212 +dx=0.0001 +dy=0.0001 
+dz=-0.0019
         +drx=8.1e-05 +dry=0.00049 +drz=-0.000792 +ds=0.00011 +t_epoch=2010
         +convention=position_vector
   +step +inv +proj=cart +ellps=GRS80
   +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m
   +step +proj=axisswap +order=2,1

It appears that the authority in charge of ETRF and ITRF made sure that 
additivity works.


> projinfo -s epsg:7931 -t epsg:7912
>
> Operation No. 1:
>
> unknown id, Conversion from ETRF2000 (geog3D) to ETRF2000 (geocentric) 
> + Inverse of ITRF2014 to ETRF2000 (1) + Conversion from ITRF2014 
> (geocentric) to ITRF2014 (geog3D), 0 m
>
> projinfo -s epsg:8403 -t epsg:7912
>
> Operation No. 1:
>
> unknown id, Conversion from ETRF2014 (geog3D) to ETRF2014 (geocentric) 
> + Inverse of ITRF2014 to ETRF2014 (2) + Conversion from ITRF2014 
> (geocentric) to ITRF2014 (geog3D), 0 m
>
> If it is not the number of steps, what makes PROJ not choose ETRS89 -> 
> ETRF2000 -> ITRF2014 but  ETRS89 -> ETRF2014 -> ITRF2014 instead? And 
> what would need to be changed in the database to change that 
> transformation route?
>
That will make you smile (or not), but I believe it is lexicographic 
order.  ETRF2000->ITRF2014 and ETRF2014->ITRF2014 have both the same 
extent and advertized accuracy (0 m!), so when combined with the 
preliminary ETRS89 -> ETRF2000 or ETRS89 -> ETRF2014 null transformation 
steps which are deduced from the definition of the ETRS89 assemble using 
its 0.1 m accuracy, the resulting pipelines ETRS89 -> ETRF2000 -> 
ITRF2014 and ETRS89 -> ETRF2014 -> ITRF2014 have both the same extent 
and advertized accuracy (0.1m) (if you look at projinfo -s ETRS89 -t 
ITRF2014  --3d output, you'll see that the one using ETRF2000->ITRF2014 
is the 3rd one). So PROJ, when having to sort results, chooses the 
pipeline whose name is the greater given lexicographic order, and 
ETRF2014 > ETRF2000 according to that criterion. The preference for the 
higher lexicographic order has been chose because typically EPSG adds 
new transformations FOO (X) and FOO (Y) with increasing numbers, and all 
other things being equal, it can makes sense to use the more recent 
records. Obviously that's not always what you want, but that's slightly 
better than a dice roll, at least that's deterministic, which is what 
you need for a sort algorithm.

So what would be needed here for what you want would be to register a 
ETRS89 to ITRF2014 transformation, typically by copying the ETRF2000 -> 
ITRF2014 Helmert transformation and assigning it an accuracy slightly 
less than 0.1 m (I guess exactly 0.1 m would also work, because PROJ 
will normally favor pipelines that have less steps than other ones, all 
other things being equal, but that should be tested, especially in 
complex pipelines mixing horizontal & vertical transformations)

Even

> Jochem
>
>
>
> Disclaimer:
> De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor 
> de geadresseerde(n).
> Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of 
> verstrekking van deze informatie aan derden is niet toegestaan.
> Op al onze producten en diensten zijn onze algemene 
> leveringsvoorwaarden van toepassing
> [https://www.kadaster.nl/algemene-leveringsvoorwaarden].
>
> Disclaimer:
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they 
> are addressed.
> If you are not the intended recipient, you are notified that 
> disclosing, copying, distributing or taking any action in reliance on 
> the contents of this information is strictly prohibited.
> Our general terms and conditions of delivery apply to all our products 
> and services
> [https://www.kadaster.com/general-terms-and-conditions].

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20230222/50c95ed9/attachment-0001.htm>