Missing +axis=neu in EPSG:4326, EPSG:3844, potentially other projinfo proj string

[SimonBin]

Example of problem

here are some projinfo outputs for epsg 3844, 4326, 25832

projinfo -o proj EPSG:3844
PROJ.4 string:
+proj=sterea +lat_0=46 +lon_0=25 +k=0.99975 +x_0=500000 +y_0=500000 +ellps=krass +units=m +no_defs +type=crs

projinfo -o proj EPSG:4326
PROJ.4 string:
+proj=longlat +datum=WGS84 +no_defs +type=crs

projinfo -o proj EPSG:25832
PROJ.4 string:
+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +type=crs

projinfo -o proj EPSG:29385
PROJ.4 string:
+proj=tmerc +axis=wsu +lat_0=-22 +lon_0=25 +k=1 +x_0=0 +y_0=0 +ellps=bess_nam +to_meter=1.0000135965 +no_defs +type=crs

Problem description

There is no reference to the axis order in the output of projinfo. This causes difficulty in correctly reading coordinates from an array e.g. when interpreting GeoSPARQL data, since GeoSPARQL will respect the axis order in the CRS when outputting coordinate arrays.

As you can see, axis info is included for EPSG:29385

The problem also penetrates many things like the epsg.io website (export of PROJ.4 strings) or the Javascript epsg module, where this useful information is missing and thus cannot be accessed by Proj4JS.

I also found on the issue tracker that a similar problem exists for Mars: issue #3995 (Missing +axis=wnu)

As an aside, the WKT2 output does include the axis info. However I cannot use WKT2 in Proj4JS.

Expected Output

+axis=neu in EPSG:4326, EPSG:3844

optionally (since it is the default)

+axis=enu in EPSG:25832

Environment Information

• PROJ version (proj)
• Rel. 9.4.1, June 1st, 2024
• Operation System Information
• openSUSE Tumbleweed 20240807

Installation method

• zypper (rpm)

[rouault]

PROJ.4 strings to express CRS are deprecated since many years and are lacking many other important information (like most datum). No enhancements to them is planned. They are basically frozen to what GDAL <= 2.4 used to generate. Proj4JS should consider evolving to support WKT2.

[mwtoews]

Proj4JS should consider evolving to support WKT2.

Xref to https://github.com/proj4js/proj4js/issues/400 where support for PROJJSON / WKT2 is planned.

[mohawk2]

I spent a couple of hours trying to get the PROJ API to tell me how it was interpreting its input coordinates. I can tell from proj_normalize_for_visualization that internally it knows what its coordinates mean. I would like an API so that I can ask a given PJ (singular or compound) what its input and output axes are.

Are you open to a PR implementing such?

[rouault]

Are you open to a PR implementing such?

no need for one. API already exists. Cf https://proj.org/en/9.5/development/reference/functions.html#c.proj_crs_get_coordinate_system + https://proj.org/en/9.5/development/reference/functions.html#c.proj_cs_get_axis_count + https://proj.org/en/9.5/development/reference/functions.html#c.proj_cs_get_axis_info

Example at https://github.com/OSGeo/PROJ/blob/master/src/apps/cs2cs.cpp#L276-L298

[SimonBin]

fwiw I have a small code here to get the info also in PROJ string: https://github.com/SimonBin/PROJ/commit/a5a15c40a88b930a960036c0199e53c04db9be1f

[mohawk2]

@rouault I have tried this, and it has not helped in my use case. I want to take any arbitrary string that's passable to pj_create, and see what units it takes as inputs (on each axis would be great), and what units it outputs (also on each axis, which might be a different number). Sadly, it seems the string +proj=eqc +lon_0=0 +datum=WGS84 gives a PJ_TYPE of PJ_TYPE_OTHER_COORDINATE_OPERATION.

I tried to get creative and use proj_create_crs_to_crs which says it can take a PROJ string, but then I get the error proj_create_operations: source_crs is not a CRS or a CoordinateMetadata. Please advise!

EDIT In a perfect world, this will be possible with 6.3 API, since Ubuntu 20.04 has 6.3.1 and is only EOL in Apr 2025.

[rouault]

Sadly, it seems the string +proj=eqc +lon_0=0 +datum=WGS84 gives a PJ_TYPE of PJ_TYPE_OTHER_COORDINATE_OPERATION.

yes, you need to add " +type=crs" to specify the PROJ.4 style string is intended to be a CRS

[mohawk2]

OK - if I naively check in my code for that, and add it if absent, will that make any other change to the PJ that's created? i.e. Will it then allow an accurate reflection of the inputs?

[mohawk2]

@rouault Will adding +type=crs change the PJ, as I suspect?