RE: [GRASS-user] suppress output to terminal completely
I use the --quiet option but then the output changes from tracing patch 1 tracing patch 2 etc... to tracing patch 1 and then only flipping this number and not rewriting the line. So it does not respect the --quiet option completely... And the 2> /dev/null option seems to work, now my script can run in the background and I can keep working. Thanks, Koen -Original Message- From: Paul Kelly [mailto:paul-gr...@stjohnspoint.co.uk] Sent: Mon 29-12-2008 17:36 To: Hufkens Koen Cc: grass-user@lists.osgeo.org Subject: Re: [GRASS-user] suppress output to terminal completely On Mon, 29 Dec 2008, Hufkens Koen wrote: > > Hi list, > > I'm working with r.le.patch in both scripts as well as interactively on the > terminal. > > Since these calculations take up a lot of time I would like to move them to > the background. > > If I use r.le.patch -mysettings & this will do just that. > > However, the module still spews stuff to my terminal. This is very annoying > as I login remotely so I can't fall back on the GUI menus. > > Can I disable my terminal output completely? > > dumping stout to /dev/null does not seem to work... GRASS modules send informative messages to stderr, not stdout - so adding 2>/dev/null (Bash shell syntax) should work. But have you tried r.le.patch --quiet first of all? I'm not sure if r.le.patch respects the --quiet setting, but redirecting stderr to /dev/null definitely will work. Paul ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] suppress output to terminal completely
Hi list, I'm working with r.le.patch in both scripts as well as interactively on the terminal. Since these calculations take up a lot of time I would like to move them to the background. If I use r.le.patch -mysettings & this will do just that. However, the module still spews stuff to my terminal. This is very annoying as I login remotely so I can't fall back on the GUI menus. Can I disable my terminal output completely? dumping stout to /dev/null does not seem to work... Any ideas, this would make GRASS workable again... Cheers, Koen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.mapcalc in ssh session
Hi list, this weekend I ssh'd in computer to let some processes run in the background so I have my results tommorow. However my script crashes on a strange error related to r.mapcalc. I tried some r.mapcalc commands within the ssh'd GRASS session and I get the same error. for example: r.mapcalc amap=pnm bmap=pbl4 formula=A*B outfile=test --overwrite syntax error, unexpected NAME, expecting $end Parse error both a and b maps exist, and the script runs as it should when using the GUI. I really can't get my head around this one. I found some reference to the problem in the archives, but it was all technical mambo jambo and it did not offer any solution to the problem (or not that I could figure out anyway). Is there a solution or workaround for this problem because this severly limits the use of GRASS in my setup? Kind regards, Koen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Exotic patch based statistics, a solution...
Hi list, just want to share some code that could be useful to some of you. I was looking for a way to do other patch based statistics than those provided in r.statistics. Using masks and a loop in GRASS was terribly slow (certainly for very patchy areas (in my case some 10). So this is the fastest I could make it without programming a module myself. I use R, but not the spgrass6 link, from within a bash script. The script uses a map with all numbered patches as can be provided by r.le.patch or r.le.stats and a cover map which contains the values u want to evaluate with some exotic statistic or function. In my setup I formatted the output as a rules file so the results could be translated back into an actual map using the patch number map as common factor. Other approaches are also possible, depending on the need of the user. Hope some people can benefit from it. Cheers, Koen -- THE BASH SCRIPT > #!/bin/bash # ### # # Grass bash script to evaluate the content of patches based upon a patch and cover map... # # !!! Only works within the GRASS terminal !!! # # # Calculate the a map with numbered patches with r.le.patch or r.le.trace. Use this as input for the patches.number.map. # The cover.map map is the map you want to evaluate based upon the delineated patches with another function than those # provided by r.statistics. # # use: sh myscript.sh patch.number.map cover.map (name of the script depends on how you save it ofcourse) # ### r.out.xyz input=$1 output=- fs=' ' | awk '{print $3}' > patches r.out.xyz input=$2 output=- fs=' ' | awk '{print $3}' > cover # # Make a two column matrix with first the patch number than the associated cover value # paste patches cover > Rinput ### # # R code starts here! # ### R --slave --vanilla --quiet --no-save <___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] output r.out.ascii
Hi list, I'm trying to use r.out.ascii to dump a map (or better a masked part of it) to stdout. I would then use sed to clean up the data so I'm only left with the pixel values and no spatial information (don't need it). However, If I run something in the lines of: r.out.ascii -h input=patch output=- null=* | sed 's/*//g' > patch.values.txt the file still remains a whopping 20mb (the size of the raw data, including all spatial stuff) I also want to do this for small patches of say 10 pixels of information so this really is overhead. Any idea how to trim the fat on this one? Kind regards, Koen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] speeding up context evaluation...
Hi list, for a validation exercise I need to extract the class values around certain pixel location. I have a map with all the locations (numbered) and a map with the validation map. The code you find below is the one I came up with to get this information (only output to terminal for the moment). However, this code includes a loop and is terribly slow. Has anyone an idea how to speed things up? Kind regards, Koen -- my code - #!/bin/bash # ### # # Get context around pixels... # # !!! Bash script only works within the GRASS terminal !!! # ### # # get number of pixels in location file... write to variable $pixels... # pixels=`r.info -r map=$1 | tail -n +2 | sed 's/max=//'` echo "their are $pixels groundtruth points..." for i in `seq 1 $pixels`; do echo "evaluating pixel $i of $pixels pixels..." # # Make MASK based upon pixel number evaluate one at a time. Mask name is MASK and patch.mask # after renaming... If kept as MASK it will apply to all operations and is a system wide setting (not wanted)... # r.mask -o input=$1 maskcats=$i --quiet g.rename rast=MASK,pixel.mask --overwrite --quiet # # create buffer around pixel value... # r.buffer input=pixel.mask output=tmp.buffer distances=4 units=meters --overwrite --quiet # # writes temporary reclass rules file... # echo "1 = NULL" > tmp.rules echo "2 = 1" >> tmp.rules echo "end" >> tmp.rules # # reclass context values using rules above... # r.reclass input=tmp.buffer output=context.mask rules=tmp.rules --overwrite # # calculate category statistics for pixel and context location... # r.mapcalculator amap=pixel.mask bmap=$2 formula=A*B outfile=pixel.category help=- --overwrite --quiet echo "pixel data..." r.stats -c -n input=pixel.category fs=space nv=* nsteps=255 r.mapcalculator amap=context.mask bmap=$2 formula=A*B outfile=context.category help=- --overwrite --quiet echo "context data..." r.stats -c -n input=context.category fs=space nv=* nsteps=255 done # # clean up tmp files... # rm tmp.rules g.remove rast=pixel.mask g.remove rast=context.mask echo "!!!DONE!!!" echo "#" ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] r.texture NULL value error
It seems that r.null missed some NULL values or some negative values are still there (one or both issues may be the cause). Anyway I worked around it by adding a fixed amount with the map calculator and rescaling it to the wanted scale. This workaround seems to be foolproof and confirms that there must be a NULL value or a negative value that is missed by the summary statistics and r.null causing r.texture to go into spasm. So, it's fixed and not fixed at the same time. Maybe I'll look into the code later. Cheers, Koen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] namens Markus Neteler Verzonden: ma 24-11-2008 15:46 Aan: Hufkens Koen CC: GRASS user list Onderwerp: Re: [GRASS-user] r.texture NULL value error On Mon, Nov 24, 2008 at 2:39 PM, Hufkens Koen <[EMAIL PROTECTED]> wrote: > Hi list, > > I've been trying to run a r.texture filter on a map but I constantly get the > error: > > ERROR: Negative or no data pixel found. This module is not yet able to >process no data holes in a map, please fill with r.fillnulls or >other algorithms > I ran into this myself a few minutes ago :) The trick is that *all* pixels in the current region are need to be set to non-NULL. If NULL pixels are present, r.texture fails. run r.univar mapname to see how many NULL cells are in the current region. Solution: - either zoom into area without NULL pixels (won't always make sense) - or fill the NULL areas with some value (various options) - (or fix r.texture if possible). Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.texture NULL value error
Hi list, I've been trying to run a r.texture filter on a map but I constantly get the error: ERROR: Negative or no data pixel found. This module is not yet able to process no data holes in a map, please fill with r.fillnulls or other algorithms However, I ran r.null to set all NULL values to 0 and r.categories also showed no negative values afterwards. What could be the cause of this error. I also rescaled the categories between 0 and 100. After all this the ERROR is still their. Furthermore, If I run a 3x3 r.neighbourhood average moving window analysis on this map, r.texture runs fine on the result of r.neighbourhood. I really don't know what causes this inconsistent behaviour. Any ideas what causes this error? Kind regards, Koen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] calculating statistics based upon a raster patch map
Hi list, I've got two maps, a map with patches or areas which I want to evaluate. A second map contains a parameter which I want to evaluate (average, std) based upon areas as delineated in the first map. The output of all this would optimally be a third map with the results of the evaluation (average, std) given to the areas of the first map. Is this possible in a simple way, or should I write something myself. I can't seem to find a premade function that does this or something close to it. Kind regards, Koen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Download link of Lorenzo Moretti's builds for mac OSX
Hi list, I don't know who maintains the grass site but I couldn't reach the latest builds of grass from Lorenzo Moretti for Mac OSX from the link provided by the grass site. It seems that the page has moved to http://grass.bologna.enea.it/download/ . Maybe I double post but anyway... this should resolve things for Mac users who want to run 6.3.x . Cheers, Koen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Geotiff export error (extra row and column)
Hi list, I've recently noticed that when exporting maps as Geotiff GDAL adds an extra row and column to the map. Within grass this data is not there. For example my map that measures 4509 rows and 4359 columns gets exported as a tiff of size 4510 by 4360. The added row and column are empty and can be removed easily but it still is an inconvenience and it should not be there in the first place. Any idea what causes this error and how it can be solved? Kind regards, Koen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] getting the number of occurences of different classes in a moving window neighbourhood
Hi list, I'm looking for a way to extract the occurence (number of pixels of a certain class in a moving window) of a certain class in a moving window neighbourhood and write this to a map. r.neighbors only provides summarized versions of what I need. Is there a way to calculate this basic statistic without resorting to too much coding or exporting my maps into R or matlab? Kind regards, Koen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] programming an automated GRASS analysis with a custom interface
Hi list, I'm currently working on a project where it would be nice to have user friendly and above all limited interface to an automated GRASS routine. Is there a quick and easy way to call GRASS from within other code (preferably a fast scripting language)? Furthermore, is interaction possible if I'm able to call GRASS from within this code, as I would like to create a mask based upon user input? Any suggestions? Kind regards, Koen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Calling external programs
Hi list, I was wondering if it is possible to feed raster maps as input into an external model and let the input be imported or be importable by GRASS as a result. The model is able to accept data of several biophysical parameters but for the moment only in 1D. Extending this to 2D with the use of rasterized data from GRASS would be a nice bonus. Or I will rephrase my question: Is there a standard command that can pipe raster data per pixel location into external code for evaluation and accept the output of this program? I know that there is shell access from within GRASS, but I don't know how it deals with the output of programs run in the shell from within GRASS. Any advice, tutorials or howtos would be appreciated. Kind regards, Koen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user