[GRASS-dev] d.vect: support for z height (geometry) colors added

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

# 3D contour lines
r.contour elevation.10m out=contour20m step=20
d.vect -z contour20m 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

Enjoy,
Markus

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

# 3D contour lines
r.contour elevation.10m out=contour20m step=20
d.vect -z contour20m 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

Enjoy,
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Thanks for adding this feature Markus. I can see several immediate
uses in my work!

Cheers,

Dylan

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

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

Something I found here:

PG:
http://www.nabble.com/Re%3A--GENERAL--SELECT-with-REAL…-p2791587.html

SQlite:
http://www.nabble.com/Problem-with-floating-point-fields%2C-and-a-feature-request-td909387.html#a909387

MySQL:
http://www.nabble.com/Re%3A-float-comparison--p1285713.html

Markus