Javier, > The prj that a friend gave me was this: > PROJCS["NAD_1983_2011_StatePlane_Colorado_Central_FIPS_0502_Ft_US",GEOGCS["G > CS_NAD_1983_2011",DATUM["D_NAD_1983_2011",SPHEROID["GRS_1980",6378137.0,298. > 257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJE > CTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",3000000.000316083 > ],PARAMETER["False_Northing",999999.999996],PARAMETER["Central_Meridian",-10 > 5.5],PARAMETER["Standard_Parallel_1",38.45],PARAMETER["Standard_Parallel_2", > 39.75],PARAMETER["Latitude_Of_Origin",37.83333333333334],UNIT["Foot_US",0.30 > 48006096012192]],VERTCS["CGVD2013_height",VDATUM["Canadian_Geodetic_Vertical > _Datum_of_2013"],PARAMETER["Vertical_Shift",0.0],PARAMETER["Direction",1.0], > UNIT["Meter",1.0]]
OK, so I've verified with another well-informed source that the above PROJCS[...],VERTCS[...] is the syntax generated and expected by ESRI software for compound CRS. I've fixed import/export of compound CRS from/into ESRI WKT for upcoming PROJ 7.2 per https://github.com/OSGeo/PROJ/pull/2389. > If GDAL is now exporting it as COMPD_CS, > but not everybody understands it, neither the horizontal part, it becomes a > compatibility problem. In the GDAL 2.x series, on output of the Shapefile driver, only the horizontal part was exported, due to morphToESRI() stripping the vertical part (not sure if it was intented or accidental) So yes we have a potential compatibility problem for .prj generated by GDAL 3 using PROJ >= 6.0 and < 7.2 that will emit COMPD_CS Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
