[postgis-devel] PostGIS 1.1.0 - call for closeup

[Markus Schaber]

Hi, Strk,

strk at refractions.net wrote:

>>>- Treat geometries with SRID=-1 as compatible with all other
>>>  geometries in geometry operations
>>
>>I had sent an first patch for this issue to the list earlier for
>>discussion, but did not receive any comments yet about the open issues.
> 
> Markus, I just found the patch too limited, sorry.

This was intended, because when trying to write the patch, a bunch of
questions popped up, and I wanted to discuss those issues here on
postgis-devel@ before investing more time and completing the code.

Maybe it would have been better to post the questions only, and omit the
half-baken patch altogether.

> I took the path you suggested about providing a separate function
> to check SRID match (you suggested it but didn't provide it in patch).
> The new function is errorIfSRIDmismatch(int, int).
>
> Currenlty only the JTS and GEOS (C++ and C wrappers) use it,
> it will be good to convert all checks to use this, so at least
> we will have a central point to change this when we come to
> a decision about it. 

Okay, then I'll recreate a patch that changes all other SRID checks to
use this function.

> About the decision to switch itself: I think that considering -1
> a compatible-to-all number cannot be limited to function checking,
> but should be also handled by triggers on spatial tables.

I think that enforcing SRID compliance in a table is a separate issue.

When we accept SRID=-1 data in a SRID checking column, then we should
transparently change it to the SRID for the column on insertions /
updates, possibly via a trigger. But I'd vote against that.

However, it does make sense to change addGeometryColumn() to skip the
SRID constraint creation altogether if the specified SRID is -1, IMHO.

> This doesn't mean that I'm convinced we should do this, but only
> that we must be consistent.

For this consistency, there's one of the open questions from my post:
What SRID should the results have?

If we only change the SRID check, we'll get inconsistent behaviour
depending on the current (random) implementation. We could introduce one
of two consistent behaviours:

- always return -1 (thus destroying the SRID information altogether)
- always return the other SRID (which might be -1 as well)

I'd personally vote for the second one.

Markus