Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Axis order in WCS #5504

Closed
ajolma opened this issue Oct 29, 2017 · 4 comments
Closed

Axis order in WCS #5504

ajolma opened this issue Oct 29, 2017 · 4 comments

Comments

@ajolma
Copy link
Contributor

ajolma commented Oct 29, 2017

In version 1.1 DescribeCoverage response MapServer puts into the SpatialDomain part the following (an example from http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows)

<ows:BoundingBox crs="urn:ogc:def:crs:EPSG::4326" dimensions="2"> <ows:LowerCorner>30.01040372 9.83125</ows:LowerCorner> <ows:UpperCorner>46.18958333 22.23542659</ows:UpperCorner> </ows:BoundingBox>

and

<GridCRS> <GridBaseCRS>urn:ogc:def:crs:EPSG::4326</GridBaseCRS> <GridOrigin>9.833333335 46.187499995</GridOrigin> </GridCRS>

The axis order is different in the two. This confuses GDAL as it sends GetCoverage request based on GridOrigin. MapServer replies with Requested BBOX (46.183333325,9.833333335,46.187499995,9.837500005) is outside requested coverage BBOX (9.83125,30.01040372,22.23542659,46.18958333).

GridOrigin is described for this purpose in OGC 07-067r2 Annex F. My interpretation of Table F.1 is that the correct GridOrigin in this case should be

<GridOrigin>46.187499995 9.833333335</GridOrigin>

which would also make GDAL not fail.
@ajolma
Copy link
Contributor Author

ajolma commented Oct 29, 2017

However, if I fix GDAL to swap the axis when it writes the bounding box to the GetCoverage, all goes well. Hm.

rouault added a commit that referenced this issue Oct 31, 2017
@rouault
WCS 1.1 GetCoverage response: honour EPSG axis order for GridOrigin a…
4f75206 
…nd GridOffsets (#5504)

F.3.4 2D simple grid (urn:ogc:def:method:WCS:1.1:2dSimpleGrid) of
https://portal.opengeospatial.org/files/07-067r2 makes it clear that EPSG axis
order should be followed, in the note of EXAMPLE 1 at page 88
'''(in this case, degrees of latitude and longitude, in that order).'''
@rouault
Copy link
Contributor

rouault commented Oct 31, 2017

Issue should be fixed per 4f75206

However, if I fix GDAL to swap the axis when it writes the bounding box to the GetCoverage, all goes well. Hm.

The GetCoverage code path does honour the EPSG axis order when parsing the input BBOX

@rouault rouault closed this as completed Oct 31, 2017
@ajolma
Copy link
Contributor Author

ajolma commented Nov 1, 2017

Does your commit mean that you concur in my interpretation of the standard?

@rouault
Copy link
Contributor

rouault commented Nov 1, 2017

Does your commit mean that you concur in my interpretation of the standard?

Yes, the standard is rather clear on that. See the extract I quote in the commit message of 4f75206

rouault added a commit that referenced this issue Nov 1, 2017
@rouault
Correcting commit message of 4f75206: 'WCS 1.1 DescribeCoverage respo…
f9f59dc 
…nse: honour EPSG axis order for GridOrigin and GridOffsets (#5504)'
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rouault @ajolma