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

[Jason Birch]

I would have thought that one of the solutions would be for FDO (or at
least the WMS provider) to use CS-Map for looking up the axis order.
Perhaps overkill, but I'd rather do this than build in a dependency on
an external web service not under our control.

On 2010-08-17, Leo Dai <leo.dai at autodesk.com> wrote:
> 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
>