[GRASS-user] SQL Error using "v.color"

[Hamish]

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.)

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.


Hamish