From: "Eric G. Miller" <egm2@jps.net>
On Wed, 6 Feb 2002 07:40:53 +0100, Markus Neteler <neteler@itc.it> wrote:
[snip]
> > Markus, do you realize d.vect.cats does not handle islands/holes correctly?
>
> Oh - actually not. However, my only intention was to merge two similar
> modules. The island problem is the next step.
>
> > Compare: http://pweb.jps.net/~egm2/d.vect.cats.jpg vs.
> > http://pweb.jps.net/~egm2/d.vect.area.jpg -- note: I drew the line work
> > a second time for d.vect (because the interiors got clobbered).
> >
> > It should be relatively easy to remedy via G_plot_area().
> May I pass this to you? Maybe you want to merge/replace again
> with your new d.vect.line?I can have a look, but here's my thinking about the different vector drawing
modules. When I was putting together d.vect.area, I was thinking about
fixing/replacing the half functional d.area. At the time, d.vect just
drew all line work. That's fine. Where d.vect.area steps in, is to do
more fine grained filled area drawing. I knew long ago that d.vect.cats
didn't handle islands/holes correctly and that was the motivation for
originally adding the category selectivity to d.area (and now d.vect.area).
The d.vect.line plays an analogous role to d.vect.area, in that it draws
labelled vector lines in various colors (unfortunately, there's not much
to do about line styles at the present). Both d.vect.line and d.vect.area
are limited to labelled things. That is, things that definitely represent
something. With the ability to have both significant line features and
significant areal features, there's a need to distinguish what is being
dealt with. One other significant difference, is both of the new d.vect.*
modules will not even consider drawing a vector unless it can be opened
at level 2, whereas d.vect did/does draw spagetti. Both possibilities
are important.Now, if we want d.vect to be the one stop vector drawing module, it needs
a way to disambiguate what type of thing it should be interested in (areas,
lines, points?). This is where some infrastructure for drawing styles
needs to be implemented. My thinking was to have a usable middle solution
until we can address these issues in 5.1 (I'm thinking, better display/drawing
capabilities, new vector format, and infrastructure for managing or generating
drawing styles on the fly via attributes).> Ideally there is only one vector drawing tool in future, we already
> have too many (similar) modules.Is there only one raster drawing tool? It's the trade off between simple
interface and design with the all encompassing uber-toolI don't
know about other users, but when a command line program gets too many
options it becomes painful to use, IMO. But, I agree with your point
as well (too many similar modules confuse users).One thing I wanted to get out of both d.vect.area and d.vect.line was the
ability to create a persistent drawing style specification (via the
"legend" file). It's crude, simple, but effective. And I hope others
will find it useful as well.
I agree with Eric. I like the simplicity of the d.vect.area solution. So maybe we should have (and I
guess this is what Eric advocates):
*d.vect - generic vector module to draw any vector map (i.e. including spaghetti), with just a
basic color option for line color and area color, but no catnum option
* d.vect.area - module for drawing areas according to category values
* d.vect.line - module for drawing lines according to category values
(if necessayr: d.vect.sites - module for drawing (vector) sites according to category values)
* no d.area as this is just confusing
The d.vect.area/line fill a void that has always bothered me, as I mostly do thematic mapping.
And I do believe that they fill this void sufficiently until we have proper vactor data management in
grass5.1.
Moritz