[GRASS5] Re: v.out.e00

[Michel Wurtz]

"Eric G. Miller" wrote:
> 
> On Mon, 17 Dec 2001 10:29:00 +0100, Markus Neteler <neteler at itc.it> wrote:
> 
> > Hi Gordon,
> >
> > (I cc this to "grass5" to get the other informed)
> >
> > On Fri, Dec 14, 2001 at 12:14:30PM -0700, gordon.haverland at gov.ab.ca wrote:
> > >
> > > Hello Markus,
> > >   Well, I've been working on v.out.e00 for about a week now, and I think I
> > > need a day or so to think about things.
> > >
> > >   Yes, there are some bugs in the existing code.  In fact, I am pretty
> > > sure that the code submitted never ran on any architecture (let alone this
> > > Intel Linux machine). However, there is something else going on with the
> > > code that I am having problems tracking down.
> > >
> > >   In the code before the "calculation" of the Universe polygon, is a
> > > branch of code which builds the doubly linked list which is searched to
> > > build the polygon and also has: if( map.Link[i].left < 0 ) {
> > >   map.Link[i].left = 1;
> > > } else {
> > >   map.Link[i].left += 1;
> > > }
> > > and similar for right.  I've tried 4 or 5 variations on writing that chunk
> > > of code dealing with the renumbering of map.Link[i].(right|left) now.  If
> > > I put fprintf(stderr,"...") statements before and after that code, I get
> > > the similar result as if I have no fprintf()s there.  That is, the if left
> > > is less than 0, that left is multiplied by -1. Sometimes right gets set to
> > > 1 and sometimes it is left alone.  However, if I put fprintf()s between
> > > the right and left chunks of code, now it renumbers left and right

Hmm... I looked (after a long time) at my code again, and found at last
one bug : this part of the code is only valid for an AREA line type.
So I just corrected v.out.e00.c in the CVS.  One should also eliminate
lines of type DOT. It is not done in this quick development.

Arc/Info and Grass topology concepts are very close, but the implementations
are different. The "Universe" polygon is typical to Arc/info and has allways
(AFAIK) 1 for Ident. So I choose to add one to each area ident, thus leaving
free the first slot. The "outside" is numbered 0 in Arc/Info and has a
negative value in Grass.

> > > correctly.  Which seems to me to be a compiler bug. However, it may be a
> > > problem with the vector library, because almost every line read from a
> > > grass vector file comes out with lines which consist of a single node
> > > pointing to itself (N1 almost always equals N2).
> 
>   I'm not sure how v.out.e00 is written, but if you're talking about negative
> numbers for area edge lines, then it means the line should be traversed in
> reverse order.  I'm not sure what you mean about each line having a single
> node.  That might be the case if your reading areas via Vect_get_area_points(),
> but that is probably not the correct way to construct an E00 file, since
> edges will get duplicated.

Yes, polygon edge lines are traversed clockwise : the interior is on the
right, so any hole must be traversed counterclockwise. the edge number is
negative when you have to traverse the line in reverse order.

You have also to keep all nodes for building the E00 file, and have some
points inside each polygon for the attribute table.

Hope this will help you to undersand the code. My personnal feeling is that
reading an e00 file is probably easier than reading Shapefile or MIF/MID
files (no need to rebuild topology), but writing an e00 file is harder than
writing Shapefile or MIF/MID files because you have to build the Arc/Info
view of topology, instead of simply drawing closed polygons.

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5