The definition of the CRS is in the .prj file of the shapefile, as plain text. In this case:
GEOGCS["WGS84(DD)", DATUM["WGS84", SPHEROID["WGS84", 6378137.0, 298.257223563]], PRIMEM["Greenwich", 0.0], UNIT["degree", 0.017453292519943295], AXIS["Geodetic longitude", EAST], AXIS["Geodetic latitude", NORTH], AUTHORITY["EPSG","4326"]] That formal definition of EPSG:4326 is northing-easting, and that WKT is saying easting-northing. So there is an inconsistency in the definition of the system, because at the end it says that the authority is EPSG:4326 You can either remove the axis or the final authority (the error message says that proj is removing the authority ;) The axis order I think is not used to read the coordinates in a shp file, so the outputs should be the same. The actual definition of EPSG:4326 in ESRI (from https://spatialreference.org/ref/epsg/4326/esriwkt.txt) GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] In case anybody needs an equivalent to EPSG:4326 but easting-northing in other context, there is https://spatialreference.org/ref/ogc/CRS84/ Cheers, Javier On Thu, 28 Mar 2024 at 03:06, Simon Eves via PROJ <[email protected]> wrote: > 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 > [email protected] > > <http://www.heavy.ai> > _______________________________________________ > PROJ mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/proj >
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
