osgeo / grass

GRASS GIS - free and open-source geospatial processing engine

GRASS GIS Repository

Description

GRASS GIS (https://grass.osgeo.org/) is a Geographic Information System used for geospatial data management and analysis, image processing, graphics/map production, spatial modeling, and visualization.

Launch this repository in Binder and experiment with GRASS's Python API in Jupyter Notebooks by clicking the button below:

Contributing

In general: you don't really need write access as you can simply open a pull request to contribute to GRASS GIS. See CONTRIBUTING file for more details.

How to get write access here

Want to become a core developer? See Procedure for gaining Git write access

How to compile GRASS

See the INSTALL.md file.

Yes, you should really read INSTALL.md. In addition, there are detailed compile instructions in the Wiki.

Docker

Build a docker image using the downloaded source code (run this in the directory containing the source code):

A. Docker image without graphical user interface - wxGUI.

docker build -t grassgis .

A test run (assuming you have the existing GRASS GIS test location; it can be downloaded from here)

# case 1: launching in the grassdata directory in which the location is stored:
docker run -it --rm --user=$(id -u):$(id -g) --volume $(pwd):/data \
    --env HOME=/data/ grassgis grass --text nc_basic_spm_grass7/user1 \
        --exec g.region -p

# case 2: launching anywhere
docker run -it --rm --user=$(id -u):$(id -g) \
    --volume /your/test/grassdata/:/data --env HOME=/data/ grassgis \
        grass /data/nc_basic_spm_grass7/PERMANENT --exec g.region -p

Note that the first grassgis is the name of the image while the second grass is the name of the executable.

To run the tests (again assuming local location):

docker run -it --rm --user=$(id -u):$(id -g) \
    --volume /your/test/grassdata/:/data --env HOME=/data/ -w /code/grass \
        grassgis grass /data/nc_basic_spm_grass7/PERMANENT --exec \
            python -m grass.gunittest.main \
                --location nc_basic_spm_grass7 --location-type nc

B. Docker image with graphical user interface - wxGUI.

docker build -t grassgis -f docker/ubuntu_wxgui/Dockerfile .

Note that the first grassgis is the name of the image while the second grass is the name of the executable.

xhost local:$(id -u)
docker run -it --privileged --user=$(id -u):$(id -g) --rm \
    --volume="$(pwd)/:/data" --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" \
    --env HOME=/data/ --env DISPLAY=$DISPLAY \
    --device="/dev/dri/card0:/dev/dri/card0" \
    grassgis grass --gui

Note: If you compiled locally before building the Docker image, you may encounter problems as the local configuration and the locally compiled files are copied to and used in the Docker image. To make sure you don't have this issue, clean all the compiled files from the source code:

make distclean

Thanks to all contributors ❤

grass's Issues

Compilation on MacOS to custom install location

I try to install GRASS to custom installation location, and do not want to add anything to the system (== I want to have multiple grass installations and not in the system /Library/ folder)

I need this for creation of dependencies for QGIS packager on Mac, you can find the recipe https://github.com/qgis/QGIS-Mac-Packager/blob/master/qgis_deps/recipes/grass/recipe.sh
and you can compile it by cd qgis_deps; ./distribute -mgrass (it takes some time...). To be able to build GRASS, I had to do this fix https://github.com/qgis/QGIS-Mac-Packager/blob/f12e73d0867c49a9f941127ab902eb7eaf5362c7/qgis_deps/recipes/grass/recipe.sh#L40

It fails on these 2 steps:

./include/Make/Install.make:	@/bin/ln -sfh "$(INST_DIR)/docs/html"
./macosx/app/build_html_user_index.sh:mkdir -p $HOME/Library/Documentation/Help/
./macosx/app/build_html_user_index.sh:ln -sfh ../../GRASS/$GRASS_MMVER/Modules/docs/html $HOME/Library/Documentation/Help/GRASS-$GRASS_MMVER-addon
./macosx/app/build_html_user_index.sh:ln -sfh $GISBASE/docs/html $HOME/Library/Documentation/Help/GRASS-$GRASS_MMVER

Would it be possible to add some variable to the config to be able to disable creation of such links in $HOME/Library/Documentation/Help/ and /Library/Documentation/Help/? I do not build with flag --enable-macosx-app so alternatively, do not create such links at all when app is not built?

• Operating System: MacOS 10.15.x
• GRASS GIS version: 7.8.2 (but it looks like the files are on master too)

related to #457

[Bug] r.buildvrt generated map used as MASK crashes r.out.gdal

Describe the bug

Using a map generated with r.buildvrt as raster MASK, and then exporting a map with r.out.gdal crashes r.out.gdal.

To Reproduce

Example from r.buildvrt (https://grass.osgeo.org/grass78/manuals/r.buildvrt.html#examples), VRT from a DEM tileset in the North Carolina sample dataset, which is then used as MASK:

# set the region
g.region raster=elev_state_500m -p
# higher resolution
g.region res=50 -p
# resample the DEM to 50 meter
r.resamp.interp input=elev_state_500m output=elev_state_50m method=bilinear
# create tiles
r.tile input=elev_state_50m output=elev_state_50m_tile_ width=1000 height=1000 overlap=0
# dump list of tiles to a file
g.list type=raster pattern=elev_state_50m_tile_* output=tilelist
# build a vrt
r.buildvrt file=tilelist output=elev_state_50m_vrt

# use VRT as a MASK
r.mask raster=elev_state_50m_vrt  
All subsequent raster operations will be limited to the MASK area. Removing
or renaming raster map named 'MASK' will restore raster operations to
normal.
[Raster MASK present]

r.out.gdal input=elevation output=bla.tif create="COMPRESS=LZW"
Checking GDAL data type and nodata value...
Segmentation fault (core dumped)
[Raster MASK present]

The segmentation fault problem is likely a conceptual one ("GDAL on top of GDAL").

Debugging

gdb r.out.gdal
r input=elevation output=bla.tif create="COMPRESS=LZW"

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f6fe16 in Rast_get_vrt_row (fd=1, buf=0x58c510, row=0, data_type=0) at vrt.c:208
208		    for (j = 0; j < p->clist->n_values; j++) {
(gdb) bt
#0  0x00007ffff7f6fe16 in Rast_get_vrt_row (fd=1, buf=0x58c510, row=0, data_type=0) at vrt.c:208
#1  0x00007ffff7f5fdd4 in get_map_row_nomask (fd=1, rast=0x58c510, row=0, data_type=0) at get_row.c:567
#2  0x00007ffff7f60a76 in embed_mask (flags=0x588370 '\001' <repeats 200 times>..., row=0) at get_row.c:994
#3  0x00007ffff7f60c06 in get_null_value_row (fd=0, flags=0x588370 '\001' <repeats 200 times>..., row=0, with_mask=1) at get_row.c:1023
#4  0x00007ffff7f60cc5 in embed_nulls (fd=0, buf=0x577d30, row=0, map_type=1, null_is_zero=0, with_mask=1) at get_row.c:1042
#5  0x00007ffff7f5ff04 in get_map_row_no_reclass (fd=0, rast=0x577d30, row=0, data_type=1, null_is_zero=0, with_mask=1) at get_row.c:593
#6  0x00007ffff7f5ffde in get_map_row (fd=0, rast=0x577d30, row=0, data_type=1, null_is_zero=0, with_mask=1) at get_row.c:616
#7  0x00007ffff7f6016b in Rast_get_row (fd=0, buf=0x577d30, row=0, data_type=1) at get_row.c:761
#8  0x000000000040422a in exact_checks (export_datatype=GDT_Float32, name=0x4de050 "elevation", mapset=0x4de150 "PERMANENT", cellhead=0x7fffffffceb0, maptype=1, 
    nodataval=-nan(0x8000000000000), nodatakey=0x409c25 "nodata", default_nodataval=1) at export_band.c:77
#9  0x00000000004071e9 in main (argc=5, argv=0x7fffffffd0c8) at main.c:535

This happens both in G7.8 as well as master.

[Bug] 3d view changing perfomances

This is about Grass 3d view performances.

Can it be that the capacity Grass has to show 3d views diminish after having experienced a crash or a block of the program?
This is my experience, now with 2 differents computers. The former with both Win 7 and Ubuntu, the former with Windows 10.
The most recent is with a 14GB raster file that worked fine as I installed Grass on a new computer and now makes the program being blocked or crash. But the same happened with the previous one.
The problem is not that the program crashes, or not only: the problem is that you won't be able to see your 3d any longer.

Does Grass or Python keeps memory of some events, a memory that lasts even if I unistall it? If so, where can I find the files to be deleted?

To Reproduce
Steps to reproduce the behavior*: import the file, which has been used to set the region and once in the map display, switch to 3d view.

Expected behavior
Here is what the console reports:

(Wed Apr 8 17:53:33 2020)
r.import input=D:\job\Sicilie occidentali\Sicilia occidentale 2x2.tif output=Sicilia_occidentale_2x2
Importing raster map <Sicilia_occidentale_2x2>...
(Wed Apr 8 17:55:16 2020) Comando terminato (1 min 42 sec)
Avviando la visualizzazione 3D...
Caricando raster Sicilia_occidentale_2x2@PERMANENT
Traceback (most recent call last):
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 424, in OnPaint

self.DoPaint()
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 436, in DoPaint

self.LoadDataLayers()
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 1322, in
LoadDataLayers

self.LoadRaster(item)
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 1517, in
LoadRaster

return self._loadRaster(item)
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 1537, in
_loadRaster

id = self._display.LoadSurface(str(layer.name), None, None)
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\wxnviz.py", line 365, in LoadSurface

self.data)
OSError
:
exception: access violation writing 0x0000022AFEB792C8
Traceback (most recent call last):
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 424, in OnPaint

self.DoPaint()
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 436, in DoPaint

self.LoadDataLayers()
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 1322, in
LoadDataLayers

self.LoadRaster(item)
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 1517, in
LoadRaster

return self._loadRaster(item)
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 1537, in
_loadRaster

id = self._display.LoadSurface(str(layer.name), None, None)
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\wxnviz.py", line 365, in LoadSurface

self.data)
OSError
:
exception: access violation reading 0x0000022AFEB33370
Traceback (most recent call last):
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 424, in OnPaint

self.DoPaint()
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 436, in DoPaint

self.LoadDataLayers()
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 1322, in
LoadDataLayers

self.LoadRaster(item)
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 1517, in
LoadRaster

return self._loadRaster(item)
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\mapwindow.py", line 1537, in
_loadRaster

id = self._display.LoadSurface(str(layer.name), None, None)
File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\nviz\wxnviz.py", line 365, in LoadSurface

self.data)
OSError
:
exception: access violation reading 0x0000022AFEB33370

System description (please complete the following information):

• Operating System: Window 10 -
• GRASS GIS version [e.g. 7.8.1]

Additional context
Add any other context about the problem here.

[Bug] wxGUI digitizer: background vector map with @mapset kills wxGUI

Describe the bug

Selecting in the additional tools for digitizing a vector background with @mapset ...

...the wxGUI is killed and the vector map destroyed. :(

Message in the terminal:
Illegal filename <ne_10m_admin_0_countries@PERMANENT>. <@> not allowed.

This is "funny" because the map selection dialog naturally adds the @mapset part.

System description (please complete the following information):

Linux Fedora 32

GRASS 7.8.3dev (latlong_wgs84):~ > g.version -rge
version=7.8.3dev
date=2020
revision=42388e55e
build_date=2020-03-15
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] Can't create new location in Grass 7.8.2 - missing projections

Describe the bug
Can't create new location in Grass 7.8.2 - missing projections. OSGeo4W, Win10

To Reproduce

1. Clean express install OSGeo4W64
2. Launch GRASS
3. Click New grass location, then Next
4. Select radio button 'Select EPSG code of spatial reference system', next
5. list of codes is not visible and cannot be searched. Next is greyed out, cannot proceed further

Expected behavior
List of projections available for choosing

System description (please complete the following information):

• Operating System: Windows 10 Enterprise build 18363
• GRASS GIS version 7.8.2
• in OSgeo4w shell, grass78 g.version - rge errors out as database directory, mapset and location are not set correctly

Additional context
epsg file missing from usual location C:\OSGeo4W64\share\proj
Can't see any relevant issues under OSgeo/proj
Adding proj5 using the advanced installer option causes the epsg file to appear but does not solve this problem
Error message on first launch that demolocation is missing - should be in C:\Users\%USER%\Documents\grassdata, which was not created on install. Can find it in C:\OSGeo4W64\apps\grass\grass78 tho...
All support packages mentioned in #371 are installed
Standalone GRASS installer works perfectly

[Feat] Use JSON for GUI settings

We should use JSON or any other standard format for GUI settings. Should be quite easy to implement. We should take care of backwards compatibility though.

[Bug] Update build GRASS as macOS application

Describe the bug
Building GRASS as a macOS application needs to be updated for Python 3 and long-gone packagemaker needs to be replaced.

To Reproduce
Steps to reproduce the behavior:

Compiling with --enable-macosx-app using Python 3 fails.

System description (please complete the following information):

• Operating System: macOS 14+
• GRASS GIS version 7.8.2+
• Python 3 with wxPython 4

[Bug] .dylib GDAL libs should be listed in lib/raster/gdal.c

The file lib/raster/gdal.c has a list of possible GDAL lib names it can dlopen () in the load_library function. However, this list so far has only included .so or .dll suffixes, which are fine for Linux and Windows, but obviously not for MacOS. It would be nice to add something like:

# ifdef _ _APPLE_ _
"libgdal.26.dylib",
…

That would help eliminate a patch file. Thanks!

[Feat] v.out.postgis enhancement

Is your feature request related to a problem? Please describe.

With v.out.postgis everything is correctly exported from GRASS to PostGIS database but taking from an hour to 4-6 hours to be reimported.
v.out.ogr is faster 10 to 30 minutes but layer rendering is different with overlap and duplicate feature.

Input layer example :
Some of features are duplicated or overlapping.

v.out.org result :
GRASS cuts and intersects everything but duplicate (underlap / overlap) are still keep even if we use layer argument (try 0 or 1 or 2),
0 keep only duplicate, 1 keep everything, 2 is empty or not exists.

v.out.postgis result :
GRASS cuts everything and there is no under or overlap with other object. I've got one and perfectly clean layer.

Describe the solution you'd like
Same quality of v.out.postgis but as fast as v.out.ogr

Describe alternatives you've considered
Export v.out.org > GPKG and then reimport GPKG to PostGIS ... Bad alternative from my opinion.

Additional context
We produce "heavy" layer such as Urban Atlas, High Resolution Layer, (for Copernicus Land Monitoring). Lot of nodes, polygons, etc.

[Bug] wxGUI: raster query tool first click without result

Describe the bug
When querying a raster map, the first click opens the result window but doesn't show the queried pixel value. This only occurs at a second (and later) click.

To Reproduce
Load a raster map and interrogate it with the wxGUI "Query raster / vector map(s)" tool.

Expected behavior
Also show the result of the first query (this used to work, perhaps this bug appeared with the move to Python 3?).

System description (please complete the following information):
g.version -rge
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

Python: 3.7.6
wxPython: 4.0.6
Platform: Linux-5.4.13-201.fc31.x86_64-x86_64-with-fedora-31-Thirty_One

[Bug] r.mapcalc: parse error with eval function and neighborhood modifier

r.mapcalc: parse error with eval function and neighborhood modifier

r.mapcalc can't parse statements if they:

• creates new rasters;
• contains neighborhood modifier on the new rasters.

To Reproduce

Example 1.

r.mapcalc <<EOF
eval(tmp1=1,\
    tmp2=2,\
    result = tmp1[0,0] + tmp2[0,1])
tmp = result
EOF

The result is the next message:

syntax error, unexpected '[', expecting ')'

Example 2.

r.mapcalc <<EOF
tmp1 = 1
tmp = tmp1[0,0] + tmp1[0,1]
EOF

The result is the next error message:

syntax error, unexpected '[', expecting $end

[Feat] r.kappa: improve output and add User's and Producer's accuracies

r.kappa lacks:

• User's and Producer's accuracies
• Output in CSV
• sort output differently:
  • arrange user and producer accuracies and omission and commission around the error matrix instead of the summary columns
• add notes to "map1" and "map2" to explain what that means (more user friendly)

For a working solution, see https://github.com/OSGeo/grass-addons/blob/master/grass7/raster/r.confusionmatrix/r.confusionmatrix.py

[Bug] r.reclass: no proper result if list is not ordered numerically

Describe the bug
Feeding r.reclass with an unordered list of values like:

245 275 247 271 261 754 556 470 244 632 738 663 = 2 (High suitability)

will not lead to a proper result (NULL pixels are returned).
r.reclass only works properly when having numerically sorted the values:

244 245 247 261 271 275 470 556 632 663 738 754 = 2 (High suitability)

Maybe not a true bug but it would be helpful to auto-sort the left side values while reading them into r.reclass.

r.slope.aspect with -n flag giving aspect of flat areas as -9998

r.slope.aspect with the "new" -n flag is giving aspect values of flat areas as -9998, instead of -9999, when the precision choosed is CELL, and the output data type is CELL.

I've tested with GRASS 7.6 (on Linux) and GRASS 7.8.2 (on Windows), both in the GUI and CLI.

(Tue Jan 28 11:19:40 2020)                                                      
r.slope.aspect -e -n --verbose elevation=SRTM_PT_25m@PERMANENT slope=SRTM_PT_25m_Slope_Deg_GRASS aspect=SRTM_PT_25m_Aspect_Std_GRASS precision=CELL
Percent complete...
Elevation products for mapset <PERMANENT> in <SRTM_PT_25m>
Min computed aspect 0.0000, max computed aspect 360.0000
Aspect raster map <SRTM_PT_25m_Aspect_Std_GRASS> complete
Min computed slope 0.0000, max computed slope 75.2970
Slope raster map <SRTM_PT_25m_Slope_Deg_GRASS> complete
(Tue Jan 28 11:20:24 2020) Comando terminado (43 sec)  

r.info map=SRTM_PT_25m_Aspect_Std_GRASS@PERMANENT                              
 +----------------------------------------------------------------------------+
 | Map:      SRTM_PT_25m_Aspect_Std_GRASS@  Date: Tue Jan 28 11:20:24 2020    |
 | Mapset:   PERMANENT                      Login of Creator: PedroVenancio   |
 | Location: SRTM_PT_25m                                                      |
 | DataBase: D:\ICNF\Modelos_Combustivel_2018\Landscape_File\grass78          |
 | Title:    Aspect counterclockwise in degrees from east                     |
 | Timestamp: none                                                            |
 |----------------------------------------------------------------------------|
 |                                                                            |
 |   Type of Map:  raster               Number of Categories: 360             |
 |   Data Type:    CELL                                                       |
 |   Rows:         23200                                                      |
 |   Columns:      11360                                                      |
 |   Total Cells:  263552000                                                  |
 |        Projection: ETRS89 / Portugal TM06                                  |
 |            N:     278000    S:    -302000   Res:    25                     |
 |            E:     164000    W:    -120000   Res:    25                     |
 |   Range of data:    min = -9998  max = 360                                 |
 |                                                                            |
 |   Data Source:                                                             |
 |    raster elevation file SRTM_PT_25m@PERMANENT                             |
 |                                                                            |
 |                                                                            |
 |   Data Description:                                                        |
 |    generated by r.slope.aspect                                             |
 |                                                                            |
 |   Comments:                                                                |
 |    aspect map elev = SRTM_PT_25m@PERMANENT                                 |
 |    zfactor = 1.00                                                          |
 |    min_slope = 0.000000                                                    |
 |                                                                            |
 |    r.slope.aspect --verbose -e -n elevation="SRTM_PT_25m@PERMANENT" slo\   |
 |    pe="SRTM_PT_25m_Slope_Deg_GRASS" aspect="SRTM_PT_25m_Aspect_Std_GRAS\   |
 |    S" format="degrees" precision="CELL" zscale=1.0 min_slope=0.0           |
 |                                                                            |
 +----------------------------------------------------------------------------+
(Tue Jan 28 11:26:09 2020) Comando terminado (0 sec) 

Using the default precision as FCELL, all goes ok:

(Tue Jan 28 11:33:08 2020)                                                      
r.slope.aspect -e -n --verbose elevation=SRTM_PT_25m@PERMANENT slope=SRTM_PT_25m_Slope_Deg_GRASS_2 aspect=SRTM_PT_25m_Aspect_Std_GRASS_2
Percent complete...
Elevation products for mapset <PERMANENT> in <SRTM_PT_25m>
Min computed aspect 0.0000, max computed aspect 359.8096
Aspect raster map <SRTM_PT_25m_Aspect_Std_GRASS_2> complete
Min computed slope 0.0000, max computed slope 75.2970
Slope raster map <SRTM_PT_25m_Slope_Deg_GRASS_2> complete
(Tue Jan 28 11:34:01 2020) Comando terminado (53 sec)

(Tue Jan 28 11:34:27 2020)                                                      
r.info map=SRTM_PT_25m_Aspect_Std_GRASS_2@PERMANENT                            
 +----------------------------------------------------------------------------+
 | Map:      SRTM_PT_25m_Aspect_Std_GRASS_  Date: Tue Jan 28 11:34:01 2020    |
 | Mapset:   PERMANENT                      Login of Creator: PedroVenancio   |
 | Location: SRTM_PT_25m                                                      |
 | DataBase: D:\ICNF\Modelos_Combustivel_2018\Landscape_File\grass78          |
 | Title:    Aspect counterclockwise in degrees from east                     |
 | Timestamp: none                                                            |
 |----------------------------------------------------------------------------|
 |                                                                            |
 |   Type of Map:  raster               Number of Categories: 360             |
 |   Data Type:    FCELL                                                      |
 |   Rows:         23200                                                      |
 |   Columns:      11360                                                      |
 |   Total Cells:  263552000                                                  |
 |        Projection: ETRS89 / Portugal TM06                                  |
 |            N:     278000    S:    -302000   Res:    25                     |
 |            E:     164000    W:    -120000   Res:    25                     |
 |   Range of data:    min = -9999  max = 359.8097                            |
 |                                                                            |
 |   Data Source:                                                             |
 |    raster elevation file SRTM_PT_25m@PERMANENT                             |
 |                                                                            |
 |                                                                            |
 |   Data Description:                                                        |
 |    generated by r.slope.aspect                                             |
 |                                                                            |
 |   Comments:                                                                |
 |    aspect map elev = SRTM_PT_25m@PERMANENT                                 |
 |    zfactor = 1.00                                                          |
 |    min_slope = 0.000000                                                    |
 |                                                                            |
 |    r.slope.aspect --verbose -e -n elevation="SRTM_PT_25m@PERMANENT" slo\   |
 |    pe="SRTM_PT_25m_Slope_Deg_GRASS_2" aspect="SRTM_PT_25m_Aspect_Std_GR\   |
 |    ASS_2" format="degrees" precision="FCELL" zscale=1.0 min_slope=0.0      |
 |                                                                            |
 +----------------------------------------------------------------------------+
(Tue Jan 28 11:34:28 2020) Comando terminado (0 sec)  

The elevation map I'm using is this one:
https://www.fc.up.pt/pessoas/jagoncal/srtm/SRTM_PT_25m.tif

As CELL is a 32 bit integer with a range from -2,147,483,647 to +2,147,483,647, -9999 should be fine to conform inside it.

Another issue I see is in r.info, that is showing the title as

| Title: Aspect counterclockwise in degrees from east

which is not correct in this case, as the -n flag was used.

Should I fill another ticket for this issue?

Thanks!

[Feat] Refactor g.extension.py

The source code of g.extension.py is too long.
Long ago I started refactoring g.extension.py.
This attempt remained unfinished :-/.

Maybe there is interest to move in more modular structures and easier to read and understand code.

[Bug] error feast with gcc-9.3 and python-3.8.2

hi there,
cannot compile grass version 7.8.2, 3 errors show up. Any help welcome.

1)grass-7.8.2/lib/python/ctypes
A lot of ---->
Error: /usr/include/sys/stat.h:235: Syntax error at '__buf'
Error: /usr/include/sys/stat.h:259: Syntax error at '__file'
Error: /usr/include/sys/stat.h:260: Syntax error at '__buf'
Status: Processing description list.
Warning: Member "def" of Struct "Option" has been renamed to "_def" because it has the same name as a Python keyword.
Status: Writing to OBJ.x86_64-mageia-linux-gnu/raster.py.
Status: Wrapping complete.
free(): invalid pointer
make[1]: *** [Makefile:102: OBJ.x86_64-mageia-linux-gnu/raster.py] Aborted (core dumped)
make[1]: *** Deleting file 'OBJ.x86_64-mageia-linux-gnu/raster.py'
make[1]: Leaving directory '/root/repos/grass/BUILD/grass-7.8.2/lib/python/ctypes'
make: *** [Makefile:81: default] Error 2

2)grass-7.8.2/display/d.linegraph

Traceback (most recent call last):
File "/root/repos/grass/BUILD/grass-7.8.2/dist.x86_64-mageia-linux-gnu/tools/g.html2man.py", line 45, in main
p.feed(line)
File "/usr/lib64/python3.8/html/parser.py", line 111, in feed
self.goahead(0)
File "/usr/lib64/python3.8/html/parser.py", line 173, in goahead
k = self.parse_endtag(i)
File "/usr/lib64/python3.8/html/parser.py", line 412, in parse_endtag
self.handle_endtag(tagname)
File "/root/repos/grass/BUILD/grass-7.8.2/dist.x86_64-mageia-linux-gnu/tools/ghtml.py", line 231, in handle_endtag
if self.pop() == tag:
File "/root/repos/grass/BUILD/grass-7.8.2/dist.x86_64-mageia-linux-gnu/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 "/root/repos/grass/BUILD/grass-7.8.2/dist.x86_64-mageia-linux-gnu/tools/g.html2man.py", line 78, in
main()
File "/root/repos/grass/BUILD/grass-7.8.2/dist.x86_64-mageia-linux-gnu/tools/g.html2man.py", line 49, in main
(infile, err.lineno, err.offset, err.msg))
AttributeError: 'IndexError' object has no attribute 'lineno'
make: *** [../../include/Make/Html.make:11: /root/repos/grass/BUILD/grass-7.8.2/dist.x86_64-mageia-linux-gnu/docs/man/man1/d.linegraph.1] Error 1

3. Same error in grass-7.8.2/man

[Bug] wxGUI digitizer: integer attribute entry of 0 becomes NULL

Describe the bug

When digitizing vectors with integer attribute(s), entering a 0 leads to the value being stored as NULL.

Backend: sqlite

To Reproduce
Steps to reproduce the behavior:

1. wxGUI, open vector digitizer
2. create new vector map
3. define one attribute column called e.g. myvalue, type INTEGER
4. ok
5. digitze an area, enter 0 as value in the upcoming attribute dialog
6. quit digitizer and save vector map
7. run v.db.select on vector map or query the polygon
8. --> attribute is NULL and not 0

Expected behavior

A zero (0) should be stored as such. No problems with 1 etc....

System description (please complete the following information):

Linux Fedora 32

GRASS 7.8.3dev (latlong_wgs84):~ > g.version -rge
version=7.8.3dev
date=2020
revision=42388e55e
build_date=2020-03-15
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

[Feat] PROJ 7.0.0 released - check for adaption in (win)GRASS

Is your feature request related to a problem? Please describe.

PROJ 7.0.0 has been released these days (announcement)

It is my pleasure to announce new releases of PROJ and related packages.

The major feature in PROJ 7 is significantly improved handling of gridded
models. This was implemented in RFC4 [0]. The main features of the RFC4
work is that PROJ now implements a new grid format, Geodetic TIFF grids,
for exchaning gridded transformation models. In addition to the new grid format,
PROJ can now also access grids online using a data store in the cloud.

The grids that was previously available via the proj-datumgrid packages are now
available in two places:

  1. The new PROJ-data package
  2. From the cloud via https://cdn.proj.org

The PROJ-data package includes all grids and other resources previously tracked
by the proj-datumgrid series of packages as well as some new grids. All grids in the
PROJ-data package have been converted to the new Geodetic Tiff Grid (GTG)
format introduced in PROJ with RFC4. The advantages of the GTG format are 

* Grids can contain more metadata than previous formats used by PROJ
* Grids are compressed, taking up significantly less space
* Cloud optimized, for easy on-the-fly access to grids online via https://cdn.proj.org/
* Advanced gridded models previously consisting of several files can now be
  contained in one file

The data in the PROJ-data package is mirrored on https://cdn.proj.org/. A
network-enabled PROJ build can leverage the CDN and retrieve (parts of) grids as
specific transformations need them on the fly.

PROJ-data can only be used with PROJ 7.0.0 and newer.

Provided with PROJ is a utility called projsync that can be used download grids
from the data store in the cloud.

The use of the new grid format and the data from the cloud requires that
PROJ is build against libtiff and libcurl. Both are optional dependencies
to PROJ but it is highly encouraged that the software is build against both.

PROJ 7.0.0 and the accompanying PROJ-data package can be download here:

http://download.osgeo.org/proj/proj-7.0.0.tar.gz
http://download.osgeo.org/proj/proj-7.0.0.zip

http://download.osgeo.org/proj/proj-data-1.0.tar.gz
http://download.osgeo.org/proj/proj-data-1.0.zip

In addition the PROJ-data package the old proj-datumgrid series of packages
has also been updated, to extend the life-time of the PROJ 6.x branch a bit
longer. These will be the last updates to the proj-datumgrid packages. The
Updated packages can be downloaded here:

http://download.osgeo.org/proj/proj-datumgrid-europe-1.6.tar.gz
http://download.osgeo.org/proj/proj-datumgrid-europe-1.6.zip

http://download.osgeo.org/proj/proj-datumgrid-north-america-1.4.tar.gz
http://download.osgeo.org/proj/proj-datumgrid-north-america-1.4.zip

http://download.osgeo.org/proj/proj-datumgrid-oceania-1.2.tar.gz
http://download.osgeo.org/proj/proj-datumgrid-oceania-1.2.zip


ATTENTION: PROJ 7 will be last major release version that includes the proj_api.h
header. The functionality in proj_api.h is deprecated and only supported in
maintenance mode. It is inferior to the functionality provided by functions
in the proj.h header and all projects still relying on proj_api.h are encouraged
to migrate to the new API in proj.h. See https://proj.org/development/migration.html
for more info on how to migrate from the old to the new API.

[0] https://proj.org/community/rfc/rfc-4.html

Describe the solution you'd like

check for needed adaptions in (win)GRASS; e.g. which PROJ-data package should be included in standalone installers, etc.

[Bug] r.info -e output line breaks not properly managed

Describe the bug
With the -e flag, r.info removes line breaks in the comments / history and adds line continuation. As a result, history cannot be parsed.

To Reproduce
Steps to reproduce the behavior:

# Copy elevation map
g.copy raster=elevation,elevation_hist
# Add two lines to history
r.support elevation_hist history=BREAK
r.support elevation_hist history=ME

# Print extended info in key-value form (no line breaks)
r.info -e elevation_hist
# Print history (with line breaks)
r.info -h elevation_hist

Expected behavior
Result should be something like:

map=elevation_hist
(...)
comments="r.proj input="ned03arcsec" location="northcarolina_latlong" mapset="helena" output="elev_ned10m" method="cubic" resolution=10
BREAK
ME"

System description (please complete the following information):

version=7.9.dev
date=2019
revision=f1f82d16b
build_date=2019-12-03
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=00000
libgis_date="?"
proj=5.2.0
gdal=2.3.2
geos=3.7.1
sqlite=3.26.0

Additional context
See: e.g.
#476
https://www.mail-archive.com/[email protected]/msg59103.html

[Bug] SyntaxWarning: "is" with a literal. Did you mean "=="? if value is '':

Seen on Debian upgrade:

/usr/lib/grass78/etc/python/grass/pygrass/gis/__init__.py:75: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if value is '':
/usr/lib/grass78/etc/python/grass/temporal/core.py:65: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if do_profiling is "True" or do_profiling is "1":
/usr/lib/grass78/etc/python/grass/temporal/core.py:65: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if do_profiling is "True" or do_profiling is "1":
/usr/lib/grass78/etc/python/grass/temporal/core.py:582: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if driver_string is not None and driver_string is not "":
/usr/lib/grass78/etc/python/grass/temporal/temporal_algebra.py:2295: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if map_i.get_type() is "raster" or map_i.get_type() is "raster3d":
/usr/lib/grass78/etc/python/grass/temporal/temporal_algebra.py:2295: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if map_i.get_type() is "raster" or map_i.get_type() is "raster3d":
/usr/lib/grass78/gui/wxpython/core/gconsole.py:600: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if line[0] is '#' and line[1] is '%':
/usr/lib/grass78/gui/wxpython/core/gconsole.py:600: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if line[0] is '#' and line[1] is '%':
/usr/lib/grass78/gui/wxpython/dbmgr/vinfo.py:170: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if where is None or where is '':
/usr/lib/grass78/gui/wxpython/gmodeler/model.py:261: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if not mapName or mapName[0] is '%':
/usr/lib/grass78/gui/wxpython/gui_core/gselect.py:1868: SyntaxWarning: "is" with a literal. Did you mean "=="?
  self.changingSizer.Show(self.dbPanel, show=(sourceType is 'db'))
/usr/lib/grass78/gui/wxpython/location_wizard/wizard.py:1306: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if self.scope is 'earth':

[Bug] Autogenerated GUI dialogs lack vertical scrollbars

Some module windows have a content larger than can be displayed in a module window. Unfortunately almost all module windows lack vertical scrollbar and thus part of options are inaccessible. Only way around is to increase window size to ludicrous (for some windows it is 2 to 3 times the display size!).
Some of module windows (r.sun) do have a scrollbar, but it is waaaaay too short.

To Reproduce
Steps to reproduce the behaviour:

1. Launch r.sun or g.region or v.distance or i.maxlik
2. Dude, where are my options?!?

Expected behaviour
A scroll bar is displayed if whole window content doesn't fit into current window size.

Screenshots
r.sun window after scrolling to the bottom. No window resizing has been done. Full size of the r.sun window is approx. 1000x1300 px.

System description (please complete the following information):

• Operating System: Gentoo Linux
  GRASS versija: 7.9.dev
  Code revision: aa3ba0f
  Būvējuma datums: 2020-04-02
  Būvēšanas platforma: x86_64-pc-linux-gnu
  GDAL: 3.0.4
  PROJ: 6.3.1
  GEOS: 3.8.1
  SQLite: 3.31.1
  Python: 3.6.10
  wxPython: 4.0.7.post2
  Platforma: Linux-5.5.5-gentoo-x86_64

[Bug] i.pansharpen fails in GRASS 7.8+

Describe the bug
i.pansharpen fails with python3 in grass 78+

Errors on line 552:
stats = stats_out.communicate()[0].split('\n')[:-1]

Error produced:
TypeError: a bytes-like object is required, not 'str'

I believe this is code designed for python2, but I am no python expert.

To Reproduce
Run i.pansharpen on system that defaults to python3.

Expected behavior
Beautiful pictures

System description (please complete the following information):

• Ubuntu in VM
• GRASS GIS version [github trunk] and GRASS 7.8.1+

[Feat] Pan to feature

Is your feature request related to a problem? Please describe.
There seems to be no way to zoom to selected feature(s) from the attribute table.

Describe the solution you'd like
It would be great if there is "Zoom to feature" in the context menu in the attribute table. Maybe, just double click as well?

Describe alternatives you've considered
Extracting features, but that's just not desirable when you only want to inspect certain features quickly.

[Feat] r.slope.aspect: Clockwise from North with flat = 0 and -9999 as NULL

Is your feature request related to a problem? Please describe.

Picking arbitrary combination of CW from North vs CCW from East and flat = -9999 vs flat = 0 is not possible. Additionally -9999 is strange since GRASS GIS is not using this as a special value.

Describe the solution you'd like

The orientation (direction plus reference direction - please suggest better naming if needed) should be selected separately from representation of flag areas in the aspect raster map. For example:

r.slope.aspect orientation=counter-clockwise-east flat=0
r.slope.aspect orientation=clockwise-north flat=-9999
r.slope.aspect orientation=counter-clockwise-east flat=NULL

Besides the greater variability, key=value options are more readable than flags and can be extended by adding, e.g., units=degrees/radians (or modified to split direction and reference direction).

This does not require removing the -n flag, but it is now possible before v8. (Side note: Based on qgis/QGIS/pull/34087, removal of -n will need to be propagated to QGIS.)

Describe alternatives you've considered

Better letter and description for the -n flag, something like "-d Behave like gdaldem (clockwise from North with flat = -9999)."

Additional context

This is continuation of a discussion from #320 by @petrasovaa and @metzm:

BTW, any reason why r.slope.aspect doesn't use nulls instead of 0 or -9999 for aspect of flat areas? Isn't that some legacy behavior or does it have a reason?

The reason is to be compliant with gdaldem which uses -9999 by default as the nodata value.

What is the reason to be compliant with gdaldem in this? Do we use -9999 for nodata anywhere else instead of NULLs? If compatibility with gdaldem is desired or some particular behavior is needed for QGIS that's something we should have, but I think we need to add it systematically. -n now switches both orientation and flat areas.

One way to resolve this would be naming the flag describing what it is: "behave like gdaldem" but we do or did have such parameters here and there and it is just very cryptic for people not knowing gdaldem and this includes the case where you are wondering why CW from N is connected with -9999 for flat. A better way would be to introduce this as two (or three) options giving user flexibility in a general way rather than solving one particular compatibility challenge. Additionally, NULLs should be provided as an additional option since it well represents "I don't know" as the answer to orientation of a flat area.

[Bug] wxnviz.py: item 1 in _argtypes_ passes a union by value, which is unsupported. - wxGUI's vector digitizer is disabled

Describe the bug

when starting the daily winGRASS build, I get following error in the OSGeo4W-console

Starting GRASS GIS...
WARNUNG: Sperren gleichzeitiger Zugriffe auf ein Mapset ist unter Windows
         nicht möglich.
Cleaning up temporary files...

          __________  ___   __________    _______________
         / ____/ __ \/   | / ___/ ___/   / ____/  _/ ___/
        / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
       / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
       \____/_/ |_/_/  |_/____/____/   \____/___//____/

Welcome to GRASS GIS 7.9.dev (13669536c)
GRASS GIS homepage:                      https://grass.osgeo.org
This version running through:            Command Prompt (C:\WINDOWS\system32\cmd.exe)
Help is available with the command:      g.manual -i
See the licence terms with:              g.version -c
See citation options with:               g.version -x
If required, restart the GUI with:       g.gui wxpython
When ready to quit enter:                exit

Launching <wxpython> GUI in the background, please wait...
Microsoft Windows [Version 10.0.18363.657]
(c) 2019 Microsoft Corporation. Alle Rechte vorbehalten.

C:\>wxnviz.py: item 1 in _argtypes_ passes a union by value, which is unsupported.
wxdigit.py: item 1 in _argtypes_ passes a union by value, which is unsupported.

and in the

wxgui console:

vector digitizer not available                                           
reason: name 'sys' is not defined                                                
Note that the wxGUI's vector digitizer is disabled in this
installation. Please keep an eye out for updated versions of
GRASS. In the meantime you can use "v.edit" for non-
interactive editing from the Develop vector map menu.

To Reproduce
Steps to reproduce the behavior:

just start the daily winGRASS build in OSGeo4W

Expected behavior

a normal start with available vector digitizer

System description (please complete the following information):

System Info                                                                     
GRASS Version: 7.9.dev                                                          
Code revision: 13669536c                                                        
Build date: 2020-02-29                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 3.0.4                                                                     
PROJ: 6.3.1                                                                     
GEOS: 3.8.0                                                                     
SQLite: 3.29.0                                                                  
Python: 3.7.6                                                                   
wxPython: 4.0.7                                                                 
Platform: Windows-10-10.0.18362-SP0 (OSGeo4W)

Additional context
Add any other context about the problem here.

[Bug] wxGUI: map display incomplete when restoring settings from project file (gxw)

Describe the bug

Starting the wxGUI (here on a dual-screen system consisting of laptop and external monitor) leads to an incomplete initial map rendering:

g.gui workspace=~/santana.gxw &

leads to (full monitor view):

Then, after double click on border it is properly refreshed:

Expected behavior

The map display properties need to be correctly computed like it apparently happens after reducing the map window size. Maybe just an internal refresh is missing?

System description (please complete the following information):

Linux Fedora 32

GRASS 7.8.3dev (latlong_wgs84):~ > g.version -rge
version=7.8.3dev
date=2020
revision=42388e55e
build_date=2020-03-15
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] g.gui.iclass: missing removed matplotlib function

Describe the bug

The scatter plot functionality of g.gui.iclass is disabled for matplotlib 3.1.0+.

To Reproduce
Steps to reproduce the behavior:

Starting g.gui.iclass triggers an error alert:

Error

Scatter plot functionality is disabled.

Reason: Unable to import packages needed for scatter plot.
The Scatterplot Tool needs the "matplotlib" (python-matplotlib) package to be 
installed. cannot import name 'dist_point_to_segment' from 'matplotlib.mlab' 
(/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/matplotlib/mlab.py)

System description (please complete the following information):

g.version -rge
version=7.9.dev
date=2020
revision=aa0d48c15
build_date=2020-03-26
build_platform=x86_64-apple-darwin18.7.0
build_off_t_size=8
libgis_revision=
libgis_date=
WARNING: GRASS GIS libgis version and date number not available
proj=6.3.1
gdal=3.0.3
geos=3.8.0
sqlite=3.31.1

Official Python release:
Python=3.7.7
wxPython=4.0.7.post2 osx-cocoa (phoenix) wxWidgets 3.0.5
matplotlib=3.2.1

Additional context
matplotlib.mlab.dist_point_to_segment() was removed with matplotlib 3.1.0
The use of matplotlib.mlab.dist_point_to_segment() at

grass/gui/wxpython/iscatt/plots.py

Line 850 in 9ce853b

d = dist_point_to_segment(p, s0, s1)

need to be replaced. Using numpy can be an alternative, see e.g. https://stackoverflow.com/questions/39840030/distance-between-point-and-a-line-from-two-points/39840218.

[Bug] r.fillnulls bicubic interpolator fails to fill large holes

Describe the bug
Some changes within the last year have changed behaviour of r.filllnulls bicubic interpolator. If it encounters large hole, it is not completely filled — there are unfilled squares left + some strange values around the new hole edges produced.

To Reproduce
Steps to reproduce the behaviour:

g.region n=1000 s=0 e=1000 w=0 res=1
r.surf.fractal output=surf
r.circle -b output=circle coordinates=500,500 max=300
r.mapcalc expression="holed = if(isnull(circle), surf, null())"
r.fillnulls input=holed output=filled method=bicubic
r.univar map=filled | grep "total null cells"

Expected behavior
No null values

System description (please complete the following information):

• Operating System: Ubuntu Bionic
• GRASS GIS version: 9da94b7

[Bug] v.import gets stuck on old-style .gfs file during GML import

Due to the fact that GDAL 2.x appears to write a temporary .gfs file during GML import, it is not possible to import e.g. the cloud mask file shipped with a Sentinel-2 scene.

(Note: the problem no longer occurs with GDAL 3.x, tested with GDAL 3.0.4)

GML file to test:

• MSK_CLOUDS_B00_gml.zip

.gfs file (auto-generated with GDAL 3.0.4):

• MSK_CLOUDS_B00_gfs_gdal304.zip

# create UTM location
grass78 -c epsg:32749 ~/grassdata/utm_32749

# attempt to import cloud mask GML file
GRASS 7.8.3dev (utm_32749):~ > v.import MSK_CLOUDS_B00.gml 
ERROR: Unable to convert input map projection to GRASS format; cannot
       create new location.
ERROR: Unable to create location from OGR datasource <MSK_CLOUDS_B00.gml>

# now tricking it : -)
GRASS 7.8.3dev (utm_32749):~ > cp MSK_CLOUDS_B00.gfs_gdal304 MSK_CLOUDS_B00.gfs

# and import works fine with a proper .gfs file:
GRASS 7.8.3dev (utm_32749):~ > v.import MSK_CLOUDS_B00.gml 
Check if OGR layer <MaskFeature> contains polygons...
 100%
Creating attribute table for layer <MaskFeature>...
Importing 920 features (OGR layer <MaskFeature>)...
[...]
Attaching centroids...
 100%
Input <MSK_CLOUDS_B00.gml> successfully imported without reprojection

Now, what is the difference in the .gfs file bewteen GDAL 2.3.2 and GDAL 3.0.4?

diff -u MSK_CLOUDS_B00.gfs MSK_CLOUDS_B00.gfs_gdal304
--- MSK_CLOUDS_B00.gfs	2020-02-27 00:33:03.445970880 +0100
+++ MSK_CLOUDS_B00.gfs_gdal304	2020-02-26 09:49:10.623901959 +0100
@@ -4,6 +4,7 @@
     <ElementPath>MaskFeature</ElementPath>
     <!--POLYGON-->
     <GeometryType>3</GeometryType>
+    <SRSName>urn:ogc:def:crs:EPSG:8.7:32749</SRSName>
     <DatasetSpecificInfo>
       <FeatureCount>920</FeatureCount>
       <ExtentXMin>699960.00000</ExtentXMin>

... the SRSName tag has been introduced which makes things work.

Proof:

gdalinfo --version
GDAL 2.3.2, released 2018/09/21

# 1st run (successful due to absence of old-style .gfs file):
rm -f MSK_CLOUDS_B00.gfs
ogrinfo -so -al MSK_CLOUDS_B00.gml
INFO: Open of `MSK_CLOUDS_B00.gml'
      using driver `GML' successful.
Metadata:
  NAME=MSK_CLOUDS pixels mask from data-strip S2A_OPER_MSK_CLOUDS_SGS__20200223T061113_A024396_T49MGU_B00_MSIL1C
Layer name: MaskFeature
Geometry: Polygon
Feature Count: 920
Extent: (699960.000000, 9790240.000000) - (809760.000000, 9900040.000000)
Layer SRS WKT:
PROJCS["WGS 84 / UTM zone 49S",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
[...]
    AUTHORITY["EPSG","32749"]]
gml_id: String (0.0) NOT NULL
maskType: String (6.0)

# 2nd run (failing, since the first run created the .gfs file lacking the SRSName tag:
ogrinfo -so -al MSK_CLOUDS_B00.gml
INFO: Open of `MSK_CLOUDS_B00.gml'
      using driver `GML' successful.
Metadata:
  NAME=MSK_CLOUDS pixels mask from data-strip S2A_OPER_MSK_CLOUDS_SGS__20200223T061113_A024396_T49MGU_B00_MSIL1C

Layer name: MaskFeature
Geometry: Polygon
Feature Count: 920
Extent: (699960.000000, 9790240.000000) - (809760.000000, 9900040.000000)
Layer SRS WKT:
(unknown)
gml_id: String (0.0) NOT NULL
maskType: String (6.0)

Expected behavior
v.import should not fail during a GML import when having GDAL 2.x on the machine.

Discussion
Indeed the problem is more on the GDAL side than on the GRASS GIS side but it would take a long time to see an updated GDAL being widely available. Hence, a short term solution would be to somehow ignore the .gfs file during import (since not relevant anyway).

I tried to find in the GDAL GML driver where the .gfs is generated to see through git blame when the needed SRSNAME tag was introduced but I didn't figure it out... anyone? (maybe @rouault ?)

[Feat] v.to.db check of column names

When running v.to.db in the GRASS 7.9dev causes an error related to the creating of new columns. More specifically, I've predefined columns in an attribute table (linked to layer 2) which I want to update with the start and end coordinates of the lines. I am aware that there is a new feature related to v.to.db that checks if a column already exists and creates the columns if the do not exists.

Reproducible example
Steps to reproduce the behavior based on the NC dataset and based on python3 commands:

grass.run_command("v.category",
	overwrite=True,
	input="busroute_a@PERMANENT",
	option="add",
	layer=2,
	output="busroute_a2")
grass.run_command("v.db.addtable",
	map="busroute_a2", layer=2,
	columns="start_x DOUBLE, start_y DOUBLE, end_x DOUBLE, end_y DOUBLE")
grass.run_command("v.to.db",
	map="busroute_a2", layer=2,
	option="start",
	columns="start_x, start_y")

Error

>>> grass.run_command("v.to.db",
...     map="busroute_a2", layer=2,
...     option="start",
...     columns="start_x, start_y")
WARNING: Values in column <start_x> will be overwritten
DBMI-SQLite driver error:
Error in sqlite3_prepare():
duplicate column name: start_y
DBMI-SQLite driver error:
Error in sqlite3_prepare():
duplicate column name: start_y
ERROR: Unable to create column < start_y>
...

System description:
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

[Bug] wxGUI digitizer: Python TypeError in wxpython/mapwin/buffered.py

I digitized some areas in longlat, closed the digitizer, then after looking at some other layers switched again to the digitizer, trying to continue editing the same vector map.

This error appeared:

Traceback (most recent call last):
  File "/home/mneteler/software/grass78_git/dist.x86_64-pc-
linux-gnu/gui/wxpython/mapwin/buffered.py", line 1377, in
MouseActions

self.OnDragging(event)
  File "/home/mneteler/software/grass78_git/dist.x86_64-pc-
linux-gnu/gui/wxpython/mapwin/buffered.py", line 1486, in
OnDragging

self.digit.GetDisplay().GetSelected() > 0)):
TypeError
:
'>' not supported between instances of 'list' and 'int'

I cannot exactly say how to reproduce but it probably is a Python2 / 3 issue.

[Bug] ZSTD might require pthreads — configure failure

ZSTD library can be compiled with or without pthreads support. If it is compiled with pthreads, it needs them to be specified for proper linking. Unfortunately I do not have autotools-fu to create a PR.

Steps to reproduce the behavior:

1. Compile ZSTD with pthreads support
2. Attempt to configure GRASS
3. Observe error: “Unable to locate zstd library“

Expected behavior
GRASS configure phase picks up ZSTD library requirement of -lpthread

System description (please complete the following information):

• Operating System: Gentoo Linux ~AMD64
• GRASS GIS version: current master 79c069d

Additional context

configure:5535: checking whether to use zstd
configure:5551: checking for location of zstd includes
configure:5576: checking for zstd.h
configure:5584: gcc -E   conftest.c >/dev/null 2>conftest.out
configure:5618: checking for location of zstd library
configure:5643: checking for ZSTD_compress in -lzstd
configure:5660: gcc -o conftest -g -O2     -Wl,--export-dynamic conftest.c -lzstd   1>&5
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib64/libzstd.so: undefined reference to `pthread_join'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib64/libzstd.so: undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
configure: failed program was:
#line 5649 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char ZSTD_compress();

int main() {
ZSTD_compress()
; return 0; }

[Bug] Broken vector topology crashes wxGUI

Describe the bug

Opening a vector map (polygons) with broken topology (due to previous crash), the entire wxGUI shuts down:

Coor file of vector map
<high_low_suitable_Europe@figures> is larger
than it should be (180 bytes excess)
Traceback (most recent call last):
  File "/home/mneteler/software/grass78_git/dist.x86_64-pc-
linux-gnu/gui/wxpython/mapwin/buffered.py", line 593, in
OnPaint

self.pdcVector.DrawToDCClipped(gcdc, rgn)
wx._core
.
wxAssertionError
:
C++ assertion "n > 1" failed at
../src/common/graphcmn.cpp(742) in StrokeLines():
Traceback (most recent call last):
  File "/home/mneteler/software/grass78_git/dist.x86_64-pc-
linux-gnu/gui/wxpython/mapwin/buffered.py", line 593, in
OnPaint

self.pdcVector.DrawToDCClipped(gcdc, rgn)
wx._core
.
wxAssertionError
:
C++ assertion "n > 1" failed at
../src/common/graphcmn.cpp(742) in StrokeLines():
Traceback (most recent call last):
[...]

It seems to be in a loop, repeating the same Traceback multiple times (may also be due to zooming attempts).

To Reproduce

Hard to reproduce. It usually silently crashes.

System description (please complete the following information):

Linux Fedora 31

g.version -rge
version=7.8.3dev
date=2020
revision=ecc6e6f79
build_date=2020-04-04
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=340c2a4a0
libgis_date="Thu Apr 2 13:03:21 2020 +0200"
proj=5.2.0
gdal=2.3.2
geos=3.7.1
sqlite=3.30.0

Screenshot

GRASS GIS 7.8.2 doesn't show the attribute table of a vector layer

BUG DESCRIPTION
As far as I know, this problem only appears on GRASS GIS 7.8.2 in a MS Windows environment. If the attribute table of a vector layer has any enconding problem or error, GRASS GIS doesn't shows the attribute table. I've also tried this with GRASS GIS 7.6, and the attribute table is correctly shown no matter if the vector layer has an encoding problem. No problem neither on GNU/Linux.

Steps to reproduce the behavior:

1. Open GRASS GIS 7.8.2 on Windows
2. Import vector layers (EPSG:4326):
   datos_autoaprendizaje_redes.zip
3. Open the attribute table of both layers: no problem with POI's table. The problem concerns the roads attribute table layer.
4. The error shown in console :

Traceback (most recent call last):

 File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\lmgr\frame.py", line 2051, in
OnShowAttributeTable

selection=selection)
  File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\dbmgr\manager.py", line 112, in __init__

self.CreateDbMgrPage(parent=self, pageName='browse')
  File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\dbmgr\base.py", line 811, in
CreateDbMgrPage

parent=parent, parentDbMgrBase=self, onlyLayer=onlyLayer)
  File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\dbmgr\base.py", line 1095, in __init__

self.AddLayer(layer)
  File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\dbmgr\base.py", line 1138, in AddLayer

self.dbMgrData, layer, self.pages)
  File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\dbmgr\base.py", line 113, in __init__

keyColumn = self.LoadData(layer)
  File "C:\Program Files\GRASS GIS
7.8\gui\wxpython\dbmgr\base.py", line 278, in LoadData

record = decode(outFile.readline().strip()).replace('\n',
'')
  File "C:\Program Files\GRASS GIS
7.8\etc\python\grass\script\utils.py", line 193, in decode

return bytes_.decode(enc)
  File "C:\Program Files\GRASS GIS
7.8\Python37\lib\encodings\cp1252.py", line 15, in decode

return codecs.charmap_decode(input,errors,decoding_table)
UnicodeDecodeError
:
'charmap' codec can't decode byte 0x81 in position 57:
character maps to <undefined>

System description (please complete the following information):

• Operating System: Windows 10
• GRASS GIS version 7.8.2

[Bug] Unable use the Temporal Plot Tool on Ubuntu 18.04

Describe the bug

(cited from https://gis.stackexchange.com/questions/355146/unable-use-a-temporal-plot-tool-in-grass-gis; with permission)

I installed GRASS GIS following the tutorial on the website for the Ubuntu 18.04 version. However, the Temporal Plot Tool function is not working, and is giving an error related to python.

Below is the error that is giving in the tool.

Unable to start Temporal Plot Tool

Motivo: The Temporal Plot Tool needs the "Matplotlib" (python-matploltib) package to be installed. Cannot load backend 'WXAgg' which requires the 'wx' interactive framework, as 'gtk3' is currently running

Traceback (most recent call last)
File "/usr/local/grass78/gui/wxpython/tplot/frame.py", line 36, in <module>
matplolib.use('WXAgg')
File "/home/luiz/.local/lib/python3.6/site-packages/matplotlib/cbook/deprecation.py", line 296, in wrapper
return func(*args, **kwargs)
File "/home/luiz/.local/lib/python3.6/site-packages/matplotlib/cbook/deprecation.py", line 358, in wrapper
return func(*args, **kwargs)
File "/home/luiz/.local/lib/python3.6/site-packages/matplotlib/_init_.py", line 1281 in use 
plt.switch_backend(name)
File "/home/luiz/.local/lib/python3.6/site-packages/matplotlib/pyplot.py", line 237, in switch_backend
newbackend, required_framework, current_framework))
ImportError:Cannot load backend 'WXAgg' which requires the 'wx' interactive framework, as 'gtk3' is currently running

During handling odf the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/grass78/gui/wxpython/lmgr/frame.py", line 1930, in OnTplotTool
from tplot.frame import TplotFrame
File "/usr/local/grass78/gui/wxpython/tplot/frame.py", line 45, in 
<module>
'(python-matplotlib) package to be installed. {0}').format(e))
ImportError: The Temporal Plot Tool needs the "matplotlib" (python-matplotlib) package to be installed Cannot load backend 'WXAgg' which requires the 'wx' interactive framework, as 'gtk3' is currently running

What should I do to solve this problem?

System description (please complete the following information):

• Operating System: Ubuntu 18.04
• GRASS GIS version: 7.8

[Bug] bugs introduced with cc6dbeb in pythonlib

Describe the bug
The behaviour of handle_errors() in lib/python/script/core.py changed with cc6dbeb for no apparent reason, introducing several bugs.

To Reproduce
See bug fixed by #333.

Expected behavior
A clear and concise description of what has changed and why it was changed. The code and the documentation should match.

Additional context
@wenzeslaus @landam
Regarding the changes introduced with cc6dbeb to handle_errors(), the priority of the errors value is not clear and the code does not conform to the documentation. Possible values are apparently "raise", "fatal", "status", "exit", and "ignore", default is "raise". Those errors values independent of the returncode must come first: status, exit, ignore. After that, if the returncode is not 0, the errors values "raise", "fatal", "ignore" must be handled, "raise" will apparently be used if the errors value is not set. At the end, handle_errors() can return result or None for returncode == 0.

What is the reason for versionchanged:: 8.0? Why would returning None instead of 0 be better in case of returncode == 0?

[ Reading settings from file: not enough values to unpack (expected 2, got 1) Line: '']

Apologies as I am very new to GRASS and python...

Upon startup, command line reads:

Error: Reading settings from file <C:\Users\paige.byassee\AppData\Roaming\GRASS7\wx> failed.
                Details: not enough values to unpack (expected 2, got 1)
                Line: ''

This line will re-appear every time I call a function but doesn't seem to inhibit the function? (screenshot)

To Reproduce

Reproduced on previous ticket https://trac.osgeo.org/grass/ticket/3940#no1 but I've tried playing with the locale and software version but I cannot find a solution...

Expected behavior
Error message continues appearing; may not interfere

Screenshots

System description

• Windows 10
• GRASS GIS version 7.9.dev (7069dd3)

Additional context
I don't believe this computer ever had GRASS 7.6.1. I installed it a month or so back, no issues, then error suddenly appeared.

If I try to install notranslation function according to https://github.com/OSGeo/grass/pull/156/files I get the following message:

C:\Users\paige.byassee>g.extension notranslation WARNING: GRASS GIS libgis version and date number not available Downloading precompiled GRASS Addons <notranslation>... ERROR: Cannot open URL: http://wingrass.fsv.cvut.cz/grass79/x86_64/addons/grass-7.9.dev/notranslation.zip

Thanks and so sorry for any redundancies

[Bug] GRASS GIS 7.8.2 fails to launch under Windows 10

Describe the bug
GRASS GIS 7.8.2 fails to launch under Windows 10

To Reproduce
Steps to reproduce the behavior:

1. Install GRASS GIS via the OSGeo4W installer (express installation, default settings)
2. Open GRASS GIS 7.8.2 from Windows 10 menu
3. GRASS GIS 7.8.2 fails to launch

...
wxnviz.py: [WinError 126] The specified module could not be found
wxdigit.py: [WinError 126] The specified module could not be found
wxdigit.py: [WinError 126] The specified module could not be found
...

Complete GRASS GIS session starting messages, including the error(s) are copy-pasted at: https://pastebin.com/GjU3FCcv

Expected behavior
GRASS GIS 7.8.2 to launch error-free under Windows 10

System description (please complete the following information):

• Operating System: Windows 10 inside a Virtual Machine running in VirtualBox
• GRASS GIS version 7.8.2

[Feat] Improved v.extract for layers at position 2+

Several GRASS modules store results of a vector-map related process into a new layer; Consequently, often maps have more than one layer often with different attribute tables connected to different layers.

However, extracting a layer (using v.extract) that is not the default layer=1 but, for example, layer=2 produces a vector output map that has a layer 2 but no layer 1. So, at the moment the output of v.extract keeps the layer position of the input (which is not a bug). Keep in mind that the default input layer for most GRASS modules is layer 1; so having an extracted map with no default layer 1 doesn't make much sense. Extracting layer 2 into a new map (copying also the attribute table) where layer numbering starts with 1 involves several steps (see example below). I think this could be simplified.

Solution you'd like
It'd be nice to add a feature (e.g. via a flag or default?) to v.extract so that the extracted layers > 1 are automatically shifted to positions starting with 1 in the output.

Example based on the NC dataset

#Prepare test data based on the NC location
#Test data = GRASS vector map with attribute table connected to layer 2+
v.category --o input=streams@PERMANENT layer=2 output=streams_2 option=add
v.db.addtable map=streams_2 layer=2

### Extract layer 2 to a new map and shift it (and the attribute table) to layer 1
# Step 1: Extract layer
v.extract --o input=streams_2 layer=2 output=streams_2_extract

# Step 2: Change layer 2->1 of new map
v.category --o input=streams_2_extract layer=2,1 output=streams_2_extract_chlayer option=chlayer

# Step 3: Delete connection for old (not existing) layer 2 (I don't know why this connection still exists after v.category with chlayer?)
v.db.connect -d map=streams_2_extract_chlayer layer=2

# Step 4: Reconnect table to correct layer 1
v.db.connect map=streams_2_extract_chlayer table=streams_2_extract_chlayer layer=1

[Bug] v.rast.stats reports same numbers for number and null_cells (winGRASS)

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

v.rast.stats reports same figures for number and null_cells (winGRASS)

r.info map=test@user1                                                           
 +----------------------------------------------------------------------------+
 | Map:      test@user1                     Date: Tue Nov  7 00:35:18 2006    |
 | Mapset:   user1                          Login of Creator: helena          |
 | Location: nc_spm_08_grass7                                                 |
 | DataBase: C:\grassdata                                                     |
 | Title:    South-West Wake county: National Elevation Data 30m              |
 | Timestamp: none                                                            |
 |----------------------------------------------------------------------------|
 |                                                                            |
 |   Type of Map:  raster               Number of Categories: 255             |
 |   Data Type:    FCELL                                                      |
 |   Rows:         450                                                        |
 |   Columns:      500                                                        |
 |   Total Cells:  225000                                                     |
 |        Projection: Lambert Conformal Conic                                 |
 |            N:     228500    S:     215000   Res:    30                     |
 |            E:     645000    W:     630000   Res:    30                     |
 |   Range of data:    min = 77.96744  max = 142.6181                         |
 |                                                                            |
 |   Data Description:                                                        |
 |    generated by r.proj                                                     |
 |                                                                            |
 |   Comments:                                                                |
 |    r.proj input="ned1arcsec" location="northcarolina_latlong" mapset="h\   |
 |    elena" output="elev_ned30m" method="cubic" resolution=30                |
 |                                                                            |
 +----------------------------------------------------------------------------+

r.info -s map=test@user1                                                        
cells=225000
n=29999
min=77.9674377441406
max=142.618118286133
mean=109.115754272498
stddev=13.2661387869186
sum=3273363.51242065

g.region -p                                                                     
projection: 99 (Lambert Conformal Conic)
zone:       0
datum:      nad83
ellipsoid:  a=6378137 es=0.006694380022900787
north:      228500
south:      215000
west:       630000
east:       645000
nsres:      30
ewres:      30
rows:       450
cols:       500
cells:      225000

calculating v.rast.stats on this region settings gives

v.report map=myregion@user1 option=area                                         
cat|stats_number|stats_null_cells|area
1|29999|29999|202500000

System description (please complete the following information):

System Info                                                                     
GRASS Version: 7.8.2                                                            
Code revision: 3900fb114                                                        
Build date: 2019-12-11                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 3.0.2                                                                     
PROJ: 6.2.1                                                                     
GEOS: 3.8.0                                                                     
SQLite: 3.29.0                                                                  
Python: 3.7.0                                                                   
wxPython: 4.0.7                                                                 
Platform: Windows-10-10.0.17763-SP0 (OSGeo4W)

[Bug] v.edit option=break does not work as expected

Breaking a single line (using v.edit) into several at multiple given point locations does produce somehow unreasonable results. More specifically, when using v.edit with option=break and two coordinate pairs to break a single line: This results, if both points are provided at the same time (i.e. within the same command), in 4 categories (features?)! I'd expect that breaking a single line at two points would result in three lines.
When the line is broken consecutively, i.e. only one point coordinate pair is provided at one time, then the result is as expected 3 lines/categories.

To Reproduce (based on the NC dataset)

##########################################################
####### VERSION 1: Break lines at two points #############
####### THIS DOES NOT WORK: Results in 4 cats ############
# Extract single line for testing
v.extract --o input=streams@PERMANENT cats=92551 output=selected_stream_v1_1

# Break line at two point locations and clean (recommended after v.edit break)
v.edit map=selected_stream_v1_1 tool=break threshold=30 coords='635861,224469,635793,224553'
v.clean --o input=selected_stream_v1_1 output=selected_stream_v1_2 tool=rmdupl

# Add categories to layer 2 to check
v.category --o input=selected_stream_v1_2 layer=2 output=selected_stream_v1_3 option=add
v.db.addtable map=selected_stream_v1_3 layer=2
v.category input=selected_stream_v1_3 option=report

##########################################################
##### VERSION 2: Break lines at each point separately ####
####### THIS WORKS: Results in 3 cats ################
# Extract single line for testing
v.extract --o input=streams@PERMANENT cats=92551 output=selected_stream_v2_1

# Break line at two point locations and clean (recommended after v.edit break)
v.edit map=selected_stream_v2_1 tool=break threshold=30 coords='635861,224469'
v.edit map=selected_stream_v2_1 tool=break threshold=30 coords='635793,224553'
v.clean --o input=selected_stream_v2_1 output=selected_stream_v2_2 tool=rmdupl

# Add categories to layer 2 to check
v.category --o input=selected_stream_v2_2 layer=2 output=selected_stream_v2_3 option=add
v.db.addtable map=selected_stream_v2_3 layer=2
v.category input=selected_stream_v2_3 option=report

Expected behavior
I'd expect that breaking a single line at two points would result in three lines. This should also work when v.edit is provided multiple points/coordinate pairs at one time.

System description:
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

[Bug] g.gui.gcp: crash when closing (wx._core.wxAssertionError: C++ assertion "GetEventHandler())

Describe the bug

g.gui.gcp crashes with this error when closing:

...
(g.gui.gcp:551149): Gtk-WARNING **: 22:34:48.159: for_size smaller than min-size (18 < 32) while measuring gadget (node entry, owner GtkSpinButton)

(g.gui.gcp:551149): Gtk-WARNING **: 22:34:48.235: for_size smaller than min-size (18 < 32) while measuring gadget (node entry, owner GtkSpinButton)

(g.gui.gcp:551149): Gtk-WARNING **: 22:34:48.300: for_size smaller than min-size (18 < 32) while measuring gadget (node entry, owner GtkSpinButton)

(g.gui.gcp:551149): Gtk-WARNING **: 22:34:48.351: for_size smaller than min-size (18 < 32) while measuring gadget (node entry, owner GtkSpinButton)

(g.gui.gcp:551149): Gtk-WARNING **: 22:34:48.404: for_size smaller than min-size (18 < 32) while measuring gadget (node entry, owner GtkSpinButton)
Traceback (most recent call last):
  File "/home/mneteler/software/grass78_git/dist.x86_64-pc-linux-gnu/scripts/g.gui.gcp", line 71, in <module>
    main()
  File "/home/mneteler/software/grass78_git/dist.x86_64-pc-linux-gnu/scripts/g.gui.gcp", line 68, in main
    app.MainLoop()
  File "/usr/lib64/python3.7/site-packages/wx/core.py", line 2166, in MainLoop
    rv = wx.PyApp.MainLoop(self)
wx._core.wxAssertionError: C++ assertion "GetEventHandler() == this" failed at ../src/common/wincmn.cpp(477) in ~wxWindowBase(): any pushed event handlers must have been removed

System description (please complete the following information):

• Operating System: Fedora 31
• GRASS GIS version:

g.version -rge
version=7.8.3dev
date=2020
revision=42388e55e
build_date=2020-03-15
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] Support of SIRGAS: Sistema de Referencia Geocentrico para America del Sur 1995

In a fresh 7.8.git, there seems to be this system missing:

SIRGAS: Sistema de Referencia Geocentrico para America del Sur 1995

gdalinfo mdt_50m.tif
Driver: GTiff/GeoTIFF
Files: mdt_50m.tif
       mdt_50m.tif.ovr
       mdt_50m.tif.aux.xml
Size is 13200, 14400
Coordinate System is:
PROJCS["SIRGAS_UTM_Zone_17S",
    GEOGCS["GCS_SIRGAS",
        DATUM["Sistema_de_Referencia_Geocentrico_para_America_del_Sur_1995",
            SPHEROID["GRS_1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            AUTHORITY["EPSG","6170"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-81],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",10000000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (490000.000000000000000,10164000.000000000000000)
Pixel Size = (50.000000000000000,-50.000000000000000)
Metadata:
  AREA_OR_POINT=Point
  TIFFTAG_MAXSAMPLEVALUE=6242
  TIFFTAG_MINSAMPLEVALUE=65514
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  490000.000,10164000.000) ( 81d 5'23.63"W,  1d29' 1.52"N)
Lower Left  (  490000.000, 9444000.000) ( 81d 5'24.77"W,  5d 1'48.61"S)
Upper Right ( 1150000.000,10164000.000) ( 75d10' 0.65"W,  1d28'33.69"N)
Lower Right ( 1150000.000, 9444000.000) ( 75d 8'47.53"W,  5d 0'14.07"S)
Center      (  820000.000, 9804000.000) ( 78d 7'26.72"W,  1d46'15.67"S)
Band 1 Block=13200x1 Type=Int16, ColorInterp=Gray
  Overviews: 6600x7200, 3300x3600, 1650x1800, 825x900, 413x450, 207x225

# create new location from GeoTIFF
grass78 -c mdt_50m.tif ~/grassdata/utm17S_ecuador
Starting GRASS GIS...
...
r.import mdt_50m.tif out=mdt_50m
WARNING: Datum
         <Sistema_de_Referencia_Geocentrico_para_America_del_Sur_1995> not
         recognised by GRASS and no parameters found
WARNING: Datum
         <Sistema_de_Referencia_Geocentrico_para_America_del_Sur_1995> not
         recognised by GRASS and no parameters found
Importing raster map <mdt_50m>...
 100%


g.proj -w
PROJCS["UTM Zone 17, Southern Hemisphere",
    GEOGCS["grs80",
        DATUM["unknown",
            SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-81],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",10000000],
    UNIT["Meter",1]]


g.version -rge
version=7.8.3dev
date=2020
revision=42388e55e
build_date=2020-03-15
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

References:

• https://epsg.io/4170
• https://georepository.com/crs_4975/SIRGAS-1995.html

I am not sure if SIRGAS support could be added in GRASS GIS (and how)?

ctypes failure item 1 in _argtypes_ passes (python 3.7)

Describe the bug

Ctypes failure appears with Python 3.7. Not reproduceable with Python 3.6

Traceback (most recent call last):
  File "/usr/lib/python3.7/ctypes/__init__.py", line 97, in CFUNCTYPE
    return _c_functype_cache[(restype, argtypes, flags)]
KeyError: (<class 'ctypes.c_int'>, (<class 'grass.lib.ctypes_preamble.String'>,), 1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/src/grass/dist.x86_64-pc-linux-gnu/scripts/t.create", line 92, in <module>
    main()
  File "/opt/src/grass/dist.x86_64-pc-linux-gnu/scripts/t.create", line 74, in main
    import grass.temporal as tgis
  File "/opt/src/grass/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/__init__.py", line 3, in <module>
    from .core import *
  File "/opt/src/grass/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/core.py", line 39, in <module>
    from .c_libraries_interface import *
  File "/opt/src/grass/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/c_libraries_interface.py", line 20, in <module>
    import grass.lib.gis as libgis
  File "/opt/src/grass/dist.x86_64-pc-linux-gnu/etc/python/grass/lib/gis.py", line 552, in <module>
    ('checker', CFUNCTYPE(UNCHECKED(c_int), String)),
  File "/usr/lib/python3.7/ctypes/__init__.py", line 99, in CFUNCTYPE
    class CFunctionType(_CFuncPtr):
TypeError: item 1 in _argtypes_ passes a union by value, which is unsupported.

To Reproduce

./bin.x86_64-pc-linux-gnu/grass79 -c /tmp/test
t.create test tit=x desc=y

System description (please complete the following information):

• Operating System: Linux
• GRASS GIS version 7.9
• Python 3.7.6

[Bug] Dead link to GitHub

https://grass.osgeo.org/development/bug-tracking/
links to
https://github.com/OSGeo/grass/issue (404) instead of
https://github.com/OSGeo/grass/issues

Appropriate input/output range for i.atcorr WorldView2 usage

Can anyone speak to the appropriate range/datatype of WorldView2 rasters when using the i.atcorr module?

I.atcorr requires the input raster be converted to at-sensor-radiance first, which I have done according to DigitalGlobe documention. DG suggests all transformations be done in FLOAT32 datatype; however, i.atcorr requires a specified input/output range that is positive.

Now, I could convert from DN's (UINT16) to radiance (FLOAT32) and then re-scale to positive values (?), but I am not sure if this would leave me with the WorldView2 range that i.atcorr is seeking... For example, Sentinel 2 L1C are also encoded as UINT16 with 15 significant bits. However, documentation states that the correct i.atcorr Sentinel range is 1-10000; 10000 being a specified QUANTIFICATION_VALUE by Sentinel.

Is there a WorldView 2 equivalent to this quantification value? Even when using the new images converted to radiance? Is there an alternative range specific to WV2? And either way, what would the appropriate output/rescale value be for using i.atcorr with WV2?

Any insight would be greatly appreciated!

*WV2 is encoded in UINT16 with an 11-bit dynamic range

[Bug] t.register: use band from i.band

i.band + t.register maps=... does not work, the band reference is not read by t.register
Providing text file with ||| works, but it would be more consistent if t.register would first and always check if a band name has been set with i.band.

Update current mapset in Data tab when switching to the tab

Is your feature request related to a problem? Please describe.
I'm using the Data tab in the Layer Manager a lot because it is really great, but when I switch to it, I usually have to press the Update current mapset button to see data I just created.

Describe the solution you'd like
When I switch to Data tab, I would like to see the latest state of the current mapset without clicking the refresh button.

Describe alternatives you've considered
Updating everything sounds like too much processing. It also might be good if it is updated when it is already active, but it gets focus. Clicking somewhere closer to the mapset name or content - like a context menu - would be an interesting alternative as it would apply to all mapsets (but it will require more clicks rather then less).

Additional context
The workflow I'm concerned with right now involves just one mapset.

[Bug] Wrong behaviour of r.external in MS Windows OS

Describe the bug
I've realized that in a ms-windows environment, the module r.external shows an unexpected behavior when linking raster layers with zero values. While in GNU/Linux no matter if you use r.in.gdal, r.import or r.external algorithms to incorporate a raster layer into a mapset, in a windows environment, r.external doesn't preserve the original zero values of the layer.

To Reproduce
Steps to reproduce the behavior:

1. Open GRASS GIS in Windows (location/mapset EPSG:25831)
2. Click on r.import to import the raster layer
   layer.zip
3. Check some stats:

r.univar map=layer_import@PERMANENT
total null and non-null cells: 4260096
total null cells: 4192343
Of the non-null cells:
n: 67753
minimum: 0
maximum: 10
range: 10
mean: 7.80585
mean of absolute values: 7.80585
standard deviation: 4.11968
variance: 16.9718
variation coefficient: 52.7768 %
sum: 528870

4. Click on r.in.gdal to import the raster layer
   layer.zip
5. Check some stats:

r.univar map=layer_gdal@PERMANENT
total null and non-null cells: 4260096
total null cells: 4192343
Of the non-null cells:
n: 67753
minimum: 0
maximum: 10
range: 10
mean: 7.80585
mean of absolute values: 7.80585
standard deviation: 4.11968
variance: 16.9718
variation coefficient: 52.7768 %
sum: 528870

6. Click on r.external to link the raster layer
   layer.zip
7. Check some stats:

r.univar map=layer_external@PERMANENT
total null and non-null cells: 4260096
total null cells: 4206156
Of the non-null cells:
n: 53940
minimum: 1
maximum: 10
range: 9
mean: 9.80478
mean of absolute values: 9.80478
standard deviation: 1.31105
variance: 1.71884
variation coefficient: 13.3715 %
sum: 528870

Note that in r.external, the original minimum value (0) has been converted to 1.

Expected behavior
The linked layer should preserve the original values: 0, 10 and null values instead of transforming 0 into 1.

System description (please complete the following information):

• Operating System: Microsoft Windows 10 Enterprise LTSC, Version 10.0.17763 Build 17763
• GRASS GIS version 7.8.2 (build date 2019-12-11)

Details about further software components

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

v.in.pdal does not compile on Mac

v.in.pdal has never compiled on the Mac for some reason. While I've asked about this briefly in the list, I have not put in a formal bug report because of many other compiling issues. Now that they are being solved, it is time to report on v.in.pdal.

The error reported is below

x86_64-apple-darwin13.4.0-clang -D_FORTIFY_SOURCE=2 -mmacosx-version-min=10.9 -I/Applications/GRASS-7.9.app/Contents/Resources/include -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.14.sdk -I/Applications/GRASS-7.9.app/Contents/Resources/include -I/Users/cmbarton/grass_source/master/grass/dist.x86_64-apple-darwin18.7.0/include -I/Users/cmbarton/grass_source/master/grass/dist.x86_64-apple-darwin18.7.0/include -I/Applications/GRASS-7.9.app/Contents/Resources/include -I/Applications/GRASS-7.9.app/Contents/Resources/include -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isystem /Applications/GRASS-7.9.app/Contents/Resources/include -fdebug-prefix-map=/usr/local/miniconda/conda-bld/pdal_1585081244914/work=/usr/local/src/conda/pdal-2.1.0 -fdebug-prefix-map=/Applications/GRASS-7.9.app/Contents/Resources=/usr/local/src/conda-prefix -std=c++11 -std=c++11 -DPACKAGE=\""grassmods"\" -I/Applications/GRASS-7.9.app/Contents/Resources/include -I/Applications/GRASS-7.9.app/Contents/Resources/include -I/Applications/GRASS-7.9.app/Contents/Resources/include -I/Applications/GRASS-7.9.app/Contents/Resources/include/libxml2 -I/Applications/GRASS-7.9.app/Contents/Resources/include -I/Users/cmbarton/grass_source/master/grass/dist.x86_64-apple-darwin18.7.0/include -I/Users/cmbarton/grass_source/master/grass/dist.x86_64-apple-darwin18.7.0/include -DRELDIR=\"vector/v.in.pdal\" -o OBJ.x86_64-apple-darwin18.7.0/filters.o -c filters.c

• Operating System: Mac OSX 10.14 (but also on earlier and later versions)
• GRASS GIS version 7.8.3dev

date=1 April 2020
revision=e6456c1f0
build_date=2020-04-01
build_platform=x86_64-apple-darwin18.7.0
build_off_t_size=8
libgis_revision=
libgis_date=
proj=6.2.0
gdal=3.0.1
geos=3.7.2dev
sqlite=3.31.1