GRASS GIS | 26 Apr 03:20 2015

[GRASS GIS] #2664: The r.watershed module documentation has the wrong value for cells that do not get included in a complete watershed.

#2664: The r.watershed module documentation has the wrong value for cells that do
not get included in a complete watershed.
-------------------------------------+-------------------------
 Reporter:  swendel621               |      Owner:  grass-dev <at> …
     Type:  defect                   |     Status:  new
 Priority:  normal                   |  Milestone:  7.0.1
Component:  Docs                     |    Version:  7.0.0
 Keywords:  r.watershed, basin, doc  |        CPU:  All
 Platform:  All                      |
-------------------------------------+-------------------------
 In the current online r.watershed module's help documentation, there is a
 conflicting statement to the output generated for the basin parameter.

 [http://grass.osgeo.org/grass71/manuals/r.watershed.html]

 In the text it says, "0 values indicate that the cell is not part of a
 complete watershed basin in the current geographic region."

 If I run r.watershed on the Elevation sample data and set the threshold to
 10000, the output basin will have areas on the edges that do not generate
 a basin. The values of these areas are null instead of 0 like the
 documentation makes it sounds like it should get. It makes sense for the
 values to be null instead of 0 so the documentation needs to be updated.

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

_______________________________________________
grass-dev mailing list
(Continue reading)

GRASS GIS | 26 Apr 02:57 2015

[GRASS GIS] #2663: Add test for r.watershed module

#2663: Add test for r.watershed module
-------------------------+-------------------------
 Reporter:  swendel621   |      Owner:  grass-dev <at> …
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  7.0.1
Component:  Default      |    Version:  unspecified
 Keywords:               |        CPU:  Unspecified
 Platform:  Unspecified  |
-------------------------+-------------------------
 I built a test for the r.watershed module to be incorporated into the
 software that can be found here:

 https://github.com/swwendel/GRASS-r.Watershed-UnitTest

 Thanks!
 Stephanie Wendel

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

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Michael Barton | 25 Apr 19:12 2015
Picon

Re: grass-dev Digest, Vol 110, Issue 36

The renaming and regularization of modules for the GRASS 7 release took place over multiple months IIRC. Martin and Markus sent out repeated requests/invitation for comment during this time.  There was a specific discussion thread for this but there was not a lot of comment for most of the modules. The discussion of whether and how to rename the module that is now called r.relief was on the dev list and lengthy, with quite a few people weighing in with different opinions (unlike most other renamed modules). There was a lengthy discussion thread for this too. I agree that the process needs to be open and transparent. But in this case, my recollection is that it was.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)



On Apr 24, 2015, at 12:01 PM, grass-dev-request <at> lists.osgeo.org wrote:

From: Moritz Lennert <mlennert <at> club.worldonline.be>
Subject: Re: [GRASS-dev] GRASS 7: r.shaded.relief changed name?
Date: April 24, 2015 at 1:06:16 AM MST
To: Vaclav Petras <wenzeslaus <at> gmail.com>, Carlos Grohmann <carlos.grohmann <at> gmail.com>
Cc: Helena Mitasova <hmitaso <at> ncsu.edu>, grass-dev <grass-dev <at> lists.osgeo.org>


On 23/04/15 16:25, Vaclav Petras wrote:
On Thu, Apr 23, 2015 at 8:41 AM, Carlos Grohmann
<carlos.grohmann <at> gmail.com <mailto:carlos.grohmann <at> gmail.com>> wrote:
>
> That was an interesting discussion, I'm sorry I missed it (should pay
more attention...)
>
> I think that modules names should be descriptive. When I started
learning GRASS (and GIS), back in my Masters, I knew what
r.shaded.relief would do. I wouldn't be sure in the case of r.relief or
r.shade.
> If we have r.local.relief in the addons, it's great but a new user
might not know about this, so the name still can cause confusion.
>
> Making the names shorter doesn't necessarily make them better, IMO.
>
> I'd say r.shaded.relief should stay as it was.
>
> As for r.shade, I'd go with something like r.drape.shade or
r.shade.drape (because that's what it is doing) or r.shade.mapping (but
this could be confusing as well - is it mapping the shades?..)

Thanks for the comments, Carlos. I think the desire to have short names
was definitively involved in the decision. Although they might be less
readable they have different advantages. According to it's name I might
see r.shaded.relief as something which shades the relief
(r.relief+r.shade) but it just creates the shade from relief (r.relief).
Also, r.relief, although not self-explanatory, does not invoke any
association with relief metrics or relief-related parameters because I'm
not familiar with these terms (also Google and Wikipedia seems to be
quite ignorant about them).

In any case, I should emphasize that although this is an important
feedback, the discussion already happened and now it would be impossible
or at least very hard to change it since we have already released 7.0.0.

As a side note: I think this also raises the question of how such changes are discussed and decided. I don't think many people realised that a thread entitled:

"[GRASS-SVN] r62845 - in grass/trunk/scripts: . d.shadedmap r.shadedmap"

discussed the renaming of modules.

I would encourage that in the future we go through a process that is minutely more formalies, i.e. that once the discussion in such a thread has ripened a new thread is created with subject making it clear that there is a proposal for a significant renaming of modules. Nothing worth an RFC, just a some "good practice".

Moritz


_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 25 Apr 13:23 2015

[GRASS GIS] #2662: v.in.proj crashes on Windows

#2662: v.in.proj crashes on Windows
----------------------------------+---------------------------------
 Reporter:  martinl               |      Owner:  grass-dev <at> …
     Type:  defect                |     Status:  new
 Priority:  blocker               |  Milestone:  7.0.1
Component:  LibGIS                |    Version:  svn-releasebranch70
 Keywords:  v.in.proj, r.in.proj  |        CPU:  Unspecified
 Platform:  Unspecified           |
----------------------------------+---------------------------------
 `v.in.proj` crashes on Windows (epsg:4326 -> epsg:5514)

 {{{
 D2/5:   file open: read (mode = r)
 D2/5: G__read_Cell_head
 D2/5: G__read_Cell_head_array
 D3/5: region item: proj:       3
 D3/5: region item: zone:       0
 D3/5: region item: north:      935275:00:27.10224S
 ERROR: Syntax error in cell header
 }}}

 on source:grass/trunk/vector/v.in.ogr/main.c#L591

 This issue has been apparently fixed in trunk (where it works). The last
 change of `get_window.c` is from 2014-12-29. Any idea when it was fixed
 (and backported to relbr70)?

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

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Paulo van Breugel | 25 Apr 09:52 2015
Picon

Any plans to port r.out.mbtiles to GRASS 7

Hi, I am looking at r.out.mbtiles, which looks like a very useful addon and would like to check if there are any plans to port this to python / GRASS GIS 7.0 (Hamish?)?

Rgds, Paulo
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Nikos Alexandris | 24 Apr 23:51 2015
Picon

Limit in number of "variables" for r.mapcalc?

Hi devs,

is there a limit in the number of "variables" that r.mapcalc accepts
within from 'eval'? If yes, how big is it?

I am trying to feed r.mapcalc's eval with a fairly large number of pixel
modifiers and, given that the final expression is a valid one, the
execution ends with:

    debug=1 ended with error
    Process ended with non-zero return code -11. See errors in the (error)
    output.

Thank you, Nikos
GRASS GIS | 24 Apr 19:16 2015

[GRASS GIS] #2661: sqlbuilder: verify button

#2661: sqlbuilder: verify button
------------------------------------------------+-------------------------
 Reporter:  martinl                             |      Owner:  grass-dev <at> …
     Type:  defect                              |     Status:  new
 Priority:  minor                               |  Milestone:  7.0.1
Component:  wxGUI                               |    Version:  unspecified
 Keywords:  attribute manager, dbmgr, wingrass  |        CPU:  Unspecified
 Platform:  MSWindows 7                         |
------------------------------------------------+-------------------------
 On Windows there is badly placed 'Verify' button (located in upper-left
 corner of the window).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2661>
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 | 23 Apr 01:01 2015

Fwd: Re: [SAC] Upgrading Trac/SVN VM

FYI

---------- Forwarded message ----------
From: "Martin Spott" <Martin.Spott <at> mgras.net>
Date: Apr 23, 2015 12:52 AM
Subject: Re: [SAC] Upgrading Trac/SVN VM
To: "System Administration Committee Discussion/OSGeo" <sac <at> lists.osgeo.org>
Cc:

On Wed, Apr 22, 2015 at 11:15:54PM +0200, Martin Spott wrote:

> I know the Trac web page is currently unavailable - I'm in the process
> of fixing it,

The site should be running again - on Debian Squeeze (6.0).
By accident (mistake) I also upgraded Trac from 0.11.7 on Python2.5 to
1.0.5 on Python2.6 and PostgreSQL from 8.3 to 8.4. I'm sure I broke
something, but at least the Trac pages which are listed on:

  http://trac.osgeo.org/

....  are looking functional to me.

Please report errors,

        Martin.
--
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
_______________________________________________
Sac mailing list
Sac <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Carlos Grohmann | 22 Apr 14:44 2015
Picon

GRASS 7: r.shaded.relief changed name?

Hi

I just installed the latest pkg for GRASS 7 on OSX (nice splash screen BTW)
and r.shaded.relief is now just r.relief

Is it too much if ask why this change? To me, r.shaded.relief is so much better, it describes the module. r.relief might be confusing (is it to calculate some rellief-related parameter? local relief? other morphometric parameter?).

best

Carlos



--
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sensing - 

http://orcid.org/0000-0001-5073-5572
________________
Can’t stop the signal.
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 21 Apr 22:17 2015

[GRASS GIS] #2660: r.external.out: support paths relative to the mapset, and variables

#2660: r.external.out: support paths relative to the mapset, and variables
----------------------------+-----------------------------------------------
 Reporter:  sbl             |       Owner:  grass-dev <at> …              
     Type:  defect          |      Status:  new                      
 Priority:  normal          |   Milestone:  7.0.1                    
Component:  Raster          |     Version:  svn-releasebranch70      
 Keywords:  r.external.out  |    Platform:  Unspecified              
      Cpu:  Unspecified     |  
----------------------------+-----------------------------------------------
 Currently, r.external.out uses absolute paths which may be incorrect if
 the database is accessed via a networked filesystem (or even a local
 filesystem if the mount point changes).

 If the directory given to r.external.out is relative (doesn't begin with a
 "/"), it's converted to an absolute path relative to the current mapset
 directory.

 Thereafter, any created maps will have the absolute path in their GDAL
 link (i.e. the cell_misc/<map>/gdal file).

 Thus, maps created with r.external.out can't be read if the database
 directory has "moved" relative to its location when the map was created.

 It would be helpful if paths relative to the mapset could be supported,
 and maybe additional options, e.g. the ability to use environment
 variables in paths

 Here is a test case in order to reproduce the issue:

 First I created a new and empty GRASS Location "test" on a network storage
 (NFS) from the Linux Server. This GRASS DB is mounted on LINUX (through
 mount.cifs) to `/home/stefan/R_raw_data/test'. On Windows the "Network
 drive" is mapped to " R:\Raw_data\test "

 Within this Location I crated a mapset "linux" (from the Linux Server) and
 a mapset "windows"  from my Windows 7 workstation.

 1st test case: Linux to Windows:
 On the Linux  server, and in the "linux" mapset I did:


 {{{
 r.external.out --verbose directory="/home/stefan/R_raw_data/test"
 extension=".tif" format="GTiff"
 g.region -p n=1 s=0 e=1 w=0 res=0.1
 r.mapcalc expression="linux_map=1"
 }}}

 On my Win 7 box I did:

 d.rast map= linux_map  <at> linux
 Here I got the following error message:

 {{{
 Command 'd.rast map=linux_map <at> linux' failed
 Details: ERROR 4: `/home/stefan/R_raw_data/test/linux_map.tif' does not
 exist in the file system, and is not recognised as a supported dataset
 name.
 }}}

 Then I tried relative paths:
 On Linux:

 {{{
 r.external.out --verbose directory="../../" extension=".tif"
 format="GTiff"
 r.mapcalc expression="linux_map=1" --o
 }}}

 Error message on Windows changes to:

 {{{
 Command 'd.rast map=linux_map <at> linux' failed
 Details: ERROR 4:
 `/home/stefan/R_raw_data/test/newLocation/linux/../..//linux_map.tif' does
 not exist in the file system, and is not recognised as a supported dataset
 name.
 }}}

 2nd test case: Windows to Linux:
 On my Windows box (and in the "windows" mapset) I did:

 {{{
 r.external.out --verbose directory="R:\Raw_data\test" extension=".tif"
 format="GTiff"
 r.mapcalc expression=windows_map=1
 }}}

 Which results in the following error message:

 {{{
 ERROR: Unable to make mapset element R:\Raw_data\test
 (R:\Raw_data\test/newLocation/windows/R:\Raw_data\test): No such file or
 directory
 }}}


 Then I tried relative paths:

 {{{
 r.external.out --verbose directory="../../" extension=.tif format=GTiff
 }}}


 The relative paths work for the Windows side. However, back on Linux I
 tried:
 d.rast map=windows_map <at> windows and got the following error message:


 {{{
 Command 'd.rast map=windows_map <at> windows' failed
 Details: ERROR 4:
 `R:\Raw_data\test/newLocation/windows/../..//windows_map.tif' does not
 exist in the file system, and is not recognised as a supported dataset
 name.
 }}}

--

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

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
matmar | 21 Apr 21:40 2015
Picon

GRASS command for raster and vector size

Hi list,

In the last few days I have been dealing with reduced amount of disk space
due to map algebra operations in GRASS, then I was quite interested to know
the size of GRASS objects in a easy way.

I solved the problem with /ls -lh/ but I was wondering if a GRASS module (or
a flag in an existing module) that prints the actual size of GRASS objects
(raster, vector, temporal databases, etc) may be useful for GRASS users.

I was thinking something like:
*g.size type=raster,vector -m or -g (human readable byte units like Mb or
Gb)* 

What do you think? Anybody willing to implement it?

Matteo

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/GRASS-command-for-raster-and-vector-size-tp5202348.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

Gmane