jratike80 kirjoitti 28.10.2017 klo 13:10:

Ari Jolma-2 wrote

For example this request to a MapServer WCS (I'm not responsible for
that server so don't know much about it), which is generated in the
driver during a DescribeCoverage for the coverage,

http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&VERSION=1.1.1&REQUEST=GetCoverage&IDENTIFIER=BGS_EMODNET_CentralMed-MCol&FORMAT=image%2Ftiff&BOUNDINGBOX=9.833333335,46.183333325,9.837500005,46.187499995,urn:ogc:def:crs:EPSG::4326&RangeSubset=band

gets the response

WCS server error. Requested BBOX
(46.183333325,9.833333335,46.187499995,9.837500005) is outside requested
coverage BBOX (9.83125,30.01040372,22.23542659,46.18958333)

If I change the order of X and Y in the bounding box in the request, the
reply is ok.
Hi,

BoundingBoxes in WCS 1.1.x and 2.x must follow the axis order of the
coordinate system, so with urn:ogc:def:crs:EPSG::4326 it must be
latitude-longitude.

ok, this is the famous confusion concerning axis order.

To me it seems that GDAL is correct since it determines the bounding box originally from GridCRS in CoverageDescription where the origin is said to be "9.833333335 46.187499995" (i.e., lon-lat). In the same GridCRS the CRS is stated to be "urn:ogc:def:crs:EPSG::4326" - so the axis order could be assumed correct. Interestingly in the same CoverageDescription MapServer says the LowerCorner of the "urn:ogc:def:crs:EPSG::4326" BoundingBox is "30.01040372 9.83125" (i.e., lat-lon). So it seems to me that MapServer is contradicting itself.

Reading MapServer code, it seems to be based on the idea that x,y is always east,north and when it writes BoundingBox, it swaps x and y if the projection is inverted (like 4326). It does not do that when it writes GridCRS.

GDAL seems to be based on the idea that x,y is what the projection says (what the projection says could be found out with OGRSpatialReference::GetAxis - however, for 4326 it does not say anything). This is my impression from WCS driver - I see there's a lot on this issue in the GML driver page.

A fix could be a WCS driver option "swap axis order for bounding box". But since I think that is not fixing the root cause (lying twice does not make you a truth speaker), also an option "swap axis order when reading GridOrigin" is needed. Isn't this fun?


  EPSG:3067 is natively an easting-northing system and
therefore it can make you believe that everything works fine but if you test
the Finnish services also with northing-easting system EPSG:2393 you may get
more frustration.
I'm sure you mean 'fun'.

An open Geoserver with a DEM of Finland is available for testing at
http://avoindata.maanmittauslaitos.fi/geoserver/wcs?service=WCS&version=2.0.1&request=GetCapabilities

I'll try the axis order with that. The geoserver at msp.smartsea.fmi.fi is mine and I'm not sure how well I can manage a geoserver.

Ari


-Jukka Rahkonen-




--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to