[GRASS5] Deprecate d.area and d.vect.line ??

[M Lennert]

> From: "Eric G. Miller" <egm2 at jps.net>
> 
> On Wed, 6 Feb 2002 07:40:53 +0100, Markus Neteler <neteler at 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-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 
grass5.1.

Moritz