GRASS GIS | 20 Nov 12:29 2014

[GRASS GIS] #2497: Incompatile PostGIS Topology export

#2497: Incompatile PostGIS Topology export
 Reporter:  strk         |       Owner:  grass-dev <at> …              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  Vector       |     Version:  svn-trunk                
 Keywords:               |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
 I've tried exporting topology to PostGIS with v.out.postgis -l and the
 result was not correct.

 First there was no record in TOPOSCHEMA.relation so that all the literal
 TopoGeometry values (written in the output feature layer) result empty.

 Second all the calls to ST_GetFaceGeometry() return a null value, which
 I've yet to inspect/understand. All I noticed so far was that there were
 many negative face_id, which don't really have any special meaning in
 PostGIS/ISO (there's no difference between an area or an island, you only
 have faces, with roles being dependent on the upper abstraction level of
 the TopoGeometry).

 Unfortunately, topology.ValidateTopology doesn't notice any of these
 problems (this would be a PostGIS bug).


Ticket URL: <>

(Continue reading)

Sandro Santilli | 20 Nov 10:47 2014

v.out.postgis -l running for hours

I'm forwarding this mail from -user as it didn't get attention there
yesterday. Today I've tried again a v.out.postgis -l, this time
with a different (bigger) dataset.

This other dataset took 20 minutes to import/build, and took 85 minutes
to export to PostGIS (4 times more expensive to export).

 v.out.postgis complete. 224655 primitives written to <grass_ulfareale>.
 real    85m16.237s
 user    2m48.962s
 sys     1m19.671s

Is the export doing anything else than INSERT calls ?
I've seen some UPDATE calls against edges (which could maybe be avoided,
same problem in PostGIS itself:;
but I hadn't noticed if GRASS is also calling SELECT against the ISO
topology functions.

The input GRASS map:


(Continue reading)

Isaac Ullah | 20 Nov 01:30 2014

Issues installing GRASS 7.0 from Ubuntu PPA

Hi all,

   I've been trying to get GRASS7 installed on several machines running Xubuntu 14.04, with no success. These are fresh installs of the OS, so there should be no cruft complicating install. I'm installing from the "GRASS-stable" ubuntu PPA repository, and am indeed following all the procedures. GRASS seems to install okay, but there are major issues when I try to run it. First, wx-gui dies on start with the following error message:

Isaac I Ullah, Ph.D.

Arizona State University
School of Human Evolution and Social Change
PO Box 2402
Tempe, AZ 85287-2402
(480) 727-1054 office
(650) 201-0479 cell
iullah <at>

grass-dev mailing list
grass-dev <at>
Markus Neteler | 20 Nov 00:29 2014

G7: v.mkhexgrid addon for hexagon creation


I have added v.mkhexgrid as new G7 addon to the Addons repo. The
original author is Trevor Wiens who already implemented it as a Python
script. I made some minor changes to get it running in GRASS GIS 7.

Originally I had hoped that v.voronoi would do the job but it does not
create proper hexagons. I was running:

# desired result: (3rd figure
# create first set of points
g.region rast=elevation -p
v.mkgrid -p map=pointpattern1 grid=13,15 position=region breaks=1
# shift grid by half point distance
g.region n=n+500 w=w+500 e=e+500 s=s+500 -p
# create second set of points
v.mkgrid -p map=pointpattern2 grid=13,15 position=region breaks=1
# merge into final point pattern
v.patch input=pointpattern1,pointpattern2 output=pointpattern3
# generate Thiessen, hoping for hexagons
v.voronoi input=pointpattern3 out=hexagon_attempt
# show result
d.mon wx0
sleep 5
d.vect hexagon_attempt type=boundary

(screenshot attached).

In essence, the Addon v.mkhexgrid does the job but it is very CPU/disk
space demanding.

grass-dev mailing list
grass-dev <at>
GRASS GIS | 19 Nov 22:55 2014

[GRASS GIS] #2496: r.random.surface error from RAN C library

#2496: r.random.surface error from RAN C library
 Reporter:  cmbarton          |       Owner:  grass-dev <at> …              
     Type:  defect            |      Status:  new                      
 Priority:  normal            |   Milestone:  7.0.0                    
Component:  Raster            |     Version:  svn-trunk                
 Keywords:  r.random.surface  |    Platform:  MacOSX                   
      Cpu:  Unspecified       |  
 We just encountered a weird bug in r.random.surface. So far, it seems to
 showing up on the Mac intermittently but not on Linux. The message is...

 ERROR: RAN1: j==-67 shouldn't happen

 It was generated from a Python script that called r.random.surface in the
 following way:

 grass.run_command("r.random.surface", quiet = "True", output =
 tempimpactg, distance = grazespatial, exponent = grazepatchy, high =

 I'm running on an oldish (ca. 5 years) iMac but with the latest OS X
 10.9,x (no upgrade to 10.10 yet). This happens on both GRASS 7.0 beta3 and
 7.1, both compiled 11 August 2014.


Ticket URL: <>

grass-dev mailing list
grass-dev <at>
GRASS GIS | 19 Nov 02:18 2014

[GRASS GIS] #2495: Java runtime error

#2495: Java runtime error
 Reporter:  ragola                      |       Owner:  grass-dev <at> …              
     Type:  defect                      |      Status:  new                      
 Priority:  normal                      |   Milestone:  6.4.5                    
Component:  Installation                |     Version:  unspecified              
 Keywords:  java, runtime, gui startup  |    Platform:  MacOSX                   
      Cpu:  OSX/Intel                   |  
 I'm attempting to open the GRASS-7 (3 beta) through Yosemite and the
 following message appears:

 Starting GRASS GIS...
 No Java runtime present, requesting install.
 ERROR: Invalid return code from GUI startup script.
 Please advise GRASS developers of this error.

 All framework packages were installed prior with no issue and I have
 reinstalled Java 8. Any assistance is much appreciated.

 -Rich G.


Ticket URL: <>

grass-dev mailing list
grass-dev <at>
Markus Neteler | 18 Nov 22:34 2014

How to calculate log() in v.db.update with SQLite backend?


playing around with the "Meuse" dataset about soil contamination I
attempted to calculate that right away but...:

v.db.update meuse_voronoi column="logzinc" qcolumn="log(zinc)"
DBMI-SQLite driver error:
Error in sqlite3_prepare():
no such function: log

DBMI-SQLite driver error:
Error in sqlite3_prepare():
no such function: log

ERROR: Error while executing: 'UPDATE meuse_voronoi SET logzinc=log(zinc)'

After some online research I found that I would need to tune my local
SQLite installation with
"extension-functions.c (50.96 KB) contributed by Liam Healy on
2010-02-06 15:45:07
Provide mathematical and string extension functions for SQL queries
using the loadable extensions mechanism. Math: acos, asin, atan, atn2,
atan2, acosh, asinh, atanh, difference, degrees, radians, cos, sin,
tan, cot, cosh, sinh, tanh, coth, exp, log, log10, power, sign, sqrt,
square, ceil, floor, pi. String: replicate, charindex, leftstr,
rightstr, ltrim, rtrim, trim, replace, reverse, proper, padl, padr,
padc, strfilter. Aggregate: stdev, variance, mode, median,
lower_quartile, upper_quartile.

Alternative: use pysqlite and define an own function.

Which way to go?

GRASS GIS | 18 Nov 18:36 2014

[GRASS GIS] #2494: d.vect.thematic broken

#2494: d.vect.thematic broken
 Reporter:  neteler                   |       Owner:  grass-dev <at> …              
     Type:  defect                    |      Status:  new                      
 Priority:  normal                    |   Milestone:  7.0.0                    
Component:  Display                   |     Version:  svn-releasebranch70      
 Keywords:  d.vect.thematic, d.graph  |    Platform:  Linux                    
      Cpu:  Unspecified               |  
 Using the NC Example from

 one gets:
 ... [all ok]...

 GRASS 7.1.svn (nc_spm_08_grass7):~ > v.univar -e elev_sample col=diff
 number of features with non NULL attribute: 200
 number of missing attributes: 0
 number of NULL attributes: 0
 minimum: -26.8796
 maximum: 21.2874
 range: 48.167

 GRASS 7.1.svn (nc_spm_08_grass7):~ > d.mon wx0
 GRASS 7.1.svn (nc_spm_08_grass7):~ > d.vect.thematic -l elev_sample
 column=diff type=point
 Thematic map legend for column diff of map elev_sample
 Value range: -26.8796 - 21.2874
 Mapped by 4 intervals of 12.04175
 Color(R:G:B)    Value
 ============    ==========
 0:0:255         -26.8796 - 21.2874
 d.vect complete.
 85:0:170                -26.8796 - 21.2874
 d.vect complete.
 170:0:85                -26.8796 - 21.2874
 d.vect complete.
 GRASS 7.1.svn (nc_spm_08_grass7):~ > Command 'd.graph color=black
 Details: Graph file
 not found

 The file names are indeed different:

 ls /home/neteler/grassdata/nc_spm_08_grass7/user1/.tmp/oboe.localdomain/
 23101.0.cmd  23101.0.env  23101.0.ppm.ppm


Ticket URL: <>

grass-dev mailing list
grass-dev <at>
GRASS GIS | 18 Nov 17:45 2014

[GRASS GIS] #2493: wxgui file import wizards: all files should be defined as '*', not '*.*'

#2493: wxgui file import wizards: all files should be defined as '*', not '*.*'
 Reporter:  mlennert                |       Owner:  grass-dev <at> …              
     Type:  defect                  |      Status:  new                      
 Priority:  normal                  |   Milestone:  7.0.0                    
Component:  wxGUI                   |     Version:  unspecified              
 Keywords:  wxgui file import glob  |    Platform:  Unspecified              
      Cpu:  Unspecified             |  
 The wxgui file import wizards define all files as '*.*' which means that
 if you have total legal tif files which do not have the .tif extension you
 cannot see them in the file selector.

 In this was replaced by '*' a long time ago, but in the import
 wizards it is still a nuisance.

 Classifying this as a bug since for some users this means they don't know
 how to import these files.


Ticket URL: <>

grass-dev mailing list
grass-dev <at>
Anna Petrášová | 18 Nov 15:02 2014

winGRASS 71 binaries missing


I realized the last grass 71 binary is from November 13, but the last log doesn't show any error?

grass-dev mailing list
grass-dev <at>
GRASS GIS | 18 Nov 11:42 2014

[GRASS GIS] #2492: v.generalize: incorrect handling of wrap at 180 meridian

#2492: v.generalize: incorrect handling of wrap at 180 meridian
 Reporter:  jkaplan       |       Owner:  grass-dev <at> …              
     Type:  defect        |      Status:  new                      
 Priority:  normal        |   Milestone:                           
Component:  Vector        |     Version:  svn-trunk                
 Keywords:  v.generalize  |    Platform:  All                      
      Cpu:  OSX/Intel     |  
 I am running GRASS 7.1.svn on Mac OS X.

 GRASS 7.1.svn (global_lonlat):~ > g.version -g

 I am having a problem with the behavior of v.generalize when attempting to
 generalize a vector feature - lines or polygons it does not seem to matter
 - that crosses the 180 meridian, using a location that is EPSG:4326 with
 global extents.

 The problem is probably best illustrated with a picture, which I have
 attached to this ticket, but can also be viewed here:

 In the picture two line vector features are displayed. The black-lined
 feature is the original vector line feature (test1). The red-lined feature
 is produced from test1 using the following command:

 v.generalize input=test1 output=test2 method=sliding_averaging
 look_ahead=5 slide=1 threshold=1

 It appears that v.generalize, when smoothing between vertices that are
 very close to the 180 meridian, results in the incorrect identification of
 the “next" point, hence the long horizontal lines connecting points “the
 wrong way around” the earth. The behavior is the same when using any of
 the generalization or smoothing tools.

 I have tested this with a simpler vector containing points farther away
 from the 180 meridian and it doesn’t appear to show the same behavior.

 I would very much appreciate any help anyone could give me to solve this

 Thank you in advance!

 Best regards,

 Jed Kaplan


 If you would like to download the original lines file and try my procedure
 yourself, I have also attached a test vector file to this ticket. It can
 also be downloaded here:

 Assuming you have OGR support for GMT in your version of GRASS, you can
 import the vector using this command:

 {{{ dsn=GRASS_wrap_problem_samplevector.gmt output=test1


Ticket URL: <>

grass-dev mailing list
grass-dev <at>