| Version 1 (modified by , 14 years ago) ( diff ) |
|---|
FDO RFC 53 - Fix axis order issue in WMS provider
This page contains a request for comments document (RFC) for the FDO Open Source project. More FDO RFCs can be found on the RFCs page.
Status
| RFC Template Version | (1.1) |
| Submission Date | 2010-08-25 |
| Last Modified | Leo Dai 2010-08-25 |
| Author | Leo Dai |
| RFC Status | draft |
| Implementation Status | Pending |
| Proposed Milestone | 3.6.0.0 |
| Assigned PSC guide(s) | Orest Halustchak, Greg Boone |
| Voting History | (vote date) |
| +1 | |
| +0 | |
| -0 | |
| -1 |
Overview
The purpose of this RFC is to update FDO WMS provider to handle axis order issue correctly so that it will get the correct data from 1.3.0 servers.
Motivation
In WMS 1.3.0 spec, it introduces the change in the way it handles axis order for several SRS. This has an impact on the way the BBOX is specified in WMS requests. In previous versions of WMS, for any SRS the first axis was the easting (x or lon) and the second axis was the northing (y or lat). Starting with WMS 1.3.0, some SRS such as the very popular EPSG:4326 have their axis reversed and the axis order becomes lon, lat instead of lat, lon.
With the Layer CS and Map CS definition in 1.3.0, the layer CRS that the BBOX applies to on query is the underlying data that we’re querying. But, once the data is selected, the WMS server projects it into the Map using the Projection of geographic CRSs into Map CS process. What we’re querying and the data that we’re seeing coming back are in different coordinate systems.
Currently, WMS provider doesn’t handle it at all. It makes no difference between 1.3.0 and previous version. So for some layer in WMS 1.3.0 server, the data we get through WMS provider isn’t correct (send wrong BBox to servers and the data got is not what client wanted).
Proposed Solution
The design solution is to handle it in WMS provider so that clients don’t have to worry about any of this. To handle it in WMS provider, we need to know which EPSG code needs to be reversed first while sending BBox parameter. Ideally, it would be good if the provider could get some sort of indication from the server. But I don’t expect the server will expose this information related in its capability file. Because it’s part of the EPSG’s definition and the name of the code name is already enough from the server’s view.
Similar with SQLServerSpatial provider, we are going to use a lookup file in WMS provider which indicates the axis order of specific EPSG codes. This file will have a reverse-order ESPG codes list. And before provider sending request to WMS server, it will decide whether to reverse the BBox value based on the two items:
- WMS server’s version in current connection.
- Check the file to determine the axis order if we got an EPSG code in the coordinate system parameter.
The basic logic is that we reverse it only when current version is 1.3.0 and the EPSG code is found in the look up file.
For the look up file, it will be a txt file with reverse-order ESPG codes list, like:
EPSG:4326[[BR]]
EPSG:xxxx[[BR]]
…
And this file will be put into wms provider.
Implications
This change will bring a new look up file with reverse-order EPSG codes list into WMS provider, and this file needs to be updated once new EPSG codes are created.
Test Plan
Add unit tests into WMS provider to test the 1.3.0 server.
Funding/Resources
Autodesk to provide resources / funding
