> after getting mad with Lidar points colorizing which till now
> required a DB table with GRASSRGB attributes, I have
> modified d.vect to support colors directly from z height
> (geometry).
it is really nice to finally have that Markus, thank you.
now I don't feel as worried about putting the v.colors script into main, it
will only be used (hopefully) when a table is already there and a new
column/table will not be too huge. With v.colors I still hesitate to break up
the nice r.what.colors pipe method with temp files but guess that has to happen.
Or figure out how to make this safe for floating point comparison on the $VALUE
column without keeping the cat column:
(my SQL is very poor)
UPDATE $TABLE SET $GIS_OPT_RGB_COLUMN = '$COLR' WHERE $GIS_OPT_COLUMN =
$VALUE
Or modify r.what.colors to pass through anything after the query number to
stdout after the color code; not sure about that.
http://trac.osgeo.org/grass/browser/grass-addons/vector/v.colors
Hamish
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
