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).
Works for 3D points, lines (eg, 3D contours) and 3D polygons
(eg delaunay triangles):
# Spearfish:
g.region rast=elevation.10m
r.random elevation.10m n=5000 vector=random3d -d
d.mon x0
# display as black points
d.vect random3d
# display 3D points colorized according to z height
d.vect -z random3d zcol=gyr
# generate 3D triangles
v.delaunay random3d out=random3d_del
# display 3D polygons colorized according to z height
d.vect -z random3d_del type=area zcol=gyr
On Sat, May 17, 2008 at 6:37 AM, Markus Neteler <neteler@osgeo.org> wrote:
Hi,
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).
Works for 3D points, lines (eg, 3D contours) and 3D polygons
(eg delaunay triangles):
# Spearfish:
g.region rast=elevation.10m
r.random elevation.10m n=5000 vector=random3d -d
d.mon x0
# display as black points
d.vect random3d
# display 3D points colorized according to z height
d.vect -z random3d zcol=gyr
# generate 3D triangles
v.delaunay random3d out=random3d_del
# display 3D polygons colorized according to z height
d.vect -z random3d_del type=area zcol=gyr
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.
On Sun, May 18, 2008 at 1:40 AM, Hamish <hamish_b@yahoo.com> wrote:
...
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