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

[Maciej Sieczka]

Michael Barton wrote:
> I'd suggest removing centroid AND boundary from the type list

That wouldn't improve anything and you could not manage categories of
centroids and boundaries anymore.

> and explaining
> the centroid+boundary=area relationship in the docs.

area=centroid+boundary indeed, but they also happen to go alone (eg. in
not topologicaly clean data, that require a cleanup; or when one
extracts some centroids or boundaries from his areas for further
processing).

> Lines can have
> categories, but it makes no sense for a "boundary" to have a cat if it is
> really the boundary of an area. If it is not, it is simply a closed
> line/arc.

No. Because when I want to v.extract some boundaries from a vector, I
have to add categories to them. Then I might want to remove them. Same
about centroids.

<snip>

> we should drop
> references to centroids and boundaries in most other places--like in
> v.category or d.vect.

Being able to display only centroids, or only boundaries is a usefull
option during exploring the data. Don't remove it.

> Somehow, we also need to make vectors respond to mouse
> clicks anywhere inside their boundaries and not just on the centroid.

That's already achieved in v.what and d.what.vect - wherever I point
withing the area, it is querried; do you mean something else?

Back to topic: I came to conclusion that v.category option=print
failing to print area's categories is a bug and should be fixed, and
that reporting for boundaries and centroids separately should be kept
as is. That's because the user might want to report categories
separately for centroids, areas and boundaries, eg. to find out which
centroids are outside area, or which areas are broken. IOW - the option
is there and is usefull, only it is not working - 'v.category
option=print' fails to print area's categories. Is that possible to be
fixed?

Maciek