donuts - Vector format flaw!(?)

Thankyou Xin, Martijn, and Craig for your responses to my
vector donut problem.

Xin writes...

Looks like we got to eat them before the breakfast.
Just joking. I'll see what I had it before.
SOunds like you're going to use these donuts as
they are rather than to use them in the rast format.
If you will convert them to raster, the two
donuts will be different and the bigger one
has a whole in the center. I'll let you know when I
get in office and log on my GRASS machine.
GRASS vects may not be smart enough to handle
donuts since they were dedigned for display
purpose.

Martijn writes...

First, I recall earlier mail saying that d.what.vect does not take
into account the possibility of islands (your B). This is clearly a
bug. Second, v.in.ascii does not represent shapes at all, so there
is no data about the area of any polygon until you ask for it to be
calculated (by d.what.vect, for instance). Third, if you really
need the area data and can stand a little imprecision, you might
v.to.rast the donut and do the area calculation with r.volume. Or
you do the subtraction of (area A+B) - (area B) by hand.

In fact, the point of this exercise was to convert a vector file with
donuts into a raster file, preserving the donuts. Regardless of
the fact that d.what.vect reports the hole as having the correct area,
and the donut as wrongly having the area of both, as long as both are
defined as polygons, the v.to.rast conversion creates a donut and a
hole that have the CORRECT area when queried with d.what.rast. The
donut and hole have different categories and display correctly as
having different colors. So I am guilty of not seeing the forest for
the trees or the donut hole for the jam or whatever :slight_smile: but my
immediate problem is solved.

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
the list some time ago, Virginia Jackson (from the archives) wrote:

"We are using data in GRASS (4.1) which contain some polygons that look like
donuts. As long as we are in raster format, GRASS seems to handle these donuts
gracefully. After we process the data in raster format, we need to output the
results in vector format for another system to use. We create the vector poly-
gons from the raster polygons using r.poly. The resulting vector polygons do
not follow a logical pattern of what a donut would look like in vector format.
(ex: list the outer edge of the donut, then mark the inner hole of the donut
as an exception). Instead, the vector file created by r.poly lists the outer
edge of the donut as a series of lines, which when put together will make up the
donut, but by just looking at the x,y vector data, there's no way to know it
represents part of a donut."

I think Virginia is hitting the nail on the head. It is GRASS's
inability to store VECTOR donuts (because, I suggest, it has no format
to describe them) that is the problem. This may not be a major hurdle
in the case of what I am doing, because the v.to.rast conversion solves
the problem, but I believe that all of the v.out.* utilites have a 'bug'
with regard to donuts unless they are exporting to programs that can
recognise donut holes implicitly by their position within a larger polygon.
(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.

Any comments and flames are welcome.

Cheers, Peter

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

realize also the absence (usually) of the term "polygons"
in the manuals. Rather, the term "area edge" is used.
I'm not arguing either way, just thought I'd mention that.

Also, if I recall correctly, there is room for additional
data types in the design of grass (in addition to point,
line, and area edge). I'm not sure if this extra room
was left for donuts...

Read the source code for more details. :sunglasses:

--Darrell

While we on this topic, can anyone confirm or
deny the exact structure used in GRASS's vector
format? Particularly whether the arc-node
topology a-la ARC/INFO is used?

Chris

Chris W Skelly (gewcs@jcu.edu.au) writes on 20 Oct 93:

While we on this topic, can anyone confirm or
deny the exact structure used in GRASS's vector
format? Particularly whether the arc-node
topology a-la ARC/INFO is used?

maybe this might be helpful to Chris and others (this is from
the fine programming manual):

Vector Topology Rules

1. Arcs should not cross each other (i.e., arcs which would cross must
be split at their intersection to form distinct arcs).

2. Arcs which share nodes must end at exactly the same points (i.e.,
must be snapped together). This is particularly important since nodes
are not explicitly represented in the arc file, but only implicitly as
endpoints of arcs.

3. Common boundaries should appear only once (i.e., should not be
double digitized).

4. Areas must be explicitly closed. This means that it must be
possible to complete each area by following one or more area edges
that are connected by common nodes, and that such tracings result in
closed areas.

5. It is recommended that area features and linear features be placed
in separate layers. However if area features and linear features must
appear in one layer, common boundaries should be digitized only once.
An area edge that is also a line (e.g., a road which is also a field
boundary), should be digitized as an area edge (i.e., arc type "A" to
complete the area. The area feature should be labeled as an area
(i.e., feature type "A" in the dig_att file). Additionally, the
common boundary arc itself (i.e., the area edge which is also a line)
should be labeled as a line (i.e., feature type "L" in the dig_att
file) to identify it as a linear feature.

In info.grass.user you write:

While we on this topic, can anyone confirm or
deny the exact structure used in GRASS's vector
format? Particularly whether the arc-node
topology a-la ARC/INFO is used?

Chris

I just did, in my previous message.
If you have any more questions, please email me at
olga@zorro.cecer.army.mil
or call 217-352-6511 (ext 526)

Olga

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@laurel.ocs.mq.edu.au
temping as micromet@rata.geog.indiana.edu

Olga