[PROJ] Unexpected CRS Validation Error

[Simon Eves]

Thanks for this, chaps. That certainly explains the original of the issue.

My remaining question, if GDAL is going to declare the resulting SR as
invalid, is whether that is grounds for rejecting the file completely,
given that GDAL does not expose those warnings when converting it to
another format. In other words, should we actually bother calling
*Validate()* at all, or just keep our head in the sand and continue with
the import anyway?

That said, I note that the PROJ code calls *emitRecoverableWarning()* in
this case, and yet the resulting string ends up in *m_wktImportErrors* in
GDAL and thus triggers the hard error. Surely if it's a warning, the string
should end up in *m_wktImportWarnings*, which would be *CPLDebug*'d but NOT
trigger the hard error.

Simon

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

> Hi,
>
> just a few complements to Javier's analysis:
>
> - what you observe and what Javier mentioned applies if you import
> directly the .prj WKT content, but the GDAL shapefile driver actually
> replaces this not pretty WKT with a cleaned version of EPSG:4326 (at least
> with GDAL+PROJ master), so if you use the high level GDAL API, things
> should work smoothly
>
> - the 9001 ID you observe when looking at the WKT2 output of the result of
> the ingestion of the .prj  is *not* a CRS ID. It is the ID of the
> ellipsoid's lengthunit=metre. You can have several IDs in a WKT definition:
> for the CRS, datum, ellipsoid, projection method, projection parameter,
> units, etc. They only apply to the node to which they are applied to. In
> some contexts, they are advised to be omitted. The general rule is "if you
> know the id of a top-level object, you can omit the IDs of its child
> elements, except in several cases". All gory details at
> https://www.ogc.org/standard/wkt-crs/
>
> So all in all, to me things are working as expected. It is mostly you deal
> with a a slightly non-compliant .prj file
>
> Even
> Le 28/03/2024 à 03:06, Simon Eves via PROJ a écrit :
>
> When trying to import this Shapefile bundle into our system with GDAL...
>
>
> https://drive.google.com/file/d/13Mwhnugcy8HrnGlc81gyroxnp9s15Skt/view?usp=sharing
>
> ...we get an *OGRERR_CORRUPT_DATA* from *OGRSpatialReference::Validate()*
> on the SR obtained from the first feature.
>
> Tracing through the GDAL and PROJ code, this appears to be because the
> PROJ import of that CRS results in the following WKT Import Error from
> PROJ...
>
>
> *Coordinate system of GeographicCRS in the WKT definition is different
> from the one of the authority. Unsetting the identifier to avoid confusion *
>
> ...and any WKT Import Error makes GDAL report that error code.
>
> The PROJ code throws this in *WKTParser::Private::buildGeodeticCRS*
> (io.cpp:3229 in 9.3.0) which is old code (although the second branch which
> can throw the same error was seemingly added between 8.2 and 9.3 in
> https://github.com/OSGeo/PROJ/pull/3274 ...but it's the first branch
> that's triggering in this case).
>
> *ogrinfo* on the Shapefile reports no errors or warnings, although it
> does report a CRS ID of 9001 even though it reports WGS84 elsewhere in the
> CRS block.
>
> I was able to trivially *ogr2ogr* it to GeoJSON, also with no errors or
> warnings, and that imports with no issue.
>
> Is there an actual problem (a bad file) here, or are we doing something
> wrong?
>
> Thanks, as ever, in advance.
>
> --
> Simon Eves
> Senior Rendering Engineer
> +1 (415) 902-1996
> simon.eves at heavy.ai
>
> <http://www.heavy.ai>
>
> _______________________________________________
> PROJ mailing listPROJ at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj
>
> -- 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/39aae6fc/attachment-0001.htm>