[gdal-dev] BAG CRS

[Even Rouault]

André,

I don't confirm this trying:

$ gdal_translate autotest/gcore/data/byte.tif byte.bag

$ gdalinfo byte.bag -mdd xml:BAG | grep PROJCS
             <gco:CharacterString>PROJCS["NAD27 / UTM zone 
11N",GEOGCS["NAD27",DATUM["North_American_Datum_1927",SPHEROID["Clarke 
1866",6378206.4,294.978698213898,AUTHORITY["EPSG","7008"]],AUTHORITY["EPSG","6267"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4267"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-117],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","26711"]]</gco:CharacterString>

This is WKT1

I'm wondering if the confusion might come from looking at the CRS 
reported by gdalinfo, which will always be WKT2 in recent GDAL versions 
whatever the encoding in the source dataset itself ?

Or perhaps you try to write a Geographic 3D CRS ? in which case WKT2 
will be used since there's no WKT1 representation for this

$ gdalwarp -overwrite autotest/gcore/data/byte.tif byte.bag -t_srs 
EPSG:4979 -ot float32

$ gdalinfo byte.bag -mdd xml:BAG | grep GEOGCRS
             <gco:CharacterString>GEOGCRS["WGS 84",ENSEMBLE["World 
Geodetic System 1984 ensemble",MEMBER["World Geodetic System 1984 
(Transit)"],MEMBER["World Geodetic System 1984 (G730)"],MEMBER["World 
Geodetic System 1984 (G873)"],MEMBER["World Geodetic System 1984 
(G1150)"],MEMBER["World Geodetic System 1984 (G1674)"],MEMBER["World 
Geodetic System 1984 (G1762)"],MEMBER["World Geodetic System 1984 
(G2139)"],ELLIPSOID["WGS 
84",6378137,298.257223563,LENGTHUNIT["metre",1]],ENSEMBLEACCURACY[2.0]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433]],CS[ellipsoidal,3],AXIS["geodetic 
latitude 
(Lat)",north,ORDER[1],ANGLEUNIT["degree",0.0174532925199433]],AXIS["geodetic 
longitude 
(Lon)",east,ORDER[2],ANGLEUNIT["degree",0.0174532925199433]],AXIS["ellipsoidal 
height (h)",up,ORDER[3],LENGTHUNIT["metre",1]], [... snip ....] 
,ID["EPSG",4979]]</gco:CharacterString>

(I see that gdalinfo also issues a "ERROR 1: PROJ: 
proj_create_compound_crs: components of the compound CRS do not belong 
to one of the allowed combinations of 
http://docs.opengeospatial.org/as/18-005r4/18-005r4.html#34" when 
reading this, which I suspect comes from the fact that it tries to 
create a CompoundCRS from this 3D GeogCRS and the "VERT_CS["unknown", 
VERT_DATUM["unknown", 2000]]", so writing 3D GeogCRS isn't really 
appropriate for BAG)

Even

Le 22/04/2022 à 18:01, Vautour, André (INT) a écrit :
>
> Hi all,
>
> It has just come to my attention that the BAG driver in GDAL is 
> writing the CRS with a WKT codeSpace and a WKT 2.0 string as the code. 
> While I am fairly sure we started that incorrect practice here at 
> CARIS with a WKT 1.0 string, this is the first time I’ve seen a WKT 
> 2.0 string written in there, and I am therefore concerned about 
> interoperability.
>
> I think we can all agree that what makes the most sense is to write an 
> EPSG codebase with the EPSG code if we have it, and I think falling 
> back to a WKT 1.0 string if it is not EPSG is a reasonable fallback if 
> it is not EPSG, given how it has been used in the past, but I am 
> worried that older software won’t recognize the WKT 2.0 string.
>
> Would you be willing to take a pull request that does that? 
> Worst-case, would you be fine with changing that WKT 2.0 string to a 
> WKT 1.0 string?
>
> Regards,
>
> André
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
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/gdal-dev/attachments/20220422/380beb12/attachment-0001.html>