[fdo-internals] Question about handling of coordinate systems
orest.halustchak at autodesk.com
Thu Jun 12 16:00:40 EDT 2008
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?
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 ) 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
fdo-internals mailing list
fdo-internals at lists.osgeo.org
More information about the fdo-internals