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