[postgis-devel] PostGIS 1.1.0 - call for closeup

[strk at refractions.net]

On Mon, Dec 12, 2005 at 02:08:51PM +0100, Markus Schaber wrote:
> 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.

Be aware that some commercial implementations (and I think some internal
OGC documents) design the first argument as "driving" the operation.

This means that when unioning a SRID=4, SRID=6 - for example -
the SRID=6 will be TRANSFORMED to SRID=4 and result will be SRID=4.

I think abstracting transformations has been already discussed 
and the "don't do that" party won, anyway it might be worth taking
that into consideration when dealing with the -1 case, ie:

	SRID=-1, SRID=5 => ERROR (can't transform -1 to anything)
	SRID=5, SRID=-1 => SRID=5 (-1 is transparently assumed to mean 5)

Still, I'm not sure we should allow this at all... after all why 
should you keep your SRIDS==-1 ? What are possible meaning for it ?
I can see the following meaning:

	- I don't know actual SRID
	  [ well, fix it! ]

	- It's a conceptual SRS, can't add a valid record for it
	  in spatial_ref_sys
	  [ you wouldn't mix this with geographic data, will you ? ]

--strk;