donuts - Vector format flaw!(?)
Olga V Fishman
ovfg9316 at uxa.cso.uiuc.edu
Fri Nov 5 14:41:43 EST 1993
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.
>normally pbriggs at laurel.ocs.mq.edu.au
>temping as micromet at rata.geog.indiana.edu
More information about the grass-user