[GRASS-dev] graph function input limitations

[Paulo van Breugel]

On 11/21/2012 10:46 PM, Helmut Kudrnovsky wrote:
>> Your suggestion to use r.recode was spot on. It not only avoids the
> mentioned limitations, it is also
>> faster. (and it really is also much simpler).
> maybe something for the wiki (http://grasswiki.osgeo.org/wiki/Main_Page)?
I am not sure where and what you would like to have mentioned on the 
Wiki? I think this whole issue was an example of bad scripting from my 
side (or perhaps it is better to call it a learning experience ;-)), in 
which I used a tool (graph function) that was definitely not the most 
appropriate or even easiest one. I did learn more about a few different 
tools and their limitations. One of the 'limitations' I often encounter 
is the (different) format of the output of the different modules, 
although with some regular expression wizardry a lot is possible as the 
example by Glyn in another email tread on 'Get min and max value of the 
ranges reported by r.stats' shows. That is perhaps a possibility, a page 
on http://grasswiki.osgeo.org/wiki/Documents with an overview of 
different ways to deal with output from different functions (especially 
those outputs that cannot be easily imported in e.g., a spreadsheet or 
R)? But that could be the subject of another email thread :-)
>
>
>
> -----
> best regards
> Helmut
> --
> View this message in context: http://osgeo-org.1560.n6.nabble.com/graph-function-input-limitations-tp5017855p5018032.html
> Sent from the Grass - Dev mailing list archive at Nabble.com.
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20121122/5bfa7dae/attachment.html>