Re: [GRASS-user] g.rename problem with Python
RichardCooper wrote:
> with open('glist_llrotate.txt') as gl:
> for line in gl:
> And the error:
> WARNING: Illegal filename >. Character <
> > not allowed.
When you iterate over a file, the strings include the line terminators
(e.g. '\n' or '\r\n'). Use e.g.
for line in gl:
renamed = line.rstrip().replace('.','_')
...
to remove any trailing whitespace (including newlines) from each line.
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using label in r.mapcalc query?
Ahmet Temiz wrote: > I am confused about using label values in r.mapcalc. > > r.category curvt_cat > 1 conc > 2 flat > 3 conx > > > r.mapcalc "dene = if ( curvt_cat == /* I want to use label values here > instead of categories*/ )" > > like this : > > r.mapcalc "dene = if ( curvt_cat == 'conc' )" > > it gives > Invalid map > > ?How can I use label in r.mapcalc query?? You can't. r.mapcalc doesn't have a string type. You'll need to parse the output from r.category to determine the numeric category corresponding to the label, then use that in the r.mapcalc expression. The @ modifier reads the category label and converts it to a float. This is basically a hack which had some utility in the GRASS 4.x era, before GRASS supported floating-point maps. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Question on memory allocation and use
Rich Shepard wrote: >I assumed that grass did not see the available memory, but did not realize > it would not use the available swap memory. Is GRASS built for 32-bit (x86) or 64-bit (x86-64 aka amd64)? Running "file" on e.g. r.contour will tell you. A 32-bit process can't use more than 4 GiB of memory regardless of how much RAM or swap is available. The amount available to malloc() etc will be somewhat lower due to reservations for the kernel, stack, etc. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] "GLdouble" syntax error when compiling GRASS 7.0.4
Benjamin Roberts wrote: > I’m trying to compile GRASS 7.0.4 on an HPC cluster running Red Hat > Enterprise Linux 6.5. We use EasyBuild to manage our toolchain, and I’m > compiling GRASS against numerous packages that I’ve previously built, such as > PROJ4, GDAL, etc. > > Unfortunately, during the compilation process, I get errors of this sort: > > Error: > /home/brob695/.local/easybuild/build/GRASS/7.0.4/foss-2015a/grass-7.0.4/dist.x86_64-pc-linux-gnu/include/grass/ogsf.h:475: > Syntax error at 'GLdouble' > Error: > /home/brob695/.local/easybuild/build/GRASS/7.0.4/foss-2015a/grass-7.0.4/dist.x86_64-pc-linux-gnu/include/grass/ogsf.h:475: > Syntax error at ';' > Error: > /home/brob695/.local/easybuild/build/GRASS/7.0.4/foss-2015a/grass-7.0.4/dist.x86_64-pc-linux-gnu/include/grass/defs/ogsf.h:178: > Syntax error at 'GLuint' > Error: > /home/brob695/.local/easybuild/build/GRASS/7.0.4/foss-2015a/grass-7.0.4/dist.x86_64-pc-linux-gnu/include/grass/defs/ogsf.h:445: > Syntax error at 'gsd_set_font' Could you provide some more context? Ideally everything after the prior "Entering directory ..." line, to indicate which component is being built and the command which is generate the errors. > Because the objective is to convert data into graphical formats > rather than displaying it, we don’t have OpenGL rendering; even the > OpenGL libraries and headers are not available. However, I have > attempted to disable OpenGL dependency using the --without-opengl > configuration option; moreover, I see “checking whether to use > OpenGL... no” in my configuration log. In which case, GRASS ought to skip any component which requires OpenGL. I suspect that this arises from building the Python ctypes wrappers for the OGSF and NVIZ libraries. In which case, we should probably change the definition of MODULES in lib/python/ctypes/Makefile to e.g.: MODULES = date gis raster gmath proj imagery vector rtree display stats \ dbmi raster3d arraystats cluster vedit segment rowio temporal ifneq ($(USE_OPENGL),) MODULES += ogsf nviz endif -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.label utf8 possible?
Robert Kuszinger wrote: > I'd like to create a label for a point vector map with point names to be > utilized in map composer (ps.map). > > Everything works except that I cannot use my UTF8 strings. They are > rendered as latin1 as far as I can see. > > Using d.vect strings are displayed correctly: > > d.vect --quiet map=places@Duna where="type='village' OR type='town'" > color=none fill_color=red width=1 icon=basic/circle attribute_column=name > label_color=black label_size=9 font=LinBiolinum_R encoding=UTF-8 > > but there is no encoding option in v.label. I've found some links to > v.label.sa which is not available in my Grass setup nor on the extension > list. > Grass version is: AIUI, v.label simply sets the labels as byte strings. Their interpretation is determined by the program which actually renders the labels, either by an explicit call to D_encoding(), or from the environment variable GRASS_ENCODING, or from the font's default encoding from the fontcap file. UTF-8 text should work with d.vect and d.labels if you use a FreeType font (but not for a stroke font, which only provide glyphs for the ASCII range). I wouldn't expect it to work with anything which generates PostScript. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] why is v.build.all (and many others) a windows batch file and not an executable?
Bartolomei.Chris wrote: > While I think that there could have been a way to move forward with > python and yet not break the legacy shell scripts users have when > migrating, I understand the changes now. If MSys treats other shell scripts as executables, one option might be to auto-generate a shell-script wrapper for each Python script, in the same way that batch-file wrappers are generated. The batch-file wrappers are generated by a rule in Script.make: $(BIN)/$(PGM).bat: $(MODULE_TOPDIR)/scripts/windows_launch.bat sed -e "s#SCRIPT_NAME#$(PGM)#" -e "s#SCRIPT_DIR#$(SCRIPT_DIR)#" $(MODULE_TOPDIR)/scripts/windows_launch.bat > $@ unix2dos $@ This is run as part of the process of "building" a script; it just takes a template .bat file and inserts the script name and directory. It would be a straightfoward matter to add a similar rule to do the same for a shell script; the only question is whether this should be done automatically and whether the wrappers should go into the bin directory or some other directory (it depends upon whether they will interfere with contexts other than shell scripts). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to define the png image dimensions when using d.mon?
Martin Landa wrote: > > d.mon is designed for interactive use. If you're writing a script, > > don't use it. Set GRASS_RENDER_IMMEDIATE=png (or =cairo) and use the > > environment variables. > > not really, beside wx monitors, you can use cairo or png (useful for > scripting). Martin You appear to be misunderstanding what "interactive" means in this context. It doesn't necessarily imply a GUI. The only situation where a script should be using d.mon is if it really is a "script", in the sense of a canned sequence of commands which is meant to be "replayed" as part of an interactive workflow. Anything which tries to behave like a typical program should manage the relevant environment variables directly. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.external.out store data in memory
Lorenzo Bottaccioli wrote: > I wanted to know if was possible and how to store produced rasters in > memory (as an rasterio object or similar) and do not store/save the in the > disk, because I just need to do some statistics and then delete them. This > if possibele will speed up my workflow because I'll avoid I/O from the disk. This isn't possible, beyond the fact that the OS will cache files in memory provided that sufficient memory is available. Writing a file doesn't wait for the data to be written to disk, and subsequent commands which read the file won't need to read from disk if the file is still in memory. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to define the png image dimensions when using d.mon?
d.mon is designed for interactive use. If you're writing a script, don't use it. Set GRASS_RENDER_IMMEDIATE=png (or =cairo) and use the environment variables. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Do filters available in GRASS takes care of cell padding?
Uttam Kumar wrote: > 4.) Which one of the above GRASS commands would be best suited to perform > window operation (high pass filtering) along with cell padding? One caveat to my previous reply: Ignoring nulls often doesn't work so well for kernels with a zero sum (e.g your high-pass filter). You can't use r.neighbors method=average with weights which sum to zero (as that results in division by zero), and method=sum introduces a bias if some weights are ignored (at the edges, you'll have a single cell with a weight of 24 and fewer than 24 cells with a weight of -1, meaning that a constant map would produce a positive value near the edges). I would suggest using two passes, e.g. r.neighbors size=5 method=average input=band5 output=band5_average r.mapcalc 'band5_highpassfilter = band5 - band5_average' g.remove raster=band5_average This returns the value of the centre cell minus the average of the surrounding non-null cells. The average value is still meaningful if the filter window overlaps null cells or the edges. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Do filters available in GRASS takes care of cell padding?
Uttam Kumar wrote: > If I am trying to use > > r.mfilter input=band5 output=band5_highpassfilter > filter=/Users/Uttam/high_pass_filter > > where high_pass_filter is > > TITLE 5x5 High Pass > MATRIX 5 > -1 -1 -1 -1 -1 > -1 -1 -1 -1 -1 > -1 -1 24 -1 -1 > -1 -1 -1 -1 -1 > -1 -1 -1 -1 -1 > DIVISOR 25 > TYPE P > > > 1.) How do I ensure that cell padding is taken care using r.grow.distance? > Do I need to apply r.grow.distance on the output of r.mfilter or it should > be applied before r.mfilter on the input image (band5 in this case)? Before. If any cell in the filter window is null (including cells outside the current region), the corresponding output cell will have the value of the original input cell. Consequently, the output from r.mfilter with a 5x5 kernel will have at least a 2-cell border containing the original (unfiltered) cell values. To avoid this, you need to enlarge the region by 2 cells in each direction, use e.g. r.grow.distance to fill the space around the input map, run r.mfilter on the result, then shrink the region back to the original size and (optionally) resample the result to remove the border. > 2.) Will use of r.resamp.filter will do both - cell padding and apply > filter in a single execution? However, I felt r.resamp.filter does not > allow specifying the type of filter such as high pass filter coefficients > in the input. r.resamp.filter largely avoids the need to add a border; unless the -n flag is used it ignores any null cells (including cells outside the current region), effectively changing the filter weights to zero for null calls (and adjusting the divisor accordingly). > r.resamp.filter input=band5 output=band5_resamp filter=box radius=1 > > How to specify the filter coefficients here? r.resamp.filter doesn't perform generalised filtering. It is designed solely for resampling; the output is intended to match the input. All of the supported filters are anti-aliasing filters. r.neighbors with the weight= option can perform generalised filtering, although it's limited to a single filter kernel. Like r.resamp.filter, it ignores null cells, which eliminates the need to add a border. > 3.) r.resamp.stats does not allow to specify the filter size (3 or 5)? Like r.resamp.filter, r.resamp.stats is designed for resampling (specifically, downsampling). But instead of interpolating between nearby values, it calculates a statistical aggregate (mean, median, etc) over the input cells corresponding to each output cell. > I feel that in any case the number of rows should increase by 2 (1 top and > 1 bottom) and number of columns should increase by 2 (1 left and 1 right) > during cell padding. Adding a border is a necessary workaround for the way that r.mfilter handles null cells. Ignoring them (as most other such modules do) is a better solution, as it effectively re-distributes the weight of the null cell over the non-null cells according to their own weights, rather than assigning it all to an arbitrarily-chosen cell (which is the effect of adding a border by extrusion or reflection). > 4.) Which one of the above GRASS commands would be best suited to perform > window operation (high pass filtering) along with cell padding? r.neighbors method=sum.with the weights= option. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Do filters available in GRASS takes care of cell padding?
Uttam Kumar wrote: > Do the filters available in GRASS GIS such as average, low pass, high pass > filters take care of cell padding automatically? "filters"? > By Cell paddding, I refer to duplicating the first row on top, duplicating > bottom row at the bottom, duplicating first column before the actual first > column and duplicating last column after the actual last column. None of the modules do this, although you can achieve that result by by first using e.g. r.grow.distance with the value= option to replace null cells with the nearest non-null cell. r.resamp.filter simply enlarges the source region by the kernel radius. If this results in it reading nulls (because the enlarged region extends beyond the area for which the map contains data), then either a) the nulls will be propagated (if -n is used) or, b) the weighting will be adjusted, i.e. the result will be sum(weight * value)/sum(weight) where both sums are evaluated over the non-null inputs. r.resamp.stats behaves similarly (i.e. it either propagates nulls or computes the aggregate over the non-null cells). r.neighbors always calculates the aggregate over the non-null cells. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] location/mapset naming restrictions
Panagiotis Mavrogiorgos wrote: > Are there any restrictions to the location/mapset names? They may not contain any of the characters: / " ' @ , = * or space, DEL (code 127/0x7F), any control character or any 8-bit character. [source: lib/gis/legal_name.c] Also, because map, mapset and location names are used directly as file and/or directory names, they may not contain any character which is prohibited in a filename by the underlying OS. On Windows, this includes: \ / : * ? " < > | [source: try entering any of these characters when renaming a file or directory on Windows.] The OS may also impose other restrictions (e.g. you typically can't have a file or directory named "." or ".." although the "." character isn't itself prohibited). > I just found out that if you use a numeric mapset (e.g. 2014_123) you have > to use single quotes in mapcalc expressions. Which names are legal and which names can be used in r.mapcalc without quoting are different. E.g. a "-" character (minus, hyphen, dash) is legal in a map, mapset or location name, but r.mapcalc requires the name to be quoted, otherwise it will be interpreted as a subtraction. > e.g the following example will > raise an error: > > r.mapcalc expression="foo=R1@2014_123" > > results in: > > syntax error, unexpected INTEGER, expecting VARNAME or NAME An unquoted name consists of a sequence of characters other than space, control characters, or any of: ^ # @ , " ' ( ) [ ] + - * / % > < ! = & | ? : ; ~ [source: raster/r.mapcalc/mapcalc.l, definition of "N" (line 97).] *However*: it may not have a prefix which is a valid integer or floating-point literal (which is why your example above generates an error), as those take precedence over names. A quoted name can contain any character other than the quote character itself. Note that quoted names aren't always maps (or mapsets or locations); they can also be used for variables if you feel you have to use a name which isn't valid as an unquoted name. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass.script.raster.mapcalc and multiple computations
Panagiotis Mavrogiorgos wrote: > Is it possible to perform multiple computations using > grass.script.raster.mapcalc()? What I want is to run something like this > (example taken from r.mapcalc documentation): > > r.mapcalc < > $GIS_OPT_OUTPUT.r = r#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - > > .$GIS_OPT_PERCENT) * r#$GIS_OPT_SECOND > > $GIS_OPT_OUTPUT.g = g#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - > > .$GIS_OPT_PERCENT) * g#$GIS_OPT_SECOND > > $GIS_OPT_OUTPUT.b = b#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - > > .$GIS_OPT_PERCENT) * b#$GIS_OPT_SECOND > > EOF expr = ";".join([ "$out.r = r#$first * $frac + (1.0 - $frac) * r#$second", "$out.g = g#$first * $frac + (1.0 - $frac) * g#$second", "$out.b = b#$first * $frac + (1.0 - $frac) * b#$second"]) grass.mapcalc(expr, out=out, first=first, second=second, frac=percent/100.0) > When I give an expression as a multiline string, I get an error like this > one: > > Invalid map > > Parse error > > ERROR: parse error > > ERROR: An error occurred while running r.mapcalc There shouldn't be any issues with multi-line strings per se, but you can use a semicolon instead of a newline. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] map algebra logical operators on DCELL rasters not admitted? maybe docs should outline it
G. Allegri wrote: > If logical operator is applied to, sat, Byte data it gives true/false > results, e.g. if(A && B,1, 0) behaves correctly even with cell values > values greater then 1. > That's why I expected it to work with floats operands too. > >From a user perspective if it works for a cell with value 2 it should also > work for a cell with value 2.0. > That'all. r.mapcalc's interpretation of booleans is borrowed from C. Booleans are just integers where zero is false and non-zero is true. But that doesn't necessarily make much sense for floats; the conventional wisdom is that comparing a float for equality with zero is usually a mistake, as results which should mathematically be equal to zero often aren't actually equal to zero due to intermediate rounding errors. In some cases, simply subtracting a number from itself won't yield zero (e.g. due to the x87 FPU using 80 bits for floating-point registers while values stored in memory use 32 or 64 bits). You can obtain C-like behaviour by converting to an integer with the int() function then using that; the result is that any value between -1.0 and 1.0 (excluding both endpoints) will be considered false while anything else is true. Or you can convert to an integer with the round() function and use that, in which case any value between -0.5 and 0.5 (including both endpoints) will be false while anything else is true. Or you can compare for equality with 0.0, in which case -0.0 and 0.0 will be false while anything else is true. Or you can compare the magnitude (obtained using abs()) to an "epsilon" value so that anything smaller than the expsilon is false while anything larger is true. That's four different possibilities, none of which is any more "correct" than any of the others. Choosing one of them would just mean that r.mapcalc was probably using the "wrong" one, and doing so silently. The current behaviour forces the user to be explicit. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] map algebra logical operators on DCELL rasters not admitted? maybe docs should outline it
G. Allegri wrote:
> > This isn't about the if() function. The bitand() function (to which
> > the error message refers) corresponds to the bitwise-and operator "&".
> >
> > The if() function accepts either integer or floating-point values for
> > its arguments.
>
> That's what disappointed my client (and me) Glynn: why integer yes and not
> floats? Is it a technical limitation or there's a ratio behind it?
> Anyway did I miss something from the docs? I couldn't find it.
What would you expect the value of (x & y) to be if x and/or y were
floating-point values?
> Why do you that I'm confusing the operators? I've always talked about
> logical operators...
Because you quote an error message which specifically refers to a
*bitwise* operator:
> "Incorrect argument types to function bitand()".
in a message which otherwise only mentions logical operators.
"bitand()" is the name of the bitwise-and function, which corresponds to
the infix "&" operator. I.e. (x & y) is exactly equivalent to bitand(x, y).
This is the same as the "&" operator in C or C++: it evaluates to an
integer where each bit in the result is set (one) if the corresponding
bit is set in both operands, and unset (zero) otherwise. E.g. (23 & 34)
is
00010111 (23)
& 00100010 (34)
= 0010 ( 2)
Perhaps it would help if you posted the exact expression which is
causing you problems.
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] map algebra logical operators on DCELL rasters not admitted? maybe docs should outline it
Moritz Lennert wrote: > >> Doing a logical operation with a DCELL raster within an if(x,a) statement > >> produces an error: "Incorrect argument types to function bitand()". > > > > First, you're confusing bitwise operators and logical operators. & and > > | are bitwise operators, while && and || (and &&& and |||) are logical > > operators. > > > > Second, both bitwise and logical operators only work on integer > > values. If you want to use floating-point values as boolean values, > > you need to explicitly convert them to integers (either via int(x) or > > round(x), or x==0.0, or abs(x)<1e-30, or whatever). > > ??? > > On my grass71 and grass64release, these work (using NC demo data set): > > r.mapcalc "test = if(elevation == 100.0, 1)" > r.mapcalc "test = if(elevation > 100.0, 1)" > > where elevation is FCELL. I would expect those to work. What won't work is using bitwise operators (& and |) or logical operators (&& and ||, &&& and |||) on floats. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Parallel processes
Dylan Beaudette wrote: > My main motivation for asking this question was to determine instances > where parallel operations in GRASS are _not_ safe. From my reading of > the wiki, manual pages, and your recent comments on GRASS-dev, it > would appear that the following operations may not be safe: > > 1. region-altering Commands which modify the WIND or VAR files cannot safely be executed in parallel. Similarly, commands which overwrite maps or modify database tables cannot safely be executed in parallel if they will (or might) modify the same maps, tables, etc. For commands which create new maps (or similar), you need to ensure that they don't concidentally choose the same name for their outputs. In short, GRASS doesn't attempt to "lock" maps, files, or similar entities which it modifies, beyond the fact that each GRASS "session" locks its current mapset. > 2. calculations in the presence of a MASK > > 3. reading "external" (r.external) GDAL sources (?) > > 4. some mapcalc expressions These should be safe if the parallelism is in the form of multiple processes. The known or suspected issues with r.mapcalc are related to using multiple threads within a single process. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Parallel processes
Dylan Beaudette wrote: > Are there any reasons to prefer sequential operations (that do not > alter the region) vs. parallel operations? Running additional jobs in parallel is only worthwhile if the resources which they would use (CPU, memory, I/O bandwidth) would otherwise be idle. Once you get to the point that a resource is saturated and jobs are contending for it, parallel execution will be less efficient than serial execution. Maybe the "parallel" command takes these factors into account sufficiently. If it only considers CPU cores (i.e. one job per core), you'd need to confirm that you aren't saturating I/O bandwidth or thrashing memory or CPU caches. Try running the same sequence of tasks with varying numbers of parallel jobs to determine the optimal value. Needless to say, this will vary according to the nature of the task (e.g. I/O-bound versus CPU-bound). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] map algebra logical operators on DCELL rasters not admitted? maybe docs should outline it
G. Allegri wrote: > Doing a logical operation with a DCELL raster within an if(x,a) statement > produces an error: "Incorrect argument types to function bitand()". First, you're confusing bitwise operators and logical operators. & and | are bitwise operators, while && and || (and &&& and |||) are logical operators. Second, both bitwise and logical operators only work on integer values. If you want to use floating-point values as boolean values, you need to explicitly convert them to integers (either via int(x) or round(x), or x==0.0, or abs(x)<1e-30, or whatever). > This doesn't seem to be described inside the docs, is it? > > When the if() function is described it only states its behaviour in case of > NULL, 0 or "otherwise" values. This isn't about the if() function. The bitand() function (to which the error message refers) corresponds to the bitwise-and operator "&". The if() function accepts either integer or floating-point values for its arguments. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Splitting a location across several disks
Dylan Beaudette wrote: > It has been a while, but glad to be back on GRASS-user. > > I am working on a project that involves a significant storage dilemma: try > and fit most of the files into a 500 Gb SSD for blazing-fast I/O, or fall > back to a standard but higher capacity disk drive. > > Would it be possible to store "derived" data into a mapset that is on > standard disk, while the "source" data reside in another mapset, stored on > the SSD? > > In other words, is it OK for a location to contain several mapsets that > don't "live" on the same physical disk. It seems like it should work (via > symlink), but I would like to see if there are any caveats that I should be > aware of. If symlinks don't work, Linux supports "mount --bind ...", which lets you mount a directory from an already-mounted filesystem at another location. Windows has similar features (e.g. reparse points), although I'm not that familiar with the specifics. The main constraint is that you can't split a single mapset across devices, as it must be possible to rename() files in the .tmp subdirectory to other directories withing the mapset, which requires that they are on the same physical partition (rename() only manipulates directory entries, it won't move the file's data blocks). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Migrating to a different database engines in Grass 7.0.1RC2
Paul Shapley wrote: > I would like to know why and where grass stores old database connection > parameters set with 'db.connect' and 'db.login'. this is not in the 'VAR' > file in the PERMANENT directory, I often switch between PostGIS and SQLite > data but even if i add a new connection it seems to retrieve a three year > old connection parameter and i dont want to keep having to create a new > 'mapset' every time i change. Should i go back to 6.4 stable or is there > another solution? Login information is kept in $HOME/.grass7/dblogin (Unix) or %APPDATA%/GRASS7/dblogin (Windows). Connection information (driver, database, table, key) is stored for each map, in the file ///vector//dbln. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] trimming color table
Paulo van Breugel wrote: > When creating a new map based on an existing using r.mapcalc, the color > table of the old map is used for the new map. However, if the new map > only contains a subset of the values of the old map, how can I trim the > color table so it only contains color definitions for the values present > in the new map? Any easy (automatic) way to do this? Note, this is > probably only useful for integer (category) maps. There isn't an automatic way to do this. The simplest way is probably along the lines of r.colors.out map | command | r.colors map rules=- where "command" is a grep/sed/etc command which filters the rules. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS-7svn: Specify wxPython Version
Rich Shepard wrote: >This situation appears related to generating some html. Does this >help indentifying the source of my problem? The manual page for a module normally involves running the module with the --html-description switch to get a list of its options. This ensures that the options listed in the manual page always reflect those actually supported by the module, without depending upon the documentation being updated manually. The g.gui.tplot script unconditionally imports core.giface, which imports core.utils, which imports core.globalvar, which calls CheckForWx() at the top-level. Consequently, any issues with the wxPython installation will cause the script to fail even when run only with e.g. the --help or --html-description options. As for why the wxPython check fails, I would assume that it's something specific to your particular installation. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS-7svn: Specify wxPython Version
Rich Shepard wrote: > > The wxPython version is handled by the CheckForWx() function in > > gui/wxpython/core/globalvar.py. The default is taken from the > > GRASS_WXVERSION environment variable if that's defined, otherwise it > > allows wxversion to select the version, subject to the constraint that the > > version must be at least 2.8.10.1. > > Glynn, > >The versions installed here are 2.8.12.1 and 3.0.2.0. I prefer to build > GRASS with the latter version. Having tried to specify the GRASS_WXVERSION > variable in various GRASS source files and exported from ~/.bash_profile > without successfully building tplot I would appreciate your suggestion where > that environment variable should be inserted. It's an environment variable. You can set environment variables within an existing shell session with e.g. export GRASS_WXVERSION=2.8-gtk2-unicode If you're using bash, you can set environment variables in ~/.bash_profile or ~/.bashrc or various other places, but those are only read when starting a new shell (~/.bash_profile is only read when starting a login shell); changing those file won't affect any existing shell sessions. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS-7svn: Specify wxPython Version
Rich Shepard wrote:
>I have two wxPython versions installed: -2.8.12.1 for one application (I
> forget which one requires this version) and -3.0.2.0 for applications I
> develop.
>
>In an application here the main module needs include these lines:
>
> import wxversion
> wxversion.select('3.0.2.0')
> import wx
>
>Because I don't want to change source code each time I suck down the
> latest from the subversion repository I'd like to specify this in the
> configuration file. However, while I see the option for specifying where to
> find wxWidgets I have not found how to specify the wxPython version, and
> this causes a fatal error when compiling.
The wxPython version is handled by the CheckForWx() function in
gui/wxpython/core/globalvar.py. The default is taken from the
GRASS_WXVERSION environment variable if that's defined, otherwise it
allows wxversion to select the version, subject to the constraint that
the version must be at least 2.8.10.1.
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] aspect map with azimuth values
Moritz Lennert wrote:
> > how can I convert aspect map's values to azimuth values?
> > or is there any way to create aspect map with azimuth values?
>
> I think this should work (but you should double check):
>
> if aspect <= 90, then azimuth = 90 - aspect
> else: azimuth = 450 - aspect
>
> i.e.
>
> r.mapcalc "azimuth_aspect = if(aspect <= 90, (90 - aspect), (450 -
> aspect))"
Or:
r.mapcalc "azimuth_aspect = (450 - aspect) % 360"
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with TRMM data and r.in.bin
Diana Brito wrote: > I'm trying to import the 3b42rt TRMM product by using r.in.bin. > > I've used the follow lines, > > r.inr.in.bin --o -f -h input=2001-1-1.bin output=2001-1-1 north=-16 > south=-57 east=50 west=76 cols=104 rows=197 > > but, always i got the follow error message: > > ADVERTENCIA: File Size 519968 ... Total Bytes 81952 r.in.bin reads raw binary input. E.g. the above command expects the file to contain 197*104*4 = 81952 bytes (197 rows by 104 columns by 4 bytes per value). According to this: http://www.eol.ucar.edu/projects/name/documentation/3B42RT_README The original 3B42RT data consists of a 2880-byte header followed by 3 arrays of 480 rows by 1440 columns, the first two being 2 bytes per value (for a total of 480*1440*2 = 1382400 bytes each) and the third being 1 byte per value (for a total of 480*1440 = 691200 bytes). But given the URL you're using: > url = "prod_id=3B42RT_daily&action=ASCII+Output" I wouldn't be surprised if the data is being converted to ASCII, in which case r.in.bin would be entirely the wrong tool to import it. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.external across Windows and Linux
Blumentrath, Stefan wrote: > Thanks for your reply. Here is a more detailed problem description: > > First I created a new and empty GRASS Location "test" on the network > storage (NFS) from the Linux Server. This GRASS DB is mounted on > LINUX (through mount.cifs) to `/home/stefan/R_raw_data/test'. On > Windows the "Network drive" is mapped to " R:\Raw_data\test " > > Within this Location I crated a mapset "linux" (from the Linux > Server) and a mapset "windows" from my Windows 7 workstation. > > 1st test case: Linux to Windows: > On the Linux server, and in the "linux" mapset I did: > > r.external.out --verbose directory="/home/stefan/R_raw_data/test" > extension=".tif" format="GTiff" > g.region -p n=1 s=0 e=1 w=0 res=0.1 > r.mapcalc expression="linux_map=1" > > On my Win 7 box I did: > > d.rast map= linux_map @linux > Here I got the following error message: > > Command 'd.rast map=linux_map@linux' failed > Details: ERROR 4: `/home/stefan/R_raw_data/test/linux_map.tif' does > not exist in the file system, and is not recognised as a supported > dataset name. > > Then I tried relative paths: > On Linux: > r.external.out --verbose directory="../../" extension=".tif" format="GTiff" > r.mapcalc expression="linux_map=1" --o > > Error message on Windows changes to: > Command 'd.rast map=linux_map@linux' failed > Details: ERROR 4: > `/home/stefan/R_raw_data/test/newLocation/linux/../..//linux_map.tif' > does not exist in the file system, and is not recognised as a > supported dataset name. Okay, so the issue is the use of absolute paths which may be incorrect if the database is accessed via a networked filesystem (or even a local filesystem if the mount point changes). Currently, if the directory given to r.external.out is relative (doesn't begin with a "/"), it's converted to an absolute path relative to the current mapset directory. Thereafter, any created maps will have the absolute path in their GDAL link (i.e. the cell_misc//gdal file). Thus, maps created with r.external.out can't be read if the database directory has "moved" relative to its location when the map was created. > Should I open a ticket in trac? Yes. We should at least support paths relative to the mapset, and may need additional options, e.g. the ability to use environment variables in paths). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.external across Windows and Linux
Blumentrath, Stefan wrote: > We are now about to move our GRASS DB to a network storage so it can > be accessed from both sides. When I created a test-DB on the network > storage I had trouble using external data (r.external.out). The > links to the data seem to be different between Linux and Windows... > > My question is: Is it in general possible to use external data > linked to a GRASS DB which is accessed both from Windows and Linux > boxes? Or is accessing one GRASS DB (or one mapset) both from > Windows and Linux a problem in general? It should work, but I don't know how much testing r.external.out has received, particlarly on Windows. If you can report specific details of any issues you've encountered, they will be looked into. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.vect: How to achieve transparency ?
"Peter Löwe" wrote: > is there a known way to render a vector layer on a GRASS monitor > (from the GRASS Shell, not through a GUI) with a level of > transparency, except for r.composite-based workarounds? Any solution > for either GRASS7.x or GRASS6.x would be welcomed. The display API doesn't support blending. The GUI implements layer transparency by rendering each layer to a separate image then specifying the opacity for each layer when the images for the individual layers are composited using g.pnmcomp. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] finding distance to raster features in a given direction
Nick Gauthier wrote: > Given a binary land/sea raster, I’m trying to calculate the shortest > distance from each land cell to the sea within a range of wind directions > (e.g. 85-95 degrees from north). The calculation is basically > r.grow.distance with an extra parameter for the range of directions (or a > raster of the input bearings at each cell) with which to restrict the > spreading function. > > I’d appreciated any advice on how to to implement something like this in > GRASS. If it was a specific angle (rather than a range), you could just rotate/shear the raster so that the desired direction was vertical, then calculate the vertical distance by accumulating along columns. If you wanted to enumerate cells within a given distance from the sea, you could use convolution via FFT. But this won't give you the distance itself (it would give you the number of sea cells within the upwind sector, which might be a reasonable approximation in some cases). Other thank that, I think that something like r.grow.distance could work. You'd first need to orient the data so that the central direction was vertical. I believe that you'd need to either: a) use a horizontal resolution significantly higher than the vertical resolution, so that the the half-angle was one "cell" in each direction, or b) consider N rows above at each step, rather than a single row, so that at least one row has multiple cells taken into account. The central idea is that the nearest upwind sea cell to any given land cell is also the nearest upwind sea cell for at least one of its upwind neighbors (essentially, the "is upwind of" relationship is transitive). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] can not install addons with g.extension
Robert Nuske wrote: > There is at least groff.py and html.py missing in the ubuntu package. > No idea about 'g.echo'. AFAIK, g.echo is only required on Windows, and only by the build system. From include/Make/Rules.make: ifneq ($(MINGW),) mkpath = $(shell $(TOOLSDIR)/g.echo$(EXE) $(1));$(2) else mkpath = $(1):$(2) endif Here, g.echo is used as a simple hack for converting filenames from MSys format to Windows' native format. MSys' shell converts filenames when passing them to an executable which isn't part of MSys; g.echo just writes its sole argument (which will already have been converted) to stdout. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] exit from grass after setting GRASS env variable
Moritz Lennert wrote: > > i have a very simple question but i'm not able find the simple answer. > > I'm following the procedure for Setting the GRASS environmental > > variables, <http://grasswiki.osgeo.org/wiki/GRASS_and_Shell>in the bash > > environment. > > Everything works grate and I'm able to access to all grass commands. > > My question is how I can exit from grass and return to the > > bash-with-nograss. > > You cannot "exit" GRASS as it is not an application by itself. If you do > not want to have access to the GRASS modules anymore, just unset your > environment variables. > > If you want to change your prompt, set PS1 to something else. Alternatively, you could just spawn a separate shell (with "bash") before setting any of the GRASS environment variables then terminate it (with "exit") when you're finished. A child process (normally) inherits its environment from its parent at start-up, but any changes to the child's environment won't affect the parent's. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] can not install addons with g.extension
Robert Nuske wrote: > > I have added py extension in `rules` file [1] and requested for the > > new build. Should be available in 10min. > > Thanks for the fix. > It already percolated into the ubuntu package grass70 > Version: 7.0.0+1svn64634~ubuntu14.04.1 > > > g.extension fails now because it can not find the html module. > > [...] > Traceback (most recent call last): > File "/usr/lib/grass70/tools/g.html2man.py", line 5, in > from html import HTMLParser, HTMLParseError > ImportError: No module named html > [...] It's in the tools directory (along with groff.py, which is also required). But the rules file doesn't appear to install those. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] can not install addons with g.extension
Martin Landa wrote: > 2015-02-09 18:34 GMT+01:00 Martin Landa : > > Right, `/usr/lib/grass70/tools/` contains `g.html2man`. This is > > probably related to the packaging, my local sample installation (make > > install from source code) contains `g.html2man.py` in the `tools` > > directory. > > it's here [1]. I am not sure why .py is removed (any Debian packager > expert here?) > > Martin > > [1] > http://bazaar.launchpad.net/~grass/grass/grass70_release_debian/view/head:/rules#L182 Maybe someone assumed that the rules for scripts applied? On platforms other than Windows, scripts are installed without the .py suffix. But g.html2man.py retains the suffix on all platforms; from Grass.make: HTML2MAN = VERSION_NUMBER=$(GRASS_VERSION_NUMBER) $(GISBASE)/tools/g.html2man.py -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] temporary files of grass.script.array
Johannes Radinger wrote:
> In GRASS 7 (RC1) python it is possible to export a raster map to an array
> which can be used e.g. by Numpy.
>
> For example:
>
> import grass.script.array as garray
> x1 = garray.array()
> x1.read("my_raster")
>
> It seems that this creates a temporary file in the .tmp folder of the
> respective
> location. I am not sure if this has been existing before, but these
> temporary
> files are not deleted after e.g. x1 is not used anymore (i.e. the
> calculation of
> the script finished). So do I need to manually (in the python script) close
> that x1 so
> that the associated temporary file gets deleted (and if yes how?)? Otherwise
> when using this procedure to do numpy calculations in loops the tmp-files
> pile up quite fast.
>
> Of course I can empty the tmp folder after every loop, but I am not sure
> if this is really the right way.
The temporary files were supposed to be deleted when the array object
was destroyed. However, this relied upon the ._close() method, which
is no longer used. r64426 (trunk) should fix this.
Apart from that, you can manually delete the temporary file for an
array object with e.g. grass.script.try_remove(x1.filename).
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] output values of r.composite
Markus Metz wrote: > On Wed, Jan 28, 2015 at 10:34 PM, Micha Silver wrote: > > When I use r.composite to create, i.e., a false_color composite from three > > Landsat bands, the RGB values in the composite are slightly different than > > the values in the original bands. Why is that? > > Because the number of levels to be used for each component is by > default 32, not 256 [0]. You can use levels=256 if you want 256 levels. But the resulting map will have a very large colour table (65536 rules), which will negatively affect the performance of anything which reads the colour table. Which is why the default is 32 levels rather than 256. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.out.file / d.save - Shell-script use issues
Vaclav Petras wrote: > > Could you choose a different prefix for these commands, and leave d.* > > for display commands? > > > > This also came to my mind but I had no better idea than `d` which is > actually pretty good since d.to.rast and d.out.file are saying the same as > r.to.vect or r.out.gdal (convert raster to vector, convert display to > raster, ...). > > If you think that only commands which are doing the actual drawing should > start with `d`, please be more specific. Not necessarily drawing, but commands which are in some way connected to the display system (rather than to e.g. wxGUI). So this would include e.g. d.info and d.where. > What about `d.mon` or > `d.what.rast`? Or what would be the right > letter to start with? These are both related to wxGUI, so probably gui.*. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] A question before I embark on a programming exercise
Moritz Lennert wrote: > r.mapcalc down_id = if(dir=1, id[1,1], if(dir=2, id[0,1], if(dir=3, > id[-1,1] etc r.mapcalc follows C expression syntax; "="is assignment, "==" is the equality test. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.out.file / d.save - Shell-script use issues
Vaclav Petras wrote: > I kindly ask command line users of d.* commands, especially those using d.* > commands in scripts, to test and participate in discussions concerning d.* > commands in GRASS GIS 7. For example, d.out.file was added (relatively) > lately to 7 and there is new command d.to.rast. They are designed to work > with wxGUI (including wx monitors). Could you choose a different prefix for these commands, and leave d.* for display commands? -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.out.file / d.save - Shell-script use issues
César Augusto Ramírez Franco wrote: > As far as I understand, d.out.file only works with X monitors, This appears to be the case, although I have no idea why. The basic operation of d.out.file is to run "d.save" to extract the list of commands used to generate the display, then replay those commands on a PNG/PS/cairo monitor. The functionality on which d.save relies isn't specific to a particular driver. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] mounting a read-only PERMANENT from remote server
Vaclav Petras wrote: > > > of disk space and where the file server is normally read-only for > > students. > > > We had recently similar issue. We had read-only GRASS location. > Unfortunately the client OS was MS Windows, so the nice trick with mounting > and symbolic link is not applicable. http://en.wikipedia.org/wiki/NTFS_reparse_point http://en.wikipedia.org/wiki/NTFS_symbolic_link -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Returning values to Python
Kevin Williams wrote: > Firstly I apologize if this is a duplicate, but I am not getting my > own posts emailed to me, and I don't see them in the list archive, so > I am using another email account. > > How does one return attribute values from a call to the 'r.what' > module running in a python script? > > When this query executes, it prints the result to the terminal, but I > need to get the value back in the script. > > One of the documentation pages mentioned a function "stdout2dict" from > "grass.pygrass.modules", but it does not look like this is in the > pygrass package any longer? If you use grass.script.raster_what(), it returns a list of dictionaries. AFAICT, PyGRASS requires you to add stdout_=PIPE, then you can get the output as a string from module.outputs["stdout"].value. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Null-value in grass python array
Johannes Radinger wrote:
> I am using the GRASS-numpy functionality [1] to read a python numpy.array
> from a GRASS raster map (GRASS7):
>
> import grass.script.array as garray
>
> a = garray.array()
>
> a.read(map)
>
> Here [2] it says that also the null value can be specified. So what is the
> actual null value in GRASS so that the raster map is correctly saved as
> numpy.array with numpy.nan where appropriate?
For integer maps, the null value is -2^31 = -2147483648. For
floating-point maps, the null value is NaN.
Note that the null= parameter for read() and write() specifies the
value in the numpy array which is mapped to/from null values in the
GRASS raster.
If you're using floating-point numpy arrays, then use
null=numpy.nan[1]. For integer arrays, using null=-2147483648 will
ensure that valid values don't collide with nulls.
[1] This assumes that atof() and sscanf("%lf") recognise "nan"; this
is the case on Linux, but doesn't appear to work on Windows.
> And a second related question: Does grass.script.array.read() respect an
> existing MASK so that areas that are masked will get numpy.nan? Of course
> this can
> also be done within numpy like map[numpy.isnan(mask)] but this again needs
> to properly define the nan value when reading the raster mask into an
> numpy.array.
read() and write() use r.out.bin and r.in.bin respectively. r.out.bin
respects the MASK.
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Gauss filter in r.neighbors
Martin Album Ytre-Eide wrote: > (maybe there is a problem in r.neighbors for grass 6.4.4?) Yes: Markus Metz wrote: > There is no problem with the Gaussian filter, but a problem with the > output map type of r.neighbours in G64: the output type is in G64 the > same like the input type, whereas in G7 the output type depends on the > chosen function. That means, if you use r.neighbours method=average in > G64 with a CELL map, the output is also CELL. If you need it to work with 6.x, convert the input to FCELL/DCELL first (with e.g. r.mapcalc "output = float(input)"). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.neighbors treating NULL values
Orr, Andrew B. wrote: > I'm trying to find a tool that will do the same thing as the > r.neighbors with a "sum cells" function, except that the tool has to > write a NULL value if a NULL is encountered within the cell "size" > that's specified. > > For example, if I have a raster: > > 3 2 3 > 42 > 1 2 3 > > where the center cell is a null, I would like the tool output to write > a NULL for the output when it passes over this part of the raster. > > As the tool is now, it seems that it treats it as a zero or simply > ignores it when "sum"ing the contents. > > Any ideas on how I could do this, or what tool I would use? Use r.neighbors method=count to count the number of non-null cells in the neighbourhood. size=3 # or whatever area=$((size * size)) r.neighbors in=map out=map.sum method=sum size=$size r.neighbors in=map out=map.count method=count size=$size r.mapcalc "result = if(map.count == $area, map.sum, null())" -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.neighbors selecting a random value from the window
Milton Ribeiro wrote:
> Given a moving window (maybe with r.neihbors), I need to select a random
> value which occurs within the window. Is there any function for this in
> grass?
No.
You could either modify r.neighbors, or use e.g. grass.script.array
(example script attached).
--
Glynn Clements
#!/usr/bin/env python
#%Module
#% description: Select a random cell from a moving window
#% keywords: raster
#%end
#%option G_OPT_R_INPUT
#%end
#%option G_OPT_R_OUTPUT
#%end
#%option
#% key: size
#% type: integer
#% required: yes
#% multiple: no
#% description: Size of window in raster cells
#%end
import numpy as np
import grass.script as grass
from grass.script.array import array
null = -0x8000
def main():
input = options['input']
output = options['output']
size = int(options['size'])
if size % 2 == 0:
grass.fatal(_("Window size must be odd"))
radius = (size - 1) / 2
src = array(dtype = np.int32)
src.read(input, null = null)
rows, cols = src.shape
orows = rows - size + 1
ocols = cols - size + 1
out = array(dtype = np.int32)
out[...] = null
dst = out[radius:-radius,radius:-radius]
ix = np.arange(ocols)
for row in xrange(orows):
dx,dy = np.random.randint(0, size, size=(2,ocols))
x = ix + dx
y = row + dy
dst[row,:] = src[y,x]
dst.write(output, null = null)
if __name__ == "__main__":
options, flags = grass.parser()
main()
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Gauss filter in r.neighbors
Martin Album Ytre-Eide wrote: > I am using the the r.neighbors function and I have an idea about > what the 'Gauss' parameter will do for me, but I can't find any > documentation for it. Experimenting with it, left me clueless. Using gauss= is equivalent to using weight= with a weights file corresponding to a Gaussian filter. The exact weights which are used can be found in the gaussian_weights() function in raster/r.neighbors/readweights.c. They are effectively: ncb.weights[i][j] = exp(-(x*x+y*y)/(2*sigma2))/(2*M_PI*sigma2); where x, y is the offset (in cells) from the centre of the neighbourhood and sigma2 is the square of the value passed to the gauss= option. > What I won't to do: > Apply a Gaussian weighting of cell neighbors and sum the values of > the neighbors. If all cells=1, I would get only 1's back. You need to use method=average to make the effective weights sum to one (when weights are used, method=average divides the weighted sum of the cell values by the sum of the weights). IIRC, the weights are such that they would sum to one if you had an infinitely-large neighbourhood, but the fact that you're cropping the curve to a finite neighbourhood means that the sum will always be less than one. The weights are determined by sigma alone, and are unaffected by the neighbourhood size. > I have a map of zeros and ones. I tried this: > > r.neighbors -c input='input_map' output='output_map' method=sum gauss=10 > size=33 > > The result is a map with only zeros. It works for me; e.g. $ r.mapcalc --o 'foo = rand(0,2)' seed=1 $ r.neighbors --o -c in=foo out=bar method=average size=33 gauss=10 $ r.info -r bar min=0.44217781042 max=0.568925311919939 $ r.neighbors --o -c in=foo out=bar method=sum size=33 gauss=10 $ r.info -r bar min=0.0985901293262625 max=0.449425795562072 $ r.mapcalc --o 'foo = 1' $ r.neighbors --o -c in=foo out=bar method=average size=33 gauss=10 $ r.info -r bar min=1 max=1 $ r.neighbors --o -c in=foo out=bar method=sum size=33 gauss=10 $ r.info -r bar min=0.221413499330273 max=0.812157275619236 -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] 64 bit Python in GRASS 6.4.2
Alex Mandel wrote: > The suggestion is that your reinstall GRASS using the OSGeo4w64 > installer. You likely used the OSGeo4w previously, which is a 32 bit > bundle of open source geo software. You can't just swap out the python > you have to get everything compiled for 64bit. FWIW, the grass.script library doesn't require that GRASS uses the same architecture (32-bit or 64-bit) as the Python interpreter. The grass.lib library (and grass.pygrass and grass.temporal, which use it) accesses the GRASS dynamic libraries from the Python interpreter, so the Python interpreter has to match the architecture for which GRASS was built. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch number of input limitation?
Markus Neteler wrote: > >> > GRASS 6.4.3 (wgs84pure):~/grassdata/import > r.patch in=$MAPS out=mosaic > >> > WARNING: Unable to open raster map > >> > ERROR: One or more input raster maps not found > ... > > Would it be possible to provide some possible reasons/suggestions in the > > error message? (the wording should be that it is "possible reason") > > Probably not. I think that the messages comes from a generic libgis or > librast function. In 7.x, G__open() will generate a warning message which includes strerror(errno) if the open() call fails. OTOH, 7.x requires twice as many descriptors per map, as it keeps both the cell (or fcell) and null files open, whereas 6.x closes the null file after reading each chunk. For modules which often open a large number of maps (e.g. r.patch, r.series), we could check the estimated number of open files against the result of sysconf(_SC_OPEN_MAX) (at least for Unix) and warn the user if the limit is likely to be exceeded. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] help with r.series
Rajat Nayak wrote:
> I have created a few list using g.mlist command in grass7. Each list has a
> few raster layers. For example; FILE2000 has lists of all monthly layers
> for the year 2000, FILE2001 has layers for 2001...so on.
> Now I want to create one layer each for each of these lists (each year). I
> can use "r.series" command with method="average", to get a layer with
> averaged values across all the months for a particular year. Now I have 14
> such lists corresponding to 14 years and do not want to repeat the process
> for each year. Is there a way to automate this process using grass prompt?
> I don't want to move to R, would like to complete all the work in GRASS.
bash:
for file in FILE20?? ; do
r.series file=$file output=output${file#file} method=average
done
Python:
import os
import grass.script as grass
for file in os.listdir('.'):
if not file.startswith('FILE20'):
continue
output = 'output' + file[4:]
grass.run_command('r.series', file=file, output=output,
method='average')
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r3.mapcalc / r.mapcalc: Logical Operators &&, || behave differently
"Peter Löwe" wrote: > Yet still I'm puzzled, as I hoped that type casting to INT would do the trick: > > r3.mapcalc l01i='int(l01)' > r3.mapcalc l02i='int(l02)' It appears that 3D volumes are always floating-point. So you would need to use e.g. r3.mapcalc "FOO3 = if((int(l01) || int(l02)),42,null())" or r3.mapcalc "FOO3 = if((l01 != 0 || l02 != 0),42,null())" -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r3.mapcalc / r.mapcalc: Logical Operators &&, || behave differently
"Peter Löwe" wrote: > for r3.mapcalc and r.mapcalc, there seems to be a difference > regarding the logical operators (&& ||, etc.): > > Assuming that two raster maps BAR and BAZ exist, the following > statement creates new map content FOO whenever BAZ and BAR are not > null: > > r.mapcalc FOO='if((BAZ && BAR),42,null())' Not quite. The result will be 42 if both BAZ and BAR are non-null and non-zero. If either are null or either are zero, the result will be null. Regarding &&: * A && B is null if either A or B are null, otherwise ... * A && B is zero if either A or B are zero, otherwise ... * A && B is one. Regarding if(): * if(A,B,C) is null if A is null, otherwise ... * if(A,B,C) is B if A is non-zero, otherwise ... * if(A,B,C) is C So if either BAZ or BAR are null, (BAZ && BAR) will be null and the if() function will evaluate to null regardless of its second and third arguments. If neither are null, then (BAZ && BAR) will be 0 if either BAZ or BAR are zero, and 1 if both are non-zero. > Doing the same with volumes (BAZ3, BAR3) results in an error message: > > r3.mapcalc FOO3='if((BAZ3 && BAR3),42,null())' FWIW, you should change the quoting to: r3.mapcalc 'FOO3 = if((BAZ3 && BAR3),42,null())' This will work in both 6.x and 7.x, whereas your original version will only work in 6.x (in 7.x, r.mapcalc/r3.mapcalc use the GRASS argument parser, so the expression musn't match the "option=value" syntax; adding spaces around the "=" avoids this issue). > => > > Incorrect argument types to function or() > Parse error > > Where's my mistake ? I suspect that either BAZ3 or BAR3 is a floating-point volume. The arguments to logical operators must be integers. Also, I don't see how you can get a reference to "or()" from an expression involving only "&&". -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.resamp.stats: how to count valid input pixels
peifer wrote: > I am trying to find a way to do "r.resamp.stats method=average" together > with some option like: "propagate NULLs, but only if >= 50% of the input > pixels are NULLs". > > I was hoping that some "method=countvalid" would perhaps exist, that would > generate a map which I could use to MASK unwanted/unreliable aggregation > results. But it doesn't. > > Any suggestions? Create a validity map with e.g. r.mapcalc "valid = !isnull(input)" then use r.resamp.stats method=average on that. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] turning grass.commands quiet
Martin Landa wrote: > > Is there a way of the grass commands not send any messages while running? > > yes, set up environmental variable GRASS_VERBOSE to 0, or -1 (also > error messages will suppressed in this case). In 6.x, errors and warnings are printed regardless of the GRASS_VERBOSE setting. > bash: > > export GRASS_VERBOSE=0 Alternatively: export GRASS_MESSAGE_FORMAT=silent will suppress all output, including warnings and errors (these will still be written to a logfile specified by $GIS_ERROR_LOG or to ~/GIS_ERROR_LOG if that file exists). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] About r.neighbors weight usage
m roy wrote: > i'm trying to use r.neighbors with the weight option along with the sum > function; > maibe i do not get how it's supposed to work... > > this is what i'm using: > > Neighborhood operation: sum > Neighborhood size: 3 > > Weight: > > 0 0 0 > -1 0 1 > 0 0 0 > > and i get a null result. You get a null result if the total number of values is zero. For a weighted sum, "the total number of values" is the sum of the weights, which in this case is zero. I'd suggest that r.mfilter may be more appropriate for implementing discrete convolution (FIR) filters. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] execGRASS("r.diversity"): [Error 3] Cannot find path specified \\.grass7\\r.li
[CC to grass-dev]
Sandra MacFadyen wrote:
> File "C:/Program Files (x86)/GRASS GIS 7.0.0beta2/scripts/r.diversity.py",
> line 116, in main
> os.mkdir(rlidir)
> WindowsError: [Error 3] The system cannot find the path specified:
> 'D:/Bands_processed1\\.grass7\\r.li'
r.diversity.py is broken on Windows:
home = os.path.expanduser('~')
rlidir = os.path.join(home, '.grass7', 'r.li')
The script tries to create an r.li subdirectory, but fails because the
parent directory doesn't exist.
$HOME/.grass7 is correct for Unix, but on Windows it's
%APPDATA%\GRASS7. From lib/init/grass.py:
# configuration directory
grass_env_file = None # see check_shell()
if sys.platform == 'win32':
grass_config_dirname = "GRASS7"
grass_config_dir = os.path.join(os.getenv('APPDATA'),
grass_config_dirname)
else:
grass_config_dirname = ".grass7"
grass_config_dir = os.path.join(os.getenv('HOME'), grass_config_dirname)
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS-7svn: Build Errors [RESOLVED]
Nikos Alexandris wrote:
> > Nikos,
> >
> > 1) wxpython-config specifies 2.7.5.
> >
> > 2) User error: I had neglected to run 'make clean' before building
> > the new
> > code. Normally, I do this immediately after 'make install'. Sigh.
>
> Nice to know that it works for you. Note, though, `make clean` !=
> `make distclean` but the latter includes the first one and is always
> "safer" in the sense that is also cleans all configuration instructions,
> created after `.configure`, which could also lead in to an erroneous
> future (re-)compilation attempt.
Just to clarify:
"make clean" deletes the files generated by compilation ("make"),
returning the source tree to the state it was in after running
"configure".
"make distclean" executes "make clean" and also deletes the files
generated by running "configure", returning the source tree to its
original state (although it won't remove files which were added by
means other than the GRASS configuration and build process).
Consequently,
make clean && configure ... && make
and
make distclean && configure ... && make
should be equivalent. Running "configure" overwrites the files which
"make distclean" would delete, so it doesn't really matter about
deleting them first.
Similarly,
make clean && make
and
make distclean && configure ... && make
should be equivalent, provided that the neither the configure script
nor its templates (Platform.make.in, config.h.in, etc) have changed,
the system's configuration hasn't changed, and configure is run with
the same arguments as the previous build.
"make distclean" (as opposed to "make clean") is only actually
required if you need to restore the source tree to its original state.
But it has the advantage of forcing you to run configure prior to the
next build, preventing you from accidentally using a stale
configuration (one which either doesn't account for any changes to the
configure script or its templates, or doesn't match your current
system configuration).
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] looping r.mapcalc in a shell script
rajatrn wrote:
> I have two layer lists, NDVIFILES and VIQALIST, both developed using g.mlist
> command in GRASS.
> Each file has 22 items in it. I would like to perform a simple raster
> calculation of the following form,
> Mask$NDVIFILES [i] = NDVIFILES[i] * VIQALIST[i]
> I'm unable to create a loop which can sequentially produce the required
> outputs.
> I will be grateful if anyone can help me with creating a loop using
> bash/shell script.
while read ndvi <&3 ; do
read viqa <&4
r.mapcalc "Mask$ndvi = $ndvi * $viqa"
done 3< NDVIFILES 4< VIQALIST
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] projection issue
Vincent Bain wrote: > I believed the nadgrid was a shifting matrix applying to ellipsoid > center (in cartesian geocentric coordinates). Does this mean > +nadgrids=@null implicitly tells cs2cs : keep the from-ellipsoid (ie > ignore the to-sphere), and shift it (of 0,0,0) ? +nadgrids=@null tells it not to perform any datum transformation. The default behaviour is to perform a matrix-based datum transformation based upon the source and destination datums. The nadgrids parameter overrides this. Normally, it is used to specify a data file containing the datum-transformed positions of a set of points; this allows for a more accurate transformation than a matrix-based transformation. nadgrids=@null is a "hack" which allows the datum transformation to be suppressed entirely. This is required when the lat/lon coordinates are based upon an ellipsoid but the cartographic transformation is based upon a sphere, as is the case for the Google Earth projection. Without that parameter, whatever ellipsoid was used for the cartographic transformation would also be used for the datum transformation. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.resamp.rst - ERROR: Input window changed while maps are open for read.
Markus Neteler wrote: > > the issue is still there. I get the same error message. Using the stable > > version of GRASS (6.4) is not an option for me since I am working with very > > large files (>2GB) for which this module returns the error described here > > <http://trac.osgeo.org/grass/ticket/1786> . > > The ticket reports on r.resamp.rst in GRASS 6. We cannot fix it there > easily since many libraries are involved (see ticket). > > Does the problem also exist in GRASS 7 for you? > You can install it in parallel to GRASS 6, see > http://grass.osgeo.org/download/software/linux/#grass70 In 6.x, the tempfile code in the RST library is limited to 2 GiB (ticket #1786). In 7.x, the RST library isn't working because it hasn't been updated for the new raster window handling (r40772 etc) (ticket #1718). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Optimized compiling of GRASS 7 for hydrological analysis on CentOS
Blumentrath, Stefan wrote: > We do not need a gui at all (as we won`t be able to access it on the > server anyway), and gui-modules are among those making trouble, can > we turn off compilation of gui modules? There shouldn't be any need to. If a module fails to compile, it won't affect the compilation of other modules (even without make's -k switch). In the worst case, you just some noise in the build output. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS7 r.mapcalc not working
César Augusto Ramírez Franco wrote: > I'm getting: > > syntax error, unexpected ',', expecting $end > Parse error > ERROR: parse error > > Everytime I try to do an "if(a,b,c)" statement like: > > "mapmask = if(mask1 && mask2, mask2, null())" FWIW, I have no problem running that exact command (having first generated random raster maps named "mask1" and "mask2"). Is this via wxGUI or the shell? -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS7 r.mapcalc not working
César Augusto Ramírez Franco wrote: > Is anyone having issues with r.mapcalc on grass7 r59245? The last change to the r.mapcalc code (as opposed to the HTML documentation) was 7 months ago (r57334), which fixed a typo in an error message. The last change to the grammar was 12 months ago (r55504), and that just implemented the error rule explicitly (rather than relying upon flex implementing it as an extension). First, I suggest ensuring that your working copy is clean, and re-compiling from scratch. If the issue persists, please provide a test case which uses one of the standard data sets (or an empty mapset). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] FYI - Output from compiling most recent release 7.0
Craig Aumann wrote: > Did it and attached! Apart from the TIFF errors discussed elsewhere, I see few warnings which indicates real errors. raster/r.statistics/o_sum.c: o_sum.c: In function ‘o_sum’: o_sum.c:47:5: warning: ‘stat’ is used uninitialized in this function [-Wuninitialized] imagery/i.segment/create_isegs.c. create_isegs.c: In function ‘calculate_shape’: create_isegs.c:965:14: warning: ‘pl1’ is used uninitialized in this function [-Wuninitialized] create_isegs.c:965:14: warning: ‘pl2’ is used uninitialized in this function [-Wuninitialized] create_isegs.c:967:17: warning: ‘n2’ is used uninitialized in this function [-Wuninitialized] create_isegs.c:967:17: warning: ‘n1’ is used uninitialized in this function [-Wuninitialized] create_isegs.c:967:31: warning: ‘s2’ is used uninitialized in this function [-Wuninitialized] create_isegs.c:967:31: warning: ‘s1’ is used uninitialized in this function [-Wuninitialized] create_isegs.c:968:17: warning: ‘e2’ is used uninitialized in this function [-Wuninitialized] create_isegs.c:968:17: warning: ‘e1’ is used uninitialized in this function [-Wuninitialized] create_isegs.c:968:31: warning: ‘w2’ is used uninitialized in this function [-Wuninitialized] create_isegs.c:968:31: warning: ‘w1’ is used uninitialized in this function [-Wuninitialized] create_isegs.c:983:11: warning: ‘count1’ is used uninitialized in this function [-Wuninitialized] create_isegs.c:983:11: warning: ‘count2’ is used uninitialized in this function [-Wuninitialized] The other -Wuninitialized warnings are all "may be used ...", which usually just indicates that they are conditionally initialised, and the compiler cannot be sure that they'll always be initialised in the cases where they're used (either because the logic is non-trivial or the usage is only safe when arguments have valid values). There are quite a few -Wformat warnings, most of which indicate real errors (mostly arising from assumptions that int, long, size_t and off_t are all 32-bit). The -Wformat-security warnings are mostly noise caused by the localisation macro. r57238 was supposed to have fixed this; I don't know why it hasn't. The -Wunused-variable warnings are probably harmless. Likewise for -Wpointer-sign. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] FYI - Output from compiling most recent release 7.0
Markus Neteler wrote: > To me it looks like that you have an outdated libtiff on your sytem. AFAICT, the problem is from trying to use an uninstalled libtiff: I note that the related compilation commands have -I/usr/src/tiff-4.0.3/build/include while the linking commands have -L/usr/src/tiff-4.0.3/build/lib That will be enough for building shared libraries which link against libtiff. But when it comes to building executables which use those libraries, you'll also need (I think) -Wl,-rpath-link,/usr/src/tiff-4.0.3/build/lib This can be added by modifying the value of TIFFLIB or TIFFLIBPATH in include/Make/Platform.make (or supplying the modified value via the make command line). Alternatively, setting LD_LIBRARY_PATH may work. But ideally you should see if there's an official TIFF package for your distribution and install that. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] FYI - Output from compiling most recent release 7.0
Craig Aumann wrote: > I include the output from compilation for the developers information. This > output is from > > make -j$threads 1>out.txt 2>err.txt & This is almost useless for developers as it disassociates the diagnostic messages from the commands which generate them. In future, I suggest using e.g.: make -j$threads >build.log 2>&1 -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] composite raster maps
Markus Metz wrote: > > I just realize I've used r.composite for ages without wondering how I > > could perform the reverse task. The thing is I ran r.composite on a 3 > > band geotiff orthoimage, dropped the initial .red, .green and .blue > > rasters, and I would need them now in order to run r.out.vtk with the > > rgbmaps argument. Dummy... > > You can use the # operator of r.mapcalc: > > r.mapcalc "map.red = r#map" > r.mapcalc "map.green = g#map" > r.mapcalc "map.blue = b#map" Note that GRASS 7 has the r.rgb script which does just this. Also, note that an r.composite+r.rgb round-trip normally loses accuracy. By default, the maps generated by r.composite only use 32 levels for each component (equivalent to a 15-bpp image). You can avoid this with "r.composite ... levels=256", but the resulting maps will have much larger colour tables (65536 rules rather than 1024), which can make certain operations significantly slower. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] About Matrix Weights
Luis Miguel Royo Perez wrote: > I hope someone can explain how works the option /"matrix weights" /of > the *r.neighbors* program. I've been trying to find out for myself but > I'm really confused. I've read the documentation but it's no clear for > me in this aspect. > > What I've trying to do to find out how works it the next: > > 1st I've created a random matrix 5x5 with values from 1-25 randomly > disposed. > 2nd I've done four different matrix, 0, 1, 5, 10, for all the values in > a 3x3 window, > > for the first one (0), all the values are NULL. > for the rest I have the same result... :S Why? > > I know i'm missing something, but I don't know what is it. I would > aprecciate some help in this point. The way that weights are used depends upon the specific aggregate (method) being used. However, most of the aggregates have the property that multiplying all of the weights by the same factor won't change the final result (an exception is method=count). Also, most (if not all) of them have the properties that an integer weight of N is equivalent to N occurrences of the cell value, and having all weights equal to one produces the same result as when weights are not used. When weights are used, the calculation for method=average is: sum(w[i]*x[i]) / sum(w[i]) In the case where all weights are zero, this will end up with both the numerator and denominator to zero, which produces a null result. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Permission denied to access a mapset in Linux
António Rocha wrote: > I have a Location and Mapset in a folder in Linux Server that was > created by me and I runned some scripts and created some maps etc. I > have a colleague that is trying enter in the mapset and it gets > Permission Denied. How can I allow her to access the mapset without any > problems? You can "access" any mapset provided that you have the relevant permissions (read permission for files, read and execute permission for directories). GRASS won't allow you to select a mapset as the current mapset unless you are the owner of the mapset directory. If you just need to access maps from a particular mapset, you can add the mapset to the search path with g.mapset, or reference maps using fully-qualified names (map@mapset format). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Trying to reclassify raster using non-linear functions in GRASS
Gabriel Zorello Laporta wrote: > I am using ArcInfo Workstation and Grid in order to to produce Gaussian > functions of elevation from a DEM with minimum value at 800m, as follow: > > elev_x800 = elev90 - 800 > elev_x800sq = pow(elev_x800, 2) > elev_x800sqn = -1 * elev_x800sq > elev_x800sqnd = elev_x800sqn / 50 > elev_x800exp = exp(elev_x800sqnd) > elev_x800gaus = elev_x800exp * 0.000798 > elev_x800gi = (elev_x800gaus * -11330) + 10.044 > > I was wondering how to apply that in GRASS (because I want to move towards > Open Software). Can you help me? You should be able to use those exact same expressions in r.mapcalc, e.g. r.mapcalc < ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] g7 svn58117 r.random ERROR: There aren't [n] non-NULL cells in the current region
Eric Goddard wrote: > Some additional info: When I run r.random with the -i flag, I get the > following results: > r.random -i input=land_cover_classification@PERMANENT n=1000 > vector_output=accuraccy_assessment_random > Collecting Stats... > Raster: land_cover_classification@PERMANENT > Cover: (null) > Cell Count: -75090892 > Null Cells: 2130552315 > > A negative cell count? hmmm Try r58118. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How GRASS loads raster images into memory?
Andranik Hayrapetyan wrote: > I would like to understand how GRASS loads raster images into memory to > perform calculations on them. > Does it load the entire image into memory and only then do the calculation > on them, or it loads image into memory by portions sequentially? The lowest-level read operation reads a specific row into memory. The lowest-level write operation writes the next row from memory. IOW, rows can be read in any order but must be written sequentially. The native GRASS raster format includes a row index, so that rows can be read out of order, and rows which aren't read can be skipped over. Modules which need more than one row at a time typically maintain a sliding window of consecutive rows. This may be done using the rowio library or within the application code. Modules which have non-sequential access patterns (e.g. r.proj) typically create a temporary copy in a format which is more suited to random access. This may be done using the segment library or within the application code. A few modules (e.g. i.fft) read the entire map into contiguous memory. This is typically restricted to modules where use of a tile cache isn't practical and/or the algorithmic complexity is such that the processing time would become a problem before the memory consumption does. > Or may be this depends on specific module? > In particular I am interested in 2 modules: *r.mapcalc* and *r.patch*. r.patch just uses row-by-row access. r.mapcalc uses the rowio library if the expression uses a neighbourhood modifier with a vertical component, otherwise it just uses row-by-row access. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] access denied to MAPSET in linux
António Rocha wrote: > I'm tryging to access a Location/mapset located in a folder (where I > have write/execute/read permission) but the mapset and location were not > created by me. When I run grass I get permission denied. How can I get > access or how can the original user of the mapset can give access > permission to other users? In order to select a mapset as the current mapset (where new maps are stored), the user must be the owner of the mapset directory. Write permission is not sufficient. You can access maps in any mapset for which you have the necessary permissions, i.e. read permission on files, read and execute permissions on directories. Maps in a mapset other than the current mapset can be accessed using the map@mapset syntax, or by adding the other mapset(s) to the mapset search path using g.mapsets. If you want to "take over" an existing location or mapset, you can change the owner with "chown" if you have root access. If you don't have root access but have write permission on the directory and all subdirectories, you can create a copy (which you will own) then delete the original and rename the copy. If you have write permission on the mapset directory but lack write permission on any non-empty subdirectories, you can still make a copy (and rename both the original and the copy) but you will not be able to delete the original directory. One of the main reasons why GRASS implements the ownership check is to prevent users from trying to create group-writable mapsets and encountering this situation. In the latest SVN versions, the ownership check can be suppressed, but this is only intended as workaround for single-user systems with "foreign" filesystems (e.g. FAT) which don't have ownership information. It is not safe on a multi-user system. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Filtering high "outliers" in Landsat reflectance imagery?
Eric Goddard wrote: > OK, I discovered what was different between my work and home machines. > The mapcalc if statement doesn't evaluate properly if using > r.external.out. If r.external isn't used, it evaluates correctly. Bug? Yes. A bug was introduced in r38127 which (by sheer coincidence) only affects floating-point GDAL output (and primarily affects double-precision GDAL output). For FCELL, zeros will be mapped to null; for DCELL, any value where the bottom 32 bits are zero (which includes all small integers) will be mapped to null. This should be fixed by r57414. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Filtering high "outliers" in Landsat reflectance imagery?
Eric Goddard wrote: > OK, I discovered what was different between my work and home machines. > The mapcalc if statement doesn't evaluate properly if using > r.external.out. If r.external isn't used, it evaluates correctly. Bug? What parameters are you using for r.external.out? -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Filtering high "outliers" in Landsat reflectance imagery?
Eric Goddard wrote:
> Hi, I need to do the same thing to some WV-2 imagery. I'm using the command
>
> grass.mapcalc("$output = if($input_rast>1.0, 1.0, $input_rast)",
> output=wv2_out, input_rast=wv2_in)
>
> from python (input and output names
> changed for simplicity) but instead of replacing the values greater
> than 1 with 1, it replaces them with NaNs. Is there something wrong
> with my mapcalc expession?
No.
Is there anything unusual about the actual map names? Names containing
any of the characters
^ # ( ) [ ] + - % > < ! & | ? : ; ~
need to quoted.
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Possible to switch off permissions check of mapsets?
Michel Wortmann wrote: > And straight on to another question: > Is there a way of switching of the permissions check when opening a > mapset? It prevents me from opening mapsets that are mounted on > different filesystems as the grass installation. E.g. if I try to open a > mapset located on a remote directory (mounted using fuse) in my local > Ubuntu grass6.4 version fails with: > > ERROR: MAPSET PERMANENT - permission denied > > Any solution to this would be much appreciated. In any of the current SVN versions, setting the environment variable GRASS_SKIP_MAPSET_OWNER_CHECK to any non-empty string will suppress the check. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass7- problems caompiling
António M. Rodrigues wrote: > if run without sudo, returns: > ./configure: 621: ./configure: cannot create ./config.log: Permission denied sudo chown -R yourusername /usr/local/src/grass7_trunk > Am I missing something really simple? IF so, sorry, but could someone help? You need write permission on the source tree. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] result from g.copy when layer exists
Rainer M Krug wrote: > I am a bit irritated, ut maybe I don't dee the reasoning behind this:' > > , > | RASS 7.0.svn (grass):~ > g.copy rast=MASK,tmp > | WARNING: already exists > | [Raster MASK present] > | GRASS 7.0.svn (grass):~ > > ` > > If the layer already exists, shouldn't the command give actually an > error and not only a warning? > > A warning implies for me that the command worked, but maybe something > unexpected could have happened (or happened) - but this one clearly did > not work, as the layer has not been copied? In GRASS, errors are fatal; the program will be terminated as soon as the error message has been printed. Each of g.copy's options accept an arbitray number of source+destination pairs, and the various options aren't mutually exclusive (e.g. a single invocation can copy both raster and vector maps). If it can't perform a particular copy for any reason, it generates a warning then moves on to the next item. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.mapcalc and the neighborhood modifier
Rainer M Krug wrote:
> I assume from that error message, that I can not supply a map go get the
> values for the neighborhood modifier, but have to use constant values.
Correct.
The main reason is that, like most GRASS raster modules, r.mapcalc
works row-by-row. For each input map, it records the minimum and
maximum row offset used in neighbourhood modifiers; it does this
before any maps are opened.
In theory, there's no reason why the column offset can't be an
arbitrary expression (or an index instead of an offset), but that
isn't currently supported.
Given how r.mapcalc works, it should be fairly simple to add a
function to allow unrestricted column indexing, e.g.
column(data, index) where both data and index are arbitrary
expressions.
Allowing the row offset to be an arbitrary expression would be
somewhat harder to implement (or to implement efficiently, at least),
as r.mapcalc would need to be able to fetch rows on-demand based upon
the results of calculations, and to know when each row was no longer
needed.
A more restricted form, where the row offset is simply the value taken
from a map would be more straightforward, as the code which determines
the range of offsets could examine the range of the map used for the
row offset. However, this would run the risk of feature creep, i.e. a
demand for extending the offset map to map+offset up to arbitrary
expressions involving maps and constants.
An alternative option would be to allow arbitrary expressions but with
explicit constant bounds.
However, while these options are viable, neither is exactly trivial.
> I could put these into if statements, but I wanted to avoid these if
> possible.
>
> Is there a way that I can use the offset from a map?
If the range of possible offsets is small (e.g. {-1,0,+1}), I'd go
with "if" statements.
Otherwise, you might want to look into using one of the Python APIs (I
think we have four now: grass.script, grass.script.array, grass.lib
and grass.pygrass).
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Python script
Pedro Camargo wrote:
> I'm trying to use r.stats via the python shell inside GRASS but I'm
> getting an error that I do not know how to solve. The code I'm using is
> this:
>
> grass.run_command('r.stats',input=inp,output='D:\\CropScape\\2012_cdls\\AZ.c
> sv',flags = 'ani')
>
> I already tried the following variables for input:
>
> inp=['AZ','COUNTIES']
> inp=['AZ@PERMANENT ','COUNTIES@PERMANENT']
Either of these should work, provided that you actually have maps with
those names in the PERMANENT mapset.
> inp=['D:\\CropScape\\2012_cdls\\AZ.tif',
> 'D:\\CropScape\\Counties\\COUNTIES.tif']
The inputs must be map names, not filenames.
Have you actually created the maps? You cannot use an image file as a
map without first either importing it (with e.g. r.in.gdal) or linking
it (with r.external).
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] handling raster resolution with r.reclass
Chiara Scaini wrote: > while using r.reclass, the output raster has a lower resolution that > the initial one. this parameter does not seem to be customizable. A reclass map always has the same bounds and resolution as its base map. It cannot be otherwise, as a reclass map is simply a table listing the mapping between categories. However, with few exceptions, GRASS modules which read raster maps automatically resample them to the current region. See the g.region manual page for details on displaying and changing the current region. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Suggestion for creating a script to create a map of agricultural capacity
Hamish wrote: > > But for this specific case, it's probably simpler to just > > generate an integer version of the slope map (if it isn't > > already) and use r.reclass, e.g. > > > > r.reclass input=slope output=slope.reclass rules=- < > 0 thru 2 = 1 > > 3 thru 5 = 2 > > 6 thru 10 = 3 > > 11 thru 15 = 4 > > 16 thru 45 = 5 > > 46 thru 70 = 6 > > * = 7 > > EOF > > note that r.reclass can read floating point maps too, but > it's a bit buggy/weird, > https://trac.osgeo.org/grass/ticket/1525#comment:10 Right; r.reclass just generates the table, the actuall reclass is performed by lib/raster. If the base map is floating-point, it will be coerced to integer using its associated quantisation rules. Note that r.reclass doesn't pay any attention to the map's quantisation rules (even if it did, they could be changed between the reclass being created and being used, and the rules at the time of use would have effect). The buggy rounding code should probably be replaced with e.g. *v = (CELL) floor(fv + 0.5); or: *v = (CELL) ceil(fv - 0.5); or: *v = (CELL) (fv > 0 ? floor(fv + 0.5) : ceil(fv - 0.5)); These differ on whether values lying exactly on a 0.5 boundary are rounded toward positive infinity, toward negative infinity, or away from zero respectively. The last one mimics the behaviour of C99's round() function. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Suggestion for creating a script to create a map of agricultural capacity
Marcello Benigno wrote: > If you can help me also in this tip, I would be very grateful, I'm > reclassifying the slope as follows: > > r.mapcalc class_1 = 'if(slope <= 2.0, 1, null())' > r.mapcalc class_2 = 'if(2.0 < slope <= 5, 2, null())' > r.mapcalc class_3 = 'if(5 < slope <= 10, 3, null())' > r.mapcalc class_4 = 'if(10 < slope <= 15, 4, null())' > r.mapcalc class_5 = 'if(15 < slope <= 45, 5, null())' > r.mapcalc class_6 = 'if(45 < slope <= 70, 6, null())' > r.mapcalc class_7 = 'if(slope > 70, 7, null())' 1. Note that "a < b <= c" is wrong; you need to use "a < b && b <= c". 2. You could optimise the above by using a single r.mapcalc command, e.g. (assuming Unix shell syntax): r.mapcalc < 70, 7, null()) EOF This will generate all 7 output maps in one go, reading the input map only once (most r.mapcalc calculations spend more time reading and writing raster maps than performing calculations). 3. This: > r.mapcalc slope.reclass = class_1 + class_2 + class_3 + class_4 + class_5 + > class_6 + class_7 will result in an all-null map, as arithmetic operators return null if either input is null. Changing the "null()" with "0" in the calculation of the class_* maps would fix this, or you could just use r.patch instead of r.mapcalc. Sticking with r.mapcalc, it would be simpler (and more efficient) to generate the output map directly from the input, without generating any intermediate maps, e.g.: r.mapcalc < ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Getting Started with GRASS Python Scripts
Martin Lacayo wrote: > I think I have now figured out most of the answers to my question, but > I am still wondering about some file management. > > Is the following command a "normal" way to make a location with a > projection from a georeferenced file: > > g.proj -c georef=/home/user/raster.tif location=example Yes. > Is there a command to delete a location? No; just remove the directory. If the database is shared by multiple users, creating or deleting locations may require root privilege. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SOLVED: How to implement 2D lookup table?
Rainer M. Krug wrote: > >> Hmm - sounds interesting, but also for other purposes. But as the result > >> will be a raster map, I don't think this approach is usable here (unless > >> I can feed the numbers back into a raster map, i.e. the inverse of > >> r.stats -c) > > > > r.cross + r.reclass ? > > There is one aspect in r.cross which makes this approach quite > difficult to implement: the value of the result map layer can not easily > be traced back to the values of the two input layers: If you only have a small number of classes, you can just create the cross-product manually, e.g.: r.mapcalc 'result = ageClass * 10 + dc' So a category of 15 would be ageClass=1, dc=5. r.cross is more useful when the total number of pairs which actually occur is much fewer than the product of the numbers of categories, as it only creates a category for each combination which actually occurs, not for each potential combination. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] make error in grass7_trunk/man
Johannes Radinger wrote:
> Thank you for that answer. I am not sure if I am
> able to understand the problem in all details resp. to solve the problem.
> So does these changes in the keywords-list (in the main.c?) involve lots of
> work or are just minor changes necessary?
>
> I am just asking as I want to use the r.fuzzy tool in GRASS7
> and need to adapt a single code line (in local_proto: #define STACKMAX 50
> (line 21))
> which makes a the selfcompilation necessary.
>
> So maybe it is possible to update the r.fuzzy tools to be successfully
> compiled
> with GRASS7.
AFAICT, it's just a case of replacing:
module->keywords = _("raster, fuzzy logic");
with:
G_add_keyword(_("raster"));
G_add_keyword(_("fuzzy logic"));
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Set raster value for specific cell
Paulo van Breugel wrote: > You can use r.mapcalc. If mymap is your raster layer and you want to > change the raster cell at coordinates 52deg and 10deg, use > > r.mapcalc "mymap = if(x()==52.0 && y()==10.00, 1, mymap)" --replace Comparing floating-point values with == is seldom a good idea. Instead: r.mapcalc "newmap = if(abs(x()-52.0)<0.001 && abs(y()-10.00)<0.001, 1, oldmap)" The above assumes that you already know the cell's centre coordinates to within the desired accuracy. If you want to set the cell containing a specific point, and be sure of setting exactly one cell when the point is on the boundary between cells: eval `g.region -g` r.mapcalc "newmap = if(row()-1 == int(($n-10.0)/$nsres) && col()-1 == int((52.0-$w)/$ewres), 1, oldmap)" This calculates the integer row/column indices for the desired cell then compares the current row/column to these. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] make error in grass7_trunk/man
Johannes Radinger wrote: > I just tried to build GRASS7 on Ubuntu with the r.stream.* and r.fuzzy > add-ons in the scripts-folder (the subdirs have been added to the makefile > in the scripts folder). > When running make I face a compilation error in the /man subfolder: > VERSION_NUMBER=7.0.svn VERSION_DATE=2013 python ./build_keywords.py > /usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/docs/html > Traceback (most recent call last): > File "./build_keywords.py", line 38, in > key = "%s%s" % (key[0].upper(), key[1:]) > IndexError: string index out of range > Any idea where to look for the problem? It appears that one of the HTML file has a keyword list which begins or ends with a comma. The KEYWORDS section is in the portion of the HTML file is generated by running the module with the --html-description flag. AFAICT, the problem is due to r.fuzzy.* not having been updated in response to r38061, which changed the "keywords" field of struct GModule from a single string (char*) to a list of strings (char**). Since that change, assigning a string to module->keywords is an error (although it will only result in a warning during compilation). Keywords must be set with either G_add_keyword() or G_set_keywords(). As a result, I'd expect those modules to crash when run with any of the options which output usage information (--help, --html-description, --interface-description, etc). This kind of "bit rot" is an inherent problem with having modules in a separate "add-ons" repository. FWIW, r38061 was made almost 4 years ago (2009-06-24). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ERROR: Bytes do not match file size with r.in.bin (but file size is correct!!)
kapo coulibaly wrote:
> You also want to check how the binary was written in FORTRAN. depending on
> the compiler and/or the access type fortran can write extra bytes before
> and after every record (they are called record marker).
That isn't his problem:
> r.in.bin -f input=inputfile.bin output=outputmap bytes=4
> n=51:05:20.4N s=41:21:50.4N w=5:08:31.2W e=9:33:36E r=19450
> c=29404 anull=-.0 --overwrite
...
> WARNING: File Size -2007336096 ... Total Bytes 2287631200
> ERROR: Bytes do not match file size 256
19450 * 29404 * 4 = 2287631200 = 2^32 - 2007336096
So the file is exactly the size it's supposed to be, it's just
overflowing the range of a 32-bit signed integer.
Upgrading is recommended, but in the absence of that, it would be
possible to split the file into two halves with dd, e.g.:
dd if=inputfile.bin of=file1.bin bs=117616 count=9725
dd if=inputfile.bin of=file2.bin bs=117616 count=9725 skip=9725
then import them separately and join them with r.patch, e.g.:
r.in.bin -f input=file1.bin output=map1 bytes=4 \
n=51:05:20.4N s=46:13:35.4N w=5:08:31.2W e=9:33:36E \
r=9725 c=29404 anull=-.0 --overwrite
r.in.bin -f input=file2.bin output=map2 bytes=4 \
n=46:13:35.4N s=41:21:50.4N w=5:08:31.2W e=9:33:36E \
r=9725 c=29404 anull=-.0 --overwrite
r.patch input=map1,map2 output=outputmap --overwrite
g.remove rast=map1,map2
rm file1.bin file2.bin
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Unix and Grass commands in Windows
Stephen Brearley wrote: > Just wondering how best to execute Unix and Grass commands using Grass > 6/7.0. I'm running Windows Vista, and had started installing Cygwin, but > this seems to be massive, and not even sure if this is the best environment, > as some users don't seem happy about it. I had initially thought I could use > the Console window, but this appears not to accept Unix commands. The console window doesn't recognise any commands; it's the shell which is run in it which executes commands. If you use the "Command Prompt" entry in the start menu, you'll get a console window running cmd.exe (largely backward-compatible with DOS). MSys and Cygwin each offer a version of bash, along with some utilities. Cygwin provides a higher degree of Unix compatibility, but is more heavyweight. MSys and Cygwin each include a terminal emulator (rxvt for MSys, mintty for Cygwin), and the corresponding icon uses this terminal emulator to run bash. However, either version of bash can be run in a Windows console window if that is preferred. > I also tried the included MySys Unix console which appears to be a > Bash shell, but this does not recognise Grass commands. GRASS commands are designed to be run inside of a GRASS "session". Essentially, this requires certain environment variables to be set (e.g. GISBASE must contain the path to the GRASS installation, GISRC must contain the path to a file containing certain settings, PATH must include the directories containing GRASS programs and DLLs). GRASS is supplied with a batch file which sets the various environment variables then starts a shell and/or a GUI. > >What would you recommend is the best option if I want to use Grass quite a > lot, but don't want to convert my PC to a fully fledged Linux system (unless > that really is the best option, such as using an emulator). GRASS 7 should run "natively" on Windows, i.e. it shouldn't require bash or any Unix utilities. GRASS 6.x requires bash and standard utilities in order to run various shell scripts (these have been converted to Python in GRASS 7). The Cygwin version should only be used if you particularly want a Unix environment but only have a Windows system. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [GRASS-dev] Using r.quantile result with r.recode
Paulo van Breugel wrote: > > r.recode will treat boundary values as belonging to the upper range, > > e.g. in the above example, 6.0 will get recoded to 2. > > > > This behaviour stems from Rast_fpreclass_get_cell_value() in > > lib/raster/fpreclass.c, and isn't configurable (i.e. there's no way > > that r.recode's behaviour could be modified without modifying the > > fpreclass functions). > > Unless I missed it, this does not seem to be mentioned explicitly in the > r.recode help file. Would it be an idea to add this? Actually, it's more accurate to say that r.recode uses the last range specified (which isn't necessarily the upper range). More generally, r.recode doesn't care if ranges overlap. It just stores the rules in the order they are given, and performs a lookup by iterating over the rules from last to first until it finds a match. The fpreclass code has a function to reverse the order of rules, but nothing uses it. Apart from the lack of clarity regarding boundary values, the existing method is inefficient if the number of rules is large; a binary search tree (or similar) would be better. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Using r.quantile result with r.recode
Pedro Venâncio wrote: > > r.recode will treat boundary values as belonging to the upper range, > > e.g. in the above example, 6.0 will get recoded to 2. > > > So we can not use directly the result of r.quantile with -r flag in r.recode, > right? > > In the example, 6 should be recoded to 1, right? For real data, most of the boundary values won't be actual values from the input data, but values derived from interpolating two adjacent values. In that situation, it doesn't matter how r.recode handles boundary values. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Using r.quantile result with r.recode
[CC to grass-dev for discussion] Pedro Venâncio wrote: > Thank you very much for your answer! > > My question lies precisely in the need to know if a quantile value > which falls as the upper limit for one range and the lower limit of > the next, should belong to the class anterior or posterior. > > > For example, assuming that r.quantile (with -r flag) gives this result: > > 2:6:1 > 6:8:2 > 8:12:3 > 12:20:4 > 20:873:5 > > the value 6 should belong to the first class or second? r.recode will treat boundary values as belonging to the upper range, e.g. in the above example, 6.0 will get recoded to 2. This behaviour stems from Rast_fpreclass_get_cell_value() in lib/raster/fpreclass.c, and isn't configurable (i.e. there's no way that r.recode's behaviour could be modified without modifying the fpreclass functions). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Using r.quantile result with r.recode
Pedro Venâncio wrote: > I have a doubt about using the r.quantile output with r.recode. > > r.quantile returns the upper limit value corresponding to each > class, right? r.quantile calculates quantile values. If you use the -r flag, each value is used as the upper limit for one range and the lower limit of the next. The map's total range sets the lower limit of the first range and the upper limit of the last range. If the number of values is an exact multiple of the number of divisions (e.g. 4 for quantiles, 10 for deciles, etc), the quantile will be one of the input values, otherwise it will be linearly interpolated between two adjacent values. It's possible that there should be a -1 in the calculation; currently, if you calculate the deciles of the 100 distinct values 0-99 inclusive, the results will be 10,20,...,90, so the ranges will be 0-10,10-20,...,90-99. > But r.recode uses r.quantile result as closed interval in the lower > value and open interval in the upper value. r.recode does whatever the Rast_fpreclass_* functions do. Which is to scan the rules from highest to lowest and stop on the first match. So for a value which is on the boundary between ranges, the upper range will be chosen. > But this is not correct. According to quantiles method, the reclassification > should be as follows: > > ]2.00:6.00] -> 1 > ]6.00:8.00] -> 2 > ]8.00:12.00] -> 3 > ]12.00:20.00] -> 4 > ]20.00:872.727295] -> 5 > > or am I wrong? I think that if the number of values is an exact multiple of the number of divisions, r.quantile+r.recode should result in each range having exactly the same number of values. But I'm not sure whether it's r.quantile, r.recode[1] or both which need to be fixed. [1] More precisely, the Rast_fpreclass_* functions. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS-Python Script: Check if output already exists, overwrite
Johannes Radinger wrote:
> I would like to check if the file defined as output in a python script
> already exists and fire an error when it exists and the overwrite flag is
> not set. Furhtermore I'd like
> to check this already in the beginning before all calculations in the
> script are executed.
g.parser should do this automatically.
If an option has "new" in the gisprompt field, G_parser() checks that
either the file/map/etc doesn't exist or overwrite is enabled.
The only time you should need to do this manually is if an output name
isn't simply an option value (e.g. r.mapcalc's output maps are
specified in the expression, r.rgb takes an output "template" to which
it appends a .r/.g/.b suffix, etc).
> I thought about something like:
>
> output = options['output']
> if (grass.find_file(name = output, element = 'cell')['file'] and
> grass.read_command("g.gisenv", get = "GRASS_OVERWRITE")!=1):
> grass.fatal(_("Output file exists already, either change output
> name or set overwrite-flag"))
>
> but what is the correct way to get the information if the overwrite flag is
> set
> or not for that script? The GRASS-OVERWRITE variable is not set although
> the script is launched with --overwrite. So how to get this info?
The grass.script.overwrite() function returns True if overwrite is
enabled. Also, os.environ['GRASS_OVERWRITE'] will have been set to '1'
by grass.script.parser() so that the overwrite status propagates down
to any commands executed by the script.
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Python placeholder (%d) in stdin statement of db.execute
Johannes Radinger wrote:
> Thank you Hamish, including the option "input=-" in the python line (for
> GRASS7) solved the problem.
Why read the command from stdin rather than using sql=...? E.g.:
grass.write_command("db.execute", sql = "UPDATE my points SET prob=100")
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Transform Reclass Map into a real Raster Map (Modeler)
Luis Miguel Royo Perez wrote:
> i'm in a trouble, i would like transform a reclass map into a real
> raster map, but i don't know how to do.
>
> 1st.- I don't know if with tool /r.mapcalculator/ i can enter the
> expression
>
> */r.mapcalc raster_map=reclass_map/*
>
> I know i can enter mapcalc expressions into mapcalulator with *-e
> flag*, but i don't know how exactly do
> it.
>
> 2nd.-I don't know if there's another way to reach what i want.
r.resample input=reclass_map output=raster_map
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
