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

[Leo Dai]

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: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] 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: 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 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 <orest.halustchak at autodesk.com> 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: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jackie Ng
> Sent: Tuesday, August 17, 2010 11:37 AM
> To: fdo-internals at lists.osgeo.org
> 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
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals