[postgis-devel] collect()

[strk at refractions.net]

On Thu, Sep 30, 2004 at 12:52:07PM -0700, Chris Hodgson wrote:
> I'm not sure which is the best way to go - if collect always returns a 
> GeometryCollection, then we may need a function that can take an all 
> point (or even point and multipoint) collection and turn it into one 
> multipoint. And the same for line/multiline poly/multipoly. 
> Alternatively, if collect always tries to return a multi-X if possible, 
> we may need a function to convert a multi-X into a collection of X...

We do have force_collection().

> Making a multi-X is also doing some flattening - turning a collection of 
> points (or even points and multipoints) into a single multipoint seems 
> to have a different meaning than leaving them as a "collection".

I agree.

> My first reaction is that collect should always return an un-flattened 
> GeometryCollection, regardless of what is inside.

Yes. This is what I'd do (but we'll loose backward-compatibility).

> And then a complete 
> "flatten()" of a geometrycollection containing all same-type geometries 
> would leave you with a multi-X... ? There still remains the question of 
> how to describe "how much" flattening you want "flatten()" to do...
> 
> maybe there are even two separate functions - flatten, and narrow:
> 
> flatten( gc( point, multipoint, gc( line, multiline, poly), multipoly ) 
> ) = gc( point, multipoint, line, multiline, multipoly )
> narrow( gc( point, multipoint, gc( line, multiline, poly), multipoly ) ) 
> = gc( multipoint, gc( multiline, poly ), multipoly )
> narrow( flatten( gc( point, multipoint, gc( line, multiline, poly), 
> multipoly ) ) = gc( multipoint, multiline, multipoly )
> 
> This allows for some different possibilities, I think it might do 
> everything you would really want to do, there are certainly other ways 
> in which you might want to manipulate nested collections... but anthing 
> more complicated than these should probably be done with plpgsql and 
> lots of getgeometryn() calls - whose meaning may also be effected by all 
> this nesting...? I haven't read the spec on it....

geometryN(
	gc(gc(mpoi, mpoly), mline),
1) == gc(mpoi, mpoly);

geometryN(
	geometryN(
		gc(gc(mpoi, mpoly), mline),
	1), -- first gc
1) == mpoi

> comments, strk?

Not easy so far.
Maybe a complete new set of aggregate functions should be used as
geometry constructors and editors, each with its own semantic:

	A make_collection(geom);
	A make_multipoint(geom); -- only points are used
	A make_line(geom); -- only points are used
	A make_poly(geom); -- only lines are used
	A make_multiline(geom); -- only lines are used
	A make_multipoly(geom); -- only polygons are used

	F add(geom1, n, geom2); -- add geom2 to element n of geom1
	F merge(geom1, n, geom2); -- merge geom2 with element n of geom1
	F delete(geom1, n); -- delete element n of geom1

Example:
	geom = gc[gc[poi,poi], line]
	geom1 = add(
		GeometryN(geom, 1), -- collection
		1, -- second position
		GeometryN(geom, 2) -- line.
	) == gc[gc[poi,line,poi]];
	geom3 = GeometryN(geom1, 1) == gc[poi,line,poi];
	geom4 = merge(
		geom3, 1, -- first poi
		geometryN(geom3, 3) -- last poi
	) == gc[mpoi,line,poi];
	geom5 = delete(geom4, 3) == gc[mpoi,line];
		

All of this is more a brainstorm then a proposal....
It would be very important to hear from actual complex geometry
users out there...

I think I'll work on the GEOS<->LWGEOM converter first, since
semantic there is well-defined.

--strk;

> 
> Chris
> 
> 
> strk at refractions.net wrote:
> 
> >On Mon, Sep 27, 2004 at 09:25:35AM -0700, Chris Hodgson wrote:
> > 
> >
> >>By flatten I suppose you mean to remove any nested collections and put 
> >>them all in one big collection? Yes. We didn't have support for nested 
> >>collections when "collect()" was written (that was the first thing I 
> >>ever wrote for postgis!).
> >>
> >>I agree, collect shouldn't flatten, but a separate function that does 
> >>flatten would be a good idea.
> >>   
> >>
> >
> >Ok. I've restructured LWGEOM API.
> >I'm now ready for collect().
> >
> >So, should collect() just return a collection consisting of NUMROWS 
> >elements withount *any* check on actual type ?
> >For example, *never* return MULTIPOINT even if input is composed by just
> >POINT ?
> >
> >--strk;
> >
> >
> > 
> >
> >>Chris
> >>
> >>strk at refractions.net wrote:
> >>
> >>   
> >>
> >>>Current (OLD) collect() function flatten geometries.
> >>>Should NEW collect() also do this or instead have a
> >>>flatten(the_geom) taking care of this ?
> >>>(I opt for the second)
> >>>--strk;
> >>>_______________________________________________
> >>>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
> >>   
> >>