donuts - Vector format flaw!(?)

[Olga V Fishman]

In info.grass.user you write:

>NEVERTHELESS...  I am suggesting (and please somebody correct me if
>I'm wrong) that there is no bug in d.what.vect.  There is a bug in
>the GRASS vector format.  I have scoured the programmers manual
>description of vector formats and the mention of donut-equivalents
>is noticeably absent.  The same goes for the user manual entries for
>all the v.in.* and v.out.* programs I have checked.  A contributer to

what other v.in or v.out programs exept v.in/out.arc?
I would like to fix this problem.

>(insert flame here).  Let's take v.in.arc and v.out.arc as an example.  Arc/info's
>e00 format seems to define a hole (with a heading -99999) and then later 
>defines a polygon to fill that hole, using the same set of points to define
>both (naturally).  v.in.arc doesn't appear to see the significance of the
>-99999 header and creates *two* polygons in the same place.  (I think it is
>this fact that generates label building errors when running v.support, rather
>than the need for a node snapping threshold as one contributor to the list
>has suggested in the past).  The format that v.out.arc generates is described
>in the user manual but there is no mention of the -99999 header, or donuts.
>My untested guess is that it doesn't know them.  I suspect that similar 
>things are true of v.in.ascii and v.out.ascii.  Is it true of other vector
>output formats?  I don't know.

Can you please send me a description of arc/info island format. We don't
have any arc/info documentation here, but I want to fix this problem.

>Any comments and flames are welcome.

>Cheers, Peter

>normally pbriggs at laurel.ocs.mq.edu.au
>temping as micromet at rata.geog.indiana.edu

Olga