[PROJ] Could you please explain me why I can't project RDN2008 (EPSG:6706) to ERTF2000 (EPSG:9067) or ITRF2000 (EPGS:8997)

[Giacomo Cappellini]

Ok I mis-interprered the meaning of "manual" here, I though there were some
additional custom magic code around WGS84 realizations transformations, but
it's the opposite.

Just side note: I'm actually quite surprised about your question about
WGS84 "Are such non-null transforms between members published somewhere ?"
as I was considered that like an obvious fact. If this information is not
officially available to the public, what's the whole point of updating the
datum? Considering that WGS is currently aligned with ITRF2014 at 2010.000, is
this made to push new maps to ITRS (that provides all the numbers)? Just
wild thoughts.

Thanks again for the answers.

G.C.

On Tue, Jul 19, 2022, 17:20 Even Rouault <even.rouault at spatialys.com> wrote:

>
> Le 19/07/2022 à 17:10, Giacomo Cappellini a écrit :
>
> Thanks Even, thanks Greg.
>
> I now understand why there are no proposed transformations from RDN2008 to
> ETRF2000 or ITRF2000.
> To get a better picture on the topic I downloaded the EPSG database and by
> grepping the available transformations starting from RDN2008 I've confirmed
> that "RDN2008 to ETRS89 (1)" and "RDN2008 to WGS 84 (1)" are the only
> available transformations according to EPSG authority.
>
> The only point I miss from the picture is the meaning of "ENSEMBLE". While
> I can generally grasp how to move from a source Reference Frame to a target
> Reference Frame, I fail to picture how to move from a Reference Frame to a
> Reference System ensemble. I'd like to ask if possible a little more
> details about the meaning of "we actually do that manually for the WGS 84
> datum ensemble vs its realizations".
>
> See the manually added records starting at
> https://github.com/OSGeo/PROJ/blob/5b2d59b68f931303d73e742763309d258f9335d4/data/sql/customizations.sql#L187.
> "manually" here means "not done in code": an alternative would be to
> explore the datum ensembles and their members in the database and figure
> out the null transformation between them. Given the relatively low number
> of datum ensembles in the EPSG database (essentially only WGS 84 and
> ETRS89), the manual way is much easier to implement than new code.
>
>
> The information I've reached so far about RS ensemble says that "all but
> the highest accuracy requirements may be considered to be insignificantly
> different from each other" and "Datasets referenced to the various
> realizations may be merged without change of coordinates":
> - https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#87
> - https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#53
>
> That's what is implemented in the above WGS 84 specific records with a
> Helmert transformation with all terms null, or my prior suggestion for
> ETRS89 <--> ETRF2000
>
> (to be pedantic we only record transformation from each member of the
> ensemble to the ensemble, to avoid the combinatory explosion of registering
> transformations between each member. but PROJ is smart enough to combine 2
> (not more) steps to do e.g WGS 84 (G1674) -> WGS 84 (G1762) as WGS 84 (G1674)
> -> WGS 84 (ensemble) -> WGS 84 (G1762) )
>
>
> Thanks,
>
> G.C.
>
> Il giorno mar 19 lug 2022 alle ore 13:48 Greg Troxel <gdt at lexort.com> ha
> scritto:
>
>>
>> Even Rouault <even.rouault at spatialys.com> writes:
>>
>> > For RDN2008, there are 2 transformations available:
>> >
>> > - one from RDN2008 to ETRS89 (EPSG:4258), with a null Helmert
>> > transformation and a accuracy of 0 m. This is consistant with how you
>> > described RDN2008, and this transformation has the comment "RDN2008 is
>> > the second Italian realization of ETRS89"
>>
>> A far more lengthy way forward might be:
>>
>>   Italian geodetic authorities (whoever defined RDN2008) publish a
>>   transformation from RDN2008 to some modern ETRFyyyy, including an
>>   error estimate.
>>
>>   They submit that to EPSG for inclusion.
>>
>>   A new EPSG version is published.
>>
>>   A proj release arrives with the new EPSG version.
>>
>>   Meanwhile, you wait for the previous 4 steps.
>>
>> I realize it doesn't solve your problem now, but authoritative
>> transforms with tight error estimates shorten the transform pipelines
>> that are used and lead to better answers.  The above avoids ETRS89.
>>
>> > Afaik, RDN2008 is ETRS89 realization ETRF2000 epoch 2008.0.
>>
>> If you believe that precisely, you could just relabel your data as being
>> ETRF2000 (assuming the standard epoch is 2008.0).
>>
>> Or insert a transform similar to Even's sugggestion, perhaps with better
>> accuracy.  I would expect RDN2008/ETRF2000:2008.0 to be at the 0.01m
>> level -- but I am pretty clueless about ETRF details.
>>
>>
>>
>> -- 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/20220720/4631a2ef/attachment.htm>