Re: [GRASS-user] g.rename problem with Python

2016-11-07 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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?

2016-10-15 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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

2016-10-01 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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

2016-07-22 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.label utf8 possible?

2016-06-27 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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?

2016-05-05 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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?

2016-03-26 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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

2016-03-15 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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?

2016-03-11 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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?

2015-12-04 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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?

2015-12-04 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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?

2015-11-30 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] location/mapset naming restrictions

2015-11-30 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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

2015-11-01 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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

2015-10-22 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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

2015-10-21 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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

2015-10-21 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Parallel processes

2015-10-19 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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

2015-10-19 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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

2015-10-07 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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

2015-09-27 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] trimming color table

2015-09-18 Thread Glynn Clements

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 <gl...@gclements.plus.com>
___
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

2015-08-02 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2015-07-30 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2015-07-27 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2015-07-08 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2015-05-07 Thread Glynn Clements

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_dailyaction=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 gl...@gclements.plus.com
___
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

2015-04-21 Thread Glynn Clements

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/map/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 gl...@gclements.plus.com
___
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

2015-04-18 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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 ?

2015-03-14 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2015-03-03 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2015-02-20 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2015-02-20 Thread Glynn Clements

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_Shellin 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 gl...@gclements.plus.com
___
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

2015-02-17 Thread Glynn Clements

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 module
 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 gl...@gclements.plus.com
___
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

2015-02-13 Thread Glynn Clements

Martin Landa wrote:

 2015-02-09 18:34 GMT+01:00 Martin Landa landa.mar...@gmail.com:
  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 gl...@gclements.plus.com
___
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

2015-02-03 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2015-01-30 Thread Glynn Clements

Markus Metz wrote:

 On Wed, Jan 28, 2015 at 10:34 PM, Micha Silver mi...@arava.co.il 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 gl...@gclements.plus.com
___
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

2014-11-14 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-11-14 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-11-12 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-10-31 Thread Glynn Clements

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 gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Returning values to Python

2014-10-30 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-10-08 Thread Glynn Clements

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 suming 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 gl...@gclements.plus.com
___
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

2014-10-08 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-10-04 Thread Glynn Clements

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 gl...@gclements.plus.com

#!/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

2014-10-02 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-09-26 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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?

2014-09-24 Thread Glynn Clements

Markus Neteler wrote:

   GRASS 6.4.3 (wgs84pure):~/grassdata/import  r.patch in=$MAPS out=mosaic
   WARNING: Unable to open raster map ASTGTM2N31E096@seasdem2
   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 gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] help with r.series

2014-09-04 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-08-20 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-08-14 Thread Glynn Clements

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 gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] turning grass.commands quiet

2014-07-02 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-06-02 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-05-21 Thread Glynn Clements

[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 gl...@gclements.plus.com
___
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]

2014-05-12 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-04-03 Thread Glynn Clements

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 gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] projection issue

2014-03-26 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-03-18 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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.

2014-03-18 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-03-15 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-03-13 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-02-08 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2014-02-08 Thread Glynn Clements

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 gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] composite raster maps

2013-11-26 Thread Glynn Clements

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 gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] About Matrix Weights

2013-11-15 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-11-12 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-11-08 Thread Glynn Clements

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 EOF
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
EOF

The above will write out each step as a map; if you only need the
final result (elev_x800gi), you can omit all of the intermediate steps
and use e.g.:

r.mapcalc elev_x800gi = (exp(-((elev90 - 800)^2) / 50) * 0.000798 
* -11330) + 10.044

Or, if you want to keep the expressions in the above form but only
want the last one written out as a map, use eval(), e.g.:

r.mapcalc EOF
eval(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
EOF

-- 
Glynn Clements gl...@gclements.plus.com
___
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

2013-10-28 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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?

2013-08-17 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-08-07 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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?

2013-08-04 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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?

2013-08-03 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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?

2013-07-31 Thread Glynn Clements

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 gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] grass7- problems caompiling

2013-07-19 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-07-16 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-07-02 Thread Glynn Clements

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 gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Python script

2013-07-02 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-05-29 Thread Glynn Clements

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=- EOF
      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 gl...@gclements.plus.com
___
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

2013-05-28 Thread Glynn Clements

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 EOF
class_1 = if(slope = 2.0, 1, null())
class_2 = if(2.0  slope  slope = 5, 2, null())
class_3 = if(5  slope  slope = 10, 3, null())
class_4 = if(10  slope  slope = 15, 4, null())
class_5 = if(15  slope  slope = 45, 5, null())
class_6 = if(45  slope  slope = 70, 6, null())
class_7 = if(slope  slope  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 EOF
slope.reclass = \
if(slope = 2,  1,\
if(slope = 5,  2,\
if(slope = 10, 3,\
if(slope = 15, 4,\
if(slope = 45, 5,\
if(slope = 70, 6,\
7))
EOF

[The above could be written on one line, but splitting the expression
with backslash-newline improves legibility.]

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=- EOF
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

-- 
Glynn Clements gl...@gclements.plus.com
___
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?

2013-05-23 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-05-23 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-05-13 Thread Glynn Clements

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 module
 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 gl...@gclements.plus.com
___
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

2013-05-13 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-05-13 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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!!)

2013-05-10 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-04-21 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-04-18 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-04-17 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-04-16 Thread Glynn Clements

[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 gl...@gclements.plus.com
___
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

2013-04-15 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-04-11 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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

2013-04-11 Thread Glynn Clements

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 gl...@gclements.plus.com
___
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)

2013-04-10 Thread Glynn Clements

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 gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] [GRASS-dev] minimal wxPython version

2013-03-21 Thread Glynn Clements

kapo coulibaly wrote:

 How about sticking with shell?

Using the shell frequently results in scripts which don't work
reliably on Unix or at all on Windows. It's also a horrible language
for anything beyond the simplest tasks.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] minimal wxPython version

2013-03-21 Thread Glynn Clements

Anna Kratochvílová wrote:

 PS - There is a similar problem with Python version (required 2.4).
 Some interesting features start with 2.5 but usually we can live
 without it. Any opinions?

I see no reason to support 2.4, and at least one reason to require at
least 2.5 (the with statement).

Requiring 2.6 would allow us to start work on forward compatibility
with Python 3.x.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] r.resamp.rst error : Not enough disk space--cannot write files

2013-03-10 Thread Glynn Clements

bidon sanshuile wrote:

 I'm in an internship for a marine institute and try to calculate the 
 sandwaves migration rate.
 Everything was ok until today. I am confronted to a difficulty I cannot 
 manage.
 
 When I try to use the tool r.resamp.rst, it gives me as answer:
 
 r.resamp.rst input=map@PERMANENT ew_res=11 ns_res=11 pcurv=curv
 Processing all selected output files will require
 261320 bytes of disk space for temp files.
 Temporarily changing the region to desired resolution ...
 Changing back to the original region ...
 Percent complete:
 Not enough disk space--cannot write files
 Not enough disk space--cannot write files
 Not enough disk space--cannot write files
 Not enough disk space--cannot write files

This error message is generated if fwrite() fails for any reason.

 interpolate() failed
 dnorm in mainc after grid before out1= 12.961481
 ERROR: split_and_interpolate() failed
 
 I have 14GB left on my hard disk so I don't understand why they are saying me 
 that :/

What filesystem? FAT32 cannot support files larger than 4 GiB; NTFS
shouldn't have any problems.

 I tried to find solution, and I found some answers (e.g. here :
 http://lists.osgeo.org/pipermail/grass-dev/2005-April/018152.html)
 but I dont understand ^^ They speak about a ulimit -f function,
 but where should I write it ? It doesn't work in GRASS. I am on
 windows, maybe is that the problem.

ulimit is Unix-specific.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] error building recent grass-svn versions

2013-03-06 Thread Glynn Clements

Vincent Bain wrote:

 Perhaps I should downgrade (force older version) ffmpeg, to get in the
 first case of the if loop.
 Here's the result of ffmpeg --version on my box:
 
 ffmpeg version 0.7.15, Copyright (c) 2000-2013 the FFmpeg
 developers
   built on Feb 22 2013 07:18:58 with gcc 4.4.5
   configuration: --enable-libdc1394 --prefix=/usr
 --extra-cflags='-Wall -g ' --cc='ccache cc' --enable-shared
 --enable-libmp3lame --enable-gpl --enable-libvorbis
 --enable-pthreads --enable-libfaac --enable-libxvid
 --enable-postproc --enable-x11grab --enable-libgsm
 --enable-libtheora --enable-libopencore-amrnb
 --enable-libopencore-amrwb --enable-libx264 --enable-libspeex
 --enable-nonfree --disable-stripping --enable-avfilter
 --enable-libdirac --disable-decoder=libdirac
 --enable-libfreetype --enable-libschroedinger
 --disable-encoder=libschroedinger --enable-version3
 --enable-libopenjpeg --enable-libvpx --enable-librtmp
 --extra-libs=-lgcrypt --disable-altivec --disable-armv5te
 --disable-armv6 --disable-vis
   libavutil50. 43. 0 / 50. 43. 0
   libavcodec   52.123. 0 / 52.123. 0
   libavformat  52.111. 0 / 52.111. 0
   libavdevice  52.  5. 0 / 52.  5. 0
   libavfilter   1. 80. 0 /  1. 80. 0
   libswscale0. 14. 1 /  0. 14. 1
   libpostproc  51.  2. 0 / 51.  2. 0

It gets better; between URL_WRONLY and AVIO_FLAG_WRITE, there was also
AVIO_WRONLY.

https://github.com/FFmpeg/FFmpeg/commit/59d96941f0285a501989d5f2c9b69be0a1393ed5

To grass-dev: given the consistent instability of the ffmpeg API, we
might want to consider generating a warning if --with-ffmpeg is used.

Amongst the few users who actually need that flag, there might be
someone willing to put in the effort to figure out which version
corresponds to which API.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] error building recent grass-svn versions

2013-03-05 Thread Glynn Clements

Vincent Bain wrote:

 Thank you Glynn for your answer, I'll trim my configure command.
 If I ever need to output video, what is the minimum version of avcodec
 to build against ?

I don't know.

Actually, the OSGF library attempts to support older versions:

#if LIBAVFORMAT_VERSION_INT  AV_VERSION_INT(52, 100, 0)
if (url_fopen(oc-pb, filename, URL_WRONLY)  0) { 
#else
if (avio_open(oc-pb, filename, AVIO_FLAG_WRITE)  0) {
#endif

So it will use the old API for versions of libavformat prior to
52.100.0.

Presumably that version number should be higher; your error message
suggest that you're using a newer version but which doesn't define the
newer macro.

I have no idea how the package versions (e.g. 5:0.7.15-dmo1)
correspond to ffmpeg's internal version numbers. E.g. here I have
ffmpeg-0.10.3, which has:

Library Version Defined in header

libavutil   51.35.100   libavutil/avutil.h
libavformat 53.32.100   libavformat/version.h
libavcodec  53.61.100   libavcodec/version.h
libavdevice 53.4.100libavdevice/avdevice.h
libavfilter 2.61.100libavfilter/version.h

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] error building recent grass-svn versions

2013-03-04 Thread Glynn Clements

Vincent Bain wrote:

 gsd_img_mpeg.c:375: error: ‘AVIO_FLAG_WRITE’ undeclared (first
 use in this function)
 gsd_img_mpeg.c:375: error: (Each undeclared identifier is
 reported only once
 gsd_img_mpeg.c:375: error: for each function it appears in.)
 make: *** [OBJ.x86_64-unknown-linux-gnu/gsd_img_mpeg.o] Erreur 1
 
 The current version of libavformat-dev is 5:0.7.15-dmo1
 
 Can anyone help me with this issue ? should I try to force a more recent
 version of the lib, or is the problem somewhere else ?

If you don't need the ability to write video files, don't use
--with-ffmpeg.

Otherwise, you'll need a more recent version of the libraries.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Run a GRASS module from a custom module (C language)

2013-02-26 Thread Glynn Clements

José María Michia Roberts wrote:

 I'm still learning! I have found that a simple call to function
 system()  is enough. But I was curious to learn how to use fork /
 exec, and was a bit difficult for me.

Note that system() is rather error-prone if you need to be able to
pass variable parameters to the command, as you need to quote or
escape characters which are significant to the shell (of which there
are many).

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


  1   2   3   4   5   6   7   8   9   10   >