[GRASS-dev] v.category option=print: fails to print area's categories

[Michael Barton]

> 
> I do not want to flog a dead horse, but 2c more -
> 
> The classic example was a road vector acting as a boundary between two
> parcels of land. The boundary's cat holds info about the road name,
> etc. It can't hold area info (beyond what roads bound it) as it is
> ambiguous as to if it refers to the area on the left side or right side
> of the boundary. 

Sorry if I was not clear. A polyline with a cat value--including a closed
polyline--can certainly be useful when it forms the boundary of an area or
is in any other context. However, AFAICT, a "boundary" is simply a cloased
line/arc associated with point that together define an area. It is
nevertheless a line/arc. Adding categories to a boundary is the same thing
as adding categories to a line/arc. By the same token,  a "centroid" is
still a point, whether it is in an area or not.

If you have a map of areas, using v.category to add categories to the lines
is the same thing as adding categories to the boundaries. I suppose you
could have a vector map that has both unclosed lines and closed lines and
only want to categories to one group or the other. But in this case, some
kind of more general querying might be more useful to accomplish this.

In the case of "centroids" and "areas", I fail to see how you can add cats
to centroids but not to areas, or cats to areas and not to centroids. Not
only is it impossible to have an area without a centroid, but all the
attribute data for an area resides in the centroid data table.

It's not that having the option of a different cat (and potentially
attribute table) for the line around an area and for the area inside the
line. It's the legacy terminology that is confusing.

Having a v.category that lets you add cats to points (and area centroids)
and lines (and area boundaries) covers all that actually happens currently.
Since, most GIS talks about points, lines/arcs, and polygons/areas as the
fundamental building blocks of 2D GIS, however, portraying the GRASS vector
structure in this way for basic tasks is pretty easily understandable by
anyone familiar with GIS.

Differentiating open lines from closed ones can be useful sometimes, but
there is no guarantee that adding cats to boundaries will only affect areas,
since closed lines exist with or without being associated with areas. This
can lead to confusion unless clearly explained. This is why I suggested
dropping the boundary option; you simply assign cats to lines regardless of
whether they border areas or not. If we really want to manage those lines
that bound areas, then they need to be defined differently from closed lines
that do not bound areas. Currently, the terminological category "boundary"
includes both.

Having different options to add cats to areas and centroids makes no sense
at all since you can't do one without doing the other.


> Perhaps don't force centroid+boundary talk in the
> "first day tutorial", but folks eventually need to know how the vector
> systems work to have any hope of fixing their data when it breaks or
> doing something new (line->area).

I agree with this. That was the other point I was trying to make. This is a
very useful way to create areas, and means that you can do some
sophisticated things--including fixing squirrelly data or changing
attributes associated with areas in complex ways. But it's not something
that needs to confront the user in many circumstances. I'm not suggesting
that we restrict functionality, but to our best to portray the very complex
functionality of GRASS in as clear and understandable way that we can.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton