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

[Orest Halustchak]

Hi Jason,

That's an interesting alternative. I think it would work, but up until now, we've avoiding adding dependencies to cs-map from providers themselves. All coordinate system transformations have been handled above the fdo level. I know this case is not an actual cs transformation case, but is still adding the dependency. But, maybe adding this dependency to WMS provider is not worse than other workaround options. What do others think?

Thanks,
Orest.

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Tuesday, August 17, 2010 10:07 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] WMS provider issue while consuming 1.3.0 server

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
>
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals