Luca Delucchi | 27 Nov 11:41 2014
Picon

t.rast.neighbors not working

Hi devs,

I'm working on temporal documentation replacing the example with the
future temporal dataset that I'm working on, so I'm testing more or
less all the command.

I'm not able to run t.rast.neighbors for this problem

t.rast.neighbors input=tempmean_monthly output=smooth_tempmean_monthly
base=tmean_smooth size=5 method=average nprocs=4
ERROR: Space time raster dataset <tempmean_monthly> is already in the
database. Use the overwrite flag.

I looked inside t.rast.neighbors source code and I found this line

new_sp = tgis.check_new_stds(input, "strds", dbif=dbif, overwrite=overwrite)

probably should be replaced with (I tried and it seems to work)

new_sp = tgis.check_new_stds(output, "strds", dbif=dbif, overwrite=overwrite)

--

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
Nikos Alexandris | 27 Nov 10:21 2014
Picon

i.landsat.toar on MSS5 scene

I dowloaded the scene the Landsat5 MSS scene LM50160351987287AAA03.  
After importing in a utm_z17n based Location, the bands are listed as 
B1, B2, B3 and B4.

Running i.landsat.toar fails:

i.landsat.toar -r input_prefix=B output_prefix=Rad. 
metfile=LM50160351987287AAA03_MTL.txt
Writing radiance of <B4> to <Rad.4>...
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
ERROR: Unable to open header file for raster map <B5 <at> >

Looking at 
<http://landsat.usgs.gov/band_designations_landsat_satellites.php> for 
Landsat Multispectral Scanner (MSS), the numbering of bands is right.

Running i.landsat.toar using the -n flag, does the conversion.  Kind 
of.  The output suffix addition, though, follows the band numbering 
scheme for MSS1-3, that is 4, 5, 6 and 7.  Plus, the The output range 
for bands "5", "6", and "7" is nan!.

Even by using the additional parameter sensor=mss5 doesn't solve it 
(which is likely overriden if a "metfile" is fed).  So, the module 
expects for *any* MSS scene the band numbering 4, 5, 6 and 7.

Unless I overlook something, this should be modified to adhere to the 
official naming pattern and expect 1, 2, 3, 4 for MSS4,5.  Maybe this 
will get the "right" bands to perform the conversion correctly?

Nikos
(Continue reading)

Anna Petrášová | 26 Nov 21:15 2014
Picon

temporal framework currently not working on windows

I just realized temporal framework doesn't work with recent GRASS 70 version on Windows:
t.list or t.create give me:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py", line 380,
in main
    prepare(preparation_data)
  File "C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py", line 495,
in prepare
    '__parents_main__', file, path_name, etc
  File "C:\GRASS70\GRASS GIS 7.0.0svn\scripts\t.create.py",
line 60, in <module>
    import grass.temporal as tgis
  File "C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\temporal\__init__.py", line 29, in
<module>
    from temporal_vector_algebra import *
  File "C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\tempo
ral\temporal_vector_algebra.py", line 422, in <module>
    import grass.pygrass.modules as pygrass
  File "C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\modules\__init__.py", line
2, in <module>
    from grass.pygrass.modules.interface import Module,
ParallelModuleQueue
  File "C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\__init__.py", line 9, in <module>
    from grass.pygrass.modules.interface import module
  File "C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\module.py", line 188, in <module>
    class Module(object):
  File "C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\module.py", line 591, in Module
    <at> mdebug(1, extra=_get_bash)
  File "C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\module.py", line 36, in mdebug
    msgr = get_msgr()
  File "C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\messages\__init__.py",
line 352, in get_msgr
    _instance[0] = Messenger(*args, **kwargs)
  File "C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\messages\__init__.py",
line 175, in __init__
    self.start_server()
  File "C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\messages\__init__.py",
line 185, in start_server
    self.server.start()
  File "C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\process.py", line 130,
in start
    self._popen = Popen(self)
  File "C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py", line 258,
in __init__
    cmd = get_command_line() + [rhandle]
  File "C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py", line 358,
in get_command_line
    is not going to be frozen to produce a Windows
executable.''')
RuntimeError:
            Attempt to start a new process before the
current process
            has finished its bootstrapping phase.
            This probably means that you are on Windows and
you have
            forgotten to use the proper idiom in the main
module:
                if __name__ == '__main__':
                    freeze_support()
                    ...
            The "freeze_support()" line can be omitted if
the program
            is not going to be frozen to produce a Windows
executable.

I tested with the most recent build and a user reports the same problem with r62706.

Anna
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 26 Nov 20:01 2014

[GRASS GIS] #2501: r.out.gdal -t creates offset values in raster table for integer grids with values beginning with 1

#2501: r.out.gdal -t creates offset values in raster table for integer grids with
values beginning with 1
--------------------------------------------------+-------------------------
 Reporter:  dnewcomb                              |       Owner:  grass-dev <at> …              
     Type:  defect                                |      Status:  new                      
 Priority:  normal                                |   Milestone:  7.0.0                    
Component:  Default                               |     Version:  svn-releasebranch70      
 Keywords:  r.out.gdal table attribute alignment  |    Platform:  Linux                    
      Cpu:  x86-64                                |  
--------------------------------------------------+-------------------------
 Exporting integer grids with values starting with 1 using r.out.gdal -t
 results in a raster attribute table with vertically shifted values in the
 last 3 columns.
 For example, if you have a raster with values of 1 to 5 with associated
 classes, you would expect a table that looks like this:
 OID Value MIN MAX CLASS
 1     1    1   1   flat
 2     2    2   2   summit
 3     3    3   3   ridge
 4     4    4   4   shoulder
 5     5    5   5   spur

 ( Should the OID start with 0?, not sure )

 In the current version of the software, the output table looks like this:
 OID Value MIN  MAX CLASS
 0    0     1    1    flat
 1    1     2    2    summit
 2    2     3    3    ridge
 3    3     4    4    shoulder
 4    4     5    5    spur
 5    5     0    0    ERROR

 See http://lists.osgeo.org/pipermail/grass-dev/2014-November/072021.html,


 The issue seems to be in lines 73 - 78 in r.out.gdal/attr.c:

         if (maptype == CELL_TYPE) {
           for (i = 0; i < cats.ncats; i++) {
             label = Rast_get_ith_c_cat(&cats, i, &CellMin, &CellMax);
                 GDALRATSetValueAsInt(hrat, i, 0, CellMin);
                 GDALRATSetValueAsInt(hrat, i, 1, CellMax);
                 GDALRATSetValueAsString(hrat, i, 2, label);

 With this current ugly hack I've got has the values aligned with the
 classes again, but there is an extra OID 0 line with 0 or blank values for
 the fields at the beginning of the table.

         if (maptype == CELL_TYPE) {
           for (i = 0; i < cats.ncats-1; i++) {
             label = Rast_get_ith_c_cat(&cats, i, &CellMin, &CellMax);
                 GDALRATSetValueAsInt(hrat, i+1, 0, CellMin);
                 GDALRATSetValueAsInt(hrat, i+1, 1, CellMax);
                 GDALRATSetValueAsString(hrat, i+1, 2, label);

 Sample output to this hack would be:
 OID Value MIN MAX CLASS
 0     0    0   0
 1     1    1   1   flat
 2     2    2   2   summit
 3     3    3   3   ridge
 4     4    4   4   shoulder
 5     5    5   5   spur

 This does not look quite right.

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2501>
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 | 26 Nov 19:32 2014
Picon

check on GRASS revision number

In the new trunk GRASS 7.1, I’m running into an error check like the following:

GRASS 7.1.svn (Penaguila):~ > r.flip &
[1] 76586
ERROR: Module built against version $Revision: 61095 $ but trying to use
       version $Revision: 62364 $. You need to rebuild GRASS GIS or
       untangle multiple installations.
[1]+  Exit 1                  r.flip


There is some value to this, but it may create more problems than it solves. As a test of what is happening to missing addons path, I installed from the GRASS 7 extensions library the module r.flip. While it is possible that r.flip will not work with revision 62364, many modules built for other revisions of the same GRASS version WILL work with a newer version. This is especially true with a lot of development work going on.

 A binary module is almost guaranteed to be built with a revision that predates the current one. Perhaps a warning is warranted but to prevent this from running seems extreme.

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)















_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler | 26 Nov 17:21 2014

g.list sorting and mapset issues

hi,

the updated g.list in G7 still has two issues:

1) when identical map names exist in the current and an/other
mapset(s), the  <at> mapset should be always printed (even if current):

GRASS 7.1.svn (nc_spm_08_grass7):~ > g.list rast | grep
lsat5_1987_div__pielou_size_5
lsat5_1987_div__pielou_size_5.0
lsat5_1987_div__pielou_size_5.0 <at> landsat

2) The default output should be sorted:

GRASS 7.1.svn (nc_spm_08_grass7):~ > g.list rast
...
lsat7_2002_61
lsat7_2002_62
lsat7_2002_70
lsat7_2002_80
ncmask_500m
ortho_2001_t792_1m
roadsmajor
slope
soilsID
soils_Kfactor
streams_derived
towns
urban
zipcodes
zipcodes_dbl
lsat5_1987_10
lsat5_1987_20
lsat5_1987_30
--> unsorted (in fact, likely sorted by mapset but then concatenated).

That needs to be changed here:

g.list/main.c, line 343
            for (j = 0; (mapset = G_get_mapset_name(j)); j++)
                make_list(fp, elem, mapset, separator, flag.type->answer,
                          flag.mapset->answer, use_region ? &window : NULL);

Thanks
Markus
Markus Neteler | 26 Nov 17:13 2014

Re: [GRASS-SVN] r62026 - in grass/trunk: display/d.info include/defs lib/display

On Thu, Sep 18, 2014 at 12:43 AM,  <svn_grass <at> osgeo.org> wrote:
> Author: glynn
> Date: 2014-09-17 15:43:22 -0700 (Wed, 17 Sep 2014)
> New Revision: 62026
>
> Modified:
>    grass/trunk/display/d.info/main.c
>    grass/trunk/include/defs/display.h
>    grass/trunk/lib/display/r_raster.c
>    grass/trunk/lib/display/setup.c
> Log:
> Change handling of display frame, graphical clip window
>  Replace D_get_window with D_get_frame
>  Add D_get_clip_window, D_set_clip_window
>  Add D_set_clip_window_to_map_window, D_set_clip_window_to_screen_window
>  Store initial frame size within display library
>  Change D_setup* functions to set graphical clip window
>

Should this be backported to relbr7?

Markus
Martin Landa | 26 Nov 17:07 2014
Picon

test scripts in the path

Hi,

is it need to have such script in the path?

test.r3flow        test.raster3d.lib

Martin

--

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
Markus Neteler | 26 Nov 16:44 2014

G7: turning manual page examples into test cases

Hi,

in the recent past I added a series of examples to various manual
pages. Most of them might qualify for (basic) testing of the
respective command.
Since it is a bit time consuming to write these standard tests
manually, would there be a chance to develop a test case generator
e.g. driven by a template?

Markus
Nikos Alexandris | 26 Nov 15:54 2014
Picon

On i.atcorr support for WorldView2, QB2

Is there anyone willing to check ticket #2059 out? [0]

I am attaching an `R` session through which I obtained the numbers fed 
to `create_iwave.py` for the template creation.

Is there, perhaps, important to keep the band-width order (instead of 
the band numbering in delivered products)? Maybe Nikos Ves' approach is 
right for Landsat8 [1] which follows the band-width order (and not the 
official band designation) works (for me) correctly.

Nikos A

[0] <http://trac.osgeo.org/grass/ticket/2059>?
[1] <http://trac.osgeo.org/grass/ticket/2305#comment:7>
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 26 Nov 15:28 2014

[GRASS GIS] #2500: r.surf.idw vs. r.surf.idw2

#2500: r.surf.idw vs. r.surf.idw2
-------------------------+--------------------------------------------------
 Reporter:  martinl      |       Owner:  grass-dev <at> …              
     Type:  task         |      Status:  new                      
 Priority:  blocker      |   Milestone:  7.0.0                    
Component:  Default      |     Version:  svn-trunk                
 Keywords:               |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
 Do we need the both modules in G7?

  * could they be merged?
  * or one of them moved to addons

 Are there other candidates which could be moved to addons?

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2500>
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