[postgis-devel] 1.3.4?

Chris Hodgson chodgson at refractions.net
Tue Sep 30 13:56:39 PDT 2008


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?

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.

Chris


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
>   




More information about the postgis-devel mailing list