Moritz Lennert | 2 Jul 17:18 2015
Picon

what is the meaning of: "Error reading raster data for row 239 of <MASK>"

Hello,

When I run a script that loops over a long series of point data sets and 
then does a series of raster calculations based on these data sets, I 
sometimes get the following error:

ERROR: Error reading raster data for row 239 of <MASK>

Can someone explain what this means and how to debug this ?

Moritz
Pietro | 1 Jul 16:14 2015
Picon

Question on C API and GRASS raster/region

Dear devs,

I'm trying to clarify the behavior of the C API of grass concerning
the interaction between raster and region, since I'm more confortable
with Python, I've just open an ipython  interpreter inside a GRASS
session, the mapset is the North Carolina.

I've imported some libraries and define two function to make the process easier:

{{{
>>> %paste
from __future__ import print_function
import ctypes
import fnmatch
from pprint import pprint

import grass.lib.gis as libgis
import grass.lib.raster as libraster

def attributes(obj):
    return sorted(fnmatch.filter(dir(obj), '[!_]*'))

def struct2items(struct):
    struct = struct.contents if hasattr(struct, 'contents') else struct
    return [(attr, getattr(struct, attr)) for attr in attributes(struct)]
## -- End pasted text --
}}}

Let's start I create an empty region structure with:

(Continue reading)

Pietro | 1 Jul 06:42 2015
Picon

table with the parser standard options

Dear devs,

I was not able to find a table in the GRASS manual pages with a
summary of all the default options as define in
parser_standard_options.c (lib/gis/parser_standard_options.c).
Therefore I wrote a python command line tool to extract them from the
source and print/write to a file in CSV/HTML format.
Probably I should use regexp but I'm not good with them...

The command line tool is attached.

Some usage example are:

$ python2 options.py -t lib/gis/parser_standard_options.c -f csv -o
stadard_options.csv

The command line should be able also to download the source file
directly from a link but it works only partially.

I believe we should add the generated table somewhere in the manual docs.
Should I add this python script to grass_addons/tools?

What do you think?

Pietro
Attachment (options.py): application/octet-stream, 7464 bytes
_______________________________________________
grass-dev mailing list
(Continue reading)

Vaclav Petras | 1 Jul 04:36 2015
Picon

Parser checking output maps but not input maps

Hi,

is there some reason for GRASS parser not checking if the input map exists? It checks if the output map exists and if it it does it ends execution with an error.

Having this interface definition (full script attached):

#%option G_OPT_R_INPUT
#% key: elevation
#%end
#%option G_OPT_R_OUTPUT
#% key: aspect
#%end

I now get this:

$ r.mapcalc "aaa = 1"
$ g.list rast m=.
aaa
$ test_parser_inputs.py elevation=bbb aspect=aaa
ERROR: option <aspect>: <aaa> exists.
$ test_parser_inputs.py elevation=bbb aspect=ccc
('bbb', 'ccc') [i.e., no error]

But I would expect to get the error also in the second case:

$ test_parser_inputs.py elevation=bbb aspect=ccc
ERROR: option <elevation>: <bbb> doesn't exist.

Is there some advantage in checking the existence of the input maps and files manually?

Vaclav
Attachment (test_parser_inputs.py): text/x-python, 591 bytes
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Martin Landa | 29 Jun 14:06 2015
Picon

Re: GRASS 7.0.1

Hi,

2015-06-29 14:02 GMT+02:00 Helmut Kudrnovsky <alectoria <at> gmx.at>:
> unfortunately it doesn't work neither in trunk nor in relbranch7 for me on several win-boxes (vista, 7,8)
with german locale

AFAIU, relbr70 worked for you [1], so it means that r65462 broke it?
Could you try to remove this change in your local installation and
test it again?

Ma

[1] https://trac.osgeo.org/grass/ticket/2634#comment:3

--

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
Martin Landa | 29 Jun 12:44 2015
Picon

GRASS 7.0.1

Hi all,

it's two weeks that we released 7.0.1RC1. I don't see any blocker
issue on trac [1]. I would like to express my feeling to release 7.0.1
as it is now.

Martin

[1] https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&priority=blocker&priority=critical&milestone=7.0.1&milestone=7.0.0&group=type&order=priority

--

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
Matej Krejci | 28 Jun 22:44 2015
Picon

<GSoC 2015> <Improved metada for GRASS GIS> <week 5>

Hi,
this is my report for "Improved metadata for GRASS GIS" project.

1) What do I have completed this week?
  • During last week I
    • established pycsw server on localhost.
    • became familiar with usage of OWSLib csw library. 
    • started on designing client-side module based on OWSLib.
2) What am I going to achieve for next week?
  • Plan for next week is to implement class allowing connection to service(service info, “getCapabilities” response, add/delete service, edit service) and related GUI.
3) Is there any blocking issue?
  • no
Best,
Matej
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Rainer M Krug | 26 Jun 13:26 2015
Picon

For OS X: homebrew tap to install and test grass 7.1 from HEAD

Hi

This is for OS X.

I have created a homebrew [1] tap to make installing and testing of GRASS
7.1 (HEAD from svn) easier.

You can find it here:

https://github.com/rkrug/homebrew-experimental

It uses homebrew [1] and installs

1) homebrew
2) North Carolina sample data set 

The grass-71 recipe includes a test

,----
| brew test grass-71
`----

which uses the dataset to run unit tests as suggested by Vaclav (with
paths adjusted according to the location of the sample dataset as
installed using homebrew):

,----
|     ./bin.../grass71 ~/grassdata/nc_spm_08/PERMANENT/ \
|         --exec python -m grass.gunittest.main \
|         --location nc_spm_08 --location-type nc
`----

These are my first steps into homebrew - so please check the recipes and
let me know if something does not work (preferably via the issue tracker
if it is a bug so that nothing gets lost).

Hope this helps,

Rainer

Footnotes: 
[1]  http://brew.sh

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer <at> krugs.de

Skype:      RMkrug

PGP: 0x0F52F982
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Nikos Alexandris | 25 Jun 17:38 2015
Picon

Re: [GRASS-user] Error in pansharp tool: missing grass.script

* Vaclav Petras <wenzeslaus <at> gmail.com> [2015-06-25 09:58:47 -0400]:

> On Thu, Jun 25, 2015 at 3:41 AM, Moritz Lennert <
> mlennert <at> club.worldonline.be> wrote:
> 
> > On 24/06/15 15:09, Vaclav Petras wrote:
> >
> >> It seems like one. I think it might help, at least help to debug, if you
> >> replace "import grass.script as grass" by "import grass.script as
> >> gscript" and "grass." by "gscript.". I think this change should be done
> >> anyway in all source code.
> >>
> >
> > Could you explain your reasoning behind this ? IMHO, it should not make
> > any difference whether you use grass or gscript as the alias.
> 
> 
> Sure. First of all, this just look strange by default I believe:
> 
> import aaa.bbb as aaa
> 
> Why not
> 
> import aaa.bbb
> 
> or often appropriate
> 
> import aaa.bbb as bbb
> 
> or (my favorite)
> 
> import aaa.bbb as ab
> 
> or simple
> 
> import aaa
> 
> ?
> 
> Alias shouldn't create confusion which I think it creates.
> 
> After
> 
> import grass.script as grass
> 
> which of the following will work?
> 
> from grass import run_commad
> from grass import pygrass
> 
> The second line will work although in the following case it is the first
> line.
> 
> grass.run_command
> grass.pygrass
> 
> Sure, this is just how Python interprets the import statements, so if you
> know it, you are fine, but why should we make reading of the source code
> harder then necessary?

I prefer self-explained names in general.  Why make it hard to read the
code, for anyone who cares, anyway?

At this point I'd like too to stress the need for proper commenting and
documenting source code.  Many, if not most, scripts, are not easy to
read. There are simply too many short and not self-explained variable names,
and undocumented functions as well.

This is yet another bold ToDo in my list, at least for add-ons, once I
will have again the freedom and time to contribute.

> The current situation leads to cases like:
> 
> >>> import grass.script as grass
> >>> grass.run_command
> <function run_command at 0x7f185ed61500>
> 
> Fine.
> 
> >>> grass.script.run_command
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> AttributeError: 'module' object has no attribute 'script'
> 
> OK. We haven't imported grass.script in the proper way, so let's do it.
> 
> >>> import grass.script
> >>> grass.script.run_command
> <function run_command at 0x7f185ed61500>
> 
> Works.
> 
> >>> grass.run_command
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> AttributeError: 'module' object has no attribute 'run_command'
> 
> Does not work anymore.

Yep, but a scripter wouldn't want to repeat `grass.script.` everytime.
Would he?  I do agree with Vaclav, however, with a convention that is
not confusing.  And, at the same time, it is still practical.

Please, think of "inviting" new scripters with code that is easy and a
joy to study.

Nikos

> I think that broadly used
> 
> import grass.script as grass
> 
> is just a legacy from the first version of Python API where "grass.script"
> was the only package and thus it was just `grass`. Then new (sub-)packages
> were introduced, probably "grass.lib" which forced the former `grass` to be
> renamed/moved to `grass.script`. To avoid changing all calls of functions
> from `grass.run_command` to something else, `grass.script` was imported
> with alias `grass`. This then spread into new and user code because the
> code is (or hopefully was) the only documentation. The unfortunate part is
> that this was some very first version of the API which was never released
> as stable (official introduction of Python API is 7.0.0, it was just
> experimental and internal in 6.4) but it influenced the common practice
> which I think is not the best practice. At least, this is how I understand
> it.
> 
> I don't see a reason why to keep it when there is a better practice
> available. We should especially change it in GUI and parser's --script. I
> believe none of them are change of the API, so it can be done anytime. The
> code itself should be changed too, we are doing a lot of other non-crucial
> changes anyway. The benefit is better code as an example for users and
> easier maintenance because it is just more clear.
> 
> Well, that's what I think.
> 
> Vaclav
Markus Neteler | 24 Jun 09:06 2015

G7.0.svn: g.remove segfault

Hi,

to my surprise I managed to generate a segfault using g.remove:

GRASS 7.0.1svn (eu_laea):~ > g.list raster
pattern="modis_lst1km*.spring_warming"
modis_lst1km2003.spring_warming
modis_lst1km2004.spring_warming
modis_lst1km2005.spring_warming
modis_lst1km2006.spring_warming
modis_lst1km2007.spring_warming
modis_lst1km2008.spring_warming
modis_lst1km2009.spring_warming
modis_lst1km2010.spring_warming
modis_lst1km2011.spring_warming
modis_lst1km2012.spring_warming
modis_lst1km2013.spring_warming
modis_lst1km2014.spring_warming

GRASS 7.0.1svn (eu_laea):~ > g.remove raster
pattern="modis_lst1km*.spring_warming" -f
Removing raster <modis_lst1km2003.spring_warming>
*** buffer overflow detected ***: g.remove terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f4548c54a07]
/lib64/libc.so.6(+0x10bbd0)[0x7f4548c52bd0]
/lib64/libc.so.6(+0x10b0f9)[0x7f4548c520f9]
/lib64/libc.so.6(_IO_default_xsputn+0xbc)[0x7f4548bc04bc]
/lib64/libc.so.6(_IO_vfprintf+0x3939)[0x7f4548b91f49]
/lib64/libc.so.6(__vsprintf_chk+0x88)[0x7f4548c52188]
/lib64/libc.so.6(__sprintf_chk+0x7d)[0x7f4548c520dd]
/usr/local/grass-7.0.1svn/lib/libgrass_manage.7.0.1svn.so(M_do_remove+0x3bb)[0x7f4549671cfb]
g.remove(main+0x76a)[0x4022be]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f4548b68af5]
g.remove[0x4015c9]
======= Memory map: ========
00400000-00403000 r-xp 00000000 fd:00 275018341
  /usr/local/grass-7.0.1svn/bin/g.remove
00602000-00603000 r--p 00002000 fd:00 275018341
  /usr/local/grass-7.0.1svn/bin/g.remove

(gdb) bt
#0  0x00007ffff70e35e9 in raise () from /lib64/libc.so.6
#1  0x00007ffff70e4cf8 in abort () from /lib64/libc.so.6
#2  0x00007ffff7123dd7 in __libc_message () from /lib64/libc.so.6
#3  0x00007ffff71bba07 in __fortify_fail () from /lib64/libc.so.6
#4  0x00007ffff71b9bd0 in __chk_fail () from /lib64/libc.so.6
#5  0x00007ffff71b90f9 in _IO_str_chk_overflow () from /lib64/libc.so.6
#6  0x00007ffff71274bc in __GI__IO_default_xsputn () from /lib64/libc.so.6
#7  0x00007ffff70f8f49 in vfprintf () from /lib64/libc.so.6
#8  0x00007ffff71b9188 in __vsprintf_chk () from /lib64/libc.so.6
#9  0x00007ffff71b90dd in __sprintf_chk () from /lib64/libc.so.6
#10 0x00007ffff7bd8cfb in sprintf (__fmt=0x7ffff7bd95e6 "colr2/%s",
    __s=0x7fffffffc360
"colr2/modis_lst_reconstructed_europe_cooling_warmj\275\367\377\177")
    at /usr/include/bits/stdio2.h:33
#11 M_do_remove (n=n <at> entry=0, old=0x655f00
"modis_lst1km2005.spring_warming") at do_remove.c:102
#12 0x00000000004022be in main (argc=<optimized out>, argv=<optimized
out>) at main.c:250

g.version -r
GRASS 7.0.1svn (2015)
libgis Revision: 64733

uname -a
Linux giscluster.intra.ismaa.it 3.10.0-229.1.2.el7.x86_64 #1 SMP Thu
Mar 26 09:10:25 CDT 2015 x86_64 x86_64 x86_64 GNU/Linux

I'm travelling now, so no chance to test myself at time.

It seems to stumble over the color2 file.

Markus
Markus Neteler | 23 Jun 18:21 2015

Re: geo-eye1 in i.atcorr

Hi all,

thanks to Marco Vizzari (http://www.agr.unipg.it/vizzari/) we have now
Geoeye1 support in i.atcorr.

Submitted to trunk in r65518, please test.

thanks
Markus

Gmane