Is there also an alternative way to map a continuous variable (using
different grades of colour to fill the area contained by boundaries),
i.e. where you do not necessarily have to create your own rgb_column?
(I have noticed an option for random colour assignment, but that is not
exactly what i want.)
there is the d.vect.thematic module, but I'm not sure how well it works in
WinGrass. Anyway we've been moving a lot of its functionality directly into
d.vect, which makes things a lot cleaner internally.
I've found the trouble with your missing colors: v.colors uses the
r.what.color module to fetch the color value. But that uses %f to display
the queried value (so only to 6 numbers behind the decimal place), but your
normalized 0.0-1.0 data is given to a higher precision than that. So when
it tries to update the database it doesn't find exact matches, it
only provides a color for the rounded version. I've changed r.what.color
now to use %.15g in 6.5svn (r44635), if the others are happy with that we
can port it to the other branches. (the real solution is to rewrite
v.colors as a C module, and extend the color library to not assume raster
data)
Since this is SQLite I'm not too upset about using an equality to do the
floating-point number comparison as AFAIR sqlite uses strings for
everything internally, and (abs(column - value) < epsilon) wouldn't
have helped in this case anyway.
Oh, and adding the table name to the layer by v.db.connect turns out to
be an SQLite thing (+v.in.ogr?), not a MS Windows thing.
I'll note but leave comments re. the classic dangers of interpreting
thematic mapping to others, as I don't have any good solutions to suggest
for resolving that.
Roy:
> Is there also an alternative way to map a continuous variable (using
> different grades of colour to fill the area contained by boundaries),
> i.e. where you do not necessarily have to create your own rgb_column?
> (I have noticed an option for random colour assignment, but that is not
> exactly what i want.)
Hamish:
there is the d.vect.thematic module,
oh yeah, another trick: if you set the continuous column as the feature's z
(elevation) value you can use 'd.vect -z zcolor=bcyr' too. [v.edit or
v.extrude?]
I am indeed able to get v.colors to work when i reduce the number of digits of my numerical/continuous variable. Putting it on the map using GUI works without any problems.
Using d.vect in command mode, however, brings the following error:
“GRASS 6.4> d.vect -a map=pse type=area rgb_column=try1
PNG: GRASS_TRUECOLOR status: FALSE
PNG: collecting to file: map.png,
GRASS_WIDTH=640, GRASS_HEIGHT=480
ERROR: PNG: couldn’t open output file map.png”
Is there also an alternative way to map a continuous variable (using
different grades of colour to fill the area contained by boundaries),
i.e. where you do not necessarily have to create your own rgb_column?
(I have noticed an option for random colour assignment, but that is not
exactly what i want.)
there is the d.vect.thematic module, but I’m not sure how well it works in
WinGrass. Anyway we’ve been moving a lot of its functionality directly into
d.vect, which makes things a lot cleaner internally.
I’ve found the trouble with your missing colors: v.colors uses the
r.what.color module to fetch the color value. But that uses %f to display
the queried value (so only to 6 numbers behind the decimal place), but your
normalized 0.0-1.0 data is given to a higher precision than that. So when
it tries to update the database it doesn’t find exact matches, it
only provides a color for the rounded version. I’ve changed r.what.color
now to use %.15g in 6.5svn (r44635), if the others are happy with that we
can port it to the other branches. (the real solution is to rewrite
v.colors as a C module, and extend the color library to not assume raster
data)
Since this is SQLite I’m not too upset about using an equality to do the
floating-point number comparison as AFAIR sqlite uses strings for
everything internally, and (abs(column - value) < epsilon) wouldn’t
have helped in this case anyway.
Oh, and adding the table name to the layer by v.db.connect turns out to
be an SQLite thing (+v.in.ogr?), not a MS Windows thing.
I’ll note but leave comments re. the classic dangers of interpreting
thematic mapping to others, as I don’t have any good solutions to suggest
for resolving that.