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

[Mateusz Loskot]

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