Re: [GRASS-dev] Python equivalent of piping results from one function to another

Dear Paulo, On Sun, Oct 18, 2015 at 8:03 PM, Paulo van Breugel wrote: > What would be the python equivalent of: > > r.category mymap | r.category mymap rules=- Let's split the problem in two step. First capture the output of a module (the python equivalent of bash

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed --+--- Reporter: sprice | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component:

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed --+--- Reporter: sprice | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component:

Re: [GRASS-dev] [GRASS GIS] #2762: more informative error messages in lib/rast/get_row.c

#2762: more informative error messages in lib/rast/get_row.c --+--- Reporter: dylan| Owner: grass-dev@… Type: enhancement | Status: new Priority: minor| Milestone: 7.1.0 Component: Raster |

Re: [GRASS-dev] [GRASS GIS] #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE

#2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE --+--- Reporter: neteler | Owner: grass-dev@… Type: enhancement | Status: new Priority: critical | Milestone: 7.1.0

[GRASS-dev] linking update for OS X - makefile help needed

To get GRASS working in the latest OS X, El Capitan/10.11, I believe the key is that the SIP security ignores DYLD_LIBRARY_PATH (an easy code injection method). So, library linking needs to be relative, with @loader_path and @executable_path. This change will still work on older OS X

Re: [GRASS-dev] Addons index page progress report

On Sat, Oct 17, 2015 at 12:04 AM, Vaclav Petras wrote: > Hi all, > > I've improved creation of the index page for addons r66518 so that the > description which goes to index is extracted from the text in Description > section when it is not available elsewhere. Great job -

Re: [GRASS-dev] t.list slow

Hi Radim, 2015-10-18 14:08 GMT+02:00 Radim Blazek : > On Sun, Oct 18, 2015 at 1:42 PM, Sören Gebbert > wrote: >> Hi Radim, >> the reason why t.list and many other t.* modules are "slow" is the >> initialization of the temporal framework.

Re: [GRASS-dev] t.list slow

Hi Radim, the reason why t.list and many other t.* modules are "slow" is the initialization of the temporal framework. Several background processes are started and the temporal databases are checked for each mapset in the mapset searchpath. You have to use the GRASS GIS temporal framework

Re: [GRASS-dev] odd behavior from t.register when loading from file and no "end date" is specified

Hi all, sorry for my late response. The documentation is unfortunately not clear about the use of "-i" flag, increment and text files. I will update this. The main idea is: The -i flag and the increment option will only work if a start time was defined at the command line (no end time!). In case

[GRASS-dev] t.list slow

Hi, I found t.list module to be quite slow, about 500ms. Simple "select * from strds_absolute_time;" takes about 8ms with sqlite3 or db.select. If I want to get list of more types for more mapsets (for example mapsets which are not in SEARCH_PATH) it takes seconds. Is there a chance to make it

Re: [GRASS-dev] t.list slow

On Sun, Oct 18, 2015 at 1:42 PM, Sören Gebbert wrote: > Hi Radim, > the reason why t.list and many other t.* modules are "slow" is the > initialization of the temporal framework. Several background processes > are started and the temporal databases are checked for

Re: [GRASS-dev] odd behavior from t.register when loading from file and no "end date" is specified

Hi, 2015-10-18 17:01 GMT+02:00 Markus Neteler : > On Sun, Oct 18, 2015 at 3:24 PM, Sören Gebbert > wrote: >> Hi all, >> sorry for my late response. >> >> The documentation is unfortunately not clear about the use of "-i" >> flag, increment and

Re: [GRASS-dev] odd behavior from t.register when loading from file and no "end date" is specified

Thank you Soeren, your notes are quite helpful. Along these lines, the new (to me) temporal framework in GRASS is great--it has made many routine analysis much more efficient, and, it has made many new types of analysis possible. Thank you and to others that have contributed to this work! I'll be

Re: [GRASS-dev] odd behavior from t.register when loading from file and no "end date" is specified

On Sun, Oct 18, 2015 at 3:24 PM, Sören Gebbert wrote: > Hi all, > sorry for my late response. > > The documentation is unfortunately not clear about the use of "-i" > flag, increment and text files. I will update this. > > The main idea is: > The -i flag and the

[GRASS-dev] [GRASS GIS] #2767: t.rast.univar: Add parallel and region specific computation

#2767: t.rast.univar: Add parallel and region specific computation +- Reporter: huhabla | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone:

[GRASS-dev] Python equivalent of piping results from one function to another

What would be the python equivalent of: r.category mymap | r.category mymap rules=- I have been looking at the pygrass interface , but I didn't understand things well enough to see how to proceed.

Re: [GRASS-dev] [GRASS GIS] #2762: more informative error messages in lib/rast/get_row.c

#2762: more informative error messages in lib/rast/get_row.c --+--- Reporter: dylan| Owner: grass-dev@… Type: enhancement | Status: new Priority: minor| Milestone: 7.1.0 Component: Raster |