[postgis-users] Problem with LWGEOM_collect_garray - neverreturnsMultiX from MultiX?

[Paragon Corporation]

Just to clarify my point.

See
SELECT ST_IsValid(ST_Collect(ST_Buffer('POINT(1 1)',1), ST_Buffer('POINT(1
1)', 2)))

Invalid MULTIPOLYGON

So when you go to use GEOS functins with these generated creatures, it blows
up because its invalid.

Although maybe this doesn't happen enough that people are that bothered by
it, though it has caused me some frustration on occasion where slivers of
geometries overlap and I would have preferred a valid geometry that is a
GEOMETRYCOLLECTION over an invalid MULTIPOLYGON.

So my proposition - try not to break/slow existing code that uses ST_Collect
by changing behavior so late in the game and as others have said the current
behavior is desired in some cases and can not be achieved by replacing with
the more common use case.

Instead introduce a whole new aggregate and non-agg that does the following

1) When it sees MULTI geometries - it returns a MULTI object if none of the
individual elements overlap (actually I think having a  MULTIPOINT with same
points is valid, but why you would want that seems questionable to me, not
sure about Multi line, but MULTIPOLYGON with overlapping regions is a
no-no.) 
2) In single cases POLYGON, LINESTRING etc. it also returns a MULTI if no
overlapping regions, but then will force a geometry collection if POLYGONs
overlap.

By all means correct the comment in the collect_garray code.

Thanks,
Regina



-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Paragon
Corporation
Sent: Saturday, October 11, 2008 1:05 AM
To: 'PostGIS Users Discussion'
Subject: RE: [postgis-users] Problem with LWGEOM_collect_garray -
neverreturnsMultiX from MultiX?

 Personally I see the change as adding overhead, and possibly would make a
lot of my existing code slower since it would inevitably mean a slighly
slower collect.

I do agree the stated behavior is probably the most desirable in most cases.

Aren't overlapping polygons invalid in a multipolygon anyway.
So as it stands its doing just a collect which could result in invalid
geometries in cases where we have POLYGONS.

I would much prefer see another aggregate function by another name
introduced that doesn't try to dissolve boundaries like ST_Union but that
ensures a MULTIPOLYGON is only returned when the polygons don't overlap and
otherwise forms a geometry collection.

Thanks,
Regina

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Friday, October 10, 2008 7:17 PM
To: PostGIS Users Discussion
Cc: mgwjenkins at gmail.com
Subject: Re: [postgis-users] Problem with LWGEOM_collect_garray -
neverreturns MultiX from MultiX?

OK, I agree, the comment header and the behavior differ... I'm a bit afraid
to change this behavior though... it's a bit long-standing now.
I wonder if doing so would cause and serious problems for people.

P.

On Wed, Feb 6, 2008 at 5:31 AM, Marcus Jenkins <mgwjenkins at gmail.com> wrote:
> Dare I say it, but I think there's a bug in lwgeom_functions_basic.c 
> in the LWGEOM_collect_garray function.  According to the docs / 
> comments, this should return a multiX if all the objects are multiX, 
> but the code on line 2112 (and around) appears to stop that happening.
>
>
>                /* Output type not initialized */
>                if ( ! outtype ) {
>                        /* Input is single, make multi */
>                        if ( intype < 4 ) outtype = intype+3;
>                        /* Input is multi, make collection */
>                        else outtype = COLLECTIONTYPE;
>                }
>
> Or, in pseudo-code, if the input object is a multiX or collection, the 
> output will be a GOEMETRYCOLLECTION.  Always.  This ain't what it says 
> in the function header.
>
>  * returned geometry is the simplest possible, based on the types
>  * of the collected objects
>  * ie. if all are of either X or multiX, then a multiX is returned
>
> I tried logging the bug on the PHP bug tracker, but I think I need to 
> be a different class of user since I'm asked to log in (when I'm 
> already logged in) to post a bug report.
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users



_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users