correction: it draws the boundaries, but uses the same color as the fill
when it should make the area color random and the line color respect
color=. e.g.:
d.vect -c type=area fcolor=none
see the d.vect symbol drawing code for an example of using a primary and
secondary color in place of line= and fill=.
I assume that in darea() of d.vect/area.c some test is needed in
the loop therein to distinguish the various vector types while
looping over all vectors.
Hi I don't know it is the same issue but I can not draw any vector map
with d.vect when I use command like d.vect output=map1 i got this error
message: output <map1> exist. If I put an inexistant vector, I got: map
<map1> not found.
Thank you
Replying to [comment:3 neuba]:
> Hi I don't know it is the same issue but I can not draw any vector map
with d.vect when I use command like d.vect output=map1 i got this error
message: output <map1> exist. If I put an inexistant vector, I got: map
<map1> not found.
There is no 'output' parameter
{{{
d.vect --help
}}}
{{{
d.vect output=x
Sorry, <output> is not a valid parameter
ERROR: Required parameter <map> not set:
(Name of input vector map).
}}}
Replying to [comment:3 neuba]:
> Hi I don't know it is the same issue but I can not draw any vector map
with d.vect when I use command like d.vect output=map1 ...
IMPORTANT to all SVN users:
After the recent change in parser.c you need to RECOMPILE GRASS from
scratch.
IMPORTANT to all SVN users:
After the recent change in parser.c you need to RECOMPILE GRASS from
scratch.
I wanted to post this but forgot about it. So
{{{
make distclean
sh configure ...
make
}}}
Might it be better to just assign explicit values to the G_OPT_*
constants, so that this issue doesn't occur whenever new constants are
added or removed?
A related, but distinct option is to make e.g. G_gisinit() check that
the library and module were compiled with the same version of gis.h,
I.e.:
On Sat, May 24, 2008 at 11:10 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
GRASS GIS wrote:
IMPORTANT to all SVN users:
After the recent change in parser.c you need to RECOMPILE GRASS from
scratch.
I wanted to post this but forgot about it. So
{{{
make distclean
sh configure ...
make
}}}
Might it be better to just assign explicit values to the G_OPT_*
constants, so that this issue doesn't occur whenever new constants are
added or removed?
A related, but distinct option is to make e.g. G_gisinit() check that
the library and module were compiled with the same version of gis.h,
I.e.:
Attached diff should fix the bug. I don't really understand why there was
a conditioning on the value of rgb in there. Looking through the code, I
don't think it is useful, but please test (notably with some of the flags,
such as table color and z-color).