[gdal-dev] WCS driver

Ari Jolma 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,
>>
>> 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev



More information about the gdal-dev mailing list