[geos-devel] GEOSBuffer doesn't take all of my geometry

Maximo Pech makzpj at gmail.com
Mon Apr 28 19:00:19 EDT 2008


Sounds like a tough problem, alright.

>
> Can you throw away all the component polygons in the first shape which
> don't intersect the second shapefile?  Does that reduce the size at all?


That would't work because many of the component polygons are invalid, in
order to throw away them if they don't intersect the shapefile I have to
clean them first because GEOSIntersects doesn't work with invalid polygons,
but some (if not all) are as screwed up as the example polygons of my first
post (inner rings outside of outer rings and many ugly things...)


>
>
> Otherwise, you could use a manual tool (like JUMP) to find all the
> self-intersections in the first shape and manually fix them.


That would be good but it's required that the final user just launches the
process and it should calculate and fix the invalid input automatically.


>
>
> I guess one other thing I might try is to:
> - split the first shape into linework
> - node the linework (by unioning it with a single point)
> - polygonize the noded linework
> That might give you a clean "big poly" - although if it is really screwed
> up you might have to drop some of the created polygons.


I will try that but I don't understand what do you mean by linework.


>
>
>
> Maximo Pech wrote:
>
> > Well, I will explain you why I have this weird geometry.
> >
> > The application I'm coding uses 2 esri shapefiles, one of them is huge,
> > it's the size of Mexico, and the shape of it is very similar to Mexico. It's
> > a huge multipolygon 24M in size.
> >
> > Then I have another shapefile, the size of a city, this one is made of
> > many polygons and it's smaller.
> >
> > I have to calculate the intersection percent between the first and the
> > second shapes.
> >
> > To do this I convert both shapefiles to WKT, so I end up with a huge WKT
> > 54M in size from the first shapefile and many small WKT's from the second
> > one.
> >
> > Problems start with the first shape, the huge one, having lots of
> > self-intersections. I tried to "fix" it by doing a GEOSbuffer on it, but
> > after some calculations, GEOSBuffer fails with an error I don't remember.
> >
> > After that I tried spliting the huge WKT multipolygon into many smaller
> > WKT polygons, and applying a GEOSBuffer to each one of them when needed, but
> > this doesn't work either because many of the resulting polygons are screwed
> > up, and I can't discard any of them. Also there is no way I can get a
> > shapefile with a valid multipolygon inside it, I have to find a way to make
> > it usable for GEOSIntersection.
> >
> > 2008/4/28 Martin Davis <mbdavis at refractions.net <mailto:
> > mbdavis at refractions.net>>:
> >
> >
> >    When I look at the geometry fragment you provided, the "hole"
> >    actually lies completely outside the shell.  If the other holes
> >    are the same, then buffer just removes them entirely.
> >
> >    In other words, buffer is behaving according to spec - it's just
> >    that your input geometry is too munged to be fixed by buffer.  8^)
> >
> >    Maximo Pech wrote:
> >
> >        Hi, I'm having trouble with a geometry in WKT form, it begins
> >        like this:
> >
> >        POLYGON ((-97.3813520229492866 26.0028241269227607,
> >        -97.3813272725338663 26.0046293743595065, -97.3793295485156989
> >        26.0046069937576725, -97.3793543294448654 26.0028017481029394,
> >        -97.3813520229492866 26.0028241269227607),
> >        (-97.3813520229492866 26.0028241269227607,
> >        -97.3813767710094567 26.0010188790133867, -97.3793791080158968
> >        26.0009965019755249, -97.3773814473803014 26.0009740973626933,
> >        -97.3753837891055838 26.0009516651750232, -97.3753589495133269
> >        26.0027569077319392, -97.3753341075571370 26.00456214981606...
> >
> >        It's a polygon with many rings inside it. I'm trying to buffer
> >        it to make a intersection operation with a lot of other
> >        geometries because GEOS says it has a self-intersection at or
> >        near point -97.3814 26.0028, but after buffering it my
> >        geometry becomes:
> >
> >        POLYGON ((-97.3813520229492866 26.0028241269227607,
> >        -97.3813272725338663 26.0046293743595065, -97.3793295485156989
> >        26.0046069937576725, -97.3793543294448654 26.0028017481029394,
> >        -97.3813520229492866 26.0028241269227607))
> >
> >        All of the remaining rings are gone.
> >
> >  ------------------------------------------------------------------------
> >
> >        _______________________________________________
> >        geos-devel mailing list
> >        geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org>
> >        http://lists.osgeo.org/mailman/listinfo/geos-devel
> >
> >
> >    --    Martin Davis
> >    Senior Technical Architect
> >    Refractions Research, Inc.
> >    (250) 383-3022
> >
> >    _______________________________________________
> >    geos-devel mailing list
> >    geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org>
> >    http://lists.osgeo.org/mailman/listinfo/geos-devel
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/geos-devel
> >
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20080428/67656379/attachment.html


More information about the geos-devel mailing list