wms 1.3 getCapabilities layer BoundingBox with swapped axis

Andrea, I could use your input on this. Originally I thought at simply using the "urn:x-ogc..." prefix would simply not affect projected crs'. For instance:

p1 = CRS.decode('urn:x-ogc:def:crs:EPSG:23031')

Results in:

PROJCS["ED50 / UTM zone 31N", 
  GEOGCS["ED50", 
    DATUM["European Datum 1950", 
      SPHEROID["International 1924", 6378388.0, 297.0, AUTHORITY["EPSG","7022"]], 
      TOWGS84[-157.89, -17.16, -78.41, 2.118, 2.697, -1.434, -1.1097046576093785], 
      AUTHORITY["EPSG","6230"]], 
    PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], 
    UNIT["degree", 0.017453292519943295], 
    AXIS["Geodetic latitude", NORTH], 
    AXIS["Geodetic longitude", EAST], 
    AUTHORITY["EPSG","4230"]], 
  PROJECTION["Transverse Mercator", AUTHORITY["EPSG","9807"]], 
  PARAMETER["central_meridian", 3.0], 
  PARAMETER["latitude_of_origin", 0.0], 
  PARAMETER["scale_factor", 0.9996], 
  PARAMETER["false_easting", 500000.0], 
  PARAMETER["false_northing", 0.0], 
  UNIT["m", 1.0], 
  AXIS["Easting", EAST], 
  AXIS["Northing", NORTH], 
  AUTHORITY["EPSG","23031"]]

However if i call p1.getBaseCRS() what I get back is:

GEOGCS["ED50", 
  DATUM["European Datum 1950", 
    SPHEROID["International 1924", 6378388.0, 297.0, AUTHORITY["EPSG","7022"]], 
    TOWGS84[-157.89, -17.16, -78.41, 2.118, 2.697, -1.434, -1.1097046576093785], 
    AUTHORITY["EPSG","6230"]], 
  PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], 
  UNIT["degree", 0.017453292519943295], 
  AXIS["Geodetic latitude", NORTH], 
  AXIS["Geodetic longitude", EAST], 
  AUTHORITY["EPSG","4230"]]

Which is flipped. So I wonder what is the best way forward. Should we just check for a geographic CRS before calling CRS.getAxisOrder()? Or somehow incorporate the logic the logic into that method? Ideas welcome.

Hi Justin,
this is unfortunately normal behavior.
When you use the urn form the lon and lat always get swapped in the geographic crs, even in the ones embedded inside the projected crs, so if you ask for the base crs you get a swapped axis one. I'll have a look into the CRS.getAxisOrder() method

I guess we might need another AxisOrder constant, like EAST_NORTH or something?
Projected CRS do have their axis order, which is not the one of the base crs, and that is normally EAST/NORTH or X/Y.
Alternatively, given the contents of the axis order enumeration, maybe "inapplicable" is a better answer? It's not lon/lat nor lat/lon.

Interesting. So in the case of a projected crs we would not go through its base geographic crs and just check the axis order of it directly?

We could change the constants to be X_Y, Y_X (or EAST_NORTH, NORTH_EAST) and then it could apply to both cases and not imply a geographic cs. And then we can keep INAPPLICABLE to actually mean there is no notion of axis order?

I guess that would work as well. We should just double check how that would affect the existing calling points. Not sure if there was a reason to have the axis order computed on projected srs that way or not

Here is a patch for this one. The approach was to add a new method to CRS that accepts a flag that controls the behaviour of whether the base crs is checked when doing the axis order check. I also updated all the known call points that i know of doing this sort of axis order check.

Also note that the geoserver patch builds off the of the patch for GEOS-4446.

Any comment on this one?

Justin, the patch looks generally good, I just have one doubt... why in the world would we desire to get the axis order from the wrapped geographic crs? I know the behavior was there already but it just does not make sense to me, I can't think of a valid use case for that.

I checked the existing code calling on that method and none of them actually needs that "check the geog cs contained in the projected cs" behavior (besides the tests there is one call point in the renderer, and one in the caps transformer of wms 1.3 in geoserver)

I agree... it does not seem to make much sense but as you say the change was to maintain backward compatibility. And also there is code in GML2ParsingUtils that does this check... although before this patch it was not calling getAxisOrder directly, but pretty much a straight copy of the code. And that case too it does not make any sense to check the base geo crs.

As I see it we have two options:

1. Remove the code to check the base crs outright and change behaviour across the board. Or...

2. We change getAxisOrder(CRS) to call through to getAxisOrder(CRS, false) rather than true. This will make the default behaviour to not check the base geo crs. Then we update the existing callpoints accordingly... changing the method call to pass in true to check the base crs. For the renderer and caps transformer since we are pretty sure

2 is a more conservative approach that leaves the codepaths unchanged.

It is a tough call... the cautious side of me says go with 2. But on the other hand we know that this check does not make any sense. So I guess i'll take the "risk" and just remove the fallback to the base geo crs and if for some reason it does become required which seems unlikely we can just add it back in.

Sigh... serves me right. Removing the check of the base geo crs caused an issues and test failures with GML encoding of the crs. Long story short this change would change the format of srsName for all projected coordinate systems which is a change I am hesitant to make now. Going to reinstate the flag and only use it for GML2 encoding. That is a bigger issue we will have to fix down the road.

Mass closing all issues that have been in "resolved" state for more than a month without further comments