Cannot use Compound CRSs

[JohannaOtt]

when importing the attached data with the Compound CRS 5555 (almost the right one, except from the date of the height reference system, that cannot be found in EPSG registry) and trying to export it to EPSG:7409 (CompoundCRS allowed in INSPIRE), hs produces an error message:

[JohannaOtt]

Also, when creating a CompoundCRS as user defined CRS in the hale studio settings with a WKT (in this case, I used EPSG:5832) and trying to export data chosing that CRS, it fails with the following message indicating that no CompoundCRSs are supported:

As the Building 3D data in the AdV project uses Compound CRSs (at least every dataset I saw so far), it would be very helpful to be able to handle those in hale studio.
Right now, users always get validation warnings for the source and target data when uploading data with a CompoundCRS to haleconnect and transforming it there.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in two weeks if no further activity occurs. Thank you for your contributions.

[florianesser]

@JohannaOtt I'm not totally sure what we can do if there is not transformation definition available in GeoTools like in the example. One potential way forward would be to try to transform XY and Z separately in such a case but that would probably require some fundamental changes to how geometry transformations are handled.

The problem with not being able to use a compound CRS as a custom CRS seems to be resolved in the meantime (most likely by a GeoTools update).

[JohannaOtt]

Thanks for the feedback.
@florianesser Would you still want to keep the issue in case we can address the separate transformation of XY and Z at one point or should we close it?

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in two weeks if no further activity occurs. Thank you for your contributions.

[JohannaOtt]

One potential way forward would be to try to transform XY and Z separately in such a case but that would probably require some fundamental changes to how geometry transformations are handled.

As there is currently no concrete use case and no concrete implementation approach for this, I close this ticket now.