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

[Martin Davis]

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?

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

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.


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