[gdal-dev] WCS driver
ari.jolma at gmail.com
Sat Oct 28 07:39:19 PDT 2017
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,
>> 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.
> 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
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
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
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.
> -Jukka Rahkonen-
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
More information about the gdal-dev