[fdo-internals] Question about handling of coordinate systems by
mateusz at loskot.net
Fri May 23 20:43:52 EDT 2008
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 ) within a single
database server, instance or schema.
> (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
> 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)
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
More information about the fdo-internals