Maptitude - http://research.umbc.edu/~roswell/maptitude.html
Hello Everyone,
Bob McLaughlin writes:
> I did not receive any replies to my original message which is listed below.
> However, on further investigation, I realized that the overlay problem only
> occurs with "donut hole" polygons. Does OVERLAY ever work with donut hole
> polygons? Is this a bug? I use Maptitude V4.2.
In general, polygon overlay works fine with polygons despite any
donut holes. We frequently run overlay on areas with multiple
regions with lakes which may contain islands without problems.
There are some reasons why it might fail, see below.
> Original question...
...
> ColumnAggregate returned an error
> Reference Info: aggr,178,1
What has happened here is that polygon overlay failed. As you
suspected, it is most likely that it encountered bad topology in
the input file.
> Does anyone have any insight as to what this error message means? I suspect
> it results from bad or twisted topology in the polygon file, although it was
> successfully created from a shape file with the "Eliminate duplicate lines"
> checkbox checked.
The "Eliminate duplicate lines" option does do some topology
validation on the input. It is mainly to generate the topological
structure that Maptitude wants for future analysis. In a
topological database, you only store shared edges once, even if
they occur in two adjacent polygons and this is what the "Eliminate
duplicate lines" option does.
Although this processing step does involve some topological
cleanup, it does unfortunately not guarantee that the database will
be topologically correct. Hence, you might run into some overlay
problems down the road.
This all being said, there have been cases where there were
actually bugs in the polygon overlay code. This is one of the
areas we have emphasized significantly on getting more robust for
the next version of Maptitude. When it encounters errors in the
input data, it will give far more descriptive messages and help you
locate the error in the input data.
> After clicking OK on this error message box the OVERLAY tool
> terminates. This leads to my main point. I think it would be much better
> if when OVERLAY hits a record it cannot perform summation for, it set the
> sum field to NULL for that record and then proceeded to the next record. At
> the end, the tool could pop up a dialog stating that summation could not be
> performed at records xx and xx. Instead, after the error, the user is left
> with nothing, and in my case has wasted 10-15 minutes unproductively. Is
> there some internal program logic that prevents this that I don't see?
> After all, you're basically just adding a field to a table. It's not like
> creating a geographical file where an error in one node would create a
> corrupted or inaccurate file. Any comments on this?
I think this is a great idea. Unfortunately it is a common problem
with many sorts of parsing schemes, that error recovery is often
the hardest part. I can think of some twisted cases where you
would have to decide which one of two polygons was "the bad one"
and you would get drastically different result depending on the
choice. But we will certainly have some discussion on this within
our development team.
-Kjartan
______________________________________________________________________
To unsubscribe, write to [EMAIL PROTECTED]
