OSGeo.org › OSGeo Software and Data Projects › Feature Data Objects (FDO) › FDO Internals

WMS provider issue while consuming 1.3.0 server

Classic

List

Threaded

9 messages Options

Leo Dai

WMS provider issue while consuming 1.3.0 server

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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Jason Birch

Re: 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 <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Orest Halustchak

RE: WMS provider issue while consuming 1.3.0 server

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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]> wrote:

Jackie Ng

RE: WMS provider issue while consuming 1.3.0 server

I'd be fine with this approach as long as the only dependency is the logic in the CS-Map library, and not it's 400+ mb of CS dictionaries.

- Jackie

Orest Halustchak

RE: WMS provider issue while consuming 1.3.0 server

Well, that's part of the problem. From a WMS server, you'd get an EPSG number and would have to look up that definition in a catalog to determine the axis order.

Thanks,
Orest.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jackie Ng
Sent: Tuesday, August 17, 2010 11:37 AM
To: [hidden email]
Subject: [fdo-internals] RE: WMS provider issue while consuming 1.3.0 server

I'd be fine with this approach as long as the only dependency is the logic in
the CS-Map library, and not it's 400+ mb of CS dictionaries.

- Jackie
--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/WMS-provider-issue-while-consuming-1-3-0-server-tp5431259p5432654.html
Sent from the FDO Internals mailing list archive at Nabble.com.
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Jason Birch

Re: WMS provider issue while consuming 1.3.0 server

While I'd love to see FDO become more intelligent about CS handling
and reprojection in general, I guess the 400mb dependency is a bit
steep just for axis order support.

In the meantime could we maybe use CS-Map to generate a lookup file of
CS and axis-order pairs (or just the reverse-order ones)? Or somehow
query the EPSG registry at build time or once per release-cycle to
generate this list? Or extract the list from the EPSG database dumps
(though they tend to lag behind the registry considerably)?

Does WMS always use EPSG short-codes, or does it allow full URN
notation (and would we have to support that)?

Jason

On 2010-08-17, Orest Halustchak <[hidden email]> wrote:

> Well, that's part of the problem. From a WMS server, you'd get an EPSG
> number and would have to look up that definition in a catalog to determine
> the axis order.
>
> Thanks,
> Orest.
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Jackie Ng
> Sent: Tuesday, August 17, 2010 11:37 AM
> To: [hidden email]
> Subject: [fdo-internals] RE: WMS provider issue while consuming 1.3.0 server
>
>
> I'd be fine with this approach as long as the only dependency is the logic
> in
> the CS-Map library, and not it's 400+ mb of CS dictionaries.
>
> - Jackie
> --
> View this message in context:
> http://osgeo-org.1803224.n2.nabble.com/WMS-provider-issue-while-consuming-1-3-0-server-tp5431259p5432654.html
> Sent from the FDO Internals mailing list archive at Nabble.com.
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Dan Stoica

RE: WMS provider issue while consuming 1.3.0 server

Using a lookup file sounds like a good idea, especially because such approach is been already used by the SQLServerSpatial provider. See:

\TRUNK\Providers\GenericRdbms\com\ExtendedCoordSys.txt

Dan.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Tuesday, August 17, 2010 12:36 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] WMS provider issue while consuming 1.3.0 server

While I'd love to see FDO become more intelligent about CS handling
and reprojection in general, I guess the 400mb dependency is a bit
steep just for axis order support.

In the meantime could we maybe use CS-Map to generate a lookup file of
CS and axis-order pairs (or just the reverse-order ones)? Or somehow
query the EPSG registry at build time or once per release-cycle to
generate this list? Or extract the list from the EPSG database dumps
(though they tend to lag behind the registry considerably)?

Does WMS always use EPSG short-codes, or does it allow full URN
notation (and would we have to support that)?

Jason

On 2010-08-17, Orest Halustchak <[hidden email]> wrote:

Leo Dai

RE: WMS provider issue while consuming 1.3.0 server

How does this ExtendedCoordSys.txt file be created?

If we want to generate this look file based on CS-Map automatically per release-cycle, I think we would need to create a utility tool which use CS-Map and output such file. But do we need to maintain this utility tool in source code?

>From the server I saw, it always uses short-codes. Below is information from spec for your reference:

6.7.3.3 EPSG namespace for CRS
The "EPSG" namespace prefix refers to the European Petroleum Survey Group geodetic dataset (EPSG), which
defines numeric identifiers (the EPSG "CRS code," corresponding to the field "COORD_REF_SYS_CODE" in the
EPSG dataset) for many common coordinate reference systems. Defining geodetic, map projection and
coordinate reference system data is related to each CRS identifier.
An "EPSG" CRS label comprises the "EPSG" prefix, the colon, and a numeric code.

Thanks,
Leo

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Dan Stoica
Sent: Wednesday, August 18, 2010 12:51 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] WMS provider issue while consuming 1.3.0 server

Using a lookup file sounds like a good idea, especially because such approach is been already used by the SQLServerSpatial provider. See:

\TRUNK\Providers\GenericRdbms\com\ExtendedCoordSys.txt

Dan.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Tuesday, August 17, 2010 12:36 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] WMS provider issue while consuming 1.3.0 server

While I'd love to see FDO become more intelligent about CS handling
and reprojection in general, I guess the 400mb dependency is a bit
steep just for axis order support.

In the meantime could we maybe use CS-Map to generate a lookup file of
CS and axis-order pairs (or just the reverse-order ones)? Or somehow
query the EPSG registry at build time or once per release-cycle to
generate this list? Or extract the list from the EPSG database dumps
(though they tend to lag behind the registry considerably)?

Does WMS always use EPSG short-codes, or does it allow full URN
notation (and would we have to support that)?

Jason

On 2010-08-17, Orest Halustchak <[hidden email]> wrote:

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Dan Stoica

RE: WMS provider issue while consuming 1.3.0 server

I've meant to create a file with reverse-order ESPGs. While having a tool to maintain it would be ideal, I guess creating and maintaining it manually is fine as well. My assumption here is that not many new coordinate systems are created every year.

Dan.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Leo Dai
Sent: Wednesday, August 18, 2010 6:15 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] WMS provider issue while consuming 1.3.0 server

How does this ExtendedCoordSys.txt file be created?

If we want to generate this look file based on CS-Map automatically per release-cycle, I think we would need to create a utility tool which use CS-Map and output such file. But do we need to maintain this utility tool in source code?

>From the server I saw, it always uses short-codes. Below is information from spec for your reference:

6.7.3.3 EPSG namespace for CRS
The "EPSG" namespace prefix refers to the European Petroleum Survey Group geodetic dataset (EPSG), which
defines numeric identifiers (the EPSG "CRS code," corresponding to the field "COORD_REF_SYS_CODE" in the
EPSG dataset) for many common coordinate reference systems. Defining geodetic, map projection and
coordinate reference system data is related to each CRS identifier.
An "EPSG" CRS label comprises the "EPSG" prefix, the colon, and a numeric code.

Thanks,
Leo

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Dan Stoica
Sent: Wednesday, August 18, 2010 12:51 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] WMS provider issue while consuming 1.3.0 server

Using a lookup file sounds like a good idea, especially because such approach is been already used by the SQLServerSpatial provider. See:

\TRUNK\Providers\GenericRdbms\com\ExtendedCoordSys.txt

Dan.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Tuesday, August 17, 2010 12:36 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] WMS provider issue while consuming 1.3.0 server

While I'd love to see FDO become more intelligent about CS handling
and reprojection in general, I guess the 400mb dependency is a bit
steep just for axis order support.

In the meantime could we maybe use CS-Map to generate a lookup file of
CS and axis-order pairs (or just the reverse-order ones)? Or somehow
query the EPSG registry at build time or once per release-cycle to
generate this list? Or extract the list from the EPSG database dumps
(though they tend to lag behind the registry considerably)?

Does WMS always use EPSG short-codes, or does it allow full URN
notation (and would we have to support that)?

Jason

On 2010-08-17, Orest Halustchak <[hidden email]> wrote: