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

[Orest Halustchak]

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