Re: [GRASS-user] exploding a color table
Neil Best pisze: Has anyone come up with a way to convert a streched color table for a floating point map into a set of discrete colors? I am thinking especially of NDVI, so I would like to generate the list of 256 colors along the NDVI floating point stretch to use with the result of r.recode that I used to convert my NDVI map to an integer map. If I could properly set the color table for that new map then I could maintain the symbolization within GRASS rather than having to spew a list of 256 colors for a Mapserver configuration. Any thoughts? Glynn already answered with r.what.color, here is how to automate that: seq 255 | r.what.color -i mapname but I wonder, are you using the r.colors color=ndvi rules? they look like this: cat $GISBASE/etc/colors/ndvi -1. white -0.3000 blue -0.2000 205 193 173 0. 150 150 150 0.1000 120 100 51 0.3000 120 200 100 0.4000 28 144 3 0.6000 6 55 0 0.8000 10 30 25 1. 6 27 7 just substitute your new range for the -1.0 to 1.0 steps with r.colors color=rules, as long as the recode was linear. I think though that your easiest solution is to use NASA's 0-255 color rules. :) http://oceancolor.gsfc.nasa.gov/DOCS/palette_ndvi.txt http://oceancolor.gsfc.nasa.gov/PRODUCTS/colorbars.html you might be able to pipe those directly into r.colors or use them with r.colors rules=palette_ndvi.txt. see also http://grass.osgeo.org/wiki/MODIS#Set_colors Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using v.line.center
Markus Neteler pisze: On Thu, Jun 5, 2008 at 7:38 PM, Maciej Sieczka [EMAIL PROTECTED] wrote: Manuel Sangiao pisze: WARNING: Cannot get point on line: cat=927 offset=89379.795093 (line lenght=2.219076) P 927 927 89379.795093 I guess the reason for this error is the projection (mapset?) unit. The projection unit(s) in my mapset is degree(s). And the length units are meters. v.line.center as it is can't work in latlon Location. It uses v.to.db for length calculation, which cannot measure in degrees, I think it can... from the man page: When calculating perimeters in Latitude-Longitude locations, the geodesic distance between the vertices is used. Markus v.line.center uses v.to.db to calculate lengths of input vector lines, which then are fed into v.segment as offsets to create lines' center points. v.segment expects offsets in units of the Location. If these are degrees we have a problem because v.to.db can't calculate length in degrees. It supports the following units: mi,miles,f,feet,me,meters,k,kilometers,a,acres,h,hectares Therefore, v.line center can't work in latlon locations. -- Maciej Sieczka www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Error in v.vol.rst
Hello, I trying to generate a 3d DEM of a gully headcut. The point data was gained by terrestrial laser scanner. As I am doing my first attempts, I do not change any parameters from that given by default. This is the result: v.vol.rst [EMAIL PROTECTED] wcolumn=dbl_3 tension=40. smooth=0.1 segmax=50 npmin=200 dmin=0.050026 wmult=1.0 zmult=1.0 elev=Olite_3d --overwrite 1511728 records selected from table some points outside of region -- will ignore... strip exists with insufficient data Processing all selected output files will require 1435616 bytes of disk space for temp files There are points outside specified 2D/3D region--ignored 57754 points (total points: 1511728) Points are more dense than specified 'DMIN'--ignored 1131669 points (remain 380059) Percent complete: Error in COGRR! Interp_call failed! Can someone give me an idea if this is my fault? Thank you! Manuel -- ___ Dr. Manuel Seeger Wiss. Assistent Scientific Assistant Physische GeographieDpt. of Physical Geography FB VI - Geographie/GeowissenschaftenGeography/Geosciences Universität Trier University of Trier D - 54286 Trier Tel.: +49-651-201 4557 Fax:+49-651-201 3976 Web:http://www-neu.uni-trier.de/index.php?id=9607 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Course in Evora, Portugal
Last week I had the privilege to hold a QGIS-GRASS course at the University of Evora, Portugal, organized by Giovanni Manghi. I hope the students (19) will agree, anyway to me it was a wonderful experience and a great success for QGIS: rather skeptical at first, the last day they looked impressed by the analytical power and ease of use of the couple Q+G. Of course we encountered several problems, especially with windows. Especially wonderful was to see several bugs and wishes fixed *during* the days of the course. Much appreciated was the plugin to add columns to dbf tables. Thanks to everybody! All the best. pc -- Paolo Cavallini, see: * http://www.faunalia.it/pc * ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.sun2 uses another prefix than the one defined in horizon= parameter!
On Thu, 2008-06-05 at 16:27 +0200, Nikos Alexandris wrote: r.horizon elevin=$ELEVATION direction=0 step=$HORIZON_STEP horizon= $HORIZON gives horizon maps like hortest.45_0, hortest.45_1, etc. r.sun2 expects something like hortest.45_000, hortest.45_001, etc. Is this a bug? Well, not really a bug, but, since r.sun2 needs eventually map(s) from r.horizon why shouldn't r.horizon name its output after what r.sun2 expects? Thank you, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
