Missing +axis=wnu for PROJ string with IAU_2015:49901

[mwtoews]

This issue is found here. Consider CRS IAU_2015:49901:

$ projinfo -k crs IAU_2015:49901
PROJ.4 string:
+proj=longlat +a=3396190 +b=3376200 +no_defs +type=crs

WKT2:2019 string:
GEOGCRS["Mars (2015) / Ographic",
    DATUM["Mars (2015)",
        ELLIPSOID["Mars (2015)",3396190,169.894447223612,
            LENGTHUNIT["metre",1]],
        ANCHOR["Viking 1 lander: 47.95137 W"]],
    PRIMEM["Reference Meridian",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",west,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    ID["IAU",49901,2015],
    REMARK["Source of IAU Coordinate systems: doi://10.1007/s10569-017-9805-5"]]

The expected axis orientation for the PROJ string should be +axis=wnu. Most other outputs contain the correct axis orientation metadata.

Other projections (e.g. projinfo -k crs EPSG:5513) support different +axis values.

Environment Information

• PROJ Rel. 9.1.1, December 1st, 2022
• Operation System Information: Win64

Installation method

• conda

[rouault]

The expected axis orientation for the PROJ string should be +axis=wnu

Actually it should +axis=nwu, shouldn't it ?

and for a similar reason, for EPSG:4326, it should be +axis=neu. Except that we never did that in PROJ < 6

PROJ >= 6 proj.4 CRS string output was aimed at being bug-to-bug compatible with GDAL 2.x exportToProj4(), which mostly/only outputs +awis=wnu for the default/non-East-North Krovak projection.

As far as I can see, this (does not) work as designed.

[mwtoews]

Correct, +axis=nwu for the Mars example. The axis orientation docs should probably specify that the order is important, as it is currently written to assume XYZ.

But ultimately, compatibility with previous forms to not introduce bugs should take precedent.

[rouault]

But ultimately, compatibility with previous forms to not introduce bugs should take precedent.

not sure to understand what you mean by that.

But basically my view of PROJ4 string is:

• you should only use them for interoperability with ancient systems (GDAL < 3, PROJ < 6).
• trying to fix them could break interoperability, because people have had a history of working around such axis order issues, by doing the axis swap or sign flip as needed.

[mwtoews]

not sure to understand what you mean by that.

Compatibility with legacy systems that still use PROJ strings should be maintained over trivial improvements (in this case, a CRS for Mars). I won't mind this to be "closed as not planned" since big changes shouldn't probably happen to PROJ strings.