[GRASS-dev] GRASS 6.3.0 release preparation

[Michael Barton]

On 8/15/07 2:48 AM, "Hamish" <hamish_nospam at yahoo.com> wrote:

> Michael Barton wrote:
>> It looks like the default is 8, which is really large for centroids.
>> would be fine for centroids. 5 is probably OK for points though.
> ..
>> My preference would be have the centroids turned off by default,
>> rather than on as is the current default.
> 
> Markus wrote:
>> For now I have changes the default symbol size (annoying crosses) from
>> 8 to 5 - already looks way better. Maybe it should be default grey to
>> be less dominant (would require new parameter scolor= symbol color).
> 
> I think we need to separate discussion of defaults for the GUI from
> defaults for command line d.vect.

I don't think this is the real problem here (see below). The real problem is
that centroids are treated like points for display.

> 
> Last time I checked the GUI uses size=5 filled circles for centroids.
> As I've complained before, this can be misleading if the data is a
> coastline with many small offshore islands which are smaller than the
> centroid circle. It effectively generalizes the offshore islands into
> circles and is easy to miss. I do like the circle as the default point
> feature symbol, but prefer the "x" as the default centroid symbol. In
> the GUI I prefer the centroids not be drawn by default, but I prefer
> d.vect from the command line to draw centroids. No idea how to make
> that happen, outside of feature type tabs and multiple d.vect calls from
> the WxGUI.

The type= option will turn centroids on and off. If type is not given, all
vector types will be drawn. If it is given, only the specified types will be
drawn. BUT...

Because centroids are treated like any other points by d.vect, a map with
areas will have the centroids colored just like the areas (fill and line),
as if points and areas were mixed in the same map (in fact, they are as far
as d.vect is concerned).

IMHO, for display purposes, GRASS should normally draw points, lines, and
areas (and maybe faces, though I'm still not sure how these work in 2D
displays). That is, these should be the feature types to display with type=.
The underlying architecture of areas (closed lines=boundaries with a
point=centroid inside) should not be part of the normal feature display, any
more than we normally display the points that make of the nodes in lines.

For those occasions when someone wants to display the components of an area
(i.e. a centroid or a boundary) apart from its role in creating an area,
these should be listed in the display= option (i.e., along with shape, cat,
topo, dir, attr, and zcoor). For that matter, I'd suggest we also add line
nodes here too. In terms of how they function, centroids and boundaries
(along with line nodes) are better grouped with vector topology than with
feature types.

Treated in this way, we might not want to have centroids (or line nodes)
behave like points for display or have boundaries behave like lines. These
could have special displays to indicate they are part of the underlying
architecture. For example, centroids could be x's, while points could not be
x's, but could be pluses; boundaries could always be drawn as dotted lines
or something. 

There is still the issue of vectors containing mixed feature types, such
that lines, point borders, and area borders are controlled by the same
options for line width and line color, and point and area files are
controlled by the same option. However, standard practices is commonly to
separate feature types into separate layers, especially if there is need to
color them differently. So this is probably not a major problem.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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