[postgis-devel] 1.3.4?

Tue Sep 30 16:48:05 PDT 2008

Hehe, whoops. Sorry for the UNION confusion. Yes, that sounds like very 
good justification for why to change the = operator to just return false 
for geometries with different SRIDs.

I hadn't been following the discussion on postgis-users. I see now that 
the nulls in aggregates issue is already under control, I don't think I 
have anything to add - I forgot that we do have 
'GEOMETRYCOLLECTION(EMPTY)'::geometry to represent empty geometries so 
we don't have to treat nulls in the same way.

Chris

Obe, Regina wrote:
>
>
>
> -----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
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>   