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

[Martin Landa]

Hi,

2006/11/23, Michael Barton <michael.barton at asu.edu>:
> 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.

I don't agree with you, sorry, boundary line (between two areas) can
be associated with a category number!! As an example I can mention the
cadastral maps. Removing centroid and boundary type from the list
would be restriction which I think does not follow GRASS way of
thinking and its freedom.

>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.

I don't know a normal user/man;-) Restrictions in general are not
good, there is a documentation for user who has power to use GRASS/or
something similar.

;-)

Best regards, Martin

> 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
> >
> >
>
>


-- 
Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *