Dynamic projection EPSG:3035 is not correctly visualized

[allyoucanmap]

Description

The projection EPSG:3035 is not correctly visualized when configuring a GeoServer crs service inside the projections selector.

We should verify if the projection is correctly parsed by the definition provided by GeoServer, this may be an axis order problem. We should also verify that the identify and the search.

Before providing a fix let's verify if the problem is on the configuration side

How to reproduce

• enable the dynamic crs configuration in the CRS selector (a GeoServer supporting rest/crs is needed >= v.2.28.x)
• create a map, add a layer and save
• change the projection using the geoserver service
• select EPSG:3035

Expected Result

The EPSG:3035 is visualized correctly and working as expected with identify and search

Current Result

The EPSG:3035 is not working correctly

• Not browser related

Browser info

(use this site: https://www.whatsmybrowser.org/ for non expert users)

Browser Affected	Version
Internet Explorer
Edge
Chrome
Firefox
Safari

Other useful information

[stefanocudini]

@allyoucanmap @dromagnoli
Client side the logic in the check conditions within ProjectionRegistry is completely correct, defined here:

MapStore2/web/client/utils/ProjectionRegistry.js

Lines 62 to 88 in 80448ce

	const { def: normalizedDef, supported } = toDef(def);
	if (supported && !proj4.defs(code)) {
	proj4.defs(code, normalizedDef);
	}
	const proj4Metadata = proj4.defs(code);
	// If proj4 already knows the code (e.g. registered earlier or via the
	// legacy addProjections helper that recovers the def from proj4 itself),
	// the projection is usable regardless of how the input def parsed -
	// mark it supported so map-library adapters pick it up.
	const isSupported = supported || !!proj4Metadata;
	const isGeographic = ['longlat', 'latlong'].includes(proj4Metadata?.projName)
	|| normalizeUnit(proj4Metadata?.units) === 'degrees';
	// proj4 reports axis 'enu' even for geographic CRS - default to 'neu' (OGC/ISO lat-first order) and let projDef.axisOrientation override if needed
	const axisOrientation = projDef?.axisOrientation || proj4Metadata?.axis || (isGeographic ? 'neu' : 'enu');
	const units = projDef?.units || proj4Metadata?.units || 'm';
	const entry = {
	code,
	def: normalizedDef,
	extent,
	worldExtent,
	axisOrientation,
	units,
	supported: isSupported
	};

Testing shows that the definition field returned only by the CRS Rest interface in geoserver version 2.28
returned here
https://development.demo.geonode.org/geoserver/rest/crs/EPSG:3035.json

is EAST,NORTH

The axes order is reversed compared to the original CRS 3035 definition.

The same does not happen when loading the same CRS from the internal definition, that appear in right order:
https://development.demo.geonode.org/geoserver/web/wicket/bookmarkable/org.geoserver.web.demo.SRSDescriptionPage?0&code=EPSG:3035

which is in the correct order. NORTH,EAST

In any case, the CRS endpoint /rest/crs/EPSG:3035.json should return the axes as per the WMS 1.3.0 standard, following the original CRS definition.
Ignoring any configuration: GeoServer → Global Settings → "Use Strict EPSG Axis Order" to False

After testing below by mocking the definition with the AXIS in the correct order, the layer displays correctly.

The mocked definition change for 3035 the order of axis, From:

AXIS["Geodetic longitude", EAST],
AXIS["Geodetic latitude", NORTH],
...

AXIS["Easting", EAST],
AXIS["Northing", NORTH],

has been changed to this:

AXIS["Geodetic latitude", NORTH],
AXIS["Geodetic longitude", EAST],
...

AXIS["Northing", NORTH],
AXIS["Easting", EAST],