[gdal-dev] [PROJ] OGRCreateCoordinateTransformation()

[Even Rouault]

Le 24/03/2022 à 18:36, Erixen Cruz a écrit :
>
>>     PROJ4_GRIDS provided a way to specify exactly which geoid file(s)
>>     to use.  Some vertical datums, such as NAVD88, only have a single
>>     EPSG code for multiple geoids – what’s the replacement for
>>     PROJ4_GRIDS in PROJ9?  If I could switch to WKT2 strings (not
>>     sure that’s really feasible) does it fix these problems?
>>
>      WKT2 hardly helps for that.
>
>
> There is one way to get WKT2 to do just this. Here's the start of the 
> thread about that: 
> https://lists.osgeo.org/pipermail/proj/2019-December/009142.html. TLDR 
> you use a BOUNDCRS with an ABRIDGEDTRANSFORMATION. Thanks again, Even, 
> for pointing us in this direction.
>
> This is not ideal though. Like Even said, this (mis)use of BOUNDCRS 
> doesn't fit very cleanly in PROJ9 at the moment.

yeah, that can be used in PROJ (and that's exactly how a WKT1 with a 
TOWGS84 or PROJ4_GRIDS, or a PROJ.4 strings with 
+towgs84/+nadgrids/+geoidgrids end up being represented), but 
pedantically a BOUNDCRS[] is not a CRS. PROJ does accept is as a CRS 
(such as a COMPOUNDCRS of BOUNDCRS[]) because there was no other 
convenient way of modeling those legacy features in ISO19111:2019 / 
WKT2:2019, but this is an extension, and strictly conforming other 
implementations would reject that.

And the ABRIDGEDTRANSFORMATION[]  syntax cannot be used for vertical 
transformations where the geographic CRS would not be the interpolation CRS.


-- 
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/gdal-dev/attachments/20220324/b08cef76/attachment.html>