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

[Radim Blazek]

On 11/23/06, Michael Barton <michael.barton at asu.edu> wrote:
> I'd suggest removing centroid AND boundary from the type list and explaining
> the centroid+boundary=area relationship in the docs. 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.

It makes sense. Try to import TIGER data (all the layers to one vector)
and query the map.

Radim

> If it is not, it is simply a closed
> line/arc.
>
> The underlying topology of GRASS vectors is logical and sensible overall.
> However, the terminology is a legacy that should be discussed as such, but
> it should not confront the everyday user.
>
> Functionally, GRASS is like any other vector GIS in that is has points,
> lines/arcs, and polygons/areas. This is how it should be presented to the
> normal user.
>
> The fact that a polygon/area is built from a closed line/arc and an
> associated point that is located inside the closed line/arc seems to be a
> very clean kind of underlying organization. It makes it nice to teach about
> GIS and geospatial data. It also makes manipulating those data in
> sophisticated ways more transparent. BUT the normal user doesn't really need
> to know that simply to do basic GIS activities.
>
> So my recommendation is to explain this in the docs so that users can learn
> sophisticated techniques like reassociating sets of boundaries and points to
> create areas with new kinds of data. In this respect, we should also leave
> this in v.type for vector type conversions (though this module needs to have
> a better GUI and explanations to be usable). However, we should drop
> references to centroids and boundaries in most other places--like in
> v.category or d.vect. Somehow, we also need to make vectors respond to mouse
> clicks anywhere inside their boundaries and not just on the centroid. GRASS
> is complex enough without including options and terminology that don't
> really offer anything to users.
>
> My 2 cents worth
>
> 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
>
>
>
> > From: Moritz Lennert <mlennert at club.worldonline.be>
> > Date: Wed, 22 Nov 2006 14:30:34 +0100
> > To: Martin Landa <landa.martin at gmail.com>
> > Cc: grass-dev <grass-dev at grass.itc.it>
> > Subject: Re: [GRASS-dev] v.category option=print: fails to print area's
> > categories
> >
> > Martin Landa wrote:
> >> Hi,
> >>
> >> 2006/11/22, Moritz Lennert <mlennert at club.worldonline.be>:
> >>
> >>> I'd rather suggest to map area to centroid (i.e. if area is given behave
> >>> the same as if centroid is given), as intuitively people are looking for
> >>> information concerning areas not centroids.
> >>
> >> Area = centroid + boundary
> >>
> >> simplification you suggest tend to be misguided;-) I prefer (but not
> >> sure) removing area from the type list and update manual pages of
> >> v.category to make it clear to user. What do you think about it?
> >
> > I think both approaches are valid. My suggestion tries to just gloss
> > over the user's lack of understanding, yours tries to teach him. So
> > probably yours is better and more in line with the general GRASS approach.
> >
> > Moritz
> >
> >
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>