[fdo-internals] Question about handling of coordinate systems by SRID

[Greg Boone]

Regarding option 1: EPSG Code as CS Name Convention

It is interesting for the community to note that the proposed EPSG convention Orest has outlined is the currently implemented mechanism the WMS and WFS providers have adopted for handling Coordinate Systems. Both providers return either EPSG:XXXX or CRS:XXXX as the FDO Coordinate System name.

I would be in favor of establishing an FDO convention that formalized this mechanism going forward.

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Thursday, June 12, 2008 4:01 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Question about handling of coordinate systems by SRID

Hi,

Mateusz, thanks for the feedback.

I agree that there is no guarantee that an SRID number is actually an ESPG code, it could be a local numbering system within a shop, although typically these days people would be using ESPG numbers.

Option 3, the look up table is not specific as to whether it's a spatial_ref_sys lookup table or a file although for rdbms-based providers it would be a good way to do this.

I like option 1 as an fdo convention and can write up an RFC for it. I don't know if option 3 would need an RFC, but maybe to change the behavior of any existing provider would require it.

Anyway, does anyone else have feedback on this?

Thanks,
Orest.


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Mateusz Loskot
Sent: Friday, May 23, 2008 8:44 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Question about handling of coordinate systems by SRID

On May 23, 2008, at 9:08 PM, Orest Halustchak wrote:
> Let's say that for a given geometry property, the provider only
> knows that the SRID is 2955. We could assume that when there is an
> SRID number that it is an EPSG code (btw, 2955 is utm zone 11n).
> That would be correct most of the time, but I don't know if we can
> guarantee in general that that's what it is since systems that don't
> have a coordinate system catalog don't enforce any particular
> numbering convention for SRID numbers (e.g. MySQL, SQL Server 2008
> geometry type).


According to my knowledge, we can not guarantee SRID == EPSG.
SRID is supposed to be a unique number (a key [1]) within a single
database server, instance or schema.

[1] http://en.wikipedia.org/wiki/SRID

>  Options:
> (1)    Csname = '2955', wkt = null.
> (2)    Csname = 'EPSG:2955', wkt = null.

If we have only number, SRID, how are we sure if this number is EPSG
or custom (local) SRID ?

> To provide any WKT values would require adding capabilities to the
> provider to access a catalog either using a coordinate system
> package (e.g. Proj4), or an internal look up table of SRID to WKT.

or provide interface to access OGC table spatial_ref_sys and perhaps
custom dictionary for non-DB datastores like Shapefile.

> So far, we have avoided requiring that providers access coordinate
> system packages internally (unless they had native support such as
> with Oracle). The next two options fall into this category.
>
> (3)    Include a look up table from SRID to WKT - could be a file
> that a user could update.
> (4)    Include access to a coordinate system library from within the
> provider.
>
> Does anyone have any preferences or other alternatives?

I'd extend the (3) with a) spatial_ref_sys interface for DB-based
datastores and b) GDAL/OGR approach based on dictionaries (flat files)
for non-DB.
However, I understand such solution would not be perfect.

> If we choose one of the first 2 options, it would mean that existing
> client application code should change to recognize the pattern.
> Options 3 and 4 introduce additional dependencies to providers. For
> option 4, note a discussion on fdo futures on client-side libraries
> for coordinate system support ( http://trac.osgeo.org/fdo/wiki/FdoClientUtilities
>  ).

For my sense of taste, all these options have pros and cons and none
looks like the best one.

I think this problem may be in-topic of recent discussions on the
MetaCRS list, about unified schema and store of CRS definitions.

--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org




_______________________________________________
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