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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
