Forum

Author Topic: ExportRaster wkt is different to the projection CRS  (Read 999 times)

EE

  • Newbie
  • *
  • Posts: 21
    • View Profile
ExportRaster wkt is different to the projection CRS
« on: December 10, 2020, 12:17:02 PM »
Dear,

I have noticed a problem with EPSG 27563.
When I use the console to print `Metashape.CoordinateSystem('EPSG::27563').wkt` I get:
Code: [Select]
`'PROJCS["NTF (Paris) / Lambert Sud France",GEOGCS["NTF (Paris)",DATUM["Nouvelle Triangulation Francaise (Paris)",SPHEROID["Clarke 1880 (IGN)",6378249.2,293.466021293627,AUTHORITY["EPSG","7011"]],TOWGS84[-168,-60,320,0,0,0,0],AUTHORITY["EPSG","6807"]],PRIMEM["Paris",2.33722917,AUTHORITY["EPSG","8903"]],UNIT["grad",0.01570796326794895,AUTHORITY["EPSG","9105"]],AUTHORITY["EPSG","4807"]],PROJECTION["Lambert_Conformal_Conic_1SP",AUTHORITY["EPSG","9801"]],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",0],PARAMETER["scale_factor",0.999877499],PARAMETER["false_easting",600000],PARAMETER["false_northing",200000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","27563"]]'`
But when I export a raster (Dem for example), gdalinfo reports a different wkt:
Code: [Select]
Coordinate System is:
BOUNDCRS[
    SOURCECRS[
        PROJCRS["NTF (Paris) / Lambert Sud France",
            BASEGEOGCRS["NTF (Paris)",
                DATUM["Nouvelle Triangulation Francaise (Paris)",
                    ELLIPSOID["Clarke 1880 (IGN)",6378249.2,293.466021293627,
                        LENGTHUNIT["metre",1]]],
                PRIMEM["Paris",2.5969213,
                    ANGLEUNIT["grad",0.0157079632679489]],
                ID["EPSG",4807]],
            CONVERSION["unnamed",
                METHOD["Lambert Conic Conformal (1SP)",
                    ID["EPSG",9801]],
                PARAMETER["Latitude of natural origin",54.4444444444445,
                    ANGLEUNIT["grad",0.0157079632679489],
                    ID["EPSG",8801]],
                PARAMETER["Longitude of natural origin",0,
                    ANGLEUNIT["grad",0.0157079632679489],
                    ID["EPSG",8802]],
                PARAMETER["Scale factor at natural origin",0.999877499,
                    SCALEUNIT["unity",1],
                    ID["EPSG",8805]],
                PARAMETER["False easting",600000,
                    LENGTHUNIT["metre",1],
                    ID["EPSG",8806]],
                PARAMETER["False northing",200000,
                    LENGTHUNIT["metre",1],
                    ID["EPSG",8807]]],
            CS[Cartesian,2],
                AXIS["easting",east,
                    ORDER[1],
                    LENGTHUNIT["metre",1]],
                AXIS["northing",north,
                    ORDER[2],
                    LENGTHUNIT["metre",1]],
            ID["EPSG",27563]]],
    TARGETCRS[
        GEOGCRS["WGS 84",
            DATUM["World Geodetic System 1984",
                ELLIPSOID["WGS 84",6378137,298.257223563,
                    LENGTHUNIT["metre",1]]],
            PRIMEM["Greenwich",0,
                ANGLEUNIT["degree",0.0174532925199433]],
            CS[ellipsoidal,2],
                AXIS["latitude",north,
                    ORDER[1],
                    ANGLEUNIT["degree",0.0174532925199433]],
                AXIS["longitude",east,
                    ORDER[2],
                    ANGLEUNIT["degree",0.0174532925199433]],
            ID["EPSG",4326]]],
    ABRIDGEDTRANSFORMATION["Transformation from NTF (Paris) to WGS84",
        METHOD["Position Vector transformation (geog2D domain)",
            ID["EPSG",9606]],
        PARAMETER["X-axis translation",-168,
            ID["EPSG",8605]],
        PARAMETER["Y-axis translation",-60,
            ID["EPSG",8606]],
        PARAMETER["Z-axis translation",320,
            ID["EPSG",8607]],
        PARAMETER["X-axis rotation",0,
            ID["EPSG",8608]],
        PARAMETER["Y-axis rotation",0,
            ID["EPSG",8609]],
        PARAMETER["Z-axis rotation",0,
            ID["EPSG",8610]],
        PARAMETER["Scale difference",1,
            ID["EPSG",8611]]]]

The preferred wkt would just be the PROJCRS and not the full BOUNDCRS. Since this BOUNDCRS is confusing GDAL (https://github.com/OSGeo/gdal/issues/3273 and https://github.com/OSGeo/gdal/pull/2370 )

Is there a way to remove this BOUNDCRS?
And how come the wkt is different in the export?

Many thanks

Alexey Pasumansky

  • Agisoft Technical Support
  • Hero Member
  • *****
  • Posts: 13210
    • View Profile
Re: ExportRaster wkt is different to the projection CRS
« Reply #1 on: December 11, 2020, 02:40:34 PM »
Hello EE,

Metashape is not writing WKT information to GeoTIFFs and is using the supported TIFF tags for the coordinate system definition. It seems gdalinfo just forms the wkt representation based on the information it has extracted from the GeoTFF header and meta data.

As for the PROJCRS line, you can access it using Metashape.CoordinateSystem('EPSG::27563').wkt2 method.
Best regards,
Alexey Pasumansky,
Agisoft LLC

EE

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: ExportRaster wkt is different to the projection CRS
« Reply #2 on: December 11, 2020, 03:01:30 PM »
Hello Alexey

That would indeed explain why there is a difference, thank you for your explanation.

Is there any way to write the information in the TIFF tags so that the BOUND_CRS is not inferred as it seems to be deprecated (and brings no extra information, see GDAL PR linked in the first message)?
Possibly we can check the difference on the TIFF tags between a direct export from Metashape (resulting in BOUND_CRS) to the same tiff passed through gdal_translate which strips the BOUND_CRS? I can send you both files if you would like to check.
Or should this be tackled on the GDAL side?

Thank you for your quick response.

EE

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: ExportRaster wkt is different to the projection CRS
« Reply #3 on: October 11, 2021, 05:52:32 PM »
Sorry for the bump, I was wondering if this behaviour has changed in recent versions or if it is still the same?
Thank you!