GRASS GIS | 22 Oct 10:57 2014

[GRASS GIS] #2458: testsuite: cosmetics for percentage output

#2458: testsuite: cosmetics for percentage output
------------------------------------+---------------------------------------
 Reporter:  neteler                 |       Owner:  grass-dev <at> …              
     Type:  enhancement             |      Status:  new                      
 Priority:  normal                  |   Milestone:  7.0.0                    
Component:  Tests                   |     Version:  svn-trunk                
 Keywords:  percentage, formatting  |    Platform:  Unspecified              
      Cpu:  Unspecified             |  
------------------------------------+---------------------------------------
 In order to avoid special characters in the percentage output of
 computations done in the testsuite, please add

 {{{
 os.putenv("GRASS_MESSAGE_FORMAT", "plain")
 }}}

 ideally at library level.

 The output becomes then "0...10...20... ...100", nice for log files.

--

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

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Martin Landa | 22 Oct 10:49 2014
Picon

pygrass and shorten parameters

Hi,

it's seems that currently PyGRASS doesn't support shorten parameters, eg.

    Module('v.db.addcolumn', map='p5', col='vymera_ha double')

 File "./u01.py", line 27, in compute
    Module('v.db.addcolumn', map='p5', col='vymera_ha double')
  File "/opt/src/grass70_release/dist.x86_64-unknown-linux-gnu/etc/python/grass/pygrass/modules/interface/module.py",
line 347, in __init__
    self.__call__(*args, **kargs)
  File "/opt/src/grass70_release/dist.x86_64-unknown-linux-gnu/etc/python/grass/pygrass/modules/interface/module.py",
line 395, in __call__
    raise ParameterError('%s is not a valid parameter.' % key)
grass.pygrass.errors.ParameterError: col is not a valid parameter.

Any chance to change this behaviour? Thanks, Martin

--

-- 
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Blumentrath, Stefan | 22 Oct 08:56 2014
Picon

WinGRASS71svn using Windows shell (not bourne shell) thogh MSYS is installed

 

Hi,

 

I just instaled the latest WinGRASS71svn through OSGeo4W (including MinGW/MSYS).

Unfortunately it uses Windows shell (CMD) instead of bourne shell (like earlier 71 installations and latest WinGRASS70beta still does (within the same OSGeo4W installation)).

 

Is that on purpose?

 

In CMD, even simple variable assignments from shell scripts do not work, and I would be missing the Unix-like environment on Windows...

 

Cheers

Stefan

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 21 Oct 18:57 2014

[GRASS GIS] #2457: DBF driver: stub functions for SQL TRANSACTION

#2457: DBF driver: stub functions for SQL TRANSACTION
-------------------------+--------------------------------------------------
 Reporter:  neteler      |       Owner:  grass-dev <at> …              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  6.4.5                    
Component:  Database     |     Version:  svn-releasebranch64      
 Keywords:  dbf, sql     |    Platform:  All                      
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
 On some systems (here: Ubuntu, user report on grass-user), it is not
 possible to run v.rast.stats properly when using the DBF driver as it is
 internally executing a SQL transaction:

 {{{
 v.rast.stats -c vector=basin_250 <at> PERMANENT raster=rainfall_idw <at> PERMANENT
 colprefix=z
 Updating the database ...
 DBMI-DBF driver error:
 SQL parser error: syntax error, unexpected NAME processing
 'BEGIN'
 in statement:
 BEGIN TRANSACTION
 Error in db_execute_immediate()
 ERROR: Error while executing: 'BEGIN TRANSACTION'
 }}}

 I would suggest to add stub functions for
  * db_begin_transaction()
  * db_commit_transaction()

 to db/drivers/dbf/execute.c to make the DBMI interface happy.

 Is attached patch ok? If yes, also add to GRASS 7?

--

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

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Martin Landa | 21 Oct 10:28 2014
Picon

Topographic prominence in GRASS

Hi all,

when searching for a suitable topic (smaller project) for one student
of mine I found [1,2].

"""
Create a new GRASS module to find the topographic_prominence of peaks
from a raster elevation map within the region. (probably this would
only make up 1/4 to 1/2 of a multi-part GSoC project)
"""

I don't know this topic enough, is there anyone who has any opinion,
suggestion or comment?

Thanks in advance, Martin

[1] http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2012
[2] http://en.wikipedia.org/wiki/Topographic_prominence

--

-- 
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
GRASS GIS | 20 Oct 18:47 2014

[GRASS GIS] #2456: read cvs from GDAL data directory

#2456: read cvs from GDAL data directory
-------------------------+--------------------------------------------------
 Reporter:  martinl      |       Owner:  grass-dev <at> …              
     Type:  task         |      Status:  new                      
 Priority:  normal       |   Milestone:  7.1.0                    
Component:  Default      |     Version:  unspecified              
 Keywords:  gdal         |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
 Currently GRASS contains copy of several CVS files from GDAL
 source:grass/trunk/lib/proj. It would make sense to modify GRASS libraries
 to read these files dynamically.

 Any comments?

--

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

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler | 20 Oct 17:51 2014

Fwd: New Defects reported by Coverity Scan for grass

FYI - from the latest coverity scan.

Markus

---------- Forwarded message ----------
From:  <scan-admin <at> coverity.com>
Date: Mon, Oct 20, 2014 at 5:11 PM
Subject: New Defects reported by Coverity Scan for grass
To: neteler <at> 

Hi,

Please find the latest report on new defect(s) introduced to grass
found with Coverity Scan.

99 new defect(s) introduced to grass found with Coverity Scan.
73 defect(s), reported by Coverity Scan earlier, were marked fixed in
the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 20 of 99 defect(s)

** CID 1248541:  Untrusted loop bound  (TAINTED_SCALAR)
/lib/vector/Vlib/read_pg.c: 1073 in polygon_from_wkb()

** CID 1248526:  Result is not floating-point  (UNINTENDED_INTEGER_DIVISION)
/imagery/i.atcorr/aerosolmodel.cpp: 388 in
AerosolModel::exscphase(double, double, double, double &, double &,
double (&)[83])()

** CID 1248523:  Result is not floating-point  (UNINTENDED_INTEGER_DIVISION)
/raster/r.contour/cont.c: 349 in getpoint()
/raster/r.contour/cont.c: 351 in getpoint()

** CID 1248527:  Result is not floating-point  (UNINTENDED_INTEGER_DIVISION)
/raster/simwe/r.sim.sediment/main.c: 335 in main()

** CID 1248529:  Result is not floating-point  (UNINTENDED_INTEGER_DIVISION)
/raster/r.sunmask/main.c: 364 in main()
/raster/r.sunmask/main.c: 385 in main()
/raster/r.sunmask/main.c: 412 in main()
/raster/r.sunmask/main.c: 423 in main()

** CID 1248535:  Untrusted value as argument  (TAINTED_SCALAR)

** CID 1248540:  Uninitialized scalar variable  (UNINIT)
/imagery/i.eb.hsebal01/main.c: 200 in main()

[other "Unused value" reports removed from here]
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit,
http://scan.coverity.com/projects/1038?tab=overview
Vaclav Petras | 20 Oct 17:38 2014
Picon

Re: [GRASS-SVN] r62246 - grass/trunk/include/Make

Hi Glynn,

can you please comment on 62246 or add documentation for it? Commit message does not tell much, it is not (yet?) used anywhere and I don't understand the relation to %reldir% [1].

Thanks,
Vaclav

On Sun, Oct 12, 2014 at 8:15 AM, <svn_grass <at> osgeo.org> wrote:
Author: glynn
Date: 2014-10-12 05:15:11 -0700 (Sun, 12 Oct 2014)
New Revision: 62246

Modified:
   grass/trunk/include/Make/Grass.make
Log:
Add RELDIR


Modified: grass/trunk/include/Make/Grass.make
===================================================================
--- grass/trunk/include/Make/Grass.make 2014-10-12 12:08:22 UTC (rev 62245)
+++ grass/trunk/include/Make/Grass.make 2014-10-12 12:15:11 UTC (rev 62246)
<at> <at> -19,6 +19,8 <at> <at>
 #
 #########################################################################

+RELDIR         := $(subst $(GRASS_HOME)/,,$(CURDIR))
+
 # GRASS global directories and constants
 # platform specific dirs
 ARCH_DISTDIR   = $(GRASS_HOME)/dist.$(ARCH)

_______________________________________________
grass-commit mailing list
grass-commit <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-commit

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 20 Oct 17:22 2014

[GRASS GIS] #2455: r.unpack/v.unpack: add sanity check for auto-detecting if pack file contains raster or vector data

#2455: r.unpack/v.unpack: add sanity check for auto-detecting if pack file
contains raster or vector data
--------------------------------+-------------------------------------------
 Reporter:  neteler             |       Owner:  grass-dev <at> …              
     Type:  defect              |      Status:  new                      
 Priority:  normal              |   Milestone:  7.0.0                    
Component:  Raster              |     Version:  svn-releasebranch70      
 Keywords:  r.unpack, v.unpack  |    Platform:  All                      
      Cpu:  Unspecified         |  
--------------------------------+-------------------------------------------
 Small issue for GRASS data transfer via "pack" format:

 In case that a user doesn't use a self-explaining file name, it may not be
 obvious if r.unpack or v.unpack has to be used. In case of running the
 wrong command, an "ugly" error message appears rather than telling the
 user to apply the other respective unpack command.

 Solution: simply check for the presence of 'mapname/cell' or
 'mapname/coor' and generate a user message if the wrong content was
 detected.

 Message suggestions:

 {{{
 #r.unpack

 grass.fatal(_("This GRASS GIS pack file contains vector data. Use v.unpack
 to unpack <%s>) % map_name))

 #v.unpack

 grass.fatal(_("This GRASS GIS pack file contains raster data. Use r.unpack
 to unpack <%s>) % map_name))
 }}}

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2455>
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 | 20 Oct 16:51 2014
Picon

v.in.ogr crashed with SIGSEGV in main() in v.what/test_vwhat_layers

Hi,

again some test failed because of segmentation fault and I'm wondering how to collect the information about it for the report.

In this case, it was crash of v.in.ogr called by script db.in.ogr, so I have absolutely no idea which process to hunt for except that it is a (grand) child of the test. It is not visible from the report:

http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-10-20-07-00/report_for_nc_spm_08_grass7_nc/vector/v.what/test_vwhat_layers/index.html

I have the Ubuntu crash report dialog(s) but I would like to associate the information with the tests, so I need something which will recognize that there was a segmenation fault in one of the children and then it will collect the information.

I made a little progress on that except that I found that there are files in /var/crash which are somehow managed by some apport-* commands. Now I was able to get file

/var/crash/_opt_src_grass-trunk-tests_dist.x86_64-unknown-linux-gnu_bin_v.in.ogr.1000.crash

which is attached and contains following useful information:

  v.in.ogr crashed with SIGSEGV in main()

  v.in.ogr --q -o dsn=./data/table1.csv output=t1

  v.what/test_vwhat_layers

  SegvAnalysis
  ...
  source ... (0x000...00) not located in known VMA region (needed readable region)!
  ...

  SegvReason
  reading NULL VMA

  Stacktrace
  __strcmp_ssse3 in .../strcmp.S
  in main()

If somebody has some ideas how to proceed or to which commands to look, please let me know.

Vaclav

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Anna Petrášová | 20 Oct 04:50 2014
Picon

r.profile tests

Hi,

I was trying to fix failing test of r.profile:

which is working on 32-bit machine. I committed this change:

which fixed it but I was wondering, if r.profile shouldn't use atan2 instead of atan? It seems that the division in atan could possibly lead to overflow? But nobody complained about it yet... Tests work with atan2.

Thanks,

Anna

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Gmane