[geos-devel] GEOSBuffer doesn't take all of my geometry
Maximo Pech
makzpj at gmail.com
Fri May 2 14:05:05 EDT 2008
Ok, I've done the following; since the rings of the polygons seem to be
unordered I first check which one is the exterior ring by checking the
length of each one. I take the longest as the exterior ring, then:
--- CODE ---
/* Node the linework, the polygon I'm trying to fix is
geos_shape_cobertura_polygons[i] */
geos_shape_polygon = GEOSGetGeometryN(geos_shape_cobertura_polygons[i],
largest_geom_index);
geos_shape2 = GEOSPointOnSurface(geos_shape_polygon);
geos_shape_polygon = GEOSUnion(geos_shape_polygon, geos_shape2);
for(j=0; j<num_geoms; j++)
{
if(j == largest_geom_index)
continue;
geos_shape = GEOSGetGeometryN(geos_shape_cobertura_polygons[i], j);
geos_shape_polygon = GEOSUnion(geos_shape_polygon,
GEOSUnion(geos_shape, geos_shape2));
}
geos_shape_polygon = GEOSPolygonize(&(geos_shape_polygon), 1);
geos_shape_cobertura_polygons[i] = GEOSGetGeometryN(geos_shape_polygon, 0);
--- END CODE ---
But the weird thing is GEOSGetNumGeometries() on the polygonized shape
returns 1280 and GEOSGetGeometryN() on the 0th geometry returns the polygon
I want, so what are all those remaining geometries?
2008/4/28 Martin Davis <mbdavis at refractions.net>:
>
>
> 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
>
> _______________________________________________
> 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/20080502/7d23e604/attachment.html
More information about the geos-devel
mailing list