[PROJ] Unexpected CRS Validation Error

[Simon Eves]

OK, thanks.

Unfortunately, in our case, an error from *OSRValidate()* aborts the import
completely. At the GDAL API level, there is no way to tell if it could be
ignored or not, as it all gets collapsed into a single error code.

Presumably if the CRS was truly bad, the subsequent
*OGRCreateCoordinateTransformation(bad_sr_from_file,
desired_good_sr)* would fail, which we would obviously also abort on.

Sounds like we should just remove the *OSRValidate()* test, which would
allow this file to import, but ones that were "more bad" would still be
rejected later.

Simon


On Thu, Mar 28, 2024 at 10:51 AM Even Rouault <even.rouault at spatialys.com>
wrote:

>
> Le 28/03/2024 à 17:47, Simon Eves a écrit :
> > Seems like whether a PROJ warning is reported as an error or warning
> > depends on whether it has "Default it to" in the text. This one does
> > not, and is returned as an error. The logic here is unclear to me.
>
> yes, there was indeed a discrepancy between the documented behavior of
> the PROJ C API and what the PROJ C++ API offered to fulfill it. That
> should be solved by https://github.com/OSGeo/PROJ/pull/4108
>
> However as noted in the updated documentation, the distinction between
> warnings and errors is probably not that much relevant, and the mapping
> to the OSRValidate() API that dates backs to well before the complete
> revanp done in PROJ 6+GDAL 3 is even more arbitrary. The bottom line is
> that if OSRValidate() returns a non-OGRERR_NONE code, there's something
> that is non nominal, and human expertise is required to assess if it can
> be ignored or not.
>
>
> --
> 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/20240328/87495f35/attachment.htm>