osgeo / grass-addons

GRASS GIS Addons Repository

The Open Source Geospatial Foundation

The Open Source Geospatial Foundation is a not-for-profit organization to empower everyone with open source geospatial. The software foundation directly supports projects serving as an outreach and advocacy organization providing financial, organizational and legal support for the open-source geospatial community. OSGeo works with our sponsors and partners to foster an open approach to software, standards, data, and education.

OSGeo has US 501(c)(4) legal status as a not-for-profit organization

This repository contains official branding, documents, and correspondence. Access is limited to volunteers working with our foundation committees.

License

All work here is copyright The Open Source Geospatial Foundation. Unless otherwise stated this content is made available to you under an appropriate Creative Commons license.

Document licenses for software developers:

• CCBY - permissive license similar to MIT or BSD allowing content to be remixed by other authors, as long as they give us a credit somewhere. This is a great choice for outreach and increases our brand awareness.

• CCBYSA - protective license similar to GPL allows content to be remixed by other authors, as long as what they are writing is also using a share-alike license.

• CC0 - Creative Commons public domain tools are used for outreach where we want the information to have as far a reach as possible. When using this approach we do not even ask for attribution! We have to be careful using this license to avoid including any content or photos that we did not create ourselves.

Not all of our content is licensed for modification:

• CCBYND - some documents are not useful to share in a modified form: our organization charter, memorandums of understanding with partners, official legal documents, letters of recommendation, letters of support. In these cases we allow free distribution, but not modification, of said content. Authors may still quote or cite these materials, and this GitHub repository provides a stable URL. Be sure to include the revision when citing as these documents change over time.

Copyright

The Open Source Geospatial Foundation maintains copyright on all materials in the repository (except otherwise noted). This material was produced by our volunteers on behalf of our organization or donated via a pull request to our foundation in accordance with our contributor license agreement.

What does "except otherwise noted" mean? Some CCBYSA photos are used in our presentation templates and branding guide. We have included these photos in our repository, appropriately crediting the original authors in the initial commit message and in the directory README.md file.

grass-addons's Issues

r.fill.gaps: compilation warning

r.fill.gaps works nicely and fast with a tiny memory footprint.

When compiling it, a warning comes up. As I am not sure how serious it is I bring it up as an issue:

grass-addons/grass7/raster/r.fill.gaps/main.c

Line 164 in d899a96

weight_matrix_line_length, "[????] ",

main.c: In function ‘print_weights_matrix’:
main.c:164:57: warning: too many arguments for format [-Wformat-extra-args]
  164 |                              weight_matrix_line_length, "[????] ",
      |                                                         ^~~~~~~~~

While at it, also this one may be fixed:

main.c: In function ‘main’:
main.c:1025:12: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
 1025 |     mapset = G_find_raster(input, "");
      |            ^

[Bug] v.what.strds.timestamp not including the first timestamp

Name of the addon

v.what.strds.timestamp

Describe the bug

The where condition used for the vector feature selection here uses > start_time (strict inequality). It can be a problem in the case of vector features stamped with a day timestamp and raster maps time-spanning only one day as no vector features would be selected.

Exempli gratia: A vector feature is timestamped with a value of 2020-05-03. We have STRDS containing two rasters stamped as 2 May 2020 00:00:00 / 3 May 2020 00:00:00 and 3 May 2020 00:00:00 / 4 May 2020 00:00:00. The vector feature would not get any value.

Expected behavior

As a non-strict inequality is used here for the STRDS selection tempwhere, I would expect the same approach (allowing >=) also in the code line mentioned above.

System description (please complete the following information):

• Operating System: Debian GNU/Linux bullseye/sid
• GRASS GIS version 7.9 dev (commit f0966f1969c73a3797c3a87343add28d6fcaa0ba)

[Bug] r.fuzzy.system: incorrect output

Name of the addon
r.fuzzy.system

Describe the bug
The output of r.fuzzy.system does not label the raster correctly. The output result is a DCELL raster with values defined by the defuzzification rules, AND labels for each value that provide the fuzzy set values prior to the defuzzification. Those labels are incorrect. The numerical values may also be incorrect, but I need to dig into this further before I can be certain.

To Reproduce
Run a simple r.fuzzy.system and examine the outputs. Visually the output raster appears correct, but the labels assign the wrong fuzzy classes. I'm also concerned that the output is not just labeled incorrectly, but is also numerically incorrect.

Example to be run in nc_spm_08_grass7

# distance to major roads
g.region raster=roadsmajor
r.grow.distance -m input=roadsmajor distance=dist

# crisp result
cat << EOF | r.reclass rules=- input=dist output=crisp
0 thru 1500 = 1 near
1500 thru 99999 = 2 far
EOF

cat << EOF > fuzzy.map
# fuzzy maps for example
% dist
$ near {right; 1000, 2000; linear; 0; 1}
$ far {left; 1000, 2000; linear; 0; 1}

% _OUTPUT_ 
$ near {right; 40,60; linear; 0;1}
$ far {left; 40,60; linear; 0;1}
EOF

cat << EOF > fuzzy.rules
# fuzzy rules for example
$ near { dist = near }
$ far { dist = far }
EOF

r.fuzzy.system -m maps=fuzzy.map rules=fuzzy.rules output=fuzzy

Expected behavior
Correct labeling

Screenshots

Crisp result

Fuzzy result

But, clicking near a road shows this:

Having both near=1.0 and far=1.0 is incorrect. That situation should never exist, because near = 1 output occurs when dist = near, which is defined as dist < 1000. From 1000 to 2000 dist is still near, but with membership < 1.0. Furthermore, output with far = 1 occurs when dist = far, which only occurs with full membeship (far = 1) for dist > 2000. The two do not overlap.

Examining the fuzzy_near and fuzzy_far maps made with the -m option to r.fuzzy.system verifies that the membership with fuzzy_far is 0 if you click near a road.

Finally, maximum fuzzy values are never equal to 1 (full membership) even when they should be - for example when fuzzy_near = 1 and fuzzy_far = 0, regardless of the implication, family, or defuz options selected. From this I question the correctness of the numerical results, not just the label results.

System description (please complete the following information):
Linux, GRASS GIS 7.8.2

Infinity does not work in Windows - case with r.hants and r.series.lwr

Describe the bug
Running r.series and r.series.lwr returns wrong results in Windows while using 'infinity' in the parameter 'range'
To Reproduce
Run r.series.lwr on any set of temporal raster maps using the following command:
r.series.lwr -l -h -i input=map1,map2,map3,map4 suffix=_lwr order=2 weight=tricube range=0,inf fet=0.5 dod=3 maxgap=3 --o

And if you test the result with 'r.univar' it will return zeroes, while it return correct output in Linux.
If you replace range=0,inf with range=0,1000000, then the command works in windows too.

To test attached a sample Location/Mapset and try the following commands:
grass78 \path\to\TMPLOC\TMPMAP
r.series.lwr -l -h -i input=ETact_SEBAL_2019_03_mm_month,ETact_SEBAL_2019_04_mm_month,ETact_SEBAL_2019_05_mm_month,ETact_SEBAL_2019_06_mm_month,ETact_SEBAL_2019_07_mm_month,ETact_SEBAL_2019_08_mm_month,ETact_SEBAL_2019_09_mm_month,ETact_SEBAL_2019_10_mm_month,ETact_SEBAL_2019_11_mm_month order=2 fet=0.5 dod=3 range=0,inf maxgap=3
r.univar ETact_SEBAL_2019_03_mm_month_lwr
Screenshots
r.univar result in Windows:

r.univar result in Linux (Ubuntu 18.04):

System description (please complete the following information):

• Operating System: Windows 10
• GRASS GIS version 7.8.3

** Related open tickets **
https://trac.osgeo.org/grass/ticket/3432
https://trac.osgeo.org/grass/ticket/2919

Test Location/Mapset
TMPLOC.zip

[Bug] i.sentinel.download: incomplete except/try for sentinelsat library presence

Name of the addon
i.sentinel.download crashes unelegantly on machines lacking the sentinelsat library:

GRASS 7.8.4dev (latlong_wgs84):~ > i.sentinel.download -l settings=~/.sentinel_esa producttype=S2MSI2A start=2018-01-01 end=2018-12-31
ERROR: Module requires sentinelsat library: No module named 'sentinelsat'
Traceback (most recent call last):
  File "/home/mneteler/.grass7/addons/scripts/i.sentinel.download", line 212, in __init__
    from sentinelsat import SentinelAPI
ModuleNotFoundError: No module named 'sentinelsat'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mneteler/.grass7/addons/scripts/i.sentinel.download", line 455, in main
    downloader = SentinelDownloader(user, password, api_url)
  File "/home/mneteler/.grass7/addons/scripts/i.sentinel.download", line 214, in __init__
    gs.fatal(_("Module requires sentinelsat library: {}").format(e))
  File "/home/mneteler/software/grass78_git/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py", line 703, in fatal
    sys.exit(1)
SystemExit: 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mneteler/.grass7/addons/scripts/i.sentinel.download", line 492, in <module>
    sys.exit(main())
  File "/home/mneteler/.grass7/addons/scripts/i.sentinel.download", line 476, in main
    except StandardError as e:
NameError: name 'StandardError' is not defined

Describe the bug
The error message should appear properly and the undefined variable be fixed.

Software

• GRASS GIS 7.8 dev
• python --version: Python 3.8.3

[Bug] r.colors.out_sld: TypeError: write() argument must be str, not bytes

Name of the addon
r.colors.out_sld

Describe the bug

Using the addon leads to an error:

GRASS 7.8.3dev (latlong_wgs84):~ > r.colors.out_sld map=ecuador_nasadem_30m style=srtm_plus output=ecuador_nasadem_30m.sld  --o
Traceback (most recent call last):
  File "/home/mneteler/.grass7/addons/scripts/r.colors.out_sld", line 177, in <module>
    sys.exit(main())
  File "/home/mneteler/.grass7/addons/scripts/r.colors.out_sld", line 173, in main
    o.write(sld.encode('utf8'))
TypeError: write() argument must be str, not bytes

The line is this one:

grass-addons/grass7/raster/r.colors.out_sld/r.colors.out_sld.py

Line 173 in 68f5291

o.write(sld.encode('utf8'))

System description (please complete the following information):

version=7.8.3dev
date=2020
revision=ac21f311f
build_date=2020-01-02
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=
libgis_date=
WARNING: GRASS GIS libgis version and date number not available
proj=5.2.0
gdal=2.3.2
geos=3.7.1
sqlite=3.30.0

[Bug] TypeError r.futures.potential.py

Describe the bug
I'm using the r.futures.potential module with the dredge function to find the best model, using the command:

r.futures.potential -d input=sampling output=potential.csv columns=devpressure_1,slope,road_dens_perc,forest_smooth_perc,dist_to_water_km,dist_to_protected_km,dist_interchanges_km,travel_time_cities developed_column=urban_2011 subregions_column=counties min_variables=4 max_variables=7 --overwrite

This results in the following error:
Traceback (most recent call last):
File "C:\Users\elyss\AppData\Roaming\GRASS7\addons/scripts
/r.futures.potential.py", line 216, in
sys.exit(main())
File "C:\Users\elyss\AppData\Roaming\GRASS7\addons/scripts
/r.futures.potential.py", line 155, in main
if dredge and minim > maxv:
TypeError: '>' not supported between instances of 'int' and
'str'

To Reproduce
I'm following this tutorial with my own data:
https://grasswiki.osgeo.org/wiki/FUTURES_tutorial

System description (please complete the following information):
Windows 10
GRASS GIS version 7.8

g.version -rge:
version=7.8.2
date=2019
revision=3900fb114
build_date=2019-12-11
build_platform=x86_64-w64-mingw32
build_off_t_size=8
libgis_revision=00000
libgis_date="?"
proj=6.2.1
gdal=3.0.2
geos=3.8.0
sqlite=3.29.0

r.learn.ml2: fails if training_map does not contain category labels

Name of the addon
r.learn.ml2 (r.learn.predict/r.learn.train)

Describe the bug
Not a bug, because it is indicated in the input options for r.learn.train that the training_map must contain labelled pixels. If they don't have category labels, r.learn.predict fails with the following error message:

Traceback (most recent call last):
  File "/root/.grass7/addons/scripts/r.learn.predict", line 172, in <module>
    main()
  File "/root/.grass7/addons/scripts/r.learn.predict", line 167, in main
    r.category(map=output, rules=rules_file, separator="comma")
  File "/usr/local/grass78/etc/python/grass/pygrass/modules/interface/module.py", line 650, in __call__
    return self.run()
  File "/usr/local/grass78/etc/python/grass/pygrass/modules/interface/module.py", line 771, in run
    self.wait()
  File "/usr/local/grass78/etc/python/grass/pygrass/modules/interface/module.py", line 794, in wait
    module=self.name, errors=stderr)
grass.exceptions.CalledModuleError: Module run r.category r.category map=classification_map_5classes_2019 separator=comma rules=/actinia_core/grassdb/dortmund/nrw_19.tmp/23aab7009ad3/2170.0 ended with error
Process ended with non-zero return code -11. See errors in the (error) output.

This is because in this case, class_labels is not None, but an empty dictionary. It would be great if r.learn.ml2 also worked without category labels assigned to training_map (also for consistency with r.learn.ml).

To Reproduce
Run r.learn.train and r.learn.predict using a training_map without category labels.

System Description
-GRASS 7.8.4, Linux

[Bug] Failure to install db.join

Name of the addon
db.join

Describe the bug
Trying to install db.join via the graphical g.extension results in an error. Installing other add-on modules (e.g. r.) works. I guess it is a problem with the path (/trunk/*); I don't know where this reference to svn comes from?!

Fetching <db.join> from GRASS GIS Addons repository (be patient)...
svn: E170000: URL 'https://github.com/OSGeo/grass-
addons/trunk/grass7/database/db.join' doesn't exist
ERROR: GRASS Addons <db.join> not found

To Reproduce

# Does not work
g.extension extension=db.join 
# Works                                                                           
g.extension extension=r.fuzzy.logic     

System description (please complete the following information):
GRASS version: 7.9.dev
Code revision: 8eba412
Build date: 2020-02-27
Build platform: x86_64-pc-linux-gnu
GDAL: 3.1.0dev-c74609560e
PROJ: 6.2.1
GEOS: 3.8.0
SQLite: 3.29.0
Python: 3.7.5
wxPython: 4.0.6
Platform: Linux-5.3.0-40-generic-x86_64-with-Ubuntu-19.10-eoan

Emissivity retrieval problem i.landsat8.swlst

Name of the addon
i.landsat8.swlst

Describe the bug
When I try to run the addon, an error message terminates the procedure saying:
"KeyError: 'Cropland'"

This error occurs at the end of the following process:

"|i Masking for pixel values <61440> in the Quality Assessment band.
Creating inverted raster MASK...
All subsequent raster operations will be limited to the MASK area. Removing or renaming raster map named 'MASK' will restore raster operations to normal.

|i Rescaling LC08_L1TP_192028_20200315_20200325_01_T1_B10@PERMANENT digital numbers to spectral radiance

|i Converting spectral radiance to at-Satellite Temperature

|i Rescaling LC08_L1TP_192028_20200315_20200325_01_T1_B11@PERMANENT digital numbers to spectral radiance

|i Converting spectral radiance to at-Satellite Temperature
Raster MASK removed
Traceback (most recent call last):
File "C:\Users\Jacopo e Teo\AppData\Roaming\GRASS7\addons/
scripts/i.landsat8.swlst.py", line 1256, in
sys.exit(main())
File "C:\Users\Jacopo e Teo\AppData\Roaming\GRASS7\addons/
scripts/i.landsat8.swlst.py", line 1114, in main
split_window_lst = SplitWindowLST(emissivity_class)
File "C:\Users\Jacopo e Teo\AppData\Roaming\GRASS7\addons
etc\i.landsat8.swlst\split_window_lst.py", line 195, in
init
self.average_lse_mapcalc =
self._build_average_emissivity_mapcalc()
File "C:\Users\Jacopo e Teo\AppData\Roaming\GRASS7\addons
etc\i.landsat8.swlst\split_window_lst.py", line 474, in
_build_average_emissivity_mapcalc
e10_t10, e10_t11 =
self._retrieve_average_emissivities('Cropland')
File "C:\Users\Jacopo e Teo\AppData\Roaming\GRASS7\addons
etc\i.landsat8.swlst\split_window_lst.py", line 264, in
_retrieve_average_emissivities
emissivity_b10 = EMISSIVITIES[emissivity_class].TIRS10"

So it appears it has come problems in retrieving emissivity from land cover class. I used the FROM GLC land cover classification from 2015, but no value of emissivity seems to be associated with the classification, so apparently the algorithm is not able to retrieve it.

System description:

• Operating System: Windows 10 Pro v. 1903
• GRASS GIS version: 7.8.2
• System time and number format set to United States

Thanks in advance.

t.rast.kappa: typo in import

t.rast.kappa

Describe the bug
Typo in https://github.com/OSGeo/grass-addons/blob/master/grass7/temporal/t.rast.kappa/t.rast.kappa.py#L83

To Reproduce
See: https://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.8.1/logs/t.rast.kappa.log

[Bug] r.fuzzy.system - core dump and incorrect examples

Name of the addon
r.fuzzy.system

Describe the bug
Core dump when running the example code. I have to run a modified version of the example code in order for it to even start to run. Modifications included below.

To Reproduce
Steps to reproduce the behavior:

1. Run the https://grass.osgeo.org/grass78/manuals/addons/r.fuzzy.system.html example code:

grass -c ./spearfish60_grass7/fuzzy
r.stream.extract elevation=elevation.10m threshold=2000 stream_rast=streams direction=dirs
r.stream.order stream_rast=streams dir=dirs horton=horton
r.mapcalc "horton3 = if(horton>2,horton,null())"
r.stream.distance stream=streams dir=dirs elevation=elevation.10m method=downstream distance=distance

Changes between the code above and the example code include:

2c2
< r.stream.order stream=streams dir=dirs horton=horton
---
> r.stream.order stream_rast=streams dir=dirs horton=horton
4c4
< r.stream.distance stream=streams dir=dirs dem=elevation.10m method=downstream distance=distance elevation=elevation 
---
> r.stream.distance stream=streams dir=dirs elevation=elevation.10m method=downstream distance=distance

Then, when trying to run the next and most important line from the example, r.fuzzy.system, the following issues arise.

1. ERROR: Raster map <elevation> not found solved with g.copy elevation.10m@PERMANENT,elevation
2. r.fuzzy.system reports ERROR: Raster map <flood> not found which is strange, because flood is an output map. I can fix this by r.mapcalc "flood = 0" and then adding a --overwrite flag to the r.fuzzy.system call

r.fuzzy.system maps=flood.map rules=flood.rul output=flood --o

Now the code can begin to run, but

> r.fuzzy.system maps=flood.map rules=flood.rul output=flood --o
Calculate...
Segmentation fault (core dumped)

Expected behavior

I expect to recreate the example in the documentation

Debug Information

I have tried to debug this following the advice at https://grasswiki.osgeo.org/wiki/GRASS_Debugging

gdb --args ~/local/src/grass/dist.x86_64-pc-linux-gnu/bin/r.fuzzy.system maps=flood.map rules=flood.rul output=flood --o

and the results are:

(gdb) run
Starting program: /home/kdm/local/src/grass/dist.x86_64-pc-linux-gnu/bin/r.fuzzy.system maps=flood.map rules=flood.rul output=flood --o
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffec351700 (LWP 2861558)]
[New Thread 0x7fffe6350700 (LWP 2861559)]
[New Thread 0x7fffe034f700 (LWP 2861560)]
[New Thread 0x7fffdc34e700 (LWP 2861561)]
[New Thread 0x7fffd834d700 (LWP 2861562)]
[New Thread 0x7fffd234c700 (LWP 2861563)]
[New Thread 0x7fffca34b700 (LWP 2861564)]
Calculate...
   0%
Thread 1 "r.fuzzy.system" received signal SIGSEGV, Segmentation fault.
0x00005555555583ac in fuzzy (cell=100000000, set=0x0) at fuzzylogic.c:8
8           if (!set->side) {           /* both left and right */
(gdb) bt full
#0  0x00005555555583ac in fuzzy (cell=100000000, set=0x0) at fuzzylogic.c:8
        x = <optimized out>
#1  0x000055555555b1fb in implicate () at system.c:37
        i = 0
        j = 0
        set_index = <optimized out>
        consequent = <optimized out>
        max_antecedent = 1
        max_agregate = 0
        result = 100000000
#2  0x0000555555557dff in main (argc=<optimized out>, argv=<optimized out>) at main.c:225
        file_vars = <optimized out>
        file_rules = <optimized out>
        par_family = <optimized out>
        par_resolution = <optimized out>
        par_defuzzify = <optimized out>
        par_implication = <optimized out>
        in_coor_opt = <optimized out>
        opt_output = <optimized out>
        history = {fields = {0x555555560210 "", 
            0x440 <error: Cannot access memory at address 0x440>, 
            0x10 <error: Cannot access memory at address 0x10>, 
            0x4000000042 <error: Cannot access memory at address 0x4000000042>, 
            0x2 <error: Cannot access memory at address 0x2>, 0x0, 0x0, 
            0x770000007c <error: Cannot access memory at address 0x770000007c>}, 
          nlines = 110, lines = 0x43414c5042444341}
        module = <optimized out>
        out_multiple = <optimized out>
        out_membership = <optimized out>
        nrows = 477
        ncols = 634
        row = 0
        col = 106
        outfd = 3
        tmp = <optimized out>
        out_buf = 0x5555555e1e10
        i = <optimized out>
        j = <optimized out>
        n = <optimized out>
(gdb) 

From this, and set=0x0 I think that the set is undefined, but I am not yet sure how to fix this.

System description (please complete the following information):

Linux, Kubuntu 20.04. GRASS 7.8.2

g.version -rge
version=7.8.2
date=2019
revision=exported
build_date=2020-03-24
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=00000
libgis_date="?"
proj=6.3.1
gdal=3.0.4
geos=3.8.0
sqlite=3.31.1

[Bug] r.skyview values greater than 1

r.skyview

Bug: values greater than 1
r.skyview should produce a map with values between 0 and 1 representing the openness of terrain, but produces maps with max values as high as 1.54 for the NC sample dataset.

To Reproduce
Steps to reproduce the behavior:

1. Start GRASS GIS in the NC sample dataset
2. Install the r.skyview addon:

g.extension extension=r.skyview

3. Set the region

g.region raster=elev_lid792_1m

4. Compute the skyview factor

4. Check if raster values are 1 or below

d.legend raster=skyview
d.rast map=skyview values=1.0-1.55
r.info map=skyview

Expected behavior
The skyview factor map should have values between 0.0 and 1.0

Screenshots

System description (please complete the following information):

• Operating System: Windows 10
• GRASS GIS version 7.8.3

[Bug] i.image.bathymetry needs corrections to the R scripting calls to run all options

Describe the bug
i.image.bathymetry can call the R GWModel program with three options, Adaptive
Gaussian , Bisquare, and Fixed Gaussian. If there are issues running bisquare or adaptive, the script fails over to Fixed. With versions 3.5.3 and 3.6.3 of R, the current call to the R package raster fails and the script runs GWR in Fixed Gaussian mode , no matter what option is given in the command

To Reproduce
Steps to reproduce the behavior:

1. Load multispectral imagery into GRASS ( Sentinel 2 bands 2,3,4,8, and 11) for an area of interest with a water body for which bathymetry is needed. Also load know depth points, tide level, and a polygon area of interest.

2. Set region to match Area of interest with resolution matching satellite imagery.

3. Run script from the command line. ( Example) i.image.bathymetry blue_band=T18STF_20191212T155641_B02_10m green_band=T18STF_20191212T155641_B03_10m red_band=T18STF_20191212T155641_B04_10m nir_band=T18STF_20191212T155641_B08_10m band_for_correction=T18STF_20191212T155641_B11_20m calibration_points=bathy_points calibration_column=depth depth_estimate=depth_out area_of_interest=lake_Shoreline_trim_buffer

4. See error
   Attaching package: 'raster'

The following object is masked from 'package:data.table':

shift

Warning message:
package 'raster' was built under R version 3.5.3
Error in .read_rast_non_plugin(vname = vname, NODATA = NODATA, driverFileExt = driverFileExt, :
no stars import yet
Calls: readRAST -> tryCatch -> tryCatchList -> .read_rast_non_plugin
Execution halted
Integer outflow...
Running Fixed-GWR using gaussian kernel...

Expected behavior
A clear and concise description of what you expected to happen.
The default should use the Adaptive Guassian kernel

Calculating optimal bandwidth using gaussian kernel..
Adaptive bandwidth: 217 CV score: 1608.003
Adaptive bandwidth: 142 CV score: 1511.212
Adaptive bandwidth: 94 CV score: 1430.953
Adaptive bandwidth: 66 CV score: 1335.32
Adaptive bandwidth: 47 CV score: 1271.241
Adaptive bandwidth: 37 CV score: 1249.903
Adaptive bandwidth: 29 CV score: 1231.113
Adaptive bandwidth: 25 CV score: 1217.598
Adaptive bandwidth: 22 CV score: 1212.767
Adaptive bandwidth: 20 CV score: 1207.13
Adaptive bandwidth: 19 CV score: 1208.674
Adaptive bandwidth: 21 CV score: 1211.075
Adaptive bandwidth: 20 CV score: 1207.13

Calculating euclidean distance

Running A-GWR using gaussian kernel
Reading input data...
100%
146789 points found in input file
Writing to output raster map...
100%

Screenshots
If applicable, add screenshots to help explain your problem.

System description (please complete the following information):

• Operating System: Windows 10
• GRASS GIS version 7.8.3
• R versions 3.5.3 and 3.6.3

Additional context
Add any other context about the problem here.

[Bug] r.basin: g.region conflict

Name of the addon
r.basin

Describe the bug
I run the application and everything seems to go well, until I get this message: ERROR: Region resolution and raster map <Basin_DEM_strahler> resolution differs. Run 'g.region raster=Basin_DEM_strahler' to set proper region resolution.

No problems on calculating other parameters, but stops there though. I run 'g.region raster=Basin_DEM_strahler', but still get the same error. I changed the outlet coordinates, and still get the same error.

To Reproduce
Load inputs and run.

Screenshots

Additional context
Windows 10. Grass 7.8.3

[Bug]: i.ortho.corr: import os2emxpath fails

The addon compilation fails here:

grass-addons/grass7/imagery/i.ortho.corr/i.ortho.corr.py

Line 83 in 1069b08

import os2emxpath

https://grass.osgeo.org/addons/grass7/logs/
--> https://grass.osgeo.org/addons/grass7/logs/i.ortho.corr.log

/usr/bin/install -c  i.ortho.corr.py /home/neteler/.grass7/addons/scripts/i.ortho.corr
if [ "/home/neteler/.grass7/addons/scripts/i.ortho.corr" != "" ] ; then GISRC=/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu/demolocation/.grassrc78 GISBASE=/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu PATH="/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu/bin:/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu/bin:/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu/scripts:$PATH" PYTHONPATH="/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu/etc/python:/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu/gui/wxpython:$PYTHONPATH" LD_LIBRARY_PATH="/home/neteler/.grass7/addons/bin:/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu/bin:/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu/scripts:/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu/lib:/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu/lib:" LC_ALL=C LANG=C LANGUAGE=C /home/neteler/.grass7/addons/scripts/i.ortho.corr --html-description < /dev/null | grep -v '</body>\|</html>' > i.ortho.corr.tmp.html ; fi
Traceback (most recent call last):
  File "/home/neteler/.grass7/addons/scripts/i.ortho.corr", line 83, in <module>
    import os2emxpath
ModuleNotFoundError: No module named 'os2emxpath'
make: *** [/home/neteler/src/releasebranch_7_8/dist.x86_64-pc-linux-gnu//include/Make/Html.make:14: i.ortho.corr.tmp.html] Error 1
rm i.ortho.corr.tmp.html

Which dependency do I have to install on grass.osgeo.org, or, can os2emxpath be replaced?

[Bug] Compilation error for new version of r.landscape.evol

Name of the addon
r.landscape.evol

Describe the bug
Hi all, I have just added a substantially new version of r.landscape.evol to the repo, but for some reason I cannot get it to install correctly with g.extension. I can't think of any code change that would do this, and I believe I have configured the Makefile and html documentation properly. Here's the error from g.extension, and any suggestions on what to change will be very much appreciated!

g.extension extension=r.landscape.evol                                          
Fetching <r.landscape.evol> from GRASS GIS Addons repository (be patient)...
Compiling...
Traceback (most recent call last):
  File "/usr/lib/grass78/tools/g.html2man.py", line 45, in
main
    p.feed(line)
  File "/usr/lib/python3.8/html/parser.py", line 111, in
feed
    self.goahead(0)
  File "/usr/lib/python3.8/html/parser.py", line 173, in
goahead
    k = self.parse_endtag(i)
  File "/usr/lib/python3.8/html/parser.py", line 421, in
parse_endtag
    self.handle_endtag(elem)
  File "/usr/lib/grass78/tools/ghtml.py", line 231, in
handle_endtag
    if self.pop() == tag:
  File "/usr/lib/grass78/tools/ghtml.py", line 185, in pop
    self.excluded = self.excluded_stack.pop()
IndexError: pop from empty list
During handling of the above exception, another exception
occurred:
Traceback (most recent call last):
  File "/usr/lib/grass78/tools/g.html2man.py", line 78, in
<module>
    main()
  File "/usr/lib/grass78/tools/g.html2man.py", line 49, in
main
    (infile, err.lineno, err.offset, err.msg))
AttributeError: 'IndexError' object has no attribute
'lineno'
make: *** [/usr/lib/grass78/include/Make/Html.make:11: /tmp/
grass7-iullah-439490/tmpnphof_e7/r.landscape.evol/docs/man/m
an1/r.landscape.evol.1] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.

To Reproduce
Steps to reproduce the behavior:

1. Go to g.extension
2. Raster> r.landscape.evol
3. Install
4. See error

Expected behavior
Should compile without error.

System description (please complete the following information):

• Linux, Pop!_OS 20.04
• GRASS GIS version [e.g. 7.8.2]

[Bug] i.sentinel.import deletes the unzipped folder without any warning

Name of the addon
i.sentinel.import

Describe the bug
i.sentinel.import erases the unzipped folder after writing the metadata to the imported bands. That "new" (maybe only for me) behaviour forces the users to unzip again if they want to use i.sentinel.mask just after the import, because they need to pass the MTD_TL.xml file. This was not the behaviour with an (older?) i.sentinel version, when I started working in this workflow a couple of weeks ago, i.e., in my office computer, it does not remove the unzipped file.

Is it possible to at least warn the user that the unzipped folder will be removed, or set this behaviour as optional with a flag?

Ideally, i.sentinel.mask could read the metadata written into the imported bands directly, then we wouldn't need to pass the MTD_TL.xml file.

[Bug] v.rast.bufferstats python 2 vs python 3 issue

v.rast.bufferstats.py

The unicode() python 2 function fails for Python 3. It should be replaced by str() according to this porting guide. After manually replacing unicode with str on line 339 the problem was gone.

To Reproduce

g.region -p raster=elevation,geology_30m
v.clip --o -r input=bridges output=bridges_wake
# Tabulate area of land cover map
g.region -p raster=elevation,geology_30m align=geology_30m
v.rast.bufferstats -t input=bridges_wake raster=geology_30m buffers=100,250,500 column_prefix=geology

Just taking the example from the manual here. Not tested, but expect it will show same error (see screenshot).

Expected behavior
v.rast.bufferstats exits with calculated results

Screenshots

System description (please complete the following information):

• Operating System: Windows 7
• GRASS GIS version 7.8.3
• details about further software components

version=7.8.3
date=2020
revision=8bcecc9a6
build_date=2020-05-05
build_platform=x86_64-w64-mingw32
build_off_t_size=8
libgis_revision=8bcecc9a6
libgis_date=2020-05-05T08:51:50+00:00
proj=6.3.2
gdal=3.0.4
geos=3.8.1
sqlite=3.29.0

[Bug] r.zonal.classes manual example fails

Name of the addon
r.zonal.classes

Describe the bug
Example from manual fails with:
RASS 7.9.dev (nc_spm_08_grass7):/tmp > r.zonal.classes zone_map=zipcodes raster=landuse96_28m csvfile=output.csv vectormap=vect_output prefix=lu
100%
r.stats command finished...
Traceback (most recent call last):
File "/home/anna/.grass7/addons/scripts/r.zonal.classes", line 312, in
main()
File "/home/anna/.grass7/addons/scripts/r.zonal.classes", line 203, in main
mode = max(iter(totals_dict[ID].items()), key=operator.itemgetter(1))[0]
ValueError: max() arg is an empty sequence

Expected behavior
This should work even if classes_list parameter is not provided. What happens now is that if you don't provide classes, you get empty dictionary that fails with the error above.

Building of addons for WinGRASS 7.6.x

What is the (new?) policy for building Add-ons for Windows? I.e., how often, when and where is it documented? (I never recall easily where the build process/script is documented/placed, but I know there is one :-)).

The builds in https://wingrass.fsv.cvut.cz/grass76/x86_64/addons/latest/ are old (dated 2019-09-02). The parent directory, however, is dated

grass-7.6.1/ 2020-02-23 09:07

Does this mean that if someone wants to install version 7.6.x, he won't get the latest Add-ons via the g.extensions installer?

[FeatureRequest] Add insol_time and npartitions parameters to r.sun.daily

r.sun.daily

r.sun.daily does not include the insol_time parameter to get the total insolation time between two dates. Also, it does not include the npartitions parameter to read the input files in a given number of chunks.

These are two parameters from r.sun that are missing in the script and that would be very useful.

t.rast.kapp

Name of the addon
The name of the GRASS GIS addon.

Describe the bug
A clear and concise description of what the bug of the addon is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Compute '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

System description (please complete the following information):

• Operating System: [e.g. Windows, Linux, ... incl. version]
• GRASS GIS version [e.g. 7.8.1]

Additional context
Add any other context about the problem here.

g.gui.cswbrowser: outdated CSW catalogue entries

The CSW catalogue entries in g.gui.cswbrowser are partially outdated:

grass-addons/grass7/gui/wxpython/wx.metadata/config/connections_resources.xml

Line 2 in 7d2dd42

<csw name="Danmark: National CSW" url="http://www.geodata-info.dk/registrant/srv/en/csw?" />

An updated list of entry candidates is available here:

• Source: https://jeodpp.jrc.ec.europa.eu/ftp/jrc-opendata/APIS4DGOV/cases/LATEST/
  • --> https://jeodpp.jrc.ec.europa.eu/ftp/jrc-opendata/APIS4DGOV/cases/LATEST/API-cases.ods
    • therein, filter column "I" (Theme(s)*) for "Geospatial",
    • and, filter column "J" (Governmental Level*) for "national / international"
      • results in: 45 URLs at European level
  • License: Creative Commons Attribution 4.0 International (CC BY 4.0)

Originally posted by @neteler in #222 (comment)

i.sentinel.mask: returncode error

Name of the addon
i.sentinel.mask

Describe the bug
When using the module to mask clouds and cloud shadows in a S2 scene, I get the following error:

[the rest skipped...]
--- Start removing misclassification from the shadow mask ---
--- Data preparation... ---
WARNING: Values in column <cat> will be overwritten
WARNING: Number of centroids exceeds number of areas: 24 > 22
WARNING: Number of duplicate centroids: 2
WARNING: Values in column <cat> will be overwritten
WARNING: Values in column <cat> will be overwritten
--- Reading mean sun zenith and azimuth from metadata file to compute
clouds shift ---
--- the mean sun Zenith is: 28.732 deg ---
--- the mean sun Azimuth is: 82.028 deg ---
--- Start computing the east and north clouds shift at steps of 100m of
clouds height---
Traceback (most recent call last):
  File "/home/veroandreo/.grass7/addons/scripts/i.sentinel.mask", line 638, in <module>
    main()
  File "/home/veroandreo/.grass7/addons/scripts/i.sentinel.mask", line 561, in main
    quiet=True, stderr=subprocess.DEVNULL)
  File "/home/veroandreo/software/grass79-dev/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py", line 499, in run_command
    return handle_errors(returncode, result=None, args=args, kwargs=kwargs)
  File "/home/veroandreo/software/grass79-dev/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py", line 392, in handle_errors
    returncode=returncode)
grass.exceptions.CalledModuleError: Module run v.overlay v.overlay --o --q ainput=addcat_5922 binput=cl_shift_5922 operator=and output=overlay_5922 ended with error
Process ended with non-zero return code 1. See errors in the (error) output.

To Reproduce
Steps to reproduce the behaviour:

1. Download S2 scene with UUID: 541021f8-63f5-4e9d-ba28-425c4c8451df

i.sentinel.download settings=your_sentinel_file output=tmp uuid=541021f8-63f5-4e9d-ba28-425c4c8451df

2. Import into a UTM 21S location (create with grass79 -c EPSG:32721 $HOME/grassdata/utm21s)

i.sentinel.import input=tmp/ pattern='B(02_1|03_1|04_1|08_1|8A_2)0m' extent=input memory=500

3. Apply cloud masking

# note the following will only work if no other S2 scene is present in the mapset, otherwise you'll have to write the map names or narrow the search pattern
blue=`g.list type=raster pattern="*B02_1*"`
green=`g.list type=raster pattern="*B03_1*"`
red=`g.list type=raster pattern="*B04_1*"`
nir=`g.list type=raster pattern="*B08_1*"`
nir8a=`g.list type=raster pattern="*B8A_2*"`
swir11=`g.list type=raster pattern="*B11_2*"`
swir12=`g.list type=raster pattern="*B12_2*"`

i.sentinel.mask -s blue=$blue green=$green red=$red swir11=$swir11 nir=$nir swir12=$swir12 nir8a=$nir8a cloud_mask=cloud shadow_mask=shadow mtd_file=`find tmp/ -name 'MTD_TL.xml'` scale_fac=10000

System description (please complete the following information):

• Operating System: fedora 31
• GRASS GIS version 79 (dev)
• Further software components
  • proj=5.2.0
  • gdal=2.3.2
  • geos=3.7.1
  • sqlite=3.30.0
  • python=3.7.4

[Bug] Delaunay3d add-on

[v.delaunay3d add-on is not working]

Traceback (most recent call last):
File "C:\PROGRA~1\QGIS\apps\grass\grass78\etc\python\grass
\script\task.py", line 474, in get_interface_description

stderr=PIPE)
File "C:\PROGRA~1\QGIS\apps\grass\grass78\etc\python\grass
\script\core.py", line 57, in init

.format(args[0]))
OSError
:
Cannot find the executable v.delaunay3d
During handling of the above exception, another exception
occurred:
Traceback (most recent call last):
File "C:\PROGRA~1\QGIS\apps\grass\grass78\gui\wxpython\gui
_core\forms.py", line 2866, in ParseCommand

blackList=_blackList)
File "C:\PROGRA~1\QGIS\apps\grass\grass78\etc\python\grass
\script\task.py", line 522, in parse_interface

tree = etree.fromstring(get_interface_description(name))
File "C:\PROGRA~1\QGIS\apps\grass\grass78\etc\python\grass
\script\task.py", line 502, in get_interface_description

"\n\nDetails: <{det}>").format(cmd=cmd, det=e))
grass.exceptions
.
ScriptError
:
Unable to fetch interface description for command
'<v.delaunay3d>'.
Details:
During handling of the above exception, another exception
occurred:
Traceback (most recent call last):
File "C:\PROGRA~1\QGIS\apps\grass\grass78\gui\wxpython\gui
_core\treeview.py", line 70, in

self._emitSignal(evt.GetItem(), self.itemActivated))
File "C:\PROGRA~1\QGIS\apps\grass\grass78\gui\wxpython\gui
_core\treeview.py", line 175, in _emitSignal

signal.emit(node=node, **kwargs)
File "C:\PROGRA~1\QGIS\apps\grass\grass78\etc\python\grass
\pydispatch\signal.py", line 229, in emit

dispatcher.send(signal=self, *args, **kwargs)
File "C:\PROGRA~1\QGIS\apps\grass\grass78\etc\python\grass
\pydispatch\dispatcher.py", line 349, in send

**named
File "C:\PROGRA~1\QGIS\apps\grass\grass78\etc\python\grass
\pydispatch\robustapply.py", line 60, in robustApply

return receiver(*arguments, **named)
File "C:\PROGRA~1\QGIS\apps\grass\grass78\gui\wxpython\gui
_core\menu.py", line 191, in

self._tree.itemActivated.connect(lambda node:
self.Run(node))
File "C:\PROGRA~1\QGIS\apps\grass\grass78\gui\wxpython\gui
_core\menu.py", line 259, in Run

eval(handler)(event=None, cmd=data['command'].split())
File "C:\PROGRA~1\QGIS\apps\grass\grass78\gui\wxpython\lmg
r\frame.py", line 906, in OnMenuCmd

GUI(parent=self, giface=self._giface).ParseCommand(cmd)
File "C:\PROGRA~1\QGIS\apps\grass\grass78\gui\wxpython\gui
_core\forms.py", line 2868, in ParseCommand

raise gcmd.GException(e.value)
core.gcmd
.
GException
:
Unable to fetch interface description for command
'<v.delaunay3d>'.
Details:
--->

Additional context
https://gis.stackexchange.com/questions/349346/grass-add-on-v-delaunay3d-wont-start/358656#358656

Archive grass6 directory

Is grass6 still required to be in the master branch? Could it be just archived?

i.sentinel.import and i.sentinel.mask: use of -j and json file is not documented

The addition of these options are a great improvement and I know the PR #137 is merged already, but how are we supposed to easily know the name of the json dump to use it as input for i.sentinel.mask? Do we need to browse in the mapset files or does it get printed when i.sentinel.import finishes?

Documentation of both new features in the respective manual pages would be great, too. Moreove, an extra example for the use case would be highly appreciated and would also make the improvement more visible and discoverable by users

Originally posted by @veroandreo in #137 (comment)

[Bug] r.learn.ml2: r.learn.predict fails if category labels are missing

Name of the addon
r.learn.ml2 (r.learn.train /r.learn.predict)

Describe the bug
r.learn.predict produces the following error message if the training_map used for r.learn.train does not contain category labels:
Traceback (most recent call last): File "/root/.grass7/addons/scripts/r.learn.predict", line 172, in <module> main() File "/root/.grass7/addons/scripts/r.learn.predict", line 167, in main r.category(map=output, rules=rules_file, separator="comma") File "/usr/local/grass78/etc/python/grass/pygrass/modules/interface/module.py", line 650, in __call__ return self.run() File "/usr/local/grass78/etc/python/grass/pygrass/modules/interface/module.py", line 771, in run self.wait() File "/usr/local/grass78/etc/python/grass/pygrass/modules/interface/module.py", line 794, in wait module=self.name, errors=stderr)

grass.exceptions.CalledModuleError: Module run r.category r.category map=classification_map_5classes_2019 separator=comma rules=/actinia_core/grassdb/idortmund/nrw_19.tmp/23aab7009ad3/2170.0 ended with error Process ended with non-zero return code -11. See errors in the (error) output.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Compute '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

System description (please complete the following information):

• GRASS GIS 7.8.4, Linux

i.sentinel.mask should remove all the *_double files

i.sentinel.mask creates a floating point version of S2 bands for its calculations.

IMO, it should remove them at exit maybe with a message or so. Think of users processing many S2 scenes with this add-on, then their mapsets (and disks) will be full of undesired intermediate maps.

@RobiFag what do you think?

[Bug] g.proj.identify does not install properly

Name of the addon
g.proj.identify

Describe the bug
g.proj.identify does not install properly

To Reproduce
Steps to reproduce the behavior:

1. Run g.proj.identify
2. See error:

g.extension extension=g.proj.identify                                           
WARNING: Extension <g.proj.identify> already installed. Re-installing...
Downloading precompiled GRASS Addons <g.proj.identify>...
Updating addons metadata file...
Updating private addons metadata file...
WARNING: No addons metadata available. Addons metadata file not updated.
ERROR: Unable to read manual page: [Errno 2] No such file or directory: 'C:\\Users\\baharmon\\AppData\\Roaming\\GRASS7\\addons\\docs\\html\\g.proj.identify.html'
(Fri Oct  2 11:53:34 2020) Command finished (2 sec)                             

Expected behavior
Add-on module installs.

System description:

• Operating System: Windows 10
• version=7.8.3
• date=2020
• revision=8bcecc9a6
• build_date=2020-05-05
• build_platform=x86_64-w64-mingw32
• build_off_t_size=8
• libgis_revision=8bcecc9a6
• libgis_date=2020-05-05T08:51:50+00:00
• proj=6.3.2
• gdal=3.0.4
• geos=3.8.1
• sqlite=3.29.0

[Bug] r.width.funct (addon) TypeError: unsupported operand type(s)

Describe the bug
Running r.basin I had these errors:

Traceback (most recent call last):
  File "/home/marco/.grass7/addons/scripts/r.width.funct", line 135, in <module>
    sys.exit(main())
  File "/home/marco/.grass7/addons/scripts/r.width.funct", line 103, in main
    print('%.0f | %s') %(findint(kl,0.05), 0.05)
TypeError: unsupported operand type(s) for %: 'NoneType' and 'tuple'

and

/home/marco/.grass7/addons/scripts/r.width.funct:123: MatplotlibDeprecationWarning: 
The wx backend was deprecated in Matplotlib 2.0 and will be removed in the future. Use wxagg instead.

A possible solution
I solved it by applying this patch:

--- r.width.funct_orig	2020-05-23 20:27:00.014187464 +0200
+++ r.width.funct	2020-05-23 21:14:10.852005699 +0200
@@ -43,7 +43,7 @@
 import sys
 import os
 import matplotlib #required by windows
-matplotlib.use('wx') #required by windows
+matplotlib.use('wxagg') #required by windows
 import matplotlib.pyplot as plt
 import grass.script as grass
 import numpy as np
@@ -100,15 +100,15 @@
     print("===========================")
     print("Width Function | quantiles")
     print("===========================")
-    print('%.0f | %s') %(findint(kl,0.05), 0.05)
-    print('%.0f | %s') %(findint(kl,0.15), 0.15)
-    print('%.0f | %s') %(findint(kl,0.3), 0.3)
-    print('%.0f | %s') %(findint(kl,0.4), 0.4)
-    print('%.0f | %s') %(findint(kl,0.5), 0.5)
-    print('%.0f | %s') %(findint(kl,0.6), 0.6)
-    print('%.0f | %s') %(findint(kl,0.7), 0.7)
-    print('%.0f | %s') %(findint(kl,0.85), 0.85)
-    print('%.0f | %s') %(findint(kl,0.95), 0.95)
+    print('%.0f | %s' %(findint(kl,0.05), 0.05))
+    print('%.0f | %s' %(findint(kl,0.15), 0.15))
+    print('%.0f | %s' %(findint(kl,0.3), 0.3))
+    print('%.0f | %s' %(findint(kl,0.4), 0.4))
+    print('%.0f | %s' %(findint(kl,0.5), 0.5))
+    print('%.0f | %s' %(findint(kl,0.6), 0.6))
+    print('%.0f | %s' %(findint(kl,0.7), 0.7))
+    print('%.0f | %s' %(findint(kl,0.85), 0.85))
+    print('%.0f | %s' %(findint(kl,0.95), 0.95))
     print('\n')
     print('Done!')

System description:

• Operating System: Linux 5.6.13-arch1-1 OSGeo/grass#1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux
• GRASS GIS version 7.8.*

[Bug] r.learn.ml- onehot encoding not working any more with scikit-learn 0.22

Name of the addon
r.learn.m

Describe the bug
In the new scikit-learn 0.22 the OneHotEncode() function parameters are changed and category maps can not be used in r.learn.m current version.

To Reproduce
Test with category maps.

Expected behavior

Error message here
clf = Pipeline([('onehot', OneHotEncoder(
categorical_features=categorymaps

System description (please complete the following information):

• Operating System: OpenSUSE Leap 15.1
• GRASS GIS version 7.9.dev
• python 3

Additional context
There is a new version of r.learn.ml (separate train and predict modules) in github where the problem is solved. In this version (training and predicting in one module) the message could be modified to indicate the last version of python3-scikit-learn that is compatible with the script:
gs.fatal("Package python3-scikit-learn 0.18 or newer is not installed") .

I have not tested with python3-scikit-learn <0.22.

[Bug] Type error in r.diversity addon

Describe the bug
Running the add-on r.diversity results in a type error.

r.diversity input=ndvi prefix=diversity method=shannon                          
Traceback (most recent call last):
  File "C:\Users\baharmon\AppData\Roaming\GRASS7\addons/scri
pts/r.diversity.py", line 283, in <module>
    sys.exit(main())
  File "C:\Users\baharmon\AppData\Roaming\GRASS7\addons/scri
pts/r.diversity.py", line 149, in main
    quiet, overwrite)
  File "C:\Users\baharmon\AppData\Roaming\GRASS7\addons/scri
pts/r.diversity.py", line 160, in calculateM
    createConfFile(r, map_in, home)
  File "C:\Users\baharmon\AppData\Roaming\GRASS7\addons/scri
pts/r.diversity.py", line 240, in createConfFile
    fileConf.writelines(outputLine)
TypeError: a bytes-like object is required, not 'str'
(Mon Jun 29 16:37:02 2020) Command finished (0 sec)   

To Reproduce
Steps to reproduce the behavior using the NC complete location:

1. Compute a vegetation index such as NDVI: i.vi output=ndvi viname=ndvi red=lsat7_2000_30@landsat nir=lsat7_2000_40@landsat
2. Compute diversity from NDVI: r.diversity input=ndvi prefix=diversity method=shannon
3. See error

Expected behavior
Compute a diversity map.

System description (please complete the following information):

• Operating System: Windows 10
• GRASS GIS version: 7.8.3

Add CONTRIBUTING file

There should be something similar to CONTRIBUTING.md file

I will try to work on it but I don't know when, when I'll start I will assign to my self.

[Bug] r.in.usgs fails

r.in.usgs

Describe the bug
r.in.usgs fails on Windows 10

r.in.usgs product=ned output_name=ned output_directory=D:\gisdata\usgs ned_dataset=ned19sec
Downloading USGS Data...
Download 1 of 1: COMPLETE
Extracting data...
Importing and reprojecting ned19_n35x75_w078x75_nc_statewide_2003.img (1 out of 1)...
Traceback (most recent call last):
  File "C:\Users\baharmon\AppData\Roaming\GRASS7\addons/scri
pts/r.in.usgs.py", line 959, in <module>
    sys.exit(main())
  File "C:\Users\baharmon\AppData\Roaming\GRASS7\addons/scri
pts/r.in.usgs.py", line 814, in main
    process.start()
  File "C:\Program Files\GRASS GIS
7.8\Python37\lib\multiprocessing\process.py", line 112, in
start
    self._popen = self._Popen(self)
  File "C:\Program Files\GRASS GIS
7.8\Python37\lib\multiprocessing\context.py", line 223, in
_Popen
    return
_default_context.get_context().Process._Popen(process_obj)
  File "C:\Program Files\GRASS GIS
7.8\Python37\lib\multiprocessing\context.py", line 322, in
_Popen
    return Popen(process_obj)
  File "C:\Program Files\GRASS GIS
7.8\Python37\lib\multiprocessing\popen_spawn_win32.py", line
65, in __init__
    reduction.dump(process_obj, to_child)
  File "C:\Program Files\GRASS GIS
7.8\Python37\lib\multiprocessing\reduction.py", line 60, in
dump
    ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object
'main.<locals>.run_file_import'
USGS file(s) to download:
-------------------------
Total download size:	206.97 MB
Tile count:	1
USGS SRS:	wgs84
USGS tile titles:
USGS NED ned19_n35x75_w078x75_nc_statewide_2003 1/9 arc-second 2012 15 x 15 minute IMG
-------------------------
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Program Files\GRASS GIS
7.8\Python37\lib\multiprocessing\spawn.py", line 99, in
spawn_main
    new_handle = reduction.steal_handle(parent_pid,
pipe_handle)
  File "C:\Program Files\GRASS GIS
7.8\Python37\lib\multiprocessing\reduction.py", line 87, in
steal_handle
    _winapi.DUPLICATE_SAME_ACCESS |
_winapi.DUPLICATE_CLOSE_SOURCE)
PermissionError: [WinError 5] Access is denied

To Reproduce
Steps to reproduce the behavior:

1. Start GRASS 7.8.3 in the NC sample dataset
2. Set the region to elev_lid792_1m at 3m resolution

g.region raster=elev_lid792_1m res=3

3. Run r.in.usgs

r.in.usgs product=ned output_name=ned output_directory=usgs ned_dataset=ned19sec

Expected behavior
r.in.usgs should import the NED elevation raster for the region.

System description (please complete the following information):

• Operating System: Windows 10
• GRASS GIS version 7.8.3

g.extension vs r.green

Describe the bug
Can't install r.green via g.extension (linux)

To Reproduce
Steps to reproduce the behavior:

g.extension r.green

Expected behavior
Success install

Screenshots

System description (please complete the following information):

• Operating System: Windows server 2019
• GRASS GIS version 7.8.3 from OSGeo4W

Additional context

If commented out in g.extension:

#for filename in pyfiles:
#    with fileinput.FileInput(filename, inplace=True) as file:
#        for line in file:
#            print(line.replace(
#                "#!/usr/bin/env python\n",
#                "#!/usr/bin/env python3\n"
#            ), end='')

Things work

[Bug] i.sentinel.download: footprint map - A geometry of type MULTIPOLYGON error

Name of the addon
When trying to create a footprint map, the following error appears:

Warning 1: A geometry of type MULTIPOLYGON is inserted into layer toscana_footprints of geometry type POLYGON, which is not normally allowed by the GeoPackage specification, but the driver will however do it. To create a conformant GeoPackage, if using ogr2ogr, the -nlt option can be used to override the layer geometry type. This warning will no longer be emitted for this combination of layer and feature geometry type.

Reproducible example:

# somewhere in Italy
GRASS 7.8.4dev (latlong_wgs84):~ > g.region n=43.6003000 s=43.4743000 w=12.0469000 e=12.2389000 -p res=0:00:01 -a

# show list of scenes and generate footprint map:
i.sentinel.download -l settings=~/.sentinel_esa producttype=S2MSI2A start=2019-06-01 end=2019-06-30 cloud=2  footprints=toscana_footprints --o
5 Sentinel product(s) found
Writing footprints into <toscana_footprints>...
Warning 1: A geometry of type MULTIPOLYGON is inserted into layer toscana_footprints of geometry type POLYGON, which is not normally allowed by the GeoPackage specification, but the driver will however do it. To create a conformant GeoPackage, if using ogr2ogr, the -nlt option can be used to override the layer geometry type. This warning will no longer be emitted for this combination of layer and feature geometry type.
WARNING: Vector map <toscana_footprints> already exists and will be
         overwritten
b9d91bee-58ad-4327-a865-e268d978109d S2A_MSIL2A_20190613T101031_N0212_R022_T32TQP_20190614T125329 2019-06-13T10:10:31Z  0% S2MSI2A
ecb49dad-9400-4d10-8bbe-3be1e71761c8 S2B_MSIL2A_20190625T100039_N0212_R122_T32TQP_20190625T131010 2019-06-25T10:00:39Z  0% S2MSI2A
1409fc58-0839-4997-ba03-4415cd0f6248 S2B_MSIL2A_20190628T101039_N0212_R022_T32TQP_20190628T143542 2019-06-28T10:10:39Z  1% S2MSI2A
d4476516-2f32-4188-80c8-edecfbd24287 S2B_MSIL2A_20190605T100039_N0212_R122_T32TQP_20190605T143319 2019-06-05T10:00:39Z  1% S2MSI2A
1a8f0d43-50e3-4bbf-8a42-90ade6ef4a7f S2B_MSIL2A_20190628T101039_N0212_R022_T32TQP_20190628T142337 2019-06-28T10:10:39Z  2% S2MSI2A

Using

• GDAL 3.0.4, released 2020/01/28

[Bug] i.modis.import: unable to import because of wrong parsing of filename

i.modis.import fails with:

Proccessing <MOD13C2.A2019335.006.2020004224207.hdf> (1/60)...
WARNING: Illegal filename
         <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_NIR_reflectance">.
         Character <"> not allowed.
WARNING: Illegal filename
         <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_NIR_reflectance">.
         Character <"> not allowed.
ERROR: <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_NIR_reflectance">
       is an illegal file name
WARNING: Error during import of
         MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_NIR_reflectance"
WARNING: Illegal filename
         <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_pixel_reliability">.
         Character <"> not allowed.
WARNING: Illegal filename
         <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_pixel_reliability">.
         Character <"> not allowed.
ERROR: 
       <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_pixel_reliability">
       is an illegal file name
WARNING: Error during import of
         MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_pixel_reliability"
WARNING: Illegal filename
         <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_MIR_reflectance">.
         Character <"> not allowed.
WARNING: Illegal filename
         <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_MIR_reflectance">.
         Character <"> not allowed.
ERROR: <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_MIR_reflectance">
       is an illegal file name
WARNING: Error during import of
         MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_MIR_reflectance"
WARNING: Illegal filename
         <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_NDVI">.
         Character <"> not allowed.
WARNING: Illegal filename
         <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_NDVI">.
         Character <"> not allowed.
ERROR: <MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_NDVI"> is an
       illegal file name
WARNING: Error during import of
         MOD13C2.A2019335.006.single_"CMG_0.05_Deg_Monthly_NDVI"

when trying to import layers of the MOD13C2 product. This used to work before. It seems the parsing is wrongly taking the quotes to build up the output filename and that's an illegal character.

To Reproduce

i.modis.download settings=$HOME/SETTING product=ndvi_terra_monthly_5600 startday=2015-01-01 endday=2015-03-31 folder=/tmp
i.modis.import files=/tmp/listfileMOD13C2.006.txt spectral="( 1 0 0 0 1 0 1 0 0 0 0 0 1 )"

@landam @lucadelu could you have a look at it, please? I downloaded and imported lst_terra_monthly_5600 without problems, but it seems ndvi_terra_monthly_5600 has a different scheme for filenames, maybe because it's a global product and not tiled.

i.sentinel.import does not recognise .jp2 as a supported file format

I'm trying to read Sentinel2 satellite imagery on GRASS GIS-7.4.4, but when i run the command i get this error:

ERROR 4: `/Volumes/Maxtor/TESI_satellite_imagery/IMMAGINI_DI
_PARTENZA/serie_storica_estate_dic2015-feb2020/S2/summer18-1
9_S2/S2A_MSIL1C_20181205T135101_N0207_R024_T21JVN_20181205T1
64652.SAFE/GRANULE/L1C_T21JVN_A018039_20181205T135104/IMG_DA
TA/T21JVN_20181205T135101_B01.jp2' not recognised as a
supported file format.
Traceback (most recent call last):
File "/Users/frah/Library/GRASS/7.4/Modules/scripts/i.sent
inel.import", line 267, in
sys.exit(main())
File "/Users/frah/Library/GRASS/7.4/Modules/scripts/i.sent
inel.import", line 255, in main
importer.print_products()
File "/Users/frah/Library/GRASS/7.4/Modules/scripts/i.sent
inel.import", line 245, in print_products
self._raster_epsg(f),
File "/Users/frah/Library/GRASS/7.4/Modules/scripts/i.sent
inel.import", line 197, in _raster_epsg
srs.ImportFromWkt(dsn.GetProjectionRef())
AttributeError: 'NoneType' object has no attribute
'GetProjectionRef'

I updated gdal to version 3.1.3.
I'll be hugely grateful if anybody can help me to solve this issue. Thank you in advance.

[Bug] r.denoise temp files don't write

Describe the bug
I'm having the same issue as this older GIS-SE question - https://gis.stackexchange.com/questions/258574/grass-r-denoise-error

Briefly, r.denoise.py crashes because it can't write temp files. The script looks like its written with the assumption that a destination folder is already set. At least on Windows, it seems that a fully qualified path must be supplied. Not sure how this behaves in a *nix env.

Script should maybe be writing to $LOCATION/$MAPSET/.tmp/$HOSTNAME per https://grass.osgeo.org/grass78/manuals/variables.html?

To Reproduce
Install GRASS 7.8.2 (OSGeo4W)
Get windows executable of mdenoise - http://www.cs.cf.ac.uk/meshfiltering/index_files/Doc/WinMDenoise.zip and make sure the exe is on the system PATH. Placing it in C:/OSGeo4W64/bin works.
Set up a location containing a small DEM and attempt to run r.denoise on it.

Expected behavior
Temp files should write to an appropriate temp directory, allowing the script to proceed

System description (please complete the following information):

• Operating System:Windows 10
• GRASS GIS version 7.8.2
• MDenoise.exe present on system

[Bug] parameter name conflict between i.zc and the GridModule class in pygrass

Name of the addon
i.cutlines

Describe the bug
As per manual, there is a parameter name conflict between i.zc and the GridModule class in pygrass.
Until this is resolved tiled edge detection is only possible with i.edge.

Question: can the conflict (which precisely, @mlennert ?) be fixed?

[Bug] i.modis.import fails when input data dir is read-only

Name of the addon
i.modis

Describe the bug
i.modis.import is currently creating temporary data in input data dir (see #199). It fails when this directory is read-only.

To Reproduce
Steps to reproduce the behavior:

Run

i.modis.import.py input=~/geodata/modis/MCD19A2.A2019031.h18v03.006.2019036210121.hdf --o

see error

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/pymodis/convertmodis_gdal.py", line 246, in _reprojectOne
    dst_ds = self.driver.Create(out_name, self.dst_xsize,
  File "/usr/lib/python3/dist-packages/osgeo/gdal.py", line 1676, in Create
    return _gdal.Driver_Create(self, *args, **kwargs)
RuntimeError: Attempt to create new tiff file `MCD19A2.A2019031.h18v03.single_Optical_Depth_055.tif' failed: Permission denied

Expected behavior

Temporary data should be produced in .tmp directory. It's not clear how to behave if -t is given, see
#199 (comment)

System description (please complete the following information):

• Operating System: Windows, Linux
• GRASS GIS version 7.8.3

[Bug] r.learn.train: IndexError: list index out of range

Using r.learn.train in a process chain in order to perform Sentinel-2 classification I run into the following problem:

• input data: NDVI, NDWI, B02m, B03, B04, B08
• training points sampled using training areas

Then:

# JSON output of process chain

executable | "r.learn.train"
-- | --
parameter |  
0 | "training_points=training_data"
1 | "field=class_int"
2 | "group=classificationinput"
3 | "n_jobs=4"
4 | "save_model=/mnt/geodata/indonesia_classification/s2scenes/model.gz"
5 | "model_name=RandomForestClassifier"
6 | "cv=5"
return_code | 1
run_time | 1.1285302639007568
stderr |  
0 | "Extracting training data"
1 | "Traceback (most recent call last):"
2 | "  File \"/usr/local/grass7/scripts/r.learn.train\", line 876, in <module>"
3 | "    main()"
4 | "  File \"/usr/local/grass7/scripts/r.learn.train\", line 588, in main"
5 | "    X, y, cat = stack.extract_points(training_points, field)"
6 | "  File \"/usr/local/grass7/etc/r.learn.ml2/raster.py\", line 883, in extract_points"
7 | "    X = [k.split(\"\|\")[1] if k.split(\"\|\")[1] != \"*\" else nodata for k in rast_data]"
8 | "  File \"/usr/local/grass7/etc/r.learn.ml2/raster.py\", line 883, in <listcomp>"
9 | "    X = [k.split(\"\|\")[1] if k.split(\"\|\")[1] != \"*\" else nodata for k in rast_data]"
10 | "IndexError: list index out of range"

The issue happens here:

grass-addons/grass7/raster/r.learn.ml2/rlearnlib/raster.py

Line 883 in 0e61c94

X = [k.split("|")[1] if k.split("|")[1] != "*" else nodata for k in rast_data]

Probably I am feeding wrong data but not sure what to look for.

Maybe @stevenpawley has an idea? Thanks in advance

[Bug] v.in.pygbif crashes with ERROR 1: missing [

Name of the addon
v.in.pygbif

Describe the bug

It crashes..:

GRASS 7.8.4dev (latlong_wgs84):~gbif > v.in.pygbif taxa="Plantae" rank=kingdom -p
ERROR 1: missing [
Traceback (most recent call last):
  File "/home/mundialis/.grass7/addons/scripts/v.in.pygbif", line 815, in <module>
    sys.exit(main())
  File "/home/mundialis/.grass7/addons/scripts/v.in.pygbif", line 460, in main
    target.ImportFromProj4(target_crs)
  File "/usr/lib64/python3.6/site-packages/osgeo/osr.py", line 1223, in ImportFromProj4
    return _osr.SpatialReference_ImportFromProj4(self, *args)
TypeError: in method 'SpatialReference_ImportFromProj4', argument 1 of type 'OSRSpatialReferenceShadow *'
Segmentation fault (core dumped)

(note: the https://grass.osgeo.org/grass7/manuals/addons/v.in.pygbif.html#examples crashes as well)

System description:

• Centos 8
• pygbif-0.4.0-py2.py3-none-any.whl (installed with pip3)

g.version -rge
version=7.8.4dev
date=2020
revision=a0a0c9361
build_date=2020-06-13
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=8e4dab571
libgis_date=2020-05-05T09:05:27+00:00
proj=6.3.2
gdal=3.0.4
geos=3.7.2
sqlite=3.26.0

Python 3.6.8

[Feature] Enable GH Actions for grass-addons

To improve the software quality it would be nice to have GH Actions also in the grass-addons repo.

It might be derived from the settings currently defined in GRASS GIS release_branch_7_8:

https://github.com/OSGeo/grass/tree/releasebranch_7_8/.github/workflows

What do you think (@wenzeslaus)?

i.sentinel.import: wrong resolution set for latlong locations

Name of the addon
i.sentinel.import

Describe the bug
When trying to import S2 scenes into a latlong location using i.sentinel.import with -r flag, the resolution is set to 10, 20 or 60 degrees instead of the equivalent of 10, 20 and 60 m in degrees. If I import into a UTM location all is fine, as well as if I use r.importinstead of i.sentinel.import with a latlong location.
As you can see below, r.import estimates a resolution, however, r.sentinel.import uses the nominal resolution in meters anyway.

To Reproduce
Steps to reproduce the behavior:

1. Download a S2 scene

i.sentinel.download settings=your_sentinel_file output=tmp uuid=541021f8-63f5-4e9d-ba28-425c4c8451df

2. Import into a latlong location - here, I already got messages that the imported map was empty

i.sentinel.import input=tmp/ pattern='B(02_1|03_1|04_1|08_1|8A_2)0m' extent=input memory=500
...
Estimated target resolution for input band
<T21JYM_20200126T134201_B11_20m>: 0.00018606630466763683
Using given resolution for input band <T21JYM_20200126T134201_B11_20m>:
20.0
Reprojecting <T21JYM_20200126T134201_B11_20m>...
ERROR: The reprojected raster <T21JYM_20200126T134201_B11_20m> is empty
Writing metadata to maps...

3. Run r.info to check (see below)

Screenshots

System description (please complete the following information):

• Operating System: Linux Fedora 31
• GRASS GIS version 7.9 (dev)
• with python 3.7.4 because of ctypes problem

i.sentinel.import: mixture of CELL and FCELL in results possible

The problem

When using i.sentinel.import, the results are not consistently of CELL type (integer) but become of FCELL type in case of reprojection being necessary.

The reason is, not surprisingly, here:

grass-addons/grass7/imagery/i.sentinel/i.sentinel.import/i.sentinel.import.py

Line 228 in ba80171

args['resample'] = 'bilinear'

This leads to at least three problems:

• output data type is inconsistent
• in case of reprojection, the resulting files are of way larger file size (not really desired)
• mosaics cannot be well generated:

r.buildvrt ...
WARNING: Input maptypes are different
WARNING: Input maptypes are different
r.buildvrt complete.

Potential solutions:

• switch to "nearest [neighbor]" in above code line
• keep "bilinear" and add a r.mapcalc call with round() function
• your idea here

[Bug] r.landscape.evol: f = file(statsout, 'wt') not working anymore in python 3

Name of the addon
r.landscape.evol

Describe the bug
f = file(statsout, 'wt') not working anymore in python 3

To Reproduce

e.g. try to run the script in winGRASS

[Bug] wx.metadata: update wxPython code (ISO/INSPIRE Metadata Support addons)

Name of the addon
The wx.metadata suite lacks an update of the wxPython code, in the files:

• g.gui.cswbrowser/g.gui.cswbrowser.py
• g.gui.metadata/g.gui.metadata.py
• mdlib/cswlib.py
• mdlib/mdeditorfactory.py
• mdlib/mdutil.py

Code in:

• https://github.com/OSGeo/grass-addons/tree/master/grass7/gui/wxpython/wx.metadata/)

The related usage documentation is at:

• https://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support

Describe the bug
Currently the addons adding ISO/INSPIRE Metadata Support to GRASS GIS are not functional any more as they crash with wxPython errors.

To Reproduce
Steps to reproduce the behavior:

Try to just start the modules on command line to get into GUI mode, they crash (probably due to lack of updates in the underlying wx.metadata libs).