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

[Paragon Corporation]

 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