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	Frozen Pending Vote
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.

By default we will have a hard-coded list containing the whole reverse-order EPSG codes. And in addition, we are going to define a lookup file which can be created by users and used to add missing EPSG codes if needed. When user meets the axis order issue with specific EPSG code, he/she can create this file and add the new EPSG code in it.

In our WMS provider, we look if in the same folder with the provider’s DLL we find this additional look up file and in case we do we load it and append the content to the internal list, otherwise we use the internal hard coded list. In this case, even if the file is missing or corrupted by users the provider can still work with the internal defined list.

And before provider sending request to WMS server, provider will decide whether to reverse the BBox value based on the two items:

1. WMS server’s version in current connection.

2. Check the list 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 reverse-order EPSG list.

For the defined additional look up file, it will be a txt file with reverse-order ESPG codes list, like:

EPSG: 4326

EPSG: xxxx

…

And this file should be put into WMS provider if user needed with the name called “ExtendedReverseEPSG.txt”.

Implications

This change will have an internal hard-coded reverse-order EPSG codes list in WMS provider, and also expose a standard file name with missing EPSG codes to be added by users.

Test Plan

Add unit tests into WMS provider to test the 1.3.0 server.

Funding/Resources

Autodesk to provide resources / funding