CoordinateSystem in geometries generated by dataproviders

Topics: Data Access
Sep 15, 2009 at 11:28 AM

Hi,

I understand that the providers are designed to work like this:

- They had an "OriginalSpatialReference" property that informs about the srid from the source

- Using that, if you want to transform the geometries, you can set the "CoordinateTransformation" property.

 

I think it's a mistake to assume that a dataprovider only has a spatialreference. For example, Sql 2008 allows to have a different srid for each row of a table.

 

I propose two improvements for dataproviders:

1) Remove "OriginalSpatialReference" property, or change the type to return a list. Instead of using this property, the dataproviders will generate each geometry with their own spatialreference

2) Change "CoordinateTransformation" property to be a delegate, passing as arguments the spatialreference an the coordinate (or the geometry)

 

This way, you could construct a dataprovider that always will return geometries in the same srid, no matter what's in the source

 

Coordinator
Sep 15, 2009 at 3:53 PM

Hi vindex, while I appreciate your point, allowing non homogenous SRIDs in a column breaks the SFS for SQL spec.

See http://portal.opengeospatial.org/modules/admin/license_agreement.php?suppressHeaders=0&access_license_id=3&target=http://portal.opengeospatial.org/files/index.php?artifact_id=18242

which states:

"

6.1.3 Identification of Spatial Reference Systems

Every Geometry Column and every geometric entity is associated with exactly one Spatial Reference System.

The Spatial Reference System identifies the coordinate system for all geometric objects stored in the column, and

gives meaning to the numeric coordinate values for any geometric object stored in the column.

"

Failure to follow this may mean that your data is not longer consumable by open standards based software. It would also add significantly to the complexity of any consuming code.

cheers jd

Sep 15, 2009 at 5:38 PM
Edited Sep 15, 2009 at 5:41 PM

Yes, you're right.

Maybe these "heterogenous" dataproviders could have a property called "ForceOutputSpatialReference". This way, using projnet transformations, you can grant access to all your data and also fit the OGC standard. Of course, if you have not set this property or the ICoordinateTransformationFactory, and you try to get heterogeneous data, you will get an exception.

For the record, the problem i'm facing is this: in Spain, we have two official datums: WGS84 for the Canary Islands and ED50 for the rest. And we already have lots of heterogeneous data in lots of tables...

Coordinator
Sep 15, 2009 at 9:27 PM

I think generally you may find it easier to split the data - after all any spatial query done in the database requires that all geometries are in the same srs for instance

declare @uk geometry
set @uk = geometry::Point(1,1, 27700)

declare @wgs geometry
set @wgs = geometry::Point(1,1,4326)

@uk.STIntersects(@wgs) would return null rather than 1 or 0 because the srs's are different (note I havent tested this)

therefore for any test geometry used in a query any records in a different srs will be ignored.

As a quick fix you could add a persisted computed column to the spatial table retruning GeometryColumn.STSrid

then you could create views isolating homogenous records and use the views as datasources

hth jd

Sep 15, 2009 at 10:39 PM

Yes views are ceirtanly an option, if you're just going to process data.

But if you want to display the information with some graphical control, you have again a problem. If I have a layer of states, for example, I want to display all in the same layer, and to be able to do searching in all the set.

Imagine that you have a table of points projected to UTM (X,Y,UTM_ZONE), it's possible to have even intersecting geometries with different srids.

I think the provider must be responsible for doing this work, for example, in a box query:

1) Find the different srids in the table

2) Project the box to all this srids, and make independent querys

3) Return all the results sequentally, projected to the same srid, in the same data reader

 

To implement this, I see two ways:

- Create a base class wich this data providers will inherit

- Implement a meta-provider, giving in the constructor a list of srid,provider and of course a coordinatetransformationfactory

 

Maybe the second way is faster, and less dependendant on the coding of each dataprovider. If you like this solution, i would love to collaborate and do the coding. Anyway i need it, the only difference it to share it ;)

Coordinator
Sep 15, 2009 at 10:58 PM

I think this functionality may be easier tackled as a group layer aggregating child layers?

Sep 16, 2009 at 8:28 AM

Sure, but that is only a concrete solution for a concrete problem.

IMHO, obtaining homogeneous data is a very low level need, if you don't want to implement again and again the same solution in different scenarios.

 

Coordinator
Sep 16, 2009 at 10:47 AM
Edited Sep 16, 2009 at 11:00 AM

I would be happy to consider any patch, but I do worry that the need is not large while the performance penalty will be significant.
It will also have far reaching impacts, and all to get around database functionality which is only possible when ignoring the open standards existing to mitigate against the problem in the first place.

Anyone else have opinions either way? jd

Sep 16, 2009 at 4:04 PM
Edited Sep 16, 2009 at 4:11 PM

Ok, and what about this:

- Instead of throwing an exception if you try to create a provider accesing a heterogeneous table, set to true a new property: HeterogeneousData, or something similar

- If this property is false, OriginalSpatialReference will be set, otherwise, it will be null

- Return each geometry with its associated SpatialReference

 

This way there is no performance penalty, and it's my call to transform the geometries or no. But at least, I can access the data

<Update>

I've just noticed that this way spatial querys still will be needed to be splited. There will be a penalty projecting the geometry of the query

 

Coordinator
Sep 16, 2009 at 4:50 PM

I would say that it still shouldn't be part of the default implementation - but you can subclass and modify to add your extra functionality though I have a feeling that implementing it will require considerable changes elsewhere.. jd