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 _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
