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

[Michael Barton]

> From: Hamish <hamish_nospam at yahoo.com>
> Date: Sat, 25 Nov 2006 20:54:43 +1300
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] v.category option=print: fails to print area's
> categories
> 
> boundaries can be open or closed, that has nothing to do with their
> vector feature-type status.
> 
> a closed line + a centroid does not make an area. An example of a closed
> line which is not a boundary is a closed contour line around a hill.

So what *is* a boundary when it is not associated with an area? This is both
a question of concept and topology. Probably 2 different answers.

I'm beginning to suspect that what ought to happen is that boundaries should
be restricted to lines surrounding areas and lines are everything else. It's
not that you can't create an entity with the topology of a boundary that is
not associated with an area, but perhaps you shouldn't. What purpose does it
serve? (This is a real and not a rhetorical question. Maybe it does
something I don't understand).

> 
>> 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.
> 
> I don't understand this. Adding cats to boundaries is rare, but when it
> happens it will not affect the surrounding areas one way or another.
> 

What I meant is the following. Combine a map of boundaries (some open and
some closed) with a map of points to create areas. Run v.category to give
cats to the boundaries. Cats will be assigned to the "boundary" arcs that
are not area boundaries as well as those that are. This is computationally
correct. But conceptually I don't see the difference between adding cats to
the boundaries, and calling the boundaries lines and adding cats to the
lines. This is in a large part a definitional issue related to my questions
about the nature of boundaries above.

> 
>> This can lead to confusion unless clearly explained.
> 
> Indeed.
> 
>> 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.
> 
> is this what you are asking:
> 
> v.category --help
>  type   Type
>            Feature type(s)
> -           options: point,line,boundary,centroid,area
> +           options: point,line,boundary,centroid
> 
> 
> or this:
> v.category --help
>  type   Type
>            Feature type(s)
> -           options: point,line,boundary,centroid,area
> +           options: point,line,area
> 
> 
> ??
> 
> I'm not sure about the first, the second is bad.

At least the first. Why list area and centroid separately?

The second would be even better (IMHO) if adding cats to lines included the
lines bordering and defining areas. If boundaries can be conceptually
differentiated from lines, then the first might be preferable, but I'm still
not sure.

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