donuts - Vector format flaw!(?)

[Micromet SG]

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