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

[Eric G. Miller]

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.

-- 
Eric G. Miller <egm2 at jps.net>