[fdo-internals] Question about handling of coordinate systemsby SRID

[Maksim Sestic]

Hi Greg,

Is it backward compatible with Map 3D (using Mentor)?

Regards,
Maksim Sestic 

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Thursday, June 12, 2008 22:53
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Question about handling of coordinate systemsby
SRID

Regarding option 1: EPSG Code as CS Name Convention

It is interesting for the community to note that the proposed EPSG
convention Orest has outlined is the currently implemented mechanism the WMS
and WFS providers have adopted for handling Coordinate Systems. Both
providers return either EPSG:XXXX or CRS:XXXX as the FDO Coordinate System
name.

I would be in favor of establishing an FDO convention that formalized this
mechanism going forward.

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Thursday, June 12, 2008 4:01 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Question about handling of coordinate systems
by SRID

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
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals

__________ NOD32 3182 (20080612) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com