GRASS GIS | 20 Sep 20:14 2014

[GRASS GIS] #2428: r.external to accept gdal config options

#2428: r.external to accept gdal config options
-------------------------+--------------------------------------------------
 Reporter:  perrygeo     |       Owner:  grass-dev <at> …              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.1.0                    
Component:  Default      |     Version:  svn-trunk                
 Keywords:               |    Platform:  Unspecified              
      Cpu:  x86-64       |  
-------------------------+--------------------------------------------------
 When linking to an external GDAL raster source, it would be useful to pass
 GDAL configuration options (http://trac.osgeo.org/gdal/wiki/ConfigOptions)


 Consider this scenario: I need to specify a GDAL config option to read an
 NetCDF file correctly. I can specify `GDAL_NETCDF_BOTTOMUP=NO` as an
 environment variable which works for most cases but when using a
 multiprocessing approach to parallelization (as e.g. `t.aggregate` does)
 the newly spawned processes don't inherit the same environment and will
 fail.

 The solution might be for `r.external` to accept GDAL config options that
 can be applied regardless of the environment variables and can allow
 externally linked rasters to function properly across processes.

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2428>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
(Continue reading)

GRASS GIS | 19 Sep 23:56 2014

[GRASS GIS] #2427: r.cost doesn't finish on Windows

#2427: r.cost doesn't finish on Windows
-------------------------+--------------------------------------------------
 Reporter:  annakrat     |       Owner:  grass-dev <at> …              
     Type:  defect       |      Status:  new                      
 Priority:  major        |   Milestone:  7.0.0                    
Component:  Raster       |     Version:  svn-releasebranch70      
 Keywords:  r.cost       |    Platform:  MSWindows 8              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
 On Windows, r.cost doesn't finish, it keeps running and outputting
 progress over 100%. It seems that some loop is not finishing.

 How to test in nc_spm:
 {{{
 g.region swwake_30m -p
 v.to.rast roadsmajor out=roadsmajor use=val type=line
 r.mapcalc "area_one = 1"
 r.cost -k in=area_one output=dist_toroad start_rast=roadsmajor
 }}}

 On Linux, this seems to be running fine. When I try not to use -k on
 Windows, it finishes correctly. But the user who actually found this was
 trying to run it without -k and still it didn't work (but I can't confirm
 it).

--

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2427>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
(Continue reading)

GRASS GIS | 18 Sep 19:03 2014

[GRASS GIS] #2426: add r.surf.nnbathy to the core code of GRASS 7.1

#2426: add r.surf.nnbathy  to the core code of GRASS 7.1
-------------------------+--------------------------------------------------
 Reporter:  bhlevca      |       Owner:  grass-dev <at> …              
     Type:  enhancement  |      Status:  new                      
 Priority:  major        |   Milestone:  7.1.0                    
Component:  Addons       |     Version:  unspecified              
 Keywords:               |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
 I find this script much faster and gives better results that
 r.surf.contour.

 I am not sure if there are licensing problems with nnbathy
 (https://code.google.com/p/nn-c/) as it is a MIT license, but my
 understanding is that it should be possible.

 I recently copied manually the script from the Grass6 add on repositories
 into the scripts directory of the Grass7.1 installation directory. I also
 compiled nnbathy from the above sources.
 The Makefile in the grass7 addons did not work although I had the grass6
 addons installed in parallel. Probably that needs fixing as well as a
 temporary measure until nnbathy is properly integrated.


 It worked flawlessly in grass 7.1. The result of a 6000x 10000 nodes was
 given in less than one minute. The r.surf.contour gave me a worse result
 in 192 minutes! That's more than 3 hours and that happened only after I
 lowered the resolution from res=2 to res=6. With res=1 in the g.region the
 r.surf.contour did not advance at all after 2 hours so I had to cancel. In
 addition the quality is not so great from r.surf.contour, especially if
(Continue reading)

Vaclav Petras | 17 Sep 15:33 2014
Picon

v.overlay handles mapname <at> mapset in a wrong way

Hi,

it seems [1] that v.overlay cannot handle dot in mapset name which probably points to a wrong handling of mapset in a parameter.

Code (Python/Bash) to test this separately is welcome.
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Vaclav Petras | 17 Sep 15:22 2014
Picon

lib/python/pygrass/vector/testsuite/test_doctest.py SIGSEGV

Hi,

doctest for pygrass.vector are crashing with segmentation fault in Vect_gen_num_db_links() function.

I'm not sure in which location, perhaps all, perhaps the empty one. All are reporting missing maps:
Vaclav
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Luca Delucchi | 17 Sep 11:23 2014
Picon

running modules from python

Hi devs,

is there ant way to use run_command using as input command a string or
a list of strings?

thanks

--

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
GRASS GIS | 17 Sep 03:35 2014

[GRASS GIS] #2425: Import translation function instead of using a buildin

#2425: Import translation function instead of using a buildin
-----------------------------------------------------+----------------------
 Reporter:  wenzeslaus                               |       Owner:  grass-dev <at> …              
     Type:  task                                     |      Status:  new                      
 Priority:  normal                                   |   Milestone:  7.1.0                    
Component:  Translations                             |     Version:  svn-releasebranch70      
 Keywords:  python, underscore, _, gettext, doctest  |    Platform:  All                      
      Cpu:  Unspecified                              |  
-----------------------------------------------------+----------------------
 ''Here are my notes about this issue since I was forgetting about it.''

 On some occasions, some of GRASS functions does not work because of
 translation function (`_` - underscore). The problem occurs on some
 strange conditions and when you are using Python
 [https://docs.python.org/2/library/doctest.html doctest] which we are
 using more and more.

 There is already several workarounds in wxGUI and also testing framework
 as
 [wiki:GSoC/2014/TestingFrameworkForGRASS#Findingandrunningthetestmodules
 described here]:
 > `doctests` currently don't work with grass.script unless you call a
 [source:grass/trunk/gui/wxpython/core/toolboxes.py?rev=60218#L630 set of
 functions] to deal with function _ (underscore) because of installing
 translate function as buildin _ function while _ function is used also in
 doctest.

 Grep for function `do_doctest_gettext_workaround` to see definition and
 how it is used.

 I already did this change for wxGUI more then a year ago and it seems to
 work. It was necessary because there was some problem with not translated
 files and this was only way to fix it besides going against documentation.

 For now I don't know how `lib/python`, `scripts`, and `temporal` differs
 in translations, so this should be clarified before changing it.

 See comment:5:ticket:1739 for deep discussion of the topic.

 For wxGUI this was implemented in the r57219 and r57220 as a result of
 #1739 and other investigation.

 This might be a blocker for some solutions of #2142. The new method should
 be flexible allowing to obtain translations from two sources
 simultaneously.

 Basically, it is necessary to remove all occurrences of:

 {{{
 gettext.install('grasswxpy', os.path.join(os.getenv("GISBASE"), 'locale'),
 unicode = True)
 }}}

 By one code based on this line in some module:

 {{{
 _ = gettext.translation('grasswxpy', os.path.join(os.getenv("GISBASE"),
 'locale')).ugettext
 }}}

 The actual implementation must be more complicated
 (changeset:57220#file0).

 Then each file, depending on the name and placement of translation
 function, must import:
 {{{
 from grass.script.utils import _
 from grass.script.translations import _
 from grass.*.utils import _
 from grass.*.translations import _
 from grass.translations import _
 }}}

 Probably `grass.translations` is the best since in GUI a module inside
 some other package is creating dependencies (changeset:57219#file10,
 changeset:57219#file13).

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2425>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 17 Sep 00:39 2014

[GRASS GIS] #2424: PyGRASS does not work when GRASS is invoked from outside

#2424: PyGRASS  does not work when GRASS is invoked from outside
------------------------------------------------------+---------------------
 Reporter:  wenzeslaus                                |       Owner:  grass-dev <at> …              
     Type:  defect                                    |      Status:  new                      
 Priority:  normal                                    |   Milestone:  7.0.0                    
Component:  Python ctypes                             |     Version:  svn-trunk                
 Keywords:  installation, pygrass, temporal, scripts  |    Platform:  MSWindows 8              
      Cpu:  Unspecified                               |  
------------------------------------------------------+---------------------
 When one want to
 [http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly

 work with GRASS without starting it explicitly], it is possible to use
 `grass.script` but it is not possible to use `grass.pygrass`,
 `grass.temporal` and `grass.lib`.

 This might have been discussed on mailing already, anyway the reason is
 that the dynamic libraries are not accessible to the current process.

 Output on Linux:

 {{{
 Traceback (most recent call last):
   File "./run_grass_from_outside.py", line 62, in <module>
     from grass.pygrass import vector
   File "/opt/src/grass-trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/pygrass/__init__.py", line 7, in <module>
     import grass.lib.gis as _libgis
   File "/opt/src/grass-trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/lib/gis.py", line 23, in <module>
     _libs["grass_gis.7.1.svn"] = load_library("grass_gis.7.1.svn")
   File "/opt/src/grass-trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/lib/ctypes_loader.py", line 55, in load_library
     return self.load(path)
   File "/opt/src/grass-trunk/dist.x86_64-unknown-linux-
 gnu/etc/python/grass/lib/ctypes_loader.py", line 71, in load
     raise ImportError,e
 ImportError: libgrass_datetime.7.1.svn.so: cannot open shared object file:
 No such file or directory
 }}}

 Output on MS Windows:

 {{{
 Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Anaconda\lib\site-
 packages\spyderlib\widgets\externalshell\sitecustomize.py", line 523, in
 runfile
    execfile(filename, namespace)
  File "C:\Users\akratoc\test_grass_standalone.py", line 59, in <module>
    from grass.pygrass import vector
  File "C:\Program Files (x86)\GRASS GIS
 7.0.0beta3\etc\python\grass\pygrass\__init__.py", line 7, in <module>
    import grass.lib.gis as _libgis
  File "C:\Program Files (x86)\GRASS GIS
 7.0.0beta3\etc\python\grass\lib\gis.py", line 23, in <module>
    _libs["grass_gis.7.0.0beta3"] = load_library("grass_gis.7.0.0beta3")
  File "C:\Program Files (x86)\GRASS GIS
 7.0.0beta3\etc\python\grass\lib\ctypes_loader.py", line 55, in
 load_library
    return self.load(path)
  File "C:\Program Files (x86)\GRASS GIS
 7.0.0beta3\etc\python\grass\lib\ctypes_loader.py", line 221, in load
    return _WindowsLibrary(path)
  File "C:\Program Files (x86)\GRASS GIS
 7.0.0beta3\etc\python\grass\lib\ctypes_loader.py", line 207, in _init_
    self.cdll = ctypes.cdll.LoadLibrary(path)
  File "C:\Anaconda\lib\ctypes\__init__.py", line 443, in LoadLibrary
    return self._dlltype(name)
  File "C:\Anaconda\lib\ctypes\__init__.py", line 365, in _init_
    self._handle = _dlopen(self._name, mode)
 WindowsError: [Error 193] %1 is not a valid Win32 application
 }}}

 It is unfortunate that you even cannot import `grass.pygrass.modules`:

 {{{
 from grass.pygrass import modules
 }}}

 For Linux, we have to rely on decision of packagers and a user being able
 to manage `~/.bashrc` or environmental variables of the given process.

 For MS Windows, the solution would be to allow user to add the variables
 to the environment. It seems to me that it is "enough" to add path with
 dynamic libraries (`lib` and `extrabin`) and GRASS installation directory
 (the one with the `grass*.bat` file) to `PATH` and Python packages
 (`etc/python`) to `PYTHONPATH`.

 The solution is of course invasive but there is no other way. A lot of
 applications just do the same without worrying about consequences. We can
 try what Git for MS Windows is doing: giving a choice how git commands and
 other tools should be spread into the system (modify or not modify the
 `PATH`).

 The question of course is what should be the default.

 Other question is whether to add to the beginning or the end of `PATH` and
 `PYTHONPATH` variables.

 Also, there must be a warning (in MS Windows installer) that no other
 version of GRASS GIS will work.

 The same might apply to other OSGeo or related software. This is
 unfortunately unknown. I guess that this option cannot be available in
 OSGeo4W installer.

 I have no idea about Mac OS X. Which solution would be appropriate there?

 Do you have some other ideas how to solve or workaround this issue? Would
 it be possible to provide a script/functionality in GRASS GIS which would
 put the things to environmental variables and take it away if requested (I
 guess that the removal is necessary for standard installation too)? This
 could be much more flexible. This might be even applicable to all
 platforms although for MS Windows it would be quite different from Linux.


 Related:
  * #2333 (choose python interpreter during the GRASS installation on
 windows)

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2424>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 16 Sep 23:15 2014

[GRASS GIS] #2423: r.series.interp missing in wxGUI menu

#2423: r.series.interp missing in wxGUI menu
------------------------------------------+---------------------------------
 Reporter:  jbrauner                      |       Owner:  grass-dev <at> …              
     Type:  defect                        |      Status:  new                      
 Priority:  normal                        |   Milestone:  7.1.0                    
Component:  wxGUI                         |     Version:  svn-trunk                
 Keywords:  r.series.interp, wxGUI, menu  |    Platform:  All                      
      Cpu:  All                           |  
------------------------------------------+---------------------------------
 Hi devs,

 r.series.interp is missing in wxGUI menu.

 I created a patch (attached) to add it just below r.series in the Raster
 -> Overlay submenu as "Raster series interpolation". This is just a
 suggestion, feel free to place it anywhere else.

 Hopefully I've modified the correct toolboxes.xml -> newbie :).

 Cheers,

 Johannes

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2423>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Vaclav Petras | 16 Sep 20:13 2014
Picon

Re: [GRASS-SVN] r61998 - grass/trunk/lib/python/pygrass/messages


On Tue, Sep 16, 2014 at 12:40 PM, <svn_grass <at> osgeo.org> wrote:
messgae = message[:1999]

Is this a typo?
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Sören Gebbert | 16 Sep 19:15 2014

GRASS7.1 experimental temporal framework update

Dear all,
JFYI i have updated the temporal framework in grass7.1 trunk (last
commit is r62000) to support distributed temporal databases. The new
default behavior is that sqlite3 based temporal databases will be
created in the current mapset. The temporal framework takes care of
which mapset specific temporal database should be used for data
access. Existing locations with temporal databases should work as
usual.

However, at the moment this works only with sqlite3 databases. Using
several different postgresql database backends is untested. Mixing of
sqlite and postgresql temporal databases in a single location is not
possible.

Some API changes were necessary to implement maspet specific temporal
database management. I did not tested yet the temporal related GUI
modules and code.

Be aware that the temporal framework and the related modules in grass
trunk (7.1 svn version) are highly experimental and should not be used
in production.

The new approach limits the use of SQL where and order statements in
t.list. These statements will be performed for each temporal database,
but not for the output of all databases together.

Best regards
Soeren

Gmane