osgeo / grass Goto Github PK
View Code? Open in Web Editor NEWGRASS GIS - free and open-source geospatial processing engine
Home Page: https://grass.osgeo.org
License: Other
GRASS GIS - free and open-source geospatial processing engine
Home Page: https://grass.osgeo.org
License: Other
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
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.
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):
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:
Expected behavior
GRASS configure phase picks up ZSTD library requirement of -lpthread
System description (please complete the following information):
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; }
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
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):
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):
Additional context
Add any other context about the problem here.
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
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!
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.
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):
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.
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.
r.kappa
lacks:
For a working solution, see https://github.com/OSGeo/grass-addons/blob/master/grass7/raster/r.confusionmatrix/r.confusionmatrix.py
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):
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
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.
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
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:
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):
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.
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!
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.
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
?
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.
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.
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
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 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:
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):
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
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)
Describe the bug
GRASS GIS 7.8.2 fails to launch under Windows 10
To Reproduce
Steps to reproduce the behavior:
...
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):
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?
related to #457
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
System description
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
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:
myvalue
, type INTEGERv.db.select
on vector map or query the polygonExpected 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
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:
I am not sure if SIRGAS support could be added in GRASS GIS (and how)?
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':
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):
r.mapcalc: parse error with eval function and neighborhood modifier
r.mapcalc can't parse statements if they:
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
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.
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
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.
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
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
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.
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:
.gfs file (auto-generated with GDAL 3.0.4):
# 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 ?)
Describe the bug
Can't create new location in Grass 7.8.2 - missing projections. OSGeo4W, Win10
To Reproduce
Expected behavior
List of projections available for choosing
System description (please complete the following information):
grass78 g.version - rge
errors out as database directory, mapset and location are not set correctlyAdditional 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
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
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.
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
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
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:
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
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
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):
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
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):
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.