Whoops. Forgot to thank Ole Gregor who recalled a previous solution to this that seems to take a similar approach to Warren and Peter.
Keith > -----Original Message----- > From: Campbell, Keith A > Sent: 01 December 2003 11:33 > To: [EMAIL PROTECTED] > Subject: SUM: MI-L Identifying Regions with Holes > > My apologies for the lateness of this reply. And also thank you to all > who responded - Melissa Blackwell, Ashley Simmonds, Katrin, Warren Vick, > Peter Horsbøll Møller and Jamie Justham. It amazes me how much some of you > put into this list. > > My question 'Is there any way to identify, by a query or other > straightforward process, all regions that have a hole or holes in them?' > > The answer is that yes, it is possible to identify regions with holes, but > it is not straightforward. There are a number of ways to tackle this and > the suggestions are as follows. I should point out that I didn't end up > using any of these, due to other issues with the data. So, my comments are > based on my perception rather than experience of using the methods, > although I briefly tried one or two. > > It did look, initially at least, that Melissa's suggestion of using the > 'Check Regions' function would provide the easy answer. When checking for > gaps, it does identify holes inside regions, and copes with islands inside > holes (and holes inside the islands!). You just need to set your maximum > gap tolerance high enough for your data. The complication arises when the > regions touch or overlap each other. The gaps between intersecting regions > are also identified and the issue of how to distinguish between the gaps > within regions from the gaps between regions arises. > > Ashley's 'IsDonut' approach, or a slight variation of it, does seem to > provide a solution. This method compares the area of the regions in their > original state as against the area after disaggregation (not retaining > holes). The slight variation would be to ensure that the regions had a > unique ID before disaggregation, and to retain the ID on the individual > regions after disaggregation. The resultant regions could then be queried > to identify the sum of the areas for each ID, like so:- > > Select ID, Sum(Area(obj, "sq km")) from <table1> group by ID into <table2> > > The result of this query can then be used to identify any regions from the > original table where the area is less than the summed areas for the > disaggregated regions with the same ID. The logic being that the area > should be the same unless any of the polygons are 'negative', i.e. holes. > > Katrin's suggestion uses a similar principle of comparing the original > intact regions with the set of disaggregated (not retaining holes) > regions. The focus of the comparison is whether any of the disaggregated > regions are entirely within any others. I don't think this can be done > with a single query (correct me if I'm wrong) but would require a MapBasic > app to iterate through each object and query whether it falls entirely > within another object that has the same ID but is not itself (same RowID). > The check for the ID match needs to done because there could be regions > that fall entirely within other regions prior to disaggregation. I think > the area comparison method is simpler and easier to implement. > > Warren and Peter, if I understand them correctly, take a similar approach > by processing all polygons within a region into single polygon regions > (same as disaggregating without retaining holes) and then checking each > polygon to identify how many other polygons of the parent region it's > centroid is within. If it's a negative number, the polygon forms a hole in > the region. This seems overly complex, as if a centroid falls within ANY > other polygons, surely there must be a hole. However, as Peter as provided > the code for this, the hard work is done already. > > Jamie's suggestions is to use a Tester in the FME Workbench, with the > @NumHoles() function. I've not tried this, but if you have FME it appears > to be an attractively easy option. > > Phew, I'm glad that's over - too much of a workout for my brain cells at > this time on a Monday morning! > > Keith > > > ---------------------------------------------- > Keith Campbell > GIS Consultant > > ATKINS ENVIRONMENT > Cornerstone House > Stafford Park 13, Telford > Shropshire, TF3 3AZ > England > Tel: +44 (0)1952 21 3268 * > Fax: +44 (0)1952 20 0981 * > > Email: [EMAIL PROTECTED] * > Web: www.atkinsglobal.com <www.atkinsglobal.com> * > > > > This email and any attached files are confidential and copyright protected. If you are not the addressee, any dissemination of this communication is strictly prohibited. Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding. --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 9358
