Sounds like a tough problem, alright.<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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?</blockquote><div><br>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...)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Otherwise, you could use a manual tool (like JUMP) to find all the self-intersections in the first shape and manually fix them.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
I guess one other thing I might try is to:<br>
- split the first shape into linework<br>
- node the linework (by unioning it with a single point)<br>
- polygonize the noded linework<br>
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.</blockquote><div><br>I will try that but I don't understand what do you mean by linework.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
<br>
Maximo Pech wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="Ih2E3d">
Well, I will explain you why I have this weird geometry.<br>
<br>
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.<br>
<br>
Then I have another shapefile, the size of a city, this one is made of many polygons and it's smaller.<br>
<br>
I have to calculate the intersection percent between the first and the second shapes.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br></div>
2008/4/28 Martin Davis <<a href="mailto:mbdavis@refractions.net" target="_blank">mbdavis@refractions.net</a> <mailto:<a href="mailto:mbdavis@refractions.net" target="_blank">mbdavis@refractions.net</a>>>:<div>
<div></div><div class="Wj3C7c"><br>
<br>
When I look at the geometry fragment you provided, the "hole"<br>
actually lies completely outside the shell. If the other holes<br>
are the same, then buffer just removes them entirely.<br>
<br>
In other words, buffer is behaving according to spec - it's just<br>
that your input geometry is too munged to be fixed by buffer. 8^)<br>
<br>
Maximo Pech wrote:<br>
<br>
Hi, I'm having trouble with a geometry in WKT form, it begins<br>
like this:<br>
<br>
POLYGON ((-97.3813520229492866 26.0028241269227607,<br>
-97.3813272725338663 26.0046293743595065, -97.3793295485156989<br>
26.0046069937576725, -97.3793543294448654 26.0028017481029394,<br>
-97.3813520229492866 26.0028241269227607),<br>
(-97.3813520229492866 26.0028241269227607,<br>
-97.3813767710094567 26.0010188790133867, -97.3793791080158968<br>
26.0009965019755249, -97.3773814473803014 26.0009740973626933,<br>
-97.3753837891055838 26.0009516651750232, -97.3753589495133269<br>
26.0027569077319392, -97.3753341075571370 26.00456214981606...<br>
<br>
It's a polygon with many rings inside it. I'm trying to buffer<br>
it to make a intersection operation with a lot of other<br>
geometries because GEOS says it has a self-intersection at or<br>
near point -97.3814 26.0028, but after buffering it my<br>
geometry becomes:<br>
<br>
POLYGON ((-97.3813520229492866 26.0028241269227607,<br>
-97.3813272725338663 26.0046293743595065, -97.3793295485156989<br>
26.0046069937576725, -97.3793543294448654 26.0028017481029394,<br>
-97.3813520229492866 26.0028241269227607))<br>
<br>
All of the remaining rings are gone.<br>
------------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
geos-devel mailing list<br></div></div>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a> <mailto:<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a>><div class="Ih2E3d">
<br>
<a href="http://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
<br>
<br>
-- Martin Davis<br>
Senior Technical Architect<br>
Refractions Research, Inc.<br>
(250) 383-3022<br>
<br>
_______________________________________________<br>
geos-devel mailing list<br></div>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a> <mailto:<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a>><div class="Ih2E3d">
<br>
<a href="http://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
<br>
<br>
------------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
</div></blockquote><div><div></div><div class="Wj3C7c">
<br>
-- <br>
Martin Davis<br>
Senior Technical Architect<br>
Refractions Research, Inc.<br>
(250) 383-3022<br>
<br>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
</div></div></blockquote></div><br>