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.
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
