<div dir="ltr">I am working on an application that uses shapefiles as its native data type. The application supports polygons with holes (for the purpose of drawing, computing area, finding inside/outside, etc.), but not polygons with holes with islands, or deeper levels of nesting. This convention of one-deep holes corresponds to the topology model in GEOS, which my application uses for a lot of geometry computations.<div><br></div><div>Shapefiles do not indicate inside outside topology. The just allow a polygon to have multiple parts (multiple rings), some of which may lie inside of others. My experience in using shapefiles from many sources is that many data sets out there do include polygons with holes, but there is no reliable convention for knowing that, say, the order of the rings will be an outer ring followed by all its holes, and then another outer ring followed by all its holes, etc.</div><div><br></div><div>So, my code keeps a separate "inside/outside" record for each shapefile polygon object, which might look something like:</div><div><br></div><div>1</div><div>-1</div><div>1</div><div>1</div><div>-1</div><div>5</div><div><br></div><div>This says, for each ring index, which ring it's inside of. For instance this list means that rings 0, 2, and 3 are inside (i.e., are a hole in) ring 1 (which itself is not inside any ring, indicated by -1), and ring 6 is inside (i.e., is a hole in) ring 5 (which itself is not inside any ring, indicated by -1).</div><div><br></div><div>So I figure out that relationship when I first see the polygon, and whenever its points change. And then for any other operation I have those inside/outside relationships cached and ready to go.</div><div><br></div><div>I figure the relationships using GEOS inside polygon check. This code is a little subtle because it's not enough to check, for instance, that a single point of one ring is inside another ring, because typically it's allowed (e.g., it's allowed by GEOS) for one point to be shared between a "shell" and its "hole". So you need to check that a point in the inner ring which is *not* shared with the outer ring is inside the outer ring.</div><div><br></div><div>Also, I have had some data sets where there *are* instances of a ring inside a ring inside a ring. In this case, it's necessary to recognize this and make that innermost ring a shell, not a hole.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 14, 2014 at 5:47 PM, David Strip <span dir="ltr"><<a href="mailto:gdal@stripfamily.net" target="_blank">gdal@stripfamily.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/14/2014 9:26 AM, mccorb wrote:<br>
> Two questions:<br>
> 1. Is it within the shapefile specification to have polygons that have holes<br>
> that have polygons?<br>
> 2. Does GDAL provide any options to coerce it to not re-order the polygons?<br>
><br>
> thanks<br>
><br>
<br>
Yes, polygons can have holes.<br>
I have no idea about question 2, but in fact this raises a different<br>
question:<br>
Does the shapefile spec say anything about rendering order?<br>
<br>
My quick read of the ESRI whitepaper suggests the answer is no.<br>
<br>
In general, I would suggest the solution is to have one shapefile for<br>
land masses, one for lakes, and one for islands. Rendering order can<br>
then be controlled by application. The one drawback of this approach is<br>
islands with lakes on them, which is a bit pathological, but does occur.<br>
In his book "Maphead", Ken Jennings (yes, the Jeopardy guy) cites some<br>
place where the nesting of water/island/water... goes three layers deep.<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div><br></div>