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  |  
-------------------------+--------------------------------------------------
 Hi

 I am preparing a 3D workspace to use it as input to the g.gui.animation
 tool.
 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

 Best

 Sajid

--

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

(Continue reading)

jotawski | 29 Aug 02:03 2014
Picon

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

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


P.O. BOX 70928, Sunnyvale, CA 94086
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 27 Aug 21:57 2014

[GRASS GIS] #2404: winGRASS: G_calloc error in v.to.rast

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

 v.rast.stats --> which calls v.to.rast:

 {{{
 ERROR: G_calloc: unable to allocate 236326912 * 1 bytes of memory at
 raster.c:83
 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
 }}}

 System:
  * winGRASS 7.1
  * RAM 32 GB

 Also reported here:
  * http://lists.osgeo.org/pipermail/grass-user/2009-April/050076.html

  * http://lists.osgeo.org/pipermail/grass-user/2009-April/050074.html

  * http://lists.osgeo.org/pipermail/grass-user/2009-April/050075.html


 The issue might be the row cache in v.to.rast:
  *
 http://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.rast.stats/v.rast.stats.py#L137

  * http://grass.osgeo.org/grass71/manuals/v.to.rast.html


 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 v.to.rast should be "auto" according to the amount
 of pixels in a row?

 BTW: seen again here:
  * https://gis.stackexchange.com/questions/102273/error-g-calloc-v-to-rast

--

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

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Pietro | 27 Aug 12:15 2014
Picon

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> gmail.com> 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.

Pietro
Niroshan Sanjaya | 27 Aug 11:43 2014
Picon

error in pygrass

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

Help me to solve it 
Thanks 

--
--------------------------
Niroshan Sanjaya

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

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Paulo van Breugel | 27 Aug 10:13 2014
Picon

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> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Luca Delucchi | 27 Aug 10:01 2014
Picon

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)

and

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?

[0] http://grass.osgeo.org/sampledata/north_carolina/nc_spf.tar.gz

--

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
Alessandro Samuel Rosa | 27 Aug 00:12 2014
Picon

v.perturb

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.

Best,
 
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: soil-scientist.net Skype: alessandrosamuel
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
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
 0..3..6..9..12..15..18..21..24..27..30..33..36..39..42..45..48..51..54..57..60..63..66..69..72..75..78..81..84..87..90..93..96..99..100
 }}}

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

--

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

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 26 Aug 11:34 2014

[GRASS GIS] #2402: v.distance in Long/Lat Locations on GRASS 7.0

#2402: v.distance in Long/Lat Locations on GRASS 7.0
-------------------------+--------------------------------------------------
 Reporter:  micha        |       Owner:  grass-dev <at> …              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  Default      |     Version:  unspecified              
 Keywords:               |    Platform:  All                      
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
 In stable version 6.4, when working in a Long-Lat LOCATION, v.distance
 returns geodesic distance on a sphere in meters (in the cases of point to
 point, and point to line).

 In GRASS 7.0 this feature is lost, and distances are always returned in
 the LOCATION units (i.e. degrees in a Long-Lat LOCATION). Geodesic
 distance should be the preferred behavior.

--

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

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 26 Aug 11:27 2014

[GRASS GIS] #2401: v.distance in Long/Lat Locations

#2401: v.distance in Long/Lat Locations
-------------------------+--------------------------------------------------
 Reporter:  micha        |       Owner:  grass-dev <at> …              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  6.4.5                    
Component:  Vector       |     Version:  6.4.4                    
 Keywords:               |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
 According to the manual, v.distance should, in a long-lat LOCATION, return
 geodesic distances in meters on a sphere, rather than in degrees. This
 works in the cases of point to point, and point to line.

 However in the case of point to boundary the module returns distances in
 degrees, and not geodesic distance.

--

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

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

Gmane