[fdo-internals] WMS provider issue while consuming 1.3.0 server

[Leo Dai]

Hi,

As we know, the WMS defined the axis order reverse in the latest version spec (1.3.0) for some EPSG codes. Accordingly, we should send different BBox value to servers if it exposes the same data between 1.3.0 and previous versions.

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.

But currently, WMS provider doesn't handle it at all. It make 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).

[Solutions]
Expose the WMS version information and leave it to FDO client

1.       Have a custom command in WMS provider to return the actual version being connected.
The problem is that BBox in WMS provider is used in two places:
 - Construct the BBox parameter string to send to server.
 - Construct the Bounds information (FdoWmsRect)which used to read the data later.
If we leave it to FDO client, then we end up with very custom client code that knows that it's using WMS, knows to get the WMS version, and then has to use some CS library to look up the epsg code if we get one (at last, pass the reversed BBox value to FDO). What's more, after client got the FeatureReader returned by WMS provider, it still needs to have some custom codes which knows the Bounds in it is not right and reverse it while reading the raster data in some case.
And also iIt makes the WMS provider less generic and harder to code against and maintain in a uniform, consistent manner with other providers.

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 need to be reversed 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.
There are two ways to get this information:

2.       Have a simple configuration file in WMS provider which indicates the axis order of specific EPSG code. The disadvantage is that we'd have to maintain and keep correct.

3.       Get ESPG code definition from Web, we can send a request to http://www.epsg-registry.org/ with a code name and it will return the definition with GML format, then we parse it and get its axes order information. The disadvantage is that we can't promise this server's stability and also can't make sure users have internet access (if users are in the LAN).

Have a discussion with Orest and Greg, we are leaning towards the configuration file option.  Is there any new ideas or comments on this issue and the solutions?

Thanks,
Leo Dai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20100817/af7f64fc/attachment.html