<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [postgis-devel] 1.3.4?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<BR>
<BR>
<P><FONT SIZE=2>-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Chris Hodgson<BR>
Sent: Tue 9/30/2008 4:56 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] 1.3.4?<BR>
<BR>
Chris,<BR>
<BR>
> The = operator returning false for geometries with different SRIDs,<BR>
> instead of an error, seems like a reasonable change to me, if there is<BR>
> some justification for it.<BR>
<BR>
> Allowing ST_union to work with geometries that have different SRIDs<BR>
> doesn't seem like valid justification to me. IMHO, any function that<BR>
> takes multiple geometries as input and returns some combination of them<BR>
> as output should throw an error if used on geometries with different<BR>
> SRIDs. It just doesn't make sense to ever use geometries with different<BR>
> SRIDs together - the simplest problem is, what is the SRID of the result?<BR>
<BR>
Sorry for the confusion. I meant UNION as in database relational union sense, not spatial union sense<BR>
<BR>
So something like<BR>
<BR>
SELECT geom1<BR>
from sometable<BR>
UNION<BR>
SELECT geom2<BR>
FROM sometable2<BR>
<BR>
And I suspect (the below too but haven't verified)<BR>
<BR>
SELECT DISTINCT gid, the_geom<BR>
FROM sometable<BR>
<BR>
Would not work if you have a table with mixed SRIDs<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
The fact that = blows up when subjected to different SRIDs has consequences else where<BR>
<BR>
e.g.<BR>
<BR>
SELECT ...<BR>
FROM<BR>
GROUP BY the_geom<BR>
<BR>
Is not possible with mixed srid tables. As Kevin pointed out in response to my comment about "Disturbing" behavior of<BR>
bbox compare used in group by is not "Disturbing" at all but quite useful. <BR>
<A HREF="http://postgis.refractions.net/pipermail/postgis-devel/2008-September/003706.html">http://postgis.refractions.net/pipermail/postgis-devel/2008-September/003706.html</A><BR>
<BR>
I prefer to think of it as a "disturbing but useful side-effect"<BR>
similar to my double-jointedness is disturbing to look at but comes in very handy.<BR>
<BR>
<BR>
> As for the aggregates, it seems to me that (a) they should all be using<BR>
> the same accumulation method, unless there are good reasons not to, and<BR>
> (b) nulls should be treated in a way that makes sense for each<BR>
> aggregate. For the union aggregate this is the same as ignoring them. I<BR>
> can't recall if there is a intersection aggregate, but if there was, a<BR>
> null input would cause a null result. This is necessary because I don't<BR>
> believe we have support for a "null geometry" ie. 'GEOMETRY()'::geometry<BR>
> - so I think we have to allow the use of the database null to specify<BR>
> that value.<BR>
<BR>
> If we can agree that nulls should be handled appropriately by each<BR>
> aggregate function, then that of course requires that our accumulation<BR>
> method can handle accumulating nulls - not sure if that is currently an<BR>
> issue with the various methods in use.<BR>
<BR>
There is no intersection aggregate in PostGIS, but then if there was I would assume it would be something of the form<BR>
<BR>
ST_Union(ST_Intersection(refgeom, geom))<BR>
<BR>
and even there you would want null intersections to drop out of the equation.<BR>
<BR>
Everyone on postgis-users seemed to agree that all PostGIS spatial aggregates should behave like regular aggregates in that they<BR>
ignore nulls. I have created aggregates where not ignoring nulls was important, but they are rare and don't use accumulation anyway.<BR>
<BR>
<A HREF="http://postgis.refractions.net/pipermail/postgis-users/2008-September/021378.html">http://postgis.refractions.net/pipermail/postgis-users/2008-September/021378.html</A><BR>
<BR>
Thanks,<BR>
Regina<BR>
<BR>
Obe, Regina wrote:<BR>
> Mark,<BR>
> <BR>
>> Also we should alter the st_unite_garray function so that aggregates<BR>
>> just ignore nulls. Let's see what results of the ST_Equals()<BR>
>> <BR>
> discussion<BR>
> <BR>
>> separately ;)<BR>
>> <BR>
><BR>
> I think we can drop the ST_Equals discussion and replace that with =<BR>
> discussion.<BR>
><BR>
> Whether = should just return false if SRIDs are different rather than<BR>
> blow up.<BR>
> Personally - I would just prefer it return false. Its just a<BR>
> rule-of-thumb check anyway so I don't see the harm in that and would<BR>
> allow for unioning of geometries with different SRIDs.<BR>
><BR>
> I disagree with Kevin that relational unioning of geometries is the same<BR>
> as<BR>
><BR>
> trying to union a boolean with 1. To me its more like char() vs.<BR>
> varchar vs. varchar(20)<BR>
><BR>
> Then again maybe we should just leave this for 1.4.<BR>
><BR>
> st_unite_garray is just used for ST_Union so would not solve the issue<BR>
> with the other<BR>
> aggregates we have and stuffing the same code in all the garray<BR>
> functions sounds kind of unappealing. If we all agree that aggregates<BR>
> should not deal with nulls then that seems to me like not the right<BR>
> place to put it.<BR>
><BR>
> Think it belongs in LWGEOM_accum which we had considered getting rid of<BR>
> and replacing with array_append anyway. So since all this is iffy - I<BR>
> think we may want to think about this a bit more.<BR>
><BR>
> Thanks,<BR>
> Regina<BR>
><BR>
><BR>
><BR>
> -----------------------------------------<BR>
> The substance of this message, including any attachments, may be<BR>
> confidential, legally privileged and/or exempt from disclosure<BR>
> pursuant to Massachusetts law. It is intended<BR>
> solely for the addressee. If you received this in error, please<BR>
> contact the sender and delete the material from any computer.<BR>
> _______________________________________________<BR>
> postgis-devel mailing list<BR>
> postgis-devel@postgis.refractions.net<BR>
> <A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
> <BR>
<BR>
_______________________________________________<BR>
postgis-devel mailing list<BR>
postgis-devel@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>