[postgis-devel] 1.3.4?

[Obe, Regina]

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Chris Hodgson
Sent: Tue 9/30/2008 4:56 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] 1.3.4?
 
Chris,
 
> The = operator returning false for geometries with different SRIDs, 
> instead of an error, seems like a reasonable change to me, if there is 
> some justification for it.

> Allowing ST_union to work with geometries that have different SRIDs 
> doesn't seem like valid justification to me. IMHO, any function that 
> takes multiple geometries as input and returns some combination of them 
> as output should throw an error if used on geometries with different 
> SRIDs. It just doesn't make sense to ever use geometries with different 
> SRIDs together - the simplest problem is, what is the SRID of the result?

Sorry for the confusion.  I meant UNION as in database relational union sense, not spatial union sense

So something like

SELECT geom1
from sometable
UNION
SELECT geom2
FROM sometable2

And I suspect (the below too but haven't verified)

SELECT DISTINCT gid, the_geom
FROM sometable

Would not work if you have a table with mixed SRIDs

The problem right now is that since = requires srids to be the same, perfectly valid things such as this where you have a network of records across the world in different srids can not be used without major checking.

Well UNION above is sort of broken anyway because = is mapped to bbox compare so it picks the first geometry of a bounding box rather than acutally unique geometries, but that can be worked around more easily and is admittedly broken and not trivial to fix.

The fact that = blows up when subjected to different SRIDs has consequences else where 

e.g.

SELECT ...
FROM 
GROUP BY the_geom

Is not possible with mixed srid tables.  As Kevin pointed out in response to my comment about  "Disturbing" behavior of
bbox compare used in group by is not "Disturbing" at all but quite useful.  
http://postgis.refractions.net/pipermail/postgis-devel/2008-September/003706.html

I prefer to think of it as a "disturbing but useful side-effect"
similar to my double-jointedness is disturbing to look at but comes in very handy.


> As for the aggregates, it seems to me that (a) they should all be using 
> the same accumulation method, unless there are good reasons not to, and 
> (b) nulls should be treated in a way that makes sense for each 
> aggregate. For the union aggregate this is the same as ignoring them. I 
> can't recall if there is a intersection aggregate, but if there was, a 
> null input would cause a null result. This is necessary because I don't 
> believe we have support for a "null geometry" ie. 'GEOMETRY()'::geometry 
> - so I think we have to allow the use of the database null to specify 
> that value.

> If we can agree that nulls should be handled appropriately by each 
> aggregate function, then that of course requires that our accumulation 
> method can handle accumulating nulls - not sure if that is currently an 
> issue with the various methods in use.

There is no intersection aggregate in PostGIS, but then if there was I would assume it would be something of the form

ST_Union(ST_Intersection(refgeom, geom))

and even there you would want null intersections to drop out of the equation.

Everyone on postgis-users seemed to agree that all PostGIS spatial aggregates should behave like regular aggregates in that they 
ignore nulls.  I have created aggregates where not ignoring nulls was important, but they are rare and don't use accumulation anyway.

http://postgis.refractions.net/pipermail/postgis-users/2008-September/021378.html

Thanks,
Regina

Obe, Regina wrote:
>  Mark,
>   
>> Also we should alter the st_unite_garray function so that aggregates 
>> just ignore nulls. Let's see what results of the ST_Equals()
>>     
> discussion 
>   
>> separately ;)
>>     
>
> I think we can drop the ST_Equals discussion and replace that with =
> discussion.
>
> Whether = should just return false if SRIDs are different rather than
> blow up.
> Personally - I would just prefer it return false.  Its just a
> rule-of-thumb check anyway so I don't see the harm in that and would
> allow for unioning of geometries with different SRIDs.
>
> I disagree with Kevin that relational unioning of geometries is the same
> as 
>
> trying to union a boolean with 1.  To me its more like char()  vs.
> varchar vs. varchar(20)
>
> Then again maybe we should just leave this for 1.4.
>
> st_unite_garray is just used for ST_Union so would not solve the issue
> with the other 
> aggregates we have and stuffing the same code in all the garray
> functions sounds kind of unappealing.  If we all agree that aggregates
> should not deal with nulls then that seems to me like not the right
> place to put it.
>
>  Think it belongs in LWGEOM_accum which we had considered getting rid of
> and replacing with array_append anyway.  So since all this is iffy - I
> think we may want to think about this a bit more.
>
> Thanks,
> Regina
>
>
>
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>   

_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20080930/39aeec0d/attachment.html>