[prev in list] [next in list] [prev in thread] [next in thread]
List: postgis-devel
Subject: Re: [postgis-devel] Should geomunion() compress output geometry type ?
From: strk <strk () keybit ! net>
Date: 2004-03-23 16:36:43
Message-ID: 20040323173643.B38104 () freek ! keybit ! net
[Download RAW message or body]
On Tue, Mar 23, 2004 at 09:58:27AM -0500, Carl Anderson wrote:
> strk wrote:
>
> > Current geomunion() implementation issues a compressType()
> > call as the final step. The compressType() function will
> > make Multi*-typed geometries with one element become
> > Single*-typed.
> >
> > This might not be what you need.
> > The bad thing is that you end up fighting against table constraints.
> > (you need a multipolygon, no matter how many resulting polygons are
> > in the risult geometry)
> >
> > What about making the compressType() function available
> > as a compress(GEOMETRY) function ?
> > Or - maybe - introduce a function to make Single-typed geoms Multi-typed ?
> >
>
> There is a bigger problem of geometry type casting up and down and
> filtering that needs help.
>
> while geomunion() can return a lesser subtype (Polygon vs MultiPolygon)
> difference(), and symdifference() can return ANY geometry type
> Polygon / Polygon can return (properly) Point, LineString,
> Polygon, GeometryCollection or the Multi form of each.
>
> If I want of silently ignore the Line and Point return types as well as
> extract Polygons from Collections I would need a
> geometry_filter(geometry,'type') function that would
>
> downcast / upcast geometry types into a requested geometry type as well
> as filter types that cannot be coalesced into the desired form.
>
> something like
> new_geom = geometry_filter(geom_union(a.geom1, b.geom2),'MULTIPOLYGON');
>
> or also upcast linestrings that are closed
>
> new_geom = geometry_filter(interiorringn(a.geom,1),'POLYGON')
>
>
> A crude example of such an function (implemented in plpgsql) is attached
>
>
>
> Carl Anderson
> GIS Manager, Fulton County E&CD
> 404.730.8026
> carl.anderson@co.fulton.ga.us
I haven't tried the attached function, but the idea seems good to me.
I think it should be part of the postgis codebase as a C function.
Since LWGEOM is coming though, I'm afraid we'll have to wait until
the job is finished.
--strk;
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic