[GRASS5] Re: v.out.e00

[gordon.haverland at gov.ab.ca]

Thanks for the feedback guys.

  I'll have a go at debugging things with gdb in emacs.  I'll re-run some of
the things I've been seeing using the fprintf() method of debugging.  :-(

The version of v.out.e00 I'm owrking with isn't quite up to date, it's about
a week old.  The main Makefile says 5.0beta12.

Perhaps it was a mistake, but the test GRASS vector file I've been using
is a file we used for masking out some treatments in a field (I work in
agriculture).  All the polygons at the beginning of this file are
quadrilaterals,
with a few many sided polygons at the end.  There are no isolated points
or lines which begin and end with the same node number in this GRASS
file.

First, the area renumbering.  If I write the two statements as follows
(takes
up the least space in print):
map.Line[i].left = map.Line[i].left < 0 ? 1 : map.Line[i].left + 1;
map.Line[i].right = map.Line[i].right < 0 ? 1 map.Line[i].right + 1;

I get unexplained/irrational behavior if their are no fprintf()s or if the
fprintf()s surround those two lines.  If I put a fprintf() in between the
two statements as well, things work as they should.  The beginning
node of a Line always equals the end node of a line.  If I add in fprintf()s
to look at the lines_pnts structure, I see the structure initializes
properly.
All lines read out of the map are of type 2, with (x,y)=(0,0).  n_points
and alloc_points are both HUGE integers (around 1 billion).  Pointers
cast to ints?

Looking at memory allocation, the various parts of the Map_info
structure seem to have the correct size, and nothing overlaps.

Other observations (may be incorrect).  If you could clarify them,
that would help in trying to figure out what is happening here.

The way I read add_line_universe(), the very first time it gets called
it correctly stored things into a G_malloc()ed struct Univ (but since
the node numbers, etc. are wrong, no good will come of this :-) and
it correctly creates the Universe struct Univ and gets it to point at the
first struct allocated for the first data point.  It is the second call to
add_line_universe() I see as having problems, in that I don't believe
it gets linked to the first data point properly.

When we first enter the PAL code for computing the universe polygon,
stack is meant to be pointing at the last element added to the doubly
linked list?

At the beginning of the CNT section, j should be n_points+1 (from computing
lengths of lines for AAT and PAT tables).  That first while statement
 while(map.Area[i].alive == 0 || (j=map.Area[i].att) <= 0)
can be satisfied by having that first test evaluate to being true, and hence
j
is never set.  Is it impossible for this setting of j to never occur when
finding
this centroid?  This same logic happens a couple of times later on.

Thanks,
Gordon Haverland