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 <[email protected]> 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. > >
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
