[postgis-devel] 1.3.4?

[Kevin Neufeld]

Obe, Regina wrote:
>
> I'm still bothered by this. But I'll itemize my concerns
>
> 1) ST_Equals IS NOT USED in UNION as I demonstrated in my last email. 
> so fixing that will NOT MAKE any change to the way
> UNION behaves.  UNION uses = which is disturbing anyway since it 
> assumes geometries with the same bounding box are equal.
>

Exactly.  I totally agree ... except for the "which is disturbing" part 
:)  I personally find bounding box comparisons extremely useful.  When 
looking for duplicate geometries, I can *quickly* winnow a set of 
16million edges to a set with duplicate bounding boxes using GROUP BY 
and then further filter using the slow exact equals (~=).

>
> 2) We should probably make a note about that somewhere in the docs 
> that UNION (and similarly GROUP BY) does a bounding box 
> grouping/distinct.  Its not as big of a deal when you are throwing 
> attributes in there like a primary key field of a table since those 
> would prevent collapsing by bounding box, but is if you don't and is 
> counter-intuitive.
>

Again it depends on use cases of GROUP BY I suppose, because I like the 
collapsing by bounding box idea.  We DEFINITELY need to document this 
though ... perhaps something a little more thorough explaining all the 
subtle differences between ST_Equals(), ST_OrderingEquals,  =, ~=.

> 3) If you change ST_Equals to return false with different SRIDs, then 
> why wouldn't you do the same with all relation boolean operators - 
> what exactly is the difference?  We said operations/relationships 
> between different SRIDS (except for ST_Transform is not supported) - 
> having ST_Equals behave differently is to me an annoying break in 
> pattern and doesn't even solve the issue that raised this whole question.
>
Yup. 

-- Kevin