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

[Orest Halustchak]

Hi,

I have a question about handling of coordinate system information in FDO when only an SRID number is known.

The general problem is that there are cases where a provider's data store contains SRID numbers for a coordinate system, but does not have WKT information or other catalog information to provide any more details on the coordinate system. So, when a client asks for the coordinate system information for that geometry property (via spatial context) what information should be returned? There are two fields relevant here, the coordinate system name and the coordinate system WKT. (There is also the spatial context name.)

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).

Options:

(1)    Csname = '2955', wkt = null.

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

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. 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? 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 ).

Currently, I think some providers do return the csname of 'EPSG:2955' pattern, but it's not consistent across providers and not specified explicitly. I'd like to have a specified consistent behavior.

Let us know if you have any thoughts about this.

Thanks,
Orest.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080523/6d4e0f14/attachment.html