[PATCH] Fix parsing of WMTS top-left corner

[nagisa]

Previously JOSM would switch north and east when parsing the WMTS top-left corner, which would then generally result in imagery being loaded at either wrong tile address or not loaded at all, because the tile x and y coordinates would become negative or otherwise out of bounds.

This patch fixes the parsing which, in turn, allows EPSG:3346 referenced imagery to work in Lithuania out of the box!

[nagisa]

Patch for the issue

[Don-vip]

Indeed I messed up in r15410. Thanks for the patch AND the unit test!

[Don-vip]

I got 9 test failures in WMTSTileSourceTest after I apply the patch. Can you please check if the tests are wrong and need an update?

[nagisa]

Huh, I'm not sure what's happening here.

So for example test/data/wmts/getcapabilities-ORTO.xml specifies

<TopLeftCorner>850000.0 100000.0</TopLeftCorner>

but that's a yx coordinate, not a xy one as seen at ​https://epsg.io/map#srs=2180&x=100000.0&y=850000.0&z=6&layer=osm (remember that this WMTS is for a Poland tileset).

Reading ​https://enonline.supermap.com/iPortal9D/API/WMTS/wmts_introduce.htm#MiniTOCBookMark8 (first hit on ddg) it looks like there's no set order in which the coordinates can appear and it might even depend on the server software used.

There's Projection.switchXY() which I think handles this but, from what I can tell, if its the way to specify this behaviour for given projection, then that should become true for the Poland's projection in this case, right?

[nagisa]

Wait, I'm now confusing myself.

So:

• The EPSG:2180 projection specifies neu axis;
• switchXY() returns true;
• The <TopLeftCorner>850000.0 100000.0</TopLeftCorner> with this patch gets parsed as EastNorth[x=e=850000.0, y=n=100000.0];
• The TLC was specified as north east in the first place, so the resulting parse is wrong.

And:

• The EPSG:3346 specifies axis=enu axis;
• switchXY() returns false;
• The <TopLeftCorner>1.00001E7 -5122000.0</TopLeftCorner> with this patch is parsed as EastNorth[x=east=-5122000.0, y=north=1.00001E7];
• The TLC was specified as north east, so the resulting parse is correct.

[nagisa]

OK, turns out it was just invalid epsg definition for the code... Will submit a patch momentarily.

EDIT: See #20346