[GRASS5] [bug #920] (grass) d.vect.line does not draw lines

[Eric G. Miller]

On Sun, Feb 17, 2002 at 01:06:48PM +0000, M Lennert wrote:
> Eric,
> 
> This does sound pretty complicated and I'm not sure it is really
> necessary to put all in one module. From my experience most of the
> time one would either be displaying and area file in which boundaries
> are normally all the same color or a line file with different colors
> for different lines. So separating the two might be easier.

The more complicated interface is the reason I was thinking a few
modules with simple interfaces might be easier for users.

> But if you we go for one unified d.vect:
> 
> > 
> > $ d.vect help Draws vector maps
> > 
> > Usage: d.vect -aflv map=name [color=name] [fillcolor=name]
> > [catnum=value[,value,...]]
> > 
> 
> couldn't you rather do the following (since I find the combination of
> -aflv plus different color options a bit confusing):
> 
> Usage: d.vect map=name [color=name] [fillcolor=name]
> [acatnum=value[,value,...]] [lcatnum=value[,value,...]]
> [alegend=filename] [llegend=filename]
> 
> Where
> 
> if "fillcolor" then if "acatnum" then fill acatnum areas with
> fillcolor else fill areas with fillcolor end if end if
> 
> if "linecolor" then if "lcatnum" then draw lcatnum lines with
> linecolor else draw all labelled lines with linecolor end if end if
> 
> if "color" then draw all lines (area boundary or not) with color end
> if
> 
> alegend = legend for areas llegend = legend for labelled lines
> 
> It would be interesting to be able to give an alegend file but still
> give a "color" option to define the boundary lines color.
> 
> default, i.e. 'd.vect mapname' :  no fillcolor and white line color
> for all lines

I have no problem with that formulation.  I'd like to get some
consensus on whether people feel one or several modules are appropriate.

> Just for information: the drawing of the boundaries with d.vect.area
> is much slower than when done through d.vect. Any idea why ?

Well, d.vect.area currently always does the fill, then rewinds the
vector file to draw the boundaries.  It's the fill part that is
slowest.  I think I have an unneeded line clipping routine in there,
which G_plot_line() repeats (so, mine should come out).  The line
clipping algorithm is pretty fast, so I'd bet it's mostly the
fill part that is slowing things down (there are a lot of malloc
and free calls, then a quicksort for the scan line conversion --
the bigger the data set and the greater the number of islands,
the slower it will be.   I don't think the rasterizer can get
much faster, but I could look at reusing memory, which would
probably help considerably.  A higher level interface to the
plotting routines could also reduce the number of memory
copies that occur -- could be down to zero copies.)

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