I recently downloaded topocheck.mbx and found it to VERY useful tool, every MI owner should get this. I directed a few question to the author so I thought I would post the whole thing. Because it's a forward of a reply, you may want to start at the end to read my original questions and page up to see the authors response. I did answer his last question in this forward (what are fat lines?) All comments made in this forward are in red. William Woodruff Zoning Administrator Charter Township of Union, T14 N R4W, Isabella County, Michigan (517) 772 4600 ext 41, FAX (517) 773 1988 -----Original Message----- From: Eric Maranne [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 24, 2000 12:38 PM To: '[EMAIL PROTECTED]' Subject: RE: topocheck Hi William, I'll try to ask your questions, but I'm not able to go back to this program I wrote years ago (I no longer have access to a MB compiler nor documentation and since I haven't upgraded to MI5, I'm a bit stuck ...) : 15 occurrences of double nodes that did not have double nodes in the > region (only one identified was actually a double node. The topochk layer > did have duplicate nodes, but not the layer being checked (Parcels). Strange .... node distance is tested against minDist parameter (expressed in meters), the projection is the table's projection - does this make sense to explain 'funny things ? - > The find gaps procedure detected a lot of areas that were composed of > several parcels and I could not find the gaps. I discovered that only the > gaps that appeared as lines at a wide zoom (they were actually elongated > regions) were indicative of a true gap between regions. The find gaps procedure works by combining all the regions into a big one, and detecting inner regions created in the process. The process is a bit twisted: the precision of the projection was not high enough to prevent virtual gaps to be detected (just like if a point was set to be at x1,y1 coords, but was read to be at x1+0.00000002, x2+0.000005 (in fact depending on the coordsys applied ...). So I had to introduce a little tolerance (1 cm). This means that gaps, as thin as 1cm can be found, but that may not make sense in your case ... You'll find in the generated table (topocheck.tab) two interesting columns : the area of the gap, and a circularity coefficient. > I also found that the detection of overlaps had a few regions that were not > overlapping another region, but again, I was glad to find the 15 or so > parcels that did overlap their neighbor. I think that the same jiggerish problem is of concern here too (if a shared node has to different coords sets, even very tiny ones, you'll find an overlap ..., and this may be because there *are* two different coord sets, or just because projection precision gives two very very close, but different coords sets... ). > > Prior to the use of your .MBX, I inspected the layer visually for "fat" > lines- Thank you so much for this tool. > What do you call 'fat lines' ? What I call FAT lines is the way two adjacent regions appear when they are gapped or gored. The common boundaries appear to fatter then the other lines in the layer. Thanks for the feedback, and hope you'll won't find too much errors (real or false !).. Eric Please note the new email adress ... Eric Maranne EMI Informatiques web : www.cycweb.com/equipage ~~~~~~~~~~~~~~~~~~~~ (33) +4 42 06 22 22 GMT +1 [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~ GIS - VRML Integration > -----Message d'origine----- > De: ZONING ADMINISTRATOR [SMTP:[EMAIL PROTECTED]] > Date: mardi 23 mai 2000 20:50 > A: [EMAIL PROTECTED] > Objet: topocheck > > Have put your application to work today. The first thing I did (after > backing up a copy of the table) was to do detect complex self intersecting > polygons. In 2500+ parcels I only had 3 bowties- I was pleased both to find > the bowties and at the low number of problems I had. However, there were > about 15 occurrences of double nodes that did not have double nodes in the > region (only one identified was actually a double node. The topochk layer > did have duplicate nodes, but not the layer being checked (Parcels). Is > this common/ a bug/ , or should I be concerned that something funny is going > on even though I could only find a single node. I check for double nodes by > pulling on the node, if there is one under the one I'm dragging away, it > shows up. Note- it occurred to me that the tool fixed the problem and that's why I couldn't find them. > I also found that the detection of overlaps had a few regions that were not > overlapping another region, but again, I was glad to find the 15 or so > parcels that did overlap their neighbor. > The find gaps procedure detected a lot of areas that were composed of > several parcels and I could not find the gaps. I discovered that only the > gaps that appeared as lines at a wide zoom (they were actually elongated > regions) were indicative of a true gap between regions. > I have, as yet, left the node detection parameters at default, as I don't > yet know what I'm doing there. Any comments as to the use of these fixes > for parcels would be appreciated. One question, where it will detect nodes > less than the specified distance, is the value entered assumed to be > whatever units of distance are selected for the map? > > Prior to the use of your .MBX, I inspected the layer visually for "fat" > lines- Thank you so much for this tool. > > William Woodruff > Zoning Administrator > Charter Township of Union, T14 N R4W, Isabella County, Michigan > (517) 772 4600 ext 41, FAX (517) 773 1988 > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.146 / Virus Database: 70 - Release Date: 09/05/00 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.146 / Virus Database: 70 - Release Date: 09/05/00 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.146 / Virus Database: 70 - Release Date: 09/05/00 ---------------------------------------------------------------------- To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
