<FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=2><DIV>Hi Hamish and others,</DIV><DIV>&nbsp;</DIV><DIV>I am indeed able to get v.colors to work when i reduce the number of digits of my numerical/continuous variable. Putting it on the map using GUI works without any problems.</DIV><DIV>&nbsp;</DIV><DIV>Using d.vect in command mode, however, brings the following error:</DIV><DIV>&nbsp;</DIV><DIV>"GRASS 6.4&gt; d.vect -a map=pse type=area rgb_column=try1<BR>PNG: GRASS_TRUECOLOR status: FALSE<BR>PNG: collecting to file: map.png,<BR>GRASS_WIDTH=640, GRASS_HEIGHT=480<BR>ERROR: PNG: couldn't open output file map.png"</DIV><DIV>&nbsp;</DIV><DIV>Any ideas?</DIV><DIV>&nbsp;</DIV><DIV>Thanks!</DIV><DIV>&nbsp;</DIV><DIV>Roy</DIV><DIV><BR>&nbsp;</DIV><FONT color=#990099>-----Hamish &lt;hamish_b@yahoo.com&gt; wrote: -----<BR><BR></FONT><BLOCKQUOTE style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">To: rvanderweide@worldbank.org<BR>From: Hamish &lt;hamish_b@yahoo.com&gt;<BR>Date: 12/19/2010 09:21PM<BR>Cc: grass-user@lists.osgeo.org<BR>Subject: Re: [GRASS-user] SQL Error using "v.color"<BR><BR><FONT size=2 face="Default Monospace,Courier New,Courier,monospace">Roy:<BR>&gt;&nbsp;Is there also an alternative way to map a continuous variable (using<BR>&gt; different grades of&nbsp;colour&nbsp;to fill&nbsp;the area contained by&nbsp;boundaries),<BR>&gt; i.e. where you do not necessarily&nbsp;have to create your own rgb_column? <BR>&gt; (I have noticed an option for random colour assignment, but that is not<BR>&gt; exactly what i want.)<BR><BR>there is the d.vect.thematic module, but I'm not sure how well it works in<BR>WinGrass. Anyway we've been moving a lot of its functionality directly into<BR>d.vect, which makes things a lot cleaner internally.<BR><BR><BR>I've found the trouble with your missing colors: v.colors uses the<BR>r.what.color module to fetch the color value. But that uses %f to display<BR>the queried value (so only to 6 numbers behind the decimal place), but your<BR>normalized 0.0-1.0 data is given to a higher precision than that. So when<BR>it tries to update the database it doesn't find exact matches, it<BR>only provides a color for the rounded version. I've changed r.what.color<BR>now to use %.15g in 6.5svn (r44635), if the others are happy with that we<BR>can port it to the other branches. (the real solution is to rewrite<BR>v.colors as a C module, and extend the color library to not assume raster<BR>data)<BR><BR><BR>Since this is SQLite I'm not too upset about using an equality to do the<BR>floating-point number comparison as AFAIR sqlite uses strings for<BR>everything internally, and (abs(column - value) &lt; epsilon) wouldn't<BR>have helped in this case anyway.<BR><BR><BR>Oh, and adding the table name to the layer by v.db.connect turns out to<BR>be an SQLite thing (+v.in.ogr?), not a MS Windows thing.<BR><BR><BR>I'll note but leave comments re. the classic dangers of interpreting<BR>thematic mapping to others, as I don't have any good solutions to suggest<BR>for resolving that.<BR><BR><BR>Hamish<BR><BR><BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;<BR></FONT></BLOCKQUOTE><BR></FONT>