Re: [GRASS-dev] [GRASS GIS] #2352: Conflicting definitions of db__driver_describe_table

2015-11-09 Thread GRASS GIS 
#2352: Conflicting definitions of db__driver_describe_table
---+---
  Reporter:  hamish|  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  6.4.6
 Component:  Database  |Version:  6.4.3
Resolution:|   Keywords:  dbf driver, libdb
   CPU:  All   |   Platform:  All
---+---

Comment (by neteler):

 Travis-CI shows now some issues:


 {{{
 (cd /home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/lib; ln
 -f -s libgrass_dbmibase.7.1.svn.so /home/travis/build/GRASS-GIS/grass-
 ci/dist.x86_64-pc-linux-gnu/lib/libgrass_dbmibase.so)
 if [ "" != "" -a -f "".html ] ; then make html ; fi
 make[4]: Leaving directory `/home/travis/build/GRASS-GIS/grass-
 ci/lib/db/dbmi_base'
 make -C dbmi_client || echo /home/travis/build/GRASS-GIS/grass-
 ci/lib/db/dbmi_client >> /home/travis/build/GRASS-GIS/grass-ci/error.log
 make -C stubs || echo /home/travis/build/GRASS-GIS/grass-ci/lib/db/stubs
 >> /home/travis/build/GRASS-GIS/grass-ci/error.log
 make[4]: Entering directory `/home/travis/build/GRASS-GIS/grass-
 ci/lib/db/stubs'
 test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
 make[4]: Entering directory `/home/travis/build/GRASS-GIS/grass-
 ci/lib/db/dbmi_client'
 test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
 gcc  -g -O2  -fPIC  -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64
 -pc-linux-gnu/include -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64
 -pc-linux-gnu/include-DPACKAGE=\""grasslibs"\"   -I/home/travis/build
 /GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/include -I/home/travis/build
 /GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/include
 -DRELDIR=\"lib/db/stubs\" -o OBJ.x86_64-pc-linux-gnu/add_col.o -c
 add_col.c
 gcc  -g -O2  -fPIC  -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64
 -pc-linux-gnu/include -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64
 -pc-linux-gnu/include -I../dbmi_base -DPACKAGE=\""grasslibs"\"
 -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/include
 -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/include
 -DRELDIR=\"lib/db/dbmi_client\" -o OBJ.x86_64-pc-linux-gnu/c_add_col.o -c
 c_add_col.c
 add_col.c:2:27: fatal error: grass/dbstubs.h: No such file or directory
 compilation terminated.

 ...

 gcc  -g -O2  -fPIC  -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64
 -pc-linux-gnu/include -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64
 -pc-linux-gnu/include -I../dbmi_base -DPACKAGE=\""grasslibs"\"
 -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/include
 -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/include
 -DRELDIR=\"lib/db/dbmi_client\" -o OBJ.x86_64-pc-linux-
 gnu/c_list_drivers.o -c c_list_drivers.c
 d_error.c: In function ‘db_d_append_error’:
 d_error.c:78:11: warning: ignoring return value of ‘fread’, declared
 with attribute warn_unused_result [-Wunused-result]

 ...

 gcc  -g -O2  -fPIC  -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64
 -pc-linux-gnu/include -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64
 -pc-linux-gnu/include -I../dbmi_base -DPACKAGE=\""grasslibs"\"
 -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/include
 -I/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/include
 -DRELDIR=\"lib/db/dbmi_client\" -o OBJ.x86_64-pc-linux-gnu/select.o -c
 select.c
 gcc -shared -o /home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-
 gnu/lib/libgrass_dbmidriver.7.1.svn.so -L/home/travis/build/GRASS-GIS
 /grass-ci/dist.x86_64-pc-linux-gnu/lib -L/home/travis/build/GRASS-GIS
 /grass-ci/dist.x86_64-pc-linux-gnu/lib -Wl,--export-dynamic -Wl,-rpath-
 link,/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/lib
 -Wl,-soname,libgrass_dbmidriver.7.1.svn.so OBJ.x86_64-pc-linux-
 gnu/d_add_col.o OBJ.x86_64-pc-linux-gnu/d_bindupdate.o OBJ.x86_64-pc-
 linux-gnu/d_close_cur.o OBJ.x86_64-pc-linux-gnu/d_closedb.o OBJ.x86_64-pc-
 linux-gnu/d_createdb.o OBJ.x86_64-pc-linux-gnu/d_create_idx.o OBJ.x86_64
 -pc-linux-gnu/d_create_tab.o OBJ.x86_64-pc-linux-gnu/d_delete.o OBJ.x86_64
 -pc-linux-gnu/d_deletedb.o OBJ.x86_64-pc-linux-gnu/d_desc_table.o
 OBJ.x86_64-pc-linux-gnu/d_drop_col.o OBJ.x86_64-pc-linux-
 gnu/d_drop_index.o OBJ.x86_64-pc-linux-gnu/d_drop_tab.o OBJ.x86_64-pc-
 linux-gnu/d_error.o OBJ.x86_64-pc-linux-gnu/d_execute.o OBJ.x86_64-pc-
 linux-gnu/d_fetch.o OBJ.x86_64-pc-linux-gnu/d_finddb.o OBJ.x86_64-pc-
 linux-gnu/d_insert.o OBJ.x86_64-pc-linux-gnu/d_listdb.o OBJ.x86_64-pc-
 linux-gnu/d_list_idx.o OBJ.x86_64-pc-linux-gnu/d_list_tabs.o OBJ.x86_64
 -pc-linux-gnu/d_mkdir.o OBJ.x86_64-pc-linux-gnu/d_opendb.o OBJ.x86_64-pc-
 linux-gnu/d_openinsert.o OBJ.x86_64-pc-linux-gnu/d_openselect.o OBJ.x86_64
 -pc-linux-gnu/d_openupdate.o OBJ.x86_64-pc-linux-gnu/d_priv.o OBJ.x86_64
 -pc-linux-gnu/driver.o

Re: [GRASS-dev] [GRASS GIS] #2352: Conflicting definitions of db__driver_describe_table

2015-11-09 Thread GRASS GIS 
#2352: Conflicting definitions of db__driver_describe_table
---+---
  Reporter:  hamish|  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  6.4.6
 Component:  Database  |Version:  6.4.3
Resolution:|   Keywords:  dbf driver, libdb
   CPU:  All   |   Platform:  All
---+---

Comment (by neteler):

 The log file: https://s3.amazonaws.com/archive.travis-
 ci.org/jobs/90080323/log.txt

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.quantile not respecting region and mask

2015-11-09 Thread Anna Petrášová 
On Mon, Nov 9, 2015 at 9:11 AM, Paulo van Breugel 
wrote:

> Hi,
>
> Am I correct that r.quantile does not use/respect the region and mask? In
> the examples on the manual page (version 7.0 and 7.1) the region is first
> set to the input raster, which implies that the region settings do matter.
> No word on the mask in the manual page. In general, I would expect GRASS
> GIS functions to respect both the region and mask. If they do not, it might
> be a good idea to explicitly mention this in the manual page (as in most
> such cases is done I think)?
>
> Assuming that the above is no bug, would it be possible to add an option
> to have r.quantiles compute the quantiles respecting the region and mask?
>
> Regards,
>
> Paulo
>

Just quick test, but it seems to work for me, setting different region
changes results, as well setting mask. The actual values looked meaningful.
Could you provide a test case where it doesn't work?

Anna


> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.quantile not respecting region and mask

2015-11-09 Thread Paulo van Breugel 

Hi,

Am I correct that r.quantile does not use/respect the region and mask? 
In the examples on the manual page (version 7.0 and 7.1) the region is 
first set to the input raster, which implies that the region settings do 
matter. No word on the mask in the manual page. In general, I would 
expect GRASS GIS functions to respect both the region and mask. If they 
do not, it might be a good idea to explicitly mention this in the manual 
page (as in most such cases is done I think)?


Assuming that the above is no bug, would it be possible to add an option 
to have r.quantiles compute the quantiles respecting the region and mask?


Regards,

Paulo
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Return value from g.copy is one when --overwrite - bug or feature?

2015-11-09 Thread Huidae Cho 
r66775 adds a warning for non-vector elements as well.

On Mon, Nov 9, 2015 at 6:20 AM, Glynn Clements 
wrote:

>
> Markus Neteler wrote:
>
> > It should probably not silently fail.
> >
> > The code in question is in
> > lib/manage/do_copy.c
>
> M_do_copy() returns a status. g.copy's main() checks that and uses it
> to set the exit status, but it doesn't generate an error or warning if
> the status is non-zero.
>
> If G_recursive_copy() or M_do_copy() raised an error, that would
> result in the program aborting on the first error; at present, it
> copies as much as it can.
>
> Realistically, g.copy() should be generating the error at the bottom
> of main() if result is non-zero. E.g.
>
> -exit(result);
> +if (result)
> +G_fatal_error(...);
> +return 0;
>
> > and potentially there to be added strerror(errno) as for example in
> > lib/gis/mapset_msc.c
>
> That would require G_recursive_copy() to call G_warning() (with the
> appropriate strerror(errno)) for each failed system call. Either that,
> or G_recursive_copy() would have to generate a "log" of failures so
> that the caller can report them.
>
> --
> Glynn Clements 
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#479 (master - e41182c)

2015-11-09 Thread Travis CI 
Build Update for GRASS-GIS/grass-ci
-

Build: #479
Status: Still Failing

Duration: 6 minutes and 6 seconds
Commit: e41182c (master)
Author: Huidae Cho
Message: M_do_copy: Add a warning for failed copy

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@66775 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/e2f3140def5c...e41182c248c3

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/90100876

--

You can configure recipients for build notifications in your .travis.yml file. 
See http://docs.travis-ci.com/user/notifications


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Broken: GRASS-GIS/grass-ci#478 (master - e2f3140)

2015-11-09 Thread Travis CI 
Build Update for GRASS-GIS/grass-ci
-

Build: #478
Status: Broken

Duration: 6 minutes and 10 seconds
Commit: e2f3140 (master)
Author: Glynn Clements
Message: Include dbstubs.h, fix prototypes for open_select_cursor and 
describe_table


git-svn-id: https://svn.osgeo.org/grass/grass/trunk@66773 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/6189177e1302...e2f3140def5c

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/90080322

--

You can configure recipients for build notifications in your .travis.yml file. 
See http://docs.travis-ci.com/user/notifications


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r66774 - grass-addons/grass7/imagery/i.segment.stats

2015-11-09 Thread Vaclav Petras 
On Mon, Nov 9, 2015 at 8:52 AM,  wrote:

> Author: mlennert
> Date: 2015-11-09 05:52:29 -0800 (Mon, 09 Nov 2015)
> New Revision: 66774
>
> Modified:
>grass-addons/grass7/imagery/i.segment.stats/i.segment.stats.py
> Log:
> clumped map is a raster, not a vector
>
>
> Modified: grass-addons/grass7/imagery/i.segment.stats/i.segment.stats.py
> ===
> --- grass-addons/grass7/imagery/i.segment.stats/i.segment.stats.py
> 2015-11-09 12:06:44 UTC (rev 66773)
> +++ grass-addons/grass7/imagery/i.segment.stats/i.segment.stats.py
> 2015-11-09 13:52:29 UTC (rev 66774)
> @@ -82,8 +82,8 @@
>  if grass.find_file(temporary_vect, element='vector')['name']:
>  grass.run_command('g.remove', flags='f', type_='vector',
>  name=temporary_vect, quiet=True)
> -if grass.find_file(temporary_clumped_rast, element='vector')['name']:
> -grass.run_command('g.remove', flags='f', type_='vector',
> +if grass.find_file(temporary_clumped_rast, element='raster')['name']:
> +grass.run_command('g.remove', flags='f', type_='raster',
>

I'm pretty sure that find_file wants cell for rasters (regardless of type).
Does this work for you?

https://trac.osgeo.org/grass/changeset/66774
https://grass.osgeo.org/grass71/manuals/libpython/_modules/script/core.html#find_file


>  name=temporary_clumped_rast, quiet=True)
>  if insert_sql:
>  os.remove(insert_sql)
>
> ___
> grass-commit mailing list
> grass-com...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-commit
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

2015-11-09 Thread GRASS GIS 
#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:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+---
Changes (by mmetz):

 * Attachment "compressors.patch" added.

 minimal modification to add more compressors

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

2015-11-09 Thread GRASS GIS 
#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:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+---

Comment (by mmetz):

 Replying to [comment:14 glynn]:
 > Replying to [comment:13 wenzeslaus]:
 >
 > > My question is if it wouldn't be more advantageous to create some
 wrapper which would take the all necessary inputs including compression
 type and do the necessary switches and format specific things.
 >
 > Agreed.
 >
 > In practical terms, there are only two distinct cases: uncompressed
 (where the size of the data read or written matches the size of the data
 stored in the file) and compressed (where the sizes differ). Everything
 else is just options.

 Without knowing about this ticket, I have implemented something like this
 recently and added support for LZ4 (and BZIP2) compression to my local
 copy of GRASS trunk. The motivation was to have a compressor that is
 substantially faster than ZLIB but still better than RLE, and another
 compressor that is substantially better (higher compression) than ZLIB but
 not exceedingly slow. XZ with lzma2 is 1) too slow, 2) uses too much
 memory, 3) does not compress binary raster data better than BZIP2.

 In particular, I have added support for new compressors to gislib, not
 rasterlib. As before gislib does the actual compression, not rasterlib. My
 gislib now also handles LZ4 and BZIP2 compression. The actual change to
 rasterlib is to replace `G_zlib_compress()` with `G_compress(..., int
 compressor)` and `G_zlib_expand()` with `G_expand(..., int compressor)`.
 `G_zlib_write()` and `G_zlib_read()` are now `G_write_compressed(..., int
 compressor)` and `G_read_compressed(..., int compressor)`. Here, "..."
 means same arguments as before. The new argument "compressor" is actually
 "cellhd.compressed" with the same meaning as before. The internal function
 `zlib_compress` is no longer needed.

 As before, the compressor type is encoded in cellhd.compressed with
 previously 0: no compression, 1: RLE, 2: ZLIB, now also 3: LZ4, 4: BZIP2.

 r.univar results for CELL, FCELL, and DCELL maps are identical,
 independent of the compressor. The new gislib interface to compress data
 is generic and it is easy to add any other compressor, e.g. LZ4HC or ZSTD.

 Generally, any new compression method should go into gislib and not into
 rasterlib, just like ZLIB compression has been done by gislib. This keeps
 changes to the rasterlib to a minimum and makes debugging easier.

 For fast storage devices with plenty of space, LZ4 is by far the fastest,
 at the same time providing some reasonable compression where possible.

 For slow storage devices, e.g. accessed over network, BZIP2 compression is
 the fastest (yes, faster than LZ4) because the amount of data is the least
 (50% - 70% of ZLIB). That reduces network traffic and saves disk space.
 For my work, it would be a big advantage to use LZ4 for actual processing
 on fast local disks and BZIP2 for storing the final results on sometimes
 very slow network attached storage.

 The compressor type for new raster maps could be selected with one other
 environment variable GRASS_COMPRESSOR, e.g. GRASS_COMPRESSOR=LZ4

 I am not sure about the pro's and con's for using compressors other than
 ZLIB. ZLIB is a good compromise of speed and compression. Adding other
 compressors to G7.1 means that raster data compressed with a new method
 can not be opened by G7.0 or earlier. New compression types should, if
 added to G7.1, be clearly marked as "use it only if you really know what
 you are doing". I would profit from the choice of other compressors, but
 on a standard laptop/desktop system the current G7 default of ZLIB is
 probably the best alround solution.

 I am attaching a patch for trunk r66775 and an archive with new files to
 go to lib/gis

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

2015-11-09 Thread GRASS GIS 
#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:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+---
Changes (by mmetz):

 * Attachment "compressors.patch" added.

 minimal modification to add more compressors

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

2015-11-09 Thread GRASS GIS 
#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:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+---

Comment (by wenzeslaus):

 Replying to [comment:19 mmetz]:
 > I have implemented something like this recently and added support for
 LZ4 (and BZIP2) compression to my local copy of GRASS trunk.
 >
 > I am attaching a patch for trunk r66775 and an archive with new files to
 go to lib/gis

 The design in the patch looks really good. I did tests and benchmark but
 it was not as successful as I hoped for.

 The benchmark was the same as [comment:10 before] but modified for this
 patch. It is more for testing than benchmark anyway. It was on 30,000,000
 cells but perhaps the previous one was on more and it is not completely
 precise overall due to some other computations running at the same time
 (although the result is from 10 runs aggregated by ''perf'').

 || type || write || read ||
 || NONE || 2.58 || 0.72 ||
 || ZLIB || 1.52 || 0.93 ||
 || LZ4 || 1.56 || 0.85 ||

 RLE and BZIP2 are missing because I got and error when writing using
 r.mapcalc with RLE:

 {{{
 *** Error in `r.mapcalc': free(): invalid next size (normal):
 0x00edacd0 ***
 r.mapcalc: Aborted
 }}}

 The the commands are:

 {{{
 export GRASS_COMPRESSOR=RLE
 r.mapcalc expression="test_rast_z_base = rand(double(-200.), 900)"
 seed=100
 r.mapcalc expression=test_rast_rle=double(test_rast_z_base)
 }}}

 I guess I'm missing something in configure because with BZIP2 it says
 "ERROR: GRASS needs to be compiled with BZIP2 for BZIP2 compression".

 The report from `r.compress`:

 {{{
  is compressed (level 2: DEFLATE). Data type: 
  is uncompressed (level 0: NONE). Data type: 
  is compressed (level 2: DEFLATE). Data type: 
  is compressed (level 3: DEFLATE). Data type: 
 }}}

 When running the tests with

 {{{
 grass71 /grassdata/ncarolina_smp_base/practice1 --exec python -m
 grass.gunittest.main--location ncarolina_smp_base --location-type nc
 }}}

 I get

 {{{
 ERROR: Error reading raster data for row 0 of 
 }}}

 from many raster-related tests. Sometimes it is a different row number.
 The environmental variable `GRASS_COMPRESSOR` was not set. I didn't get if
 you already meant it to be backwards compatible with existing maps.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Paris Code Sprint 2016

2015-11-09 Thread Luca Delucchi 
Hi devs,

another event to meet each others, with a lot of other communities

http://wiki.osgeo.org/wiki/Paris_Code_Sprint_2016

I hope to see other GRASS developers there, if you want we can also
share a house like in Como.


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r66774 - grass-addons/grass7/imagery/i.segment.stats

2015-11-09 Thread Vaclav Petras 
On Mon, Nov 9, 2015 at 9:45 AM, Vaclav Petras  wrote:

> I'm pretty sure that find_file wants cell for rasters (regardless of type).


This is true about g.findfile. find_file gives warning for convenience of
the developer at expense of confused user. I actually implemented similar
function (now focused just on gunittest) which explicitly supports the
normal names (i.e. not g.findfile element names but g.list types). Would
this function be helpful for you if it would be in grass.script.utils or
core?

https://grass.osgeo.org/grass71/manuals/libpython/_modules/gunittest/gutils.html#is_map_in_mapset
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2352: Conflicting definitions of db__driver_describe_table

2015-11-09 Thread GRASS GIS 
#2352: Conflicting definitions of db__driver_describe_table
---+---
  Reporter:  hamish|  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  6.4.6
 Component:  Database  |Version:  6.4.3
Resolution:|   Keywords:  dbf driver, libdb
   CPU:  All   |   Platform:  All
---+---

Comment (by hcho):

 I'm having the same issue when compiling SVN. I needed to copy
 lib/db/dbmi_driver/dbstubs.h to dist/include/grass.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.quantile not respecting region and mask

2015-11-09 Thread Paulo van Breugel 
On Mon, Nov 9, 2015 at 4:03 PM, Anna Petrášová 
wrote:

>
>
> On Mon, Nov 9, 2015 at 9:11 AM, Paulo van Breugel 
> wrote:
>
>> Hi,
>>
>> Am I correct that r.quantile does not use/respect the region and mask? In
>> the examples on the manual page (version 7.0 and 7.1) the region is first
>> set to the input raster, which implies that the region settings do matter.
>> No word on the mask in the manual page. In general, I would expect GRASS
>> GIS functions to respect both the region and mask. If they do not, it might
>> be a good idea to explicitly mention this in the manual page (as in most
>> such cases is done I think)?
>>
>> Assuming that the above is no bug, would it be possible to add an option
>> to have r.quantiles compute the quantiles respecting the region and mask?
>>
>> Regards,
>>
>> Paulo
>>
>
> Just quick test, but it seems to work for me, setting different region
> changes results, as well setting mask. The actual values looked meaningful.
> Could you provide a test case where it doesn't work?
>


Mmm, I actually can't. Sorry, for wasting your time. Not sure what
happened, but I can't replicate this anymore after a reboot of GRASS.


>
> Anna
>
>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

2015-11-09 Thread GRASS GIS 
#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:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+---
Changes (by wenzeslaus):

 * Attachment "gislib_compressor_benchmark.sh" added.

 Benchmark DCELL rasters with GRASS_COMPRESSOR

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Return value from g.copy is one when --overwrite - bug or feature?

2015-11-09 Thread Glynn Clements 

Markus Neteler wrote:

> It should probably not silently fail.
> 
> The code in question is in
> lib/manage/do_copy.c

M_do_copy() returns a status. g.copy's main() checks that and uses it
to set the exit status, but it doesn't generate an error or warning if
the status is non-zero.

If G_recursive_copy() or M_do_copy() raised an error, that would
result in the program aborting on the first error; at present, it
copies as much as it can.

Realistically, g.copy() should be generating the error at the bottom
of main() if result is non-zero. E.g.

-exit(result);
+if (result)
+G_fatal_error(...);
+return 0;

> and potentially there to be added strerror(errno) as for example in
> lib/gis/mapset_msc.c

That would require G_recursive_copy() to call G_warning() (with the
appropriate strerror(errno)) for each failed system call. Either that,
or G_recursive_copy() would have to generate a "log" of failures so
that the caller can report them.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] First step by GRASS

2015-11-09 Thread Markus Neteler 
On Fri, Nov 6, 2015 at 2:52 PM, Nunzia Laguardia
 wrote:
> I want to create a simple plugin that uses grass.
> My configuration is:
> - OS: widows 7 64bit
> - Python: 2.7.4 (32bit)
> - Osgeo4W (32bit) with
>
>-Qgis: 2.12.0
>-Grass: 6.4.4
>-Python: 2.7.4

... since you just start to write, please consider to upgrade to GRASS
7.0 (you can keep GRASS 6 in parallel if needed).

Then see the page
https://grasswiki.osgeo.org/wiki/GRASS_and_Python

Best
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

2015-11-09 Thread GRASS GIS 
#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:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+---
Changes (by mmetz):

 * Attachment "giscompress.tar.gz" added.

 new files for lib/gis to support different compressors

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Return value from g.copy is one when --overwrite - bug or feature?

2015-11-09 Thread Rainer M Krug 
Markus Neteler  writes:

> On Sun, Nov 8, 2015 at 11:22 AM, Rainer M Krug  wrote:
>> Huidae Cho  writes:
>>
>>> Rainer,
>>>
>>> I cannot seem to replicate your issue:
>>>
>>> G srorg6630/tmp ~> g.version
>>> GRASS 7.1.svn (2015)
>>>
>>> G srorg6630/tmp ~> g.list region
>>> tmp
>>> tmp.d.rast.edit.6753
>>> tmp1
>>>
>>> G srorg6630/tmp ~> g.copy region=tmp,tmp1 --overwrite
>>> Copy region definition  to current mapset as 
>>>
>>> G srorg6630/tmp ~> echo $?
>>> 0
>>>
>>> g.copy returns 1 when it cannot either read the source or write to the
>>> target. Please check your permissions on your region files in
>>> LOCATION/MAPSET/windows/.
>>
>> You are correct - they are read only.
>>
>> So the return value is correct - but an error should be raised - or is
>> there a reason why this should silently fail?
>
> It should probably not silently fail.

Absolutely not - this can lead to errors as one assumes that no error
message means that the command was successful - I usually don't check
the return codes when I am working in a terminal.

>
> The code in question is in
> lib/manage/do_copy.c
>
> and potentially there to be added strerror(errno) as for example in
> lib/gis/mapset_msc.c

I don't know the inner workings of GRASS - but it looks like a good place?

On a related note - are the return codes documented somewhere (apart
From the source code)? OK - 0 is evident, but the others? They seem to
have specific meanings in GRASS?

Thanks,

Rainer

>
> ?
>
> Markus

-- 
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:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev