[GRASS5] Deprecate d.area and d.vect.line ??
fa1079 at qmul.ac.uk
Wed Feb 6 07:09:34 EST 2002
> From: "Eric G. Miller" <egm2 at jps.net>
> On Wed, 6 Feb 2002 07:40:53 +0100, Markus Neteler <neteler at itc.it> wrote:
> > > 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-tool ;-) I 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
More information about the grass-dev