[postgis-devel] Re: Patch for PostGis Envelope Bug

[Charlie Savage]

> Applied to trunk. I don't see any way it can do harm.

Thanks :)

I should ask if issues #1 (check can be subverted) and #2 (SRID 
handling) mentioned below seem ok?

And I think I got the memory handling right, but its probably worth a 
quick check from someone with more knowledge of PostGIS internals 
(unless of course you already did that).

Thanks again,

Charlie

> 
> On 18-Sep-07, at 8:57 PM, Charlie Savage wrote:
> 
>> Anyone have feedback on this patch?  It seems like the current 
>> behavior is incorrect, and I don't see any easy way to work around it 
>> without fixing it.
>>
>> Charlie
>>
>> Charlie Savage wrote:
>>>>> However, is this another bug then?
>>>>>
>>>>> select astext(extent(GeomFromText('POINT(-104 40)')))
>>>>>
>>>>> "POLYGON((-104 40,-104 40,-104 40,-104 40,-104 40))"
>>> Martin Davis wrote:
>>>> Looks like the same bug/design issue.  JTS would return the envelope 
>>>> as a POINT in this case.
>>> This issue has been causing me problems, so I dug into.  Geos in fact
>>> does return a POINT when you ask for the envelope of a POINT.
>>> It's PostGIS that is wrong.  The method LWGEOM_envelope (line 2493 in
>>> lwgeom_functions_basic.c) *always* returns a polygon.  So I changed it
>>> to return a point if the input geometry is a point.
>>> I've attached a patch that fixes this issue.  The patch checks to see if
>>> the input geometry is a point or a multipoint with just one geometry.
>>> There may be 2 issues with the patch:
>>> 1.  The check ins't foolproof, one could subvert it by:
>>> select asText(Envelope(GeomFromText('MULTIPOINT(10 10, 10 10)')));
>>> Maybe checking the bounds (or area) of the envelope would be better?
>>> 2.  I'm not sure I handled the SRID correctly for a mutlipoint.  I just
>>> took it from the multipoint itself.  Can the first point in a multipoint
>>> have a different SRID?
>>> Anyway, it would be great if someone could review this patch and apply
>>> it if it seems ok.  I think its important because its easy to create
>>> invalid geometries that don't work with GeomUnion/Contains/Within/etc.
>>> We run into this problem a lot now that we've upgraded to GEOS 3 (GEOS
>>> 2.1 seemed to work ok, although maybe that was pure luck.).
>>> Thanks,
>>> Charlie
>> _______________________________________________
>> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20070918/f9a136a3/attachment.bin>