[geos-devel] GEOSBuffer doesn't take all of my geometry
Martin Davis
mbdavis at refractions.net
Mon Apr 28 19:12:04 EDT 2008
Maximo Pech wrote:
> 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...)
You could check their Envelopes, instead of the geometry itself. That
avoids the problem with invalid geometry.
>
>
>
>
> 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.
Well, all I can say is that there is no magic answer to cleaning invalid
geometry. That's why APIs generally require valid geometry! When
trying to handle invalid data, the approach to take is heavily dependent
on exactly *how* they can be invalid. Your problem is compounded by the
fact that the input is so large.
>
>
>
>
> 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.
"Linework" means the lines which make up the geometries. In the case of
polygons, you get get this by calling getBoundary.
>
>
>
>
>
> 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>
> <mailto: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>
> <mailto: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>
> <mailto: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 <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
More information about the geos-devel
mailing list