Database: import scope/remarks for coordinate operation and add C API

[rouault]

• Import scope and remarks for coordinate operations of the EPSG dataset.
  Database size goes from 5.2 MB to 5.55 MB
• Add proj_get_scope() and proj_get_remarks()

[jmckenna]

I personally think the benefit of adding the remarks is worth the increase in file size. (even as a packager) +1

[nyalldawson]

Wow, thanks for the fast response here!

[nyalldawson]

@rouault Been giving this a test run, and I think some information is missing.

E.g.:

./projinfo -s EPSG:28356 -t EPSG:7856 --spatial-test intersects

gives:

...
Operation n°2:

unknown id, Inverse of Map Grid of Australia zone 56 + GDA94 to GDA2020 (2) + Map Grid of Australia zone 56, 0.05 m, Australia - onshore, at least one grid missing
...
   STEP[
        COORDINATEOPERATION["GDA94 to GDA2020 (2)",
            VERSION["ICSM-Aus Conf and Dist"],
            SOURCECRS[
                GEOGCRS["GDA94",
                    DATUM["Geocentric Datum of Australia 1994",
                        ELLIPSOID["GRS 1980",6378137,298.257222101,
                            LENGTHUNIT["metre",1]]],
                    PRIMEM["Greenwich",0,
                        ANGLEUNIT["degree",0.0174532925199433]],
                    CS[ellipsoidal,2],
                        AXIS["geodetic latitude (Lat)",north,
                            ORDER[1],
                            ANGLEUNIT["degree",0.0174532925199433]],
                        AXIS["geodetic longitude (Lon)",east,
                            ORDER[2],
                            ANGLEUNIT["degree",0.0174532925199433]],
                    ID["EPSG",4283]]],
            TARGETCRS[
                GEOGCRS["GDA2020",
                    DATUM["Geocentric Datum of Australia 2020",
                        ELLIPSOID["GRS 1980",6378137,298.257222101,
                            LENGTHUNIT["metre",1]]],
                    PRIMEM["Greenwich",0,
                        ANGLEUNIT["degree",0.0174532925199433]],
                    CS[ellipsoidal,2],
                        AXIS["geodetic latitude (Lat)",north,
                            ORDER[1],
                            ANGLEUNIT["degree",0.0174532925199433]],
                        AXIS["geodetic longitude (Lon)",east,
                            ORDER[2],
                            ANGLEUNIT["degree",0.0174532925199433]],
                    ID["EPSG",7844]]],
            METHOD["NTv2",
                ID["EPSG",9615]],
            PARAMETERFILE["Latitude and longitude difference file","GDA94_GDA2020_conformal_and_distortion.gsb"],
            OPERATIONACCURACY[0.05],
            ID["EPSG",8447],
            REMARK["See GDA94 to GDA2020 (1) or (3) (codes 8048 and 8446) for alternative conformal-only transformation without local distortion modelling. GDA2020 Technical Manual and fact sheet T1 give guidance on which to use."]]],
...

There's no SCOPE information here - yet the EPSG registry has "Transformation of GDA94 coordinates when localised distortion needs to be taken into account, e.g. if GDA94 coordinates were derived survey control monuments." as the scope for EPSG:8447. (And I do see this scope information when running ./projinfo EPSG:8447 -k operation)

[rouault]

Been giving this a test run, and I think some information is missing.

Yes, this is a consequence of the coordinate operation being integrated in a concatenatedoperation and some formatting rules of WKT export to try to reduce the amount of text generated. There are a number of prescriptions in the WKT standard, in particular regarding when to put ID or not. I can't find anything for USAGE[] so this is probably my own decision (the rule being that if the concatenatedoperation has a USAGE[] node, then the ones of the steps are omitted), based on examples in the WKT standard actually which seem to follow that rule.
The information should still be there if you inspect the steps of the concatenated operation with the C API.
In that particular case where the concatenatedoperation chains "boring" conversions and just a single coordinateoperation, one could probably "import" the scope and remark from that coordinateoperation to the concatenatedoperation itself, but that starts to becoming tricky...

[nyalldawson]

@rouault thanks for the clarification

So what I was thinking (for QGIS) was to iterate through the steps of the coordinate operation (what's the c api for doing this? I can't work it out from the docs), and collecting a list of remarks and scope. I'll then concatenate all these into a list to display to users. It's not perfect, but should give enough clues regarding the limitations/scope of a particular coordinate operation to help users make informed decisions...

[rouault]

what's the c api for doing this?

was missing. Just added it per 8b11663

[nyalldawson]

Thanks, looks good to me

[nyalldawson]

Ok, this is MUCH better, thank you very much!

[nyalldawson]

QGIS PR which uses this new API at qgis/QGIS#30501

[rduivenvoorde]

THANKS @rouault @nyalldawson !! Nice work!

@nyalldawson I've seen this dialog popup now on a couple of incidents, and I think the 'average' user is now aware of these 'details'. What about adding Help button in that dialog pointing to:
https://docs.qgis.org/testing/en/docs/user_manual/working_with_projections/working_with_projections.html ?

Even better: if we add a chapter there which explains defines the differences between crs, projection, transformation, datum etc etc. Anybody a good primer for that? Personally I found the Esri page https://pro.arcgis.com/en/pro-app/help/mapping/properties/coordinate-systems-and-projections.htm a nice intro, though I do not know if we use the exact same definitions..

[nyalldawson]

@rduivenvoorde do you mean "not aware"? (Let's move the QGIS specific conversation to qgis/QGIS#30501 to avoid spamming the proj maintainers )