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

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

> 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.

Thank you for the pointer.

I find the word "manual" to be very confusing here.  As I see it, this
is basically forming a database which is the union of the EPSG database
and some other entries.  Arguably, these entries or something like them
should be in the EPSG database, but they aren't for various reasons.

I wonder if instead, or probably, we should have transforms from each
member to the next, as particularly for recent members the accuracy
statement can be vastly lower.

> (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) )

Is that limitation fundamental?  It could be reasonable to go through
multiple steps from WGS84(TRANSIT) to WGS84(G2139), some of which are
not null transforms.  Anyway we can avoid traversing an ensemble to
solve a requested transform seems better as there is an intrinsic loss
of accuracy from ensembles where we pause at "we don't really know what
frame the data is in".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220719/83a91a82/attachment.sig>