Is `EuropeanETRS89_LAEAQuad.json` example right ? about 2d-tile-matrix-set

[joanma747]

I cannot believe that this EPSG is also in the "reverse" order!! https://epsg.org/crs_3035/ETRS89-extended-LAEA-Europe.html
"Cartesian 2D CS. Axes: northing, easting (Y,X). Orientations: north, east." I'm sure that I ignored it when I defined it and it is in the wrong order.

If you try this:
https://epsg.io/transform#s_srs=3035&t_srs=4326&x=5500000.0000000&y=2000000.0000000
It is not very "top" so the "topLeftCorner" was defined in the wrong order. This is much better:
https://epsg.io/transform#s_srs=3035&t_srs=4326&x=2000000.0000000&y=5500000.0000000

This was extracted that some official european service that I'm not able to find again (evne if I have tried. Sorry.

I agree with the requested change.

[jerstlouis]

Thank you @vincentsarago for reporting this.
You are right, there is an issue. Both the boundingBox lowerLeft / upperRight and pointOfOrigin should all be flipped.

http://www.opengis.net/def/crs/EPSG/0/3035 pointing to https://apps.epsg.org/api/v1/CoordRefSystem/4258/export?format=gml lists the order as: northing, easting.

Cartesian 2D CS. Axes: northing, easting (Y,X). Orientations: north, east

(axisAbbrev Y, X).

A) Assuming the bounding box is correct (northing / Y going from 2,000,000.0 to 6,500,000.0; followed by easting / X going from 1,000,000.0 to 5,500,000.0) then the pointOfOrigin should probably be [ 6500000.0, 1000000.0 ] rather than [ 2000000.0, 5500000.0 ].

B) If on the other hand the bounding box is intended to be (easting / X going from 2,000,000.0 to 6,500,000.0; followed by northing / Y going from 1,000,000.0 to 5,500,000.0), then the pointOfOrigin coordinates of [ 2000000.0, 5500000.0 ] would be correct, but both the boundingBox and the pointOfOrigin need to be flipped.

[EDIT: This (B) is the case.]

In either case, there is an issue (which we probably already had in 2DTMS 1.0). But do we know which it is? I am having trouble figuring out what are the EPSG:3035 valid bounds.

I see on a cached version of https://spatialreference.org/ref/epsg/etrs89-etrs-laea/ (currently down) that EPSG:3035 valids bounds are:

WGS84 Bounds: -10.6700, 34.5000, 31.5500, 71.0500
Projected Bounds: 2426378.0132, 1528101.2618, 6293974.6215, 5446513.5222

but which axis the projected bounds refer to is ambiguous.

If this is to be interpreted as a lowerLeft point followed by upperRight, each specified in the "CRS order" that would mean:
[EDIT: spatialreference.org does NOT follow CRS order. EPSG:4326 lists -180 first]

northing / Y range: 2,426,378.0132 .. 6,293,974.6215,
easting / X range: 1,528,101.2618 .. 5,446,513.5222

The TMS is rounding these down and up as:

2,426,378.0132 -> 2,000,000.0
1,528,101.2618 -> 1,000,000.0
6,293,974.6215 -> 6,500,000.0
5,446,513.5222 -> 5,500,000.0

and that would point to A) (the pointOfOrigin should be [ 6500000.0, 1000000.0 ]).
[EDIT: Not the case]

If however that should be interpreted as:

northing / Y range: 1,528,101.2618 .. 5,446,513.5222
easting / X range: 2,426,378.0132 .. 6,293,974.6215,
[EDIT: This is the proper interpretation]

then that would point to B) (both the boundingBox and the pointOfOrigin need to be flipped).

My guess is that it is B) and that spatialreference.org does not follow CRS order. How could we verify?
[EDIT: This is the case. I checked and https://spatialreference.org/ref/epsg/wgs-84/ shows EPSG:4326 but still lists -180 first]

Really, anwyhere not specifying a bunch of coordinates in bulk (as in for geometry), axes should be explicitly named -- 4 numbers in a row is just way too ambiguous.

@joanma747 It's exactly for these ambiguities that I wish we did not just follow CRS order, but always explicitly named minimum & maximum value for each axes identified by name. Enumerating values in a list of 4 values is just a terrible idea, as examplified by looking at that spatialreference.org info and not being sure whether the CRS axis order is followed. Then there's the problem of non-normative axisAbbrev... CRS axes really need a normative identifiers that should always explicitly be used. Then we would not be having all those problems. I wonder if new PROJJSON definitions of CRSes could help with that.

This makes me want to discuss #18 again.
If we cannot get it right in our own examples, it's an indication we're doing it wrong.