Luca Delucchi | 2 Sep 09:15 2014

Fwd: [GSoC Mentors] After GSoC ... Semester of Code!

I wrote to OSGeo GSOC mailing list to ask if they want to apply,
otherwise we could apply as single project.. what do you think?

---------- Forwarded message ----------
From: Scott Wilson <scott.bradley.wilson <at>>
Date: 29 August 2014 13:35
Subject: [GSoC Mentors] After GSoC ... Semester of Code!
To: Google Summer of Code Mentors List
<google-summer-of-code-mentors-list <at>>

Hi everyone,

Just to let you know that Semester of Code is now open for
registration. This is a programme that gets students involved in open
source projects for course credit or as a contribution to their final
year or masters projects. Its inspired by GSoC (hence the name), but
is organised by a small consortium of companies and organisations
based in the EU.

If you didn't get any takers for some of the ideas you put up for GSoC
this year, or didn't have enough slots, this could be a good
opportunity to give it another shot. Or you may have come up with more
work that would suit a student project.

There are more details on how you get involved as a project here:

You need to register your organisation by the 12th of September. There
are no application requirements or financial considerations for this
(Continue reading)

Moritz Lennert | 29 Aug 19:05 2014

New addon: v.centerline


I just added a new module to the GRASS7 addons [1] which I called 
v.centerline. It is somewhat of an experimental module and I invite 
anyone with other ideas of how to solve this problem to add to the module.

Below a description of the module and the two implemented algorithms.

Enjoy !



v.centerline creates a new map with a line representing an approximation 
of the central tendency of a series of input lines. This can for 
example, be the central line of a river represented by its two sides, or 
a line representing the general direction of a series of flight paths, 

Two algorithms are proposed in the module, both based on the idea of 
using a reference line, creating a series of reference points along this 
line and then finding the coordinates of corresponding points on all the 
input lines. The default algorithm uses closest distance to identify 
corresponding points, while the second algorithm draws perpendicular 
transversals at the reference points and uses the intersections of these 
transversals with the other lines as corresponding points.

(Continue reading)

GRASS GIS | 29 Aug 18:13 2014

[GRASS GIS] #2405: WXGUI-3D view, workspace not saving all the position changes made

#2405: WXGUI-3D view, workspace not saving all the position changes made
 Reporter:  spareeth     |       Owner:  grass-dev <at> …              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  wxGUI        |     Version:  svn-releasebranch70      
 Keywords:  wxNVIZ       |    Platform:  Linux                    
      Cpu:  Unspecified  |  

 I am preparing a 3D workspace to use it as input to the g.gui.animation
 When I make changes in the map display, the changes are not reflected in
 the layer manager > 3D view > view tab and in the saved workspace file.

 But when I make changes in the layer manager > 3D view > view tab, the
 workspace is saved appropriately with the changed parameters.

 It is much easier to set the 3d map position in map display, so nice to
 get this issue corrected




Ticket URL: <>

(Continue reading)

jotawski | 29 Aug 02:03 2014

jotawski <at> has indicated you're a friend. Accept?

Click here to discover jotawski <at>'s favorite websites!
jotawski <at> wants to follow you
I would like to add you as a friend
-jotawski <at>
Accept Decline
Following jotawski <at> helps you discover great websites they recommend :)
Click here to unsubscribe from such emails from jotawski <at> or all friends

P.O. BOX 70928, Sunnyvale, CA 94086
grass-dev mailing list
grass-dev <at>
GRASS GIS | 27 Aug 21:57 2014

[GRASS GIS] #2404: winGRASS: G_calloc error in

#2404: winGRASS: G_calloc error in
 Reporter:  neteler      |       Owner:  grass-dev <at> …              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  Vector       |     Version:  svn-trunk                
 Keywords:    |    Platform:  MSWindows 7              
      Cpu:  Unspecified  |  
 winGRASS (32bit binaries):

 v.rast.stats --> which calls

 ERROR: G_calloc: unable to allocate 236326912 * 1 bytes of memory at
 ERROR: An error occurred while converting vector to raster

 Computational region:

 g.region rast=somemap <at> LANDCOVER -p
 projection: 99 (Lambert Azimuthal Equal Area)
 zone:       0
 datum:      etrs89
 ellipsoid:  grs80
 north:      5416100
 south:      941500
 west:       1547000
 east:       7316700
 nsres:      100
 ewres:      100
 rows:       44746
 cols:       57697
 cells:      2581709962

 g.region vect=othermap <at> LANDCOVER -p
 projection: 99 (Lambert Azimuthal Equal Area)
 zone:       0
 datum:      etrs89
 ellipsoid:  grs80
 north:      5310000
 south:      940000
 west:       1540000
 east:       6530000
 nsres:      100
 ewres:      100
 rows:       43700
 cols:       49900
 cells:      2180630000

  * winGRASS 7.1
  * RAM 32 GB

 Also reported here:



 The issue might be the row cache in


 with rows=4096 (Number of rows to hold in memory by default).

 According to the latter email, the memory consumption would be (in GB,
 plus overhead):

 > 4096 * 44746 rows * 8 bytes /1024 /1024 /1024
 [1] 1.36554

 Given the 32GB of RAM, that should be ok (but even for winGRASS 7 32bit?).

 Maybe the row cache in should be "auto" according to the amount
 of pixels in a row?

 BTW: seen again here:


Ticket URL: <>

grass-dev mailing list
grass-dev <at>
Pietro | 27 Aug 12:15 2014

Re: error in pygrass

Please keep the conversation on the mailing-list.

On Wed, Aug 27, 2014 at 12:00 PM, Niroshan Sanjaya <nsanj88 <at>> wrote:
> Yes I do programming on GRASS python shell, then I tried with terminal then
> I got the same error.
> I used the following codes
> from grass.pygrass.modules.shortcuts import raster as r
> from grass.pygrass.modules.shortcuts import imagery as i

I believe that you are using grass6.*, and unfortunately the pygrass
modules is available only on grass7.*

Let me know.

Niroshan Sanjaya | 27 Aug 11:43 2014

error in pygrass

when I work with GRASS GIS I got following error
"No module named pygrass.modules.shortcuts" 

Help me to solve it 

Niroshan Sanjaya

P Save a Tree.Please consider the environment before printing this email

grass-dev mailing list
grass-dev <at>
Paulo van Breugel | 27 Aug 10:13 2014

Error reading null row 2725 for <MASK>

When running several r.mapcalc in a loop (via R) the function stops with an error:

ERROR: Error reading null row 2725 for <MASK>

The row number varies. This seems to happen at random, and when I repeat the same r.mapcalc calculation that stopped with the error before, things run without problem.

I tried after removing the mask, and this time no problem so it may have to do something with the MASK? (as these error messages only occur once in a while, I can't be completely sure it only happens when a MASK is defined).

I ran it through R, using the execGRASS() function of the spgrass6 package. I ran the same, but using the system call instead of execGRASS. Still got the same error messages. I therefore guess this has nothing to do with R?
grass-dev mailing list
grass-dev <at>
Luca Delucchi | 27 Aug 10:01 2014

v.clean meters against feets

Hi everybody,

I'm testing v.clean with meters and feet projection system.
I'm trying to run v.clean in the same map and with the same
parameters, but I obtain a different result. For the testing I'm using
zipcodes_wake map of nc_spm_08

Here my procedure:

- download nc_spf location from here [0]
- reproject zipcodes_wake from nc_spm_08 to nc_spf

- run v.clean on meters location with "v.clean in=zipcodes_wake
out=zipcodes_wake_clean tool=rmarea thre=10000000" the result is

Number of nodes: 106
Number of primitives: 166
Number of points: 0
Number of lines: 0
Number of boundaries: 135
Number of centroids: 31
Number of areas: 31
Number of isles: 2

-  run v.clean on feet location with "v.clean in=zipcodes_wake
out=zipcodes_wake_clean tool=rmarea thre=107638674"

Number of nodes: 84
Number of primitives: 103
Number of points: 0
Number of lines: 0
Number of boundaries: 93
Number of centroids: 10
Number of areas: 10
Number of isles: 1

The threshold in feet should be the same of the meters one because:

1 meters is 0.3048006096012192 feet (according with g.proj output)


10000000 squared meters is 107638674 squared feet ( 10000000 / 0.3048^2 )

I expected the same output map, but this not happen; I'm wrong or
there is something wrong in the v.clean code?



Alessandro Samuel Rosa | 27 Aug 00:12 2014


Dear GRASS GIS developers,

I am planning to use v.perturb to run a spatial simulated annealing exercise. Two drawbacks with v.perturb exist. First, "output vector points are not guaranteed to be contained within the current geographic region". Second, all vector points are perturbed together.

Is it very difficult to solve this issues?

Another option for perturbation would be v.edit, but in that case the direction and distance are not random.

Alessandro Samuel-Rosa
Graduate School in Agronomy - Soil Science
Federal Rural University of Rio de Janeiro
Seropédica, Rio de Janeiro, Brazil
Guest Researcher at ISRIC - World Soil Information
Wageningen, the Netherlands
Homepage: Skype: alessandrosamuel
grass-dev mailing list
grass-dev <at>
GRASS GIS | 26 Aug 20:11 2014

[GRASS GIS] #2403: cairo driver fails to create surface

#2403: cairo driver fails to create surface
 Reporter:  martinl                     |       Owner:  grass-dev <at> …              
     Type:  defect                      |      Status:  new                      
 Priority:  major                       |   Milestone:  7.0.0                    
Component:  Display                     |     Version:  unspecified              
 Keywords:  cairo, resolution, surface  |    Platform:  Linux                    
      Cpu:  x86-64                      |  
 Steps to reproduce:

 g.region rast=elevation res=0.1 -p
 projection: 99 (Lambert Conformal Conic)
 zone:       0
 datum:      nad83
 ellipsoid:  a=6378137 es=0.006694380022900787
 north:      228500
 south:      215000
 west:       630000
 east:       645000
 nsres:      0.1
 ewres:      0.1
 rows:       135000
 cols:       150000
 cells:      20250000000

 Rendering via Cairo driver fails:

 d.mon cairo
 d.rast elevation
 ERROR: Cairo_begin_raster(): Failed to create surface (invalid value
 (typically too big) for the size of the input (surface, pattern, etc.)).
 Using rows: 135000, cols: 150000

 While PNG driver works:

 d.mon -r
 d.mon png
 d.rast elevation

 wxGUI also works since it uses it's own display resolution.


Ticket URL: <>

grass-dev mailing list
grass-dev <at>