Re: [GRASS-user] r.threshold not found in repository -- GRASS 7.8.6 ubuntu machine
I think you should be able to download the extension for GRASS 7 from github here: https://github.com/OSGeo/grass-addons/tree/grass7/src/raster/r.threshold/ So this should work: g.extension r.threshold url="https://github.com/OSGeo/grass-addons/tree/grass7/src/raster/r.threshold; And consider upgrading your GRASS installation.;-) On 25/04/2024 20:40, Rengifo Ortega via grass-user wrote: Hei guys tried to load r.threshold from the repository but it was not available best regards Rengifo Ortega [Errno 2] No such file or directory: 'r.threshold': (Thu Apr 25 19:34:27 2024) r.threshold [Errno 2] No such file or directory: 'r.threshold': 'r.threshold' (Thu Apr 25 19:34:27 2024) Command finished (0 sec) (Thu Apr 25 19:35:05 2024) g.extension extension=r.threshold Fetching from GRASS GIS Addons repository (be patient)... svn: E170013: Unable to connect to a repository at URL 'https://github.com/OSGeo/grass- addons/branches/grass7/src/raster/r.threshold' svn: E160013: '/OSGeo/grass- addons/branches/grass7/src/raster/r.threshold' path not found ERROR: GRASS Addons not found (Thu Apr 25 19:35:07 2024) Command finished (2 sec) ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Using RStudio in a GRASS GIS session
Silly question, do you have the 'rgrass' library installed? i.e. can you do `library(rgrass)` at the R command prompt (without rstudio)? On 17/04/2024 21:34, sibylle via grass-user wrote: Dear community To use RStudio in a GRASS GIS session I used the command line GRASS> rstudio & library(rgrass) (see https://grasswiki.osgeo.org/wiki/R_statistics/rgrass) Unfortunately I was not able to solve the error message: - The command "GRASS" is either misspelled or could not be found. - The command "library" is either misspelled or could not be found. Kind regards Sibylle (Wed Apr 17 20:25:17 2024) GRASS> rstudio & Der Befehl "GRASS" ist entweder falsch geschrieben oder konnte nicht gefunden werden. (Wed Apr 17 20:25:17 2024) Command ended with non-zero return code 1 (0 sec) (Wed Apr 17 20:25:29 2024) library(rgrass) Der Befehl "library" ist entweder falsch geschrieben oder konnte nicht gefunden werden. (Wed Apr 17 20:25:29 2024) Command ended with non-zero return code 1 (0 sec) ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] detrending time series maps
end_strds - (trend_strds*map(slope) + map(offset))". Others suggest, to detrend by subtracting the previous value, i.e. that would imply using the temporal algebra with the temporal index, something like "detrended_strds = trend_strds[1] - trend_strds[0]". I haven't tested any of these, just a couple of ideas ;-) However, I do not know how this might interact with seasonality within data, or irregular gaps. hth somehow Vero El vie, 22 dic 2023 a las 5:10, Ivan Marchesini via grass-user (<grass-user@lists.osgeo.org>) escribió: Dear colleagues I would like to the advantage of the t.* modules for detrending a strd. In the strd I have earth observation data irregularly sampled (2 or 3 times per month), in the period November-February, for 7 years. They are not equally spaced (i.e gaps have different duration) A simple t.rast.series analysis (opion=slope,offset) highlights that probably there is a descending trend when considering the maps ordered by id. I would like to fit a proper time depending fitting curve for each pixel and then subtract the function from the real data. any hints on how I can do this task exploiting the GRASS GIS modules or some simple bash/python scripting? thank you Ivan ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?
:42 PM bonushenricus <bonushenricu...@gmail.com>
wrote:
Hi Anna
I too immediately thought it was enough
to compute it for the final step of the
simulation,
but I noticed that the same slope, same
ditches, same rainfall, for two reservoirs
at the same location, same length along a
contour, but different width and depth, at
the final step of the simulation the water
depth was always 30 cm, I went to read the
article
Mitasova, Helena, Chris Thaxton,
Jaroslav Hofierka, Richard McLaughlin,
Amber Moore, e Lubos Mitas. «Path Sampling
Method for Modeling Overland Water Flow,
Sediment Transport, and Short Term Terrain
Evolution in Open Source GIS». In Developments
in Water Science, 55:1479–90.
Elsevier, 2004. https://doi.org/10.1016/S0167-5648(04)80159-X
where I read the Saint-Venant equation.
I am an agricultural technician and
geographer unfortunately ignorant of
hydrological calculations and serious
mathematics, and I understood, looking at
the equation, that the water depth is the
depth of overland flow = rainfall exces -
water flow.
So the final 30 cm should not be
understood as accumulated water, but as
the blade of water that was added at that
precise moment.
Isn't my interpretation right?
No, it should be actual water depth. I
didn't understand the discrepancy you are
describing?
--
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Running canny edge detection on thinned binary image
AFAIK, the Canny algorithm requires large, wide areas of black pixels, adjacent to large wide areas of white pixels in order to find the edge. It compares the change in value over a wide "strip" to determine the edge. It's a bit counter-intuitive, but the algorithm will not work on single pixel width areas. On 24/07/2023 6:28, Venka wrote: Hi All, I have a question about Canny Edge Detection using i.edge 1) I produce a thinned binary image as below r.thin --overwrite input=line_element output=thinned_line_element a) the "line_element" represents valleys that are, at places, few pixel wide b) the output "thinned_line_element" represents valley lines that are a single pixel wide 2) I run the Canny edge detector on "thinned_line_element" as below i.edge --overwrite input=thin_line_element output=edge_map angles_map=angle_map The resultant "edge_map" produces a monotone (no edges) edge map and the "angle_map" outputs the angles correctly 3) Running the Canny edge detector on the un-thinned "line_element" i.edge --overwrite input=line_element@PERMANENT output=edge_map1 angles_map=angle_map1 produces both "edge_map1" and "angles_map1" correctly. Any idea why the Canny edge detector does not produce edge map on thinned image? Kind regards, Venka ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Rscript error when using v.class.mlR
On 17/07/2023 16:56, Jamille Haarloo wrote: Thank you Micha, This was the msg following "C:\Users\haarlooj\Documents> sessionInfo()": 'sessionInfo' is not recognized as an internal or external command, operable program or batch file. What you need to try is: Rscript -e "sessionInfo()" The GRASS module v.class.mlR needs to be able to "find" the Rscript executable in order to run. I looked for the location and found this as location of R: C:\Program Files\R\R-4.3.0\bin\x64 Location for Rstudio: C:\Program Files\RStudio Is it correct that I need to change the paths? What is the best method? Best, Jamille On Sat, Jul 15, 2023 at 9:17 AM Micha Silver <tsvi...@gmail.com> wrote: Hi Jamille On 15/07/2023 2:04, Jamille Haarloo wrote: > Dear all, > > What was the solution to this error? I recently got a similar error > from the same module v.class.mlR. I am using GRASS GIS 8.2.1 on > Windows 10. > The previous post was in reference to MacOS. Can you check on your system that the Rscript executable is available from the GRASS command window? i.e. - start grass (even without the GUI) - go to the command shell - run Rscript -e "sessionInfo()" This will identify if the problem is due to missing PATH in the env variables. > Best, > Jamille > > > Running R now. Following output is R output. > Traceback (most recent call last): > File "C:\Users\haarlooj\AppData\Roaming\GRASS8\addons\scri > pts\v.class.mlR.py <http://v.class.mlR.py>", line 977, in > main() > File "C:\Users\haarlooj\AppData\Roaming\GRASS8\addons\scri > pts\v.class.mlR.py <http://v.class.mlR.py>", line 908, in main > subprocess.check_call( > File "C:\OSGeo4W\apps\Python39\lib\subprocess.py", line > 368, in check_call > retcode = call(*popenargs, **kwargs) > File "C:\OSGeo4W\apps\Python39\lib\subprocess.py", line > 349, in call > with Popen(*popenargs, **kwargs) as p: > File "C:\OSGeo4W\apps\Python39\lib\subprocess.py", line > 951, in __init__ > self._execute_child(args, executable, preexec_fn, > close_fds, > File "C:\OSGeo4W\apps\Python39\lib\subprocess.py", line > 1420, in _execute_child > hp, ht, pid, tid = _winapi.CreateProcess(executable, > args, > FileNotFoundError: [WinError 2] The system cannot find the > file specified > > > On Sun, Feb 20, 2022 at 8:24 AM Nicklas Larsson via grass-user > <grass-user@lists.osgeo.org> wrote: > > Daniel, > > I assume you use the official GRASS app bundle for mac. If you are > not using the final 8.0.0 version, but one of the release > candidates, I'd suggest you download the latest. There are changes > in the startup script in the final version that relate to PATH > issues like this. > > > > Best, > Nicklas > > > > > > > > On Sunday, 20 February 2022, 01:55:28 CET, Daniel Kozar via > grass-user <grass-user@lists.osgeo.org> wrote: > > > > > > Hi Micha, > > Thanks for the reply. I ran the script lines you sent both in the > terminal as well as a GRASS session. Rscript is recognized in the > terminal command but
Re: [GRASS-user] Rscript error when using v.class.mlR
Hi Jamille On 15/07/2023 2:04, Jamille Haarloo wrote: Dear all, What was the solution to this error? I recently got a similar error from the same module v.class.mlR. I am using GRASS GIS 8.2.1 on Windows 10. The previous post was in reference to MacOS. Can you check on your system that the Rscript executable is available from the GRASS command window? i.e. - start grass (even without the GUI) - go to the command shell - run Rscript -e "sessionInfo()" This will identify if the problem is due to missing PATH in the env variables. Best, Jamille Running R now. Following output is R output. Traceback (most recent call last): File "C:\Users\haarlooj\AppData\Roaming\GRASS8\addons\scri pts\v.class.mlR.py <http://v.class.mlR.py>", line 977, in main() File "C:\Users\haarlooj\AppData\Roaming\GRASS8\addons\scri pts\v.class.mlR.py <http://v.class.mlR.py>", line 908, in main subprocess.check_call( File "C:\OSGeo4W\apps\Python39\lib\subprocess.py", line 368, in check_call retcode = call(*popenargs, **kwargs) File "C:\OSGeo4W\apps\Python39\lib\subprocess.py", line 349, in call with Popen(*popenargs, **kwargs) as p: File "C:\OSGeo4W\apps\Python39\lib\subprocess.py", line 951, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File "C:\OSGeo4W\apps\Python39\lib\subprocess.py", line 1420, in _execute_child hp, ht, pid, tid = _winapi.CreateProcess(executable, args, FileNotFoundError: [WinError 2] The system cannot find the file specified On Sun, Feb 20, 2022 at 8:24 AM Nicklas Larsson via grass-user wrote: Daniel, I assume you use the official GRASS app bundle for mac. If you are not using the final 8.0.0 version, but one of the release candidates, I'd suggest you download the latest. There are changes in the startup script in the final version that relate to PATH issues like this. Best, Nicklas On Sunday, 20 February 2022, 01:55:28 CET, Daniel Kozar via grass-user wrote: Hi Micha, Thanks for the reply. I ran the script lines you sent both in the terminal as well as a GRASS session. Rscript is recognized in the terminal command but not in the GRASS 8.0 command. Since GRASS 8.0 did not recognize Rscript I tried making a symbolic link for "Rscript" to the full path: /usr/local/bin/Rscript. This still doesn't recognize the command and I'm unsure how else to work around it. Any Mac aficionados reading this - do you have an idea to resolve this? Thanks Daniel On Sat, Feb 19, 2022 at 1:46 AM Micha Silver wrote: > Hi > > > On 19/02/2022 04:27, Daniel Kozar via grass-user wrote: >> Hi everyone, >> >> When using the extension "v.class.mlR" I get an error [Message 1] (see >> below) that "Rscript" cannot be located. I traced this back to the >> script for "v.class.mlR" and edited line 908 to read the direct path >> to Rscript - '/usr/local/bin/Rscript' rather than 'Rscript' alone. >> However, when I re-open GRASS 8.0 I get an error [Message 2] that the >> extension failed when loading and that the operation isn't permitted. >> I allowed for the application to have administrative rights but it >> still doesn't work. Does anyone know how to work around this or solve >> the issue finding "Rscript"? >> >> I have R running and have installed necessary packages. I'm >> running GRASS on MacOS Monterey. > > > This looks like a Mac problem (which I know nothing about). > > To test, can you run, first from a terminal: > > micha@RMS:~$ Rscript -e "sessionInfo()" > > Now run the same from within a GRASS session: > > (here's what I get) > > micha@RMS:QGIS$ g.version > GRASS 8.1.dev <http://8.1.dev> (2022) > > micha@RMS:QGIS$ Rscript -e "sessionInfo()" > R version 4.1.2 (2021-11-01) > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Debian GNU/Linux 11 (bullseye) > > Matrix products: default > BLAS: /usr/lib/x86_64-linux-gnu/ openblas-pthread/libblas.so.3 > LAPACK: /usr/lib/x86_64-linux-gnu/ openblas-pthread/libopenblasp- r0.3.13.so <http://r0.3.13.so> > > locale: > [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C > [3] LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8 > [5] LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8 > [7] LC_PAPER=en_GB.UTF-8 LC_NAME=C > [9] LC_ADDRESS=C LC_TELEPHONE=C > [11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATI
Re: [GRASS-user] v.in.ascii data error
On 22/05/2023 20:06, Rich Shepard wrote: I've added elevation and a feature name to the standard format v.in.ascii file. Grass reports an import error; the same error occurs without those two added columns. I'm not seeing the error, your fresh eyes will see it. Data file: Do you actually have the text "Data file:" as part of the header? AFAIK, You need, at minimum, "VERTI:" in the header. B 5 45.654023|-122.980241|393|Shop 45.653931|-122.980315|393|Shop 45.653960|-122.979910|393|Shop 45.653856|-122.979831|393|Shop 45.654023|-122.980241|393|Shop Command: v.in.ascii -z in=$HOME/projects/oregon/northside-rock/data/shop.txt out=maintenance_bldg format=standard sep=pipe cat=0 x=1 y=2 z=3 columns='x double precision, y double precision, z integer, label char(4)' --o Results: v.in.ascii -z in=$HOME/projects/oregon/northside-rock/data/shop.txt out=maintenance_bldg format=standard sep=pipe cat=0 x=1 y=2 z=3 columns='x double precision, y double precision, z integer, label char(4)' --o WARNING: Unexpected data in vector header: [B 5] ERROR: Import failed I've not calculated a centroid; intend to use v.centroid to add the point to the bound area. Help appreciated, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS, ENVI 5.6, IDL 8.8 Archaeological Site Geology and GIS
On 13/05/2023 23:24, Mustafa Umut Sarac
wrote:
Hello Micha and Everyone,
question is for ENVI users,
In that case, you'd
best post your question to an ENVI forum.
Best regards, Micha
Can you help me ?
Thanks,
Umut
On Sat, May 13, 2023 at
10:36 PM Micha Silver <tsvi...@gmail.com>
wrote:
Your question is very broad, so it's
difficult to give any specific answers.
You might start with The GRASS Book: https://grassbook.org/
to get a feel for working with GRASS GIS.
Then there is this Wiki page: https://grasswiki.osgeo.org/wiki/LANDSAT
dedicated to processing Landsat in GRASS.
Once you get started, if you encounter
any specific questions, post back what you have
tried, what you got and what you expected. Then I'm
sure someone will be able to offer help.
On 13/05/2023 21:47, Mustafa Umut Sarac wrote:
Hello there,
Is there a step by step tutorial , pdf
or book which will teach an archaeologist how to
use the latest Landsat satellite multispectral
images to make a geology map of an
archaeological site? And I want to know how GRASS
works for archaeologists and if GRASS supports me
, I need a book , pdf or tutorial to teach me step
by step.
Thank you,
Mustafa Umut Sarac
Ankara - DTCF - Archaeology
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS, ENVI 5.6, IDL 8.8 Archaeological Site Geology and GIS
Your question is very broad, so it's difficult to give any specific answers. You might start with The GRASS Book: https://grassbook.org/ to get a feel for working with GRASS GIS. Then there is this Wiki page: https://grasswiki.osgeo.org/wiki/LANDSAT dedicated to processing Landsat in GRASS. Once you get started, if you encounter any specific questions, post back what you have tried, what you got and what you expected. Then I'm sure someone will be able to offer help. On 13/05/2023 21:47, Mustafa Umut Sarac wrote: Hello there, Is there a step by step tutorial , pdf or book which will teach an archaeologist how to use the latest Landsat satellite multispectral images to make a geology map of an archaeological site? And I want to know how GRASS works for archaeologists and if GRASS supports me , I need a book , pdf or tutorial to teach me step by step. Thank you, Mustafa Umut Sarac Ankara - DTCF - Archaeology ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.clip error I don't understand
On 09/05/2023 23:53, Rich Shepard
wrote:
I'm
trying to clip the vector contour map with its very large areal
coverage to my project's analysis area (image attached). The
v.clip module
has three parameters: input map, clip map, output map. I wonder if
the
structure of my analysis area is the source of the error(s).
Analysis area used for input with v.in.ascii (output name
clipbox):
L 5 1
2306066.00 224201.00
2307121.58 224201.00
2307121.58 223164.00
2306066.00 223164.00
2306066.00 224201.00
1 1
Your v.in.ascii command has create a *line* feature, (the L on
the first line) not an area. Even though the lines connect it's
not a boundary, and there's no centroid, which is required for a
closed boundary to be considered a polygon area. Have another
look at the v.in.ascii man page, and refer to Example 1 a). You'll
need to define the list of corners as B (not L) and also add
another few lines for the centroid.
The
command and its results:v.clip in=base_contours clip=clipbox
out=dm_baseline
Default clipping with dissolved clip map.
WARNING: No 'column' option specified. Dissolving based on
category values
from layer <1>.
Extracting features...
100%
Building topology for vector map
...
Registering primitives...
Writing attributes...
Removing duplicate centroids...
Building topology for vector map
...
Registering primitives...
Copying vector features from
...
100%
Copying vector features from ...
ERROR: No area features found in vector map
.
Verify 'btype' parameter.
ERROR: Clipping steps failed. Check above error messages and see
following
details:
Module run `v.overlay ainput=base_contours
binput=temp_13361
operator=and output=dm_baseline olayer=0,1,0` ended with an
error.
The subprocess ended with a non-zero return code: 1. See
errors
above the traceback or in the error output
Perhaps the error is the result of my not using the -d option
because I'm
not sure what would be dissolved with it: the contours external to
the
clipbox? Which is what I want.
Confused,
Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.gdal: geoTIFF file no data?
On 05/05/2023 20:44, Rich Shepard wrote: I have a 242M geotiff file, 45122f8.tif, which r.in.gdal imported as three files: NRS_baseline_dem.1, NRS_baseline_dem.2 and NRS_baseline_dem.3. Each has the same display (geotiff.png attached). This is most probably an RGB color image that GRASS has split into three color bands. r.info shows the same data for each of the three created files, but no categories, but with 688235940 cells (each 1.5' resolution ). That output file is also attached. I don't see from the output that each band has the same data. You'd have to run r.univar on each band to get the statistics (mean, etc) What might I have done incorrectly that the results do not cover the entire 1:24000 quadrangle map? Can you view the original tif in a graphics program (or QGIS) to see what's there? Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Vector map appears empty of detail data
On 05/05/2023 19:07, Rich Shepard
wrote:
I
need help: there's only one digital topographic data set that
includes my
client's operational area. That data set imports into grass with
v.in.ogr
and has all the expected files in the vector/ subdirectory.
When I view it with d.vect map=usgs_dem display=shape I see a wide
screen
filled with solid blue blocks. Zooming in I see no details. I
assume this
one file covers a very wide range of 7.5" topograhic quads and I
see no
identifying information in them.
The data subdirectory is uploaded to
and I
ask for help in learning if there is information in it that allows
me to get
to the one map I need and use those data for hydrologic analyses.
Can you send the original file before you imported into GRASS?
Thanks
in advance,
Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re-projection fails
On 01/05/2023 19:52, Rich Shepard wrote: I've started a new thread on this issue: it's more specific. The script that imports the LiDAR topographic map works: GRASS Dixie_Mountain_2010_LiDAR/PERMANENT:~ > r.in.gdal in=$HOME/projects/oregon/northside-rock/data/LDQ-45122F8/2010-USACE-Columbia-River/Bare_Earth/be45122f8/hdr.adf out=2010_topo mem=2000 --o First comment: I think you should not have GRASS map names starting with a digit. Can you change the above to output=topo_2010 ?? Importing raster map <2010_topo>... 100% GRASS Dixie_Mountain_2010_LiDAR/PERMANENT:~ > g.list type=raster 2010_topo The imported 2010_topo exists in the designated location and mapset. But, the script to re-project this map fails. I think it has something to do with how I'm mis-using Micha's suggestion of assigning the re-projected output to an environmental variable, NSR. grass /data1/grassdata/Oregon/PERMANENT g.mapset -c NSR_2010_DEM GRASS Oregon/NSR_2010_DEM:~ > NSR=`r.proj -g loc=Dixie_Mountain_2010_LiDAR map=PERMANENT in=2010_topo method=lanczos mem=2000 --o` Input map <2010_topo@PERMANENT> in location : Selected PROJ pipeline: +proj=pipeline +step +inv +proj=utm +zone=10 +ellps=GRS80 +step +proj=lcc +lat_0=43.7 +lon_0=-120.5 +lat_1=46 +lat_2=44.3 +x_0=250 +y_0=0 +ellps=GRS80 GRASS Oregon/NSR_2010_DEM:~ > g.list type=rast GRASS Oregon/NSR_2010_DEM:~ > The first run of r.proj (with the -g flag) only gives you the target region settings. You now need to set the region with those settings, and then run r.proj again (without -g) do actually do the work. g.region -ap $NSR r.proj loc=Dixie_Mountain_2010_LiDAR map=PERMANENT in=2010_topo method=lanczos mem=2000 output=topo_2010 --o There's no output and I'm not seeing why that is. TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Region doesn't match EPSG
On 30/04/2023 23:03, Rich Shepard
wrote:
On
Sun, 30 Apr 2023, Micha Silver wrote:
g.region -ap $new_region
Micha,
(Reformatted to fit the scrsen)
It's still not working:
GRASS NorthsideRock/PERMANENT:~ > NSR=`r.proj -g
loc=Dixie_Mountain_2010_LiDAR map=Northside_rock_2010_topo
in=2010_DEM
out=2010_topo method=lanczos_f mem=2000 --o`
GRASS NorthsideRock/PERMANENT:~ > g.region -ap NSR
I guess you're missing the '$' to recognize NSR as a shell
variable.
ERROR:
Region not found
GRASS NorthsideRock/PERMANENT:~ > g.list type=raster
GRASS NorthsideRock/PERMANENT:~ >
Regards,
Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Region doesn't match EPSG
On 30/04/2023 21:47, Rich Shepard wrote: When I invoke grass using a location and PERMANENT map set, and try to re-project a raster file to it, grass rejects the action because the map to be transferred has greater boundaries than the target mapset. The location was created with EPSG:6884 name: NAD83(CORS96) / Oregon North ellps: grs80 proj: lcc lat_0: 43.7 lon_0: -120.5 lat_1: 46 lat_2: 44.3 x_0: 250 y_0: 0 no_defs: defined Starting grass in that location and the PERMANENT mapset I find this region: g.region -p projection: 99 (NAD83(CORS96) / Oregon North) zone: 0 datum: ** unknown (default: WGS84) ** ellipsoid: grs80 north: 1 south: 0 west: 0 east: 1 nsres: 1 ewres: 1 rows: 1 cols: 1 cells: 1 What you do is run the r.proj module with the '-g' flag. That gives you the region settings in the current mapset that would match the region of the input raster from the other mapset. Then you use those setting as input to g.region. So: new_region=`r.proj -g location= mapset= input=` g.region -ap $new_region What did I do incorrectly? And, how to I fix it so I can reproject the map to the project's region? TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Specify window size when grass invoked
On 28/04/2023 21:23, Rich Shepard wrote: I'm running grass-8.x on a laptop with a 14" screen. Starting grass within a virtual terminal opens a GUI window that exceeds the monitor's width and height. Is there a place where I can define the window's geometry globally? I don't see a config file, such as ~/.grassrc. On my system it's ~/.grass8/wx.json, a json formatted config file. I think you should try to resize with the "handles" on the window corners. Then using the menu "Settings->Preferences" check the option "Save current window layout as default", and click "Save". That should keep the window size for next time. TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Shell scripts to define GISDATABASE, location, and mapset; import data
Hi Rich: On 28/04/2023 0:56, Rich Shepard wrote: I write shell scripts to run modules for analyses, but have always used the GUI to define locations and/or mapsets before importing data even with starting grass with the -c option. What I want to do now when importing project data is to have a script that defines the location and mapset then imports the data. I've read the startup program manual page <https://grass.osgeo.org/grass82/manuals/grass.html> several times today without seeing how to specify the all three parameters to define a location and mapset and immediately follow that with a data import command; is --exec really necessary? Here's your script with corrections #!/usr/bin/bash # set grass location for quarry boundary map grass -c $HOME/projects/oregon/northside-rock/data/data/property/Tax_Lots.shp /data1/grassdata/quarry-name/permitted-boundary # Import quarry boundary map # Comments: # The 'output' parameter should be just a grass vector name, NOT a path. # Best to use underscore in map names, NOT '-' # And '--overwrite' == '--o' v.import input=$HOME/projects/oregon/northside-rock/data/property/Tax_Lots.shp output=permitted_boundary --overwrite One additional point that might make this easier: GRASS locations are typically defined by a coordinate reference system. If you work with data in only a few CRS, then you can consider to create a collections of locations, one for each CRS that you use. Then when you start a new project, open grass in the location that contains data in the CRS of the project, and create a new *mapset* just for that project. Then import into that mapset. This approach has two advantages: (1) - You don't need to be creating new locations all the time with possibly redundant CRS definitions. And (2) - you most likely have some data that can be shared between projects. With one overall location defined by i.e. "NAD83(HARN) Oregon", then you can store in the PERMANENT mapset any dataset that might be shared among projects. And each mapset will be specific to one project. Creating a new project specific mapset, within an existing location is done by: # Start GRASS in existing location grass /data/grassdata/some_location/PERMANENT # create new mapset g.mapset -c # Now import whatever data you need v.import input=... Best, Micha An example file is attached. Please correct my format and I'll use this as a template for all data imports. TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ogr where-clause not working
On 23/01/2023 19:34,
gisfi...@t-online.de wrote:
Hi Micha,
sorry, I did not tell the whole truth again. The boundaries are clean, but the cents are not complete. Strictly speaking, it is the goal of the whole process to find cases where the digitizing operator forgot to
This is getting a bit murky ;-)
If the goal is to find areas in the digitized boundaries where
the centroid was missed, then how about a workflow like this:
Import just the boundaries.
Run v.centroid to convert them all to areas.
Import just the points (centroids, with some missing)
Run an intersection between the polygons and points.
Delete all polygons that intersect a point.
What's left are the polygons that were without a centroid.
HTH,
Micha
place centroids. Thus, I need to import bounds and cents. As far as I can see (in my old workflow), areas WITH centroids were placed on layer 2 while areas WITHOUT centroids were placed on layer 1 (at least this is what QGIS shows when the imported GRASS map was loaded). I will try to add category values to those somehow "empty" areas using v.category option=add, and I hope that I can adress them after this in my script and export them (for usage as error markers) using v.out.ogr. I remember that I tried to add centroids using v.centroid in a similar case, but I could not get it to work. So I used v.category. Not sure if I did everything correct.
Best regards,
Uwe
-Ursprüngliche Nachricht-
Von: Micha Silver
Gesendet: Montag, 23. Januar 2023 16:29
An: gisfi...@t-online.de; grass-user@lists.osgeo.org
Betreff: Re: AW: [GRASS-user] v.in.ogr where-clause not working
On 23/01/2023 17:21, gisfi...@t-online.de wrote:
Hello Micha and list,
thank you for the answer.
The double quotes did not work. But when I tried, it suddenly became clear what could be the problem. You could not see that in my example. I use a directory as input, containing one shapefile with boundaries and one with centroids (goal: create area vector map). Only the boundaries have the attribute LENGTH. So it cannot be found in the centroids, and that is the reason for that message.
I wonder why it worked in the old GRASS/PYTHON? There was a message that the 'where' clause is only applied to the first input layer which is the boundary shapefile named 'arc.shp' (starts with a, so probably it is the first). This must have changed in GRASS78.
I used this and was happy with it because I need to import those shapes and create a vector map out of them. Now, I think I will have to import them in two steps (only one with 'where') and put them together in GRASS. Is 'v.patch' followed by 'v.build' a good way or is there a better straightforward way?
If the boundary shapefile is topologically clean (no crossing lines, and all boundaries are closed) then no need to import the centroids. Just get the boundary lines, then run v.centroid with option=add. It will take care of adding centroids to all closed boundaries, thus creating areas. This would be after v.clean in any case.
Thank you and best regards,
Uwe
-Ursprüngliche Nachricht-
Von: Micha Silver
Gesendet: Sonntag, 22. Januar 2023 21:40
An: gisfi...@t-online.de; grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] v.in.ogr where-clause not working
Hi
On 22/01/2023 14:42, gisfi...@t-online.de wrote:
Hello list,
I have problems with v.in.ogr in a python script; I use:
/grass.run_command('v.in.ogr',input='d:/my_input',output='my_output',
t ype='boundary,centroid',where='LENGTH
!= 1',snap=0.01,min_area=0.01,flags="o",overwrite=True)/
This has been working fine for years in GRASS 7.0.3 with Python 2.
Now, I tried in GRASS 7.8 on Python 3 and I get the following error:
ERROR 1: "LENGTH" not recognised as an available field.
FEHLER: Error setting attribute filter 'LENGTH != 1'
The field called LENGTH is present and there is no typing error. What
I absolutely not understand is that the command is working fine
inside GRASS itself! Just the Python script does not.
Can you try to create the where clause with double quotes before calling grass.run_command? Like so:
expr = '"LENGTH != 1"'
grass.run_command('v.in.ogr', input='...', output='...', where=expr,
type='...', .)
„LENGTH“ is not a Python reserved keyword, and no SQL reserved
keyword. I also tried it with another name for that column. That also
did not work.
Any ideas what could be wrong? Thank you very much.
Uwe
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
--
Micha Silver
Ben Gurion
Re: [GRASS-user] v.in.ogr where-clause not working
On 23/01/2023 17:21, gisfi...@t-online.de wrote:
Hello Micha and list,
thank you for the answer.
The double quotes did not work. But when I tried, it suddenly became clear what
could be the problem. You could not see that in my example. I use a directory
as input, containing one shapefile with boundaries and one with centroids
(goal: create area vector map). Only the boundaries have the attribute LENGTH.
So it cannot be found in the centroids, and that is the reason for that message.
I wonder why it worked in the old GRASS/PYTHON? There was a message that the
'where' clause is only applied to the first input layer which is the boundary
shapefile named 'arc.shp' (starts with a, so probably it is the first). This
must have changed in GRASS78.
I used this and was happy with it because I need to import those shapes and
create a vector map out of them. Now, I think I will have to import them in two
steps (only one with 'where') and put them together in GRASS. Is 'v.patch'
followed by 'v.build' a good way or is there a better straightforward way?
If the boundary shapefile is topologically clean (no crossing lines, and
all boundaries are closed) then no need to import the centroids. Just
get the boundary lines, then run v.centroid with option=add. It will
take care of adding centroids to all closed boundaries, thus creating
areas. This would be after v.clean in any case.
Thank you and best regards,
Uwe
-Ursprüngliche Nachricht-
Von: Micha Silver
Gesendet: Sonntag, 22. Januar 2023 21:40
An: gisfi...@t-online.de; grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] v.in.ogr where-clause not working
Hi
On 22/01/2023 14:42, gisfi...@t-online.de wrote:
Hello list,
I have problems with v.in.ogr in a python script; I use:
/grass.run_command('v.in.ogr',input='d:/my_input',output='my_output',t
ype='boundary,centroid',where='LENGTH
!= 1',snap=0.01,min_area=0.01,flags="o",overwrite=True)/
This has been working fine for years in GRASS 7.0.3 with Python 2.
Now, I tried in GRASS 7.8 on Python 3 and I get the following error:
ERROR 1: "LENGTH" not recognised as an available field.
FEHLER: Error setting attribute filter 'LENGTH != 1'
The field called LENGTH is present and there is no typing error. What
I absolutely not understand is that the command is working fine inside
GRASS itself! Just the Python script does not.
Can you try to create the where clause with double quotes before calling
grass.run_command? Like so:
expr = '"LENGTH != 1"'
grass.run_command('v.in.ogr', input='...', output='...', where=expr,
type='...', .)
„LENGTH“ is not a Python reserved keyword, and no SQL reserved
keyword. I also tried it with another name for that column. That also
did not work.
Any ideas what could be wrong? Thank you very much.
Uwe
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ogr where-clause not working
Hi
On 22/01/2023 14:42, gisfi...@t-online.de wrote:
Hello list,
I have problems with v.in.ogr in a python script; I use:
/grass.run_command('v.in.ogr',input='d:/my_input',output='my_output',type='boundary,centroid',where='LENGTH
!= 1',snap=0.01,min_area=0.01,flags="o",overwrite=True)/
This has been working fine for years in GRASS 7.0.3 with Python 2.
Now, I tried in GRASS 7.8 on Python 3 and I get the following error:
ERROR 1: "LENGTH" not recognised as an available field.
FEHLER: Error setting attribute filter 'LENGTH != 1'
The field called LENGTH is present and there is no typing error. What
I absolutely not understand is that the command is working fine inside
GRASS itself! Just the Python script does not.
Can you try to create the where clause with double quotes before calling
grass.run_command? Like so:
expr = '"LENGTH != 1"'
grass.run_command('v.in.ogr', input='...', output='...', where=expr,
type='...', .)
„LENGTH“ is not a Python reserved keyword, and no SQL reserved
keyword. I also tried it with another name for that column. That also
did not work.
Any ideas what could be wrong? Thank you very much.
Uwe
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] single window gui crash with Ubuntu 22.04 LTS
I checked on my Debian 11 with KDE desktop. Recompiled 8.2 from git. No problem here. On 02/01/2023 16:53, Frank David wrote: Hello, I've installed GRASS 8.2.0 in a fresh KDE UBUNTU 22.04 and the GUI crash if the single window gui is enabled. As soon as I turn off this choice in .grass8/wx.json file the GUI works. console error message : /usr/lib/grass82/scripts/g.extension:167: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives from distutils.dir_util import copy_treeTraceback (most recent call last): File "/usr/lib/python3/dist-packages/wx/core.py", line 3282, in lambda event: event.callable(*event.args, **event.kw) ) File "/usr/lib/grass82/gui/wxpython/wxgui.py", line 95, in show_main_guimainframe = GMFrame(parent=None, id=wx.ID_ANY, workspace=self.workspaceFile) File "/usr/lib/grass82/gui/wxpython/main_window/frame.py", line 164, in __init__self.BuildPanes() File "/usr/lib/grass82/gui/wxpython/main_window/frame.py", line 645, in BuildPanesself._auimgr.AddPane( File "/usr/lib/python3/dist-packages/wx/lib/agw/aui/framemanager.py", line 4711, in AddPanereturn self.AddPane4(window, arg1, target) File "/usr/lib/python3/dist-packages/wx/lib/agw/aui/framemanager.py", line 4879, in AddPane4self.UpdateNotebook() File "/usr/lib/python3/dist-packages/wx/lib/agw/aui/framemanager.py", line 6653, in UpdateNotebooknotebook.AddPage(pane.window, title, True, pane.icon) File "/usr/lib/python3/dist-packages/wx/lib/agw/aui/auibook.py", line 3575, in AddPagereturn self.InsertPage(self.GetPageCount(), page, caption, select, bitmap, disabled_bitmap, control, tooltip) File "/usr/lib/python3/dist-packages/wx/lib/agw/aui/auibook.py", line 3653, in InsertPageself.SetSelectionToWindow(page) File "/usr/lib/python3/dist-packages/wx/lib/agw/aui/auibook.py", line 4410, in SetSelectionToWindowself.SetSelection(idx) File "/usr/lib/python3/dist-packages/wx/lib/agw/aui/auibook.py", line 4357, in SetSelectionctrl.MakeTabVisible(ctrl_idx, ctrl) File "/usr/lib/python3/dist-packages/wx/lib/agw/aui/auibook.py", line 1843, in MakeTabVisibleif not self.IsTabVisible(tabPage, self.GetTabOffset(), dc, win): File "/usr/lib/python3/dist-packages/wx/lib/agw/aui/auibook.py", line 1732, in IsTabVisibleself.Render(dc, wnd) File "/usr/lib/python3/dist-packages/wx/lib/agw/aui/auibook.py", line 1687, in Renderpage.rect, tab_button.rect, x_extent = self._art.DrawTab(dc, wnd, page, rect, tab_button.cur_state) File "/usr/lib/python3/dist-packages/wx/lib/agw/aui/tabart.py", line 475, in DrawTabr.SetHeight(r.GetHeight()/2)TypeError: Rect.SetHeight(): argument 1 has unexpected type 'float' Is there a way to solve this ? Thank you for the trick. Regards, Frank _______ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Clip a raster using a polygon boundary with r.mask
Hi You need a few more steps. Like many processes in GRASS, things look complicated at the beginning. But that's because you have full control of what you're doing. The r.mask module is used to block out certain regions of a raster. You set the mask to an existing map (either vector or raster). Then you have to create the new, masked raster. So in this case: # As always in GRASS set the computational region g.region -ap rast=big_raster # Create the mask r.mask vector=small_vector # Now create the masked raster r.mapcalc "masked_raster = big_raster" However, you mentioned "clipo a raster" in your question. So the above isn't enough. In order to actually clip to the bounds of the small_vector, you also must reset the computational region to the extent of the vector, So: # As always in GRASS set the computational region g.region -ap rast=big_raster # to make sure the resolution matches the original raster # But now reset the region to the vector g.region -ap vect=small_vector # Create the mask r.mask vector=small_vector # Now create the masked and clipped raster r.mapcalc "clipped_raster = big_raster" If you examine the two rasters created above (i.e. r.info... ) you'll see the difference HTH On 13/07/2022 17:35, Asim via grass-user wrote: Hello! I've recently started using GRASS and finding it very cool. The only other GIS software I'm familiar with is QGIS. Today's newbie question is how to clip a raster using a vector having polygon geometries? Judging by the docs, r.mask should be used with "vector=..." parameter. The command "r.mask raster=big_raster vector=smaller_vector" was successful, mask was created. However, when "big_raster" was added to the map layers in GUI, it was rendered in its entirety, without getting clipped. An operation such as r.to.vect on big_raster also resulted in the entire raster being used. What am I missing? Are there examples illustrating the use of "vector=" parameter in r.mask? Asim ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How can I locate points on a river?
On 6/21/22 13:32, Thomas Adams wrote:
Hi Micha!
Thank you for the suggestion — yes, I think so; I just
started looking at v.segment… the capability of GRASS
continues to amaze me! Your help is much appreciated!
Me too! Now there is the cloud based actinia to run GRASS modules
"close to the data".
BTW, on a separate note… did you get my email some time
ago about revising the "Flood Forecasting: a global
perspective" book? Are you and your colleague interested in
making any additions or revisions to your book chapter for
the 2nd edition? Others reading this, who may be interested,
please contact me!
Yes, I did. The lead author is employed privately now, so I doubt
he's interested. I contacted the third author, and did not get a
very enthusiastic response. Maybe I'll reach out to the lead
author anyway...
Thank you again!
Best wishes,
Tom
On Mon, Jun 20, 2022 at 3:52
PM Micha Silver <tsvi...@gmail.com>
wrote:
Hi Tom:
Will v.segment or v.lrs.segment help?
https://grass.osgeo.org/grass82/manuals/v.segment.html
https://grass.osgeo.org/grass82/manuals/v.lrs.segment.html
You'll need a start point, and a text file with the
distances (along the line) for all additional river
miles.
Cheers, Micha
On 20/06/2022 20:07, Thomas Adams wrote:
Hi all,
I'm trying to identify specific points on the
centerline of a river channel by "river mile" , that
is, points along a path at specified distances from
a starting point — not at regular intervals. Any
suggestions how I might go about this?
I'm using GRASS 8.x
Much appreciated…
Tom
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
--
Thomas E Adams, III
207 Chowning Place
Blacksburg, VA 24060
tea...@gmail.com
(personal)
t...@terrapredictions.org
(work)
1 (513) 739-9512 (cell)
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
https://orcid.org/-0002-1128-1325
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How can I locate points on a river?
Hi Tom:
Will
v.segment or v.lrs.segment help?
https://grass.osgeo.org/grass82/manuals/v.segment.html
https://grass.osgeo.org/grass82/manuals/v.lrs.segment.html
You'll need a start point, and a text file with the distances
(along the line) for all additional river miles.
Cheers, Micha
On 20/06/2022 20:07, Thomas Adams
wrote:
Hi all,
I'm trying to identify specific points on the centerline of
a river channel by "river mile" , that is, points along a path
at specified distances from a starting point — not at
regular intervals. Any suggestions how I might go about this?
I'm using GRASS 8.x
Much appreciated…
Tom
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Unable to export vector data after upgrading to GRASS 8
If you can retrace your steps from scratch, and reproduce the same error, it would be helpful to file a bug report. Here's a similar issue: https://github.com/OSGeo/grass/issues/2187 If you have a github account, would you add details of your setup, the procedure and the error result there? Regards, Micha On 04/04/2022 15:08, Amit Ghosh wrote: It shows: v.info MDG_UNSALB_admin3_selectionSN5@PERMANENT ++ | Name: MDG_UNSALB_admin3_selectionSN5 | | Mapset: PERMANENT | | Location: southern_africa_grass | | Database: /run/media/amit/InternalHD/FAO/country | | Title: | | Map scale: 1:1 | | Name of creator: amit | | Organization: | | Source date: Tue Mar 22 17:47:24 2022 | | Timestamp (first layer): none | || | Map format: native | || | Type of map: vector (level: 2) | | | | Number of points: 0 Number of centroids: 7 | | Number of lines: 0 Number of boundaries: 27 | | Number of areas: 7 Number of islands: 2 | | | | Map is 3D: No | | Number of dblinks: 1 | | | | Projection: Africa_Albers_Equal_Area_Conic | | | | N: -2374864.5344628 S: -2811333.16032851 | | E: 2422280.61532197 W: 2266547.34604055 | | | | Digitization threshold: 0 | | Comment: | | | ++ On Mon, 4 Apr 2022 at 17:20, Micha Silver <tsvi...@gmail.com> wrote: On 04/04/2022 14:29, Amit Ghosh wrote: Dear Mr. Micha, Yes, it is EPSG: 102022, I used the proj4 string to create the location. Many thanks for the solution. It worked. However, the v.out.ogr module exports the file without the CRS. What does v.info MDG_UNSALB_admin3_selectionSN5 show ?? Projection information updated (Mon Apr 4 16:44:33 2022) Command finished
Re: [GRASS-user] Unable to export vector data after upgrading to GRASS 8
On 04/04/2022 14:29, Amit Ghosh wrote: Dear Mr. Micha, Yes, it is EPSG: 102022, I used the proj4 string to create the location. Many thanks for the solution. It worked. However, the v.out.ogr module exports the file without the CRS. What does v.info MDG_UNSALB_admin3_selectionSN5 show ?? Projection information updated (Mon Apr 4 16:44:33 2022) Command finished (0 sec) (Mon Apr 4 16:44:45 2022) g.proj -p -PROJ_INFO- name : Africa_Albers_Equal_Area_Conic datum : wgs84 ellps : wgs84 proj : aea lat_0 : 0 lon_0 : 25 lat_1 : 20 lat_2 : -23 x_0 : 0 y_0 : 0 no_defs : defined -PROJ_SRID- SRID : EPSG:102022 -PROJ_UNITS unit : meter units : meters meters : 1 v.out.ogr input=MDG_UNSALB_admin3_selectionSN5@PERMANENT output=/home/amit/Documents/mdg_unsalb_east_mdg.gpkg format=GPKG proj_create: crs not found Exporting 7 areas (may take some time)... v.out.ogr complete. 7 features (Polygon type) written to (GPKG format). (Mon Apr 4 16:45:39 2022) Command finished (0 sec) Kind regards, Amit On Mon, 4 Apr 2022 at 16:33, Micha Silver <tsvi...@gmail.com> wrote: Hello: On 04/04/2022 13:38, Amit Ghosh wrote: > Hi, > I tried to export a vector file to use it in another application. The > module returns an error message that says "Unable to create OGR > spatial reference". The detailed output is here: > > v.out.ogr input=MDG_UNSALB_admin3_selectionSN5@PERMANENT > output=/home/amit/Documents/mdg_aoi2_.gpkg > ERROR 10: Pointer 'hSRS' is NULL in 'OSRImportFromWkt'. > ERROR: Unable to create OGR spatial reference > > > Projection info > > g.proj -p > -PROJ_INFO- > I would guess that this is the problem: > name : unknown > datum : wgs84 > ellps : wgs84 > proj : aea > lat_0 : 0 > lon_0 : 25 > lat_1 : 20 > lat_2 : -23 > x_0 : 0 > y_0 : 0 > no_defs : defined > towgs84 : 0.000,0.000,0.000 > -PROJ_UNITS > unit : meter > units : meters > meters : 1 > > > I cannot figure out where I am wrong. Can you suggest an alternative? How did you initially create the GRASS Location? Is the albers equal area projection described by a standard EPSG code? It appears to be this one: https://epsg.io/102022 **IF** that's the correct projection, then you should be able to do: echo "PROJCS["Africa_Albers_Equal_Area_Conic",GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Albers_Conic_Equal_Area"],PARAMETER["False_Easting",0],PARAMETER["False_Northing",0],PARAMETER["longitude_of_center",25],PARAMETER["Standard_Parallel_1",20],PARAMETER["Standard_Parallel_2",-23],PARAMETER["latitude_of_center",0],UNI
Re: [GRASS-user] Unable to export vector data after upgrading to GRASS 8
Hello: On 04/04/2022 13:38, Amit Ghosh wrote: Hi, I tried to export a vector file to use it in another application. The module returns an error message that says "Unable to create OGR spatial reference". The detailed output is here: v.out.ogr input=MDG_UNSALB_admin3_selectionSN5@PERMANENT output=/home/amit/Documents/mdg_aoi2_.gpkg ERROR 10: Pointer 'hSRS' is NULL in 'OSRImportFromWkt'. ERROR: Unable to create OGR spatial reference Projection info g.proj -p -PROJ_INFO- I would guess that this is the problem: name : unknown datum : wgs84 ellps : wgs84 proj : aea lat_0 : 0 lon_0 : 25 lat_1 : 20 lat_2 : -23 x_0 : 0 y_0 : 0 no_defs : defined towgs84 : 0.000,0.000,0.000 -PROJ_UNITS unit : meter units : meters meters : 1 I cannot figure out where I am wrong. Can you suggest an alternative? How did you initially create the GRASS Location? Is the albers equal area projection described by a standard EPSG code? It appears to be this one: https://epsg.io/102022 **IF** that's the correct projection, then you should be able to do: echo "PROJCS["Africa_Albers_Equal_Area_Conic",GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Albers_Conic_Equal_Area"],PARAMETER["False_Easting",0],PARAMETER["False_Northing",0],PARAMETER["longitude_of_center",25],PARAMETER["Standard_Parallel_1",20],PARAMETER["Standard_Parallel_2",-23],PARAMETER["latitude_of_center",0],UNIT["Meter",1],AUTHORITY["EPSG","102022"]]" | g.proj -c wkt=- That long WKT string will reset the projection definition of the Location, then you should be able to export OK. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Need support with v.neighborhoodmatrix addon in GRASS
On 23/02/2022 22:03, Mohajane Meriame wrote: Thank you very much for your support Moritz Lennert, I successfully added *v.neighborhoodmatrix *addon in GRASS 8.0 manually , but the plugin is not appearing in the list of extensions in GRASS software. Regards. Meriame Seems to be working here: micha@RMS:GIS$ g.version GRASS 8.1.dev (2022) micha@RMS:GIS$ g.extension v.neighborhoodmatrix Fetching from GRASS GIS Addons repository (be patient)... Compiling... Installing... Updating extensions metadata file... Updating extension modules metadata file... Installation of successfully finished micha@RMS:GIS$ v.neighborhoodmatrix help Exports the neighborhood matrix of polygons in a vector map Usage: v.neighborhoodmatrix [-b] input=name [player=value] [idcolumn=name] [output=name] [separator=character] [--overwrite] [--help] [--verbose] [--quiet] [--ui] Flags: -b create bidirectional matrix (same neighborhood relation repeated twice) Le mer. 23 févr. 2022 à 18:58, Moritz Lennert a écrit : Hi Mohajane, Le 23 février 2022 16:44:21 GMT+01:00, Mohajane Meriame a écrit : >I am new to GRASS software. >I successfully added v.neighborhoodmatrix addon in GRASS 8.0 manually , but >I couldn't use it. Could you explain what you mean by that ? What did you do and what exactly went wrong? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Rscript error when using v.class.mlR
Hi On 19/02/2022 04:27, Daniel Kozar via grass-user wrote: Hi everyone, When using the extension "v.class.mlR" I get an error [Message 1] (see below) that "Rscript" cannot be located. I traced this back to the script for "v.class.mlR" and edited line 908 to read the direct path to Rscript - '/usr/local/bin/Rscript' rather than 'Rscript' alone. However, when I re-open GRASS 8.0 I get an error [Message 2] that the extension failed when loading and that the operation isn't permitted. I allowed for the application to have administrative rights but it still doesn't work. Does anyone know how to work around this or solve the issue finding "Rscript"? I have R running and have installed necessary packages. I'm running GRASS on MacOS Monterey. This looks like a Mac problem (which I know nothing about). To test, can you run, first from a terminal: micha@RMS:~$ Rscript -e "sessionInfo()" Now run the same from within a GRASS session: (here's what I get) micha@RMS:QGIS$ g.version GRASS 8.1.dev (2022) micha@RMS:QGIS$ Rscript -e "sessionInfo()" R version 4.1.2 (2021-11-01) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Debian GNU/Linux 11 (bullseye) Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3 LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.13.so locale: [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8 [5] LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8 [7] LC_PAPER=en_GB.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.1.2 If the Rscript executable is not found, then v.class.mlR cannot be run. Any help would be appreciated. - Daniel - *[Message 1]* Running R now. Following output is R output. Traceback (most recent call last): File "/Users/dankozar/Library/GRASS/8.0/Addons/scripts/v.class.mlR", line 977, in main() File "/Users/dankozar/Library/GRASS/8.0/Addons/scripts/v.class.mlR", line 908, in main subprocess.check_call( File "/Applications/GRASS-8.0.app/Contents/Resources/lib/python3.9/subprocess.py", line 368, in check_call retcode = call(*popenargs, **kwargs) File "/Applications/GRASS-8.0.app/Contents/Resources/lib/python3.9/subprocess.py", line 349, in call with Popen(*popenargs, **kwargs) as p: File "/Applications/GRASS-8.0.app/Contents/Resources/lib/python3.9/subprocess.py", line 951, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File "/Applications/GRASS-8.0.app/Contents/Resources/lib/python3.9/subprocess.py", line 1821, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) FileNotFoundError: [Errno 2] No such file or directory: 'Rscript' *[Message 2]* Details: <[Errno 1] Operation not permitted: 'v.class.mlR'> WARNING: Some addons failed when loading. Please consider to update your addons by running 'g.extension.all -f'. -- Thank you, Daniel Kozar PhD Candidate UC Davis - Hydrologic Sciences djko...@ucdavis.edu (814) 380-6900 _______ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Joining Vectors for Training Data - Object Based Image Analysis
You do not have any ID column for each class in the original shapefiles, so there is no information to maintain. You should add an ID column, and edit this column such that it contains either text or a number to indicate the class. (There's no need for two separate shapefiles: just one with a column containing the ID.) You can do this either in the other software, or directly in GRASS. If you want to accomplish this in GRASS with the existing point layers, then: Add a column for the class_id to both using: v.db.addcolumn column="class_id INTEGER" v.db.addcolumn column="class_id INTEGER" Update this column for both: v.db.update column="class_id" value=0 # for the bare v.db.update column=class_id value=1 # for the woody points Now merge: v.patch -e input="woody,bare" output=training On 18/02/2022 00:00, Daniel Jeffrey Kozar via grass-user wrote: Hi everyone, I am generating a workflow for object-based image classification of drone imagery and am getting tripped up when utilizing vectors for training data. I have ".shp" files for each class created in another software and am trying to join them to create one vector file with an ID column corresponding to the class. I have been trying to use the command v.patch, which does join them, but doesn't seem to allow for maintaining information about the class. Does anyone have any recommendations to do this? Any help would be greatly appreciated. Ive attached two example ".shp" files for reference. Best, Daniel ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass command to subset the columns of a vector
On 09/02/2022 15:56, Bernardo Santos via grass-user wrote:
Dear Markus
Thanks for your answer. I thought about v.db.dropcolumn earlier.
However, I am trying to include this within a function, following a
workflow in which the input vector might have columns with different
names, in which case it would be good to be able to select the ones to
keep instead of the ones to remove.
For instance, let's say I want to be able to provide either of the
following input vectors:
- "vector1", with columns "a, b, c, d, e"
- "vector2", with columns "j, a, k, f, e"
Let's say I want to keep only "a" and "e".
If I use v.db.dropcolumn, I'll have to first list the names of all
columns (maybe with v.db.select), then match all the column names that
I do not want to keep ("b, c, d" in the first case, "j, k, f" in the
second), then drop them with v.db.dropcolumn. I thought just selecting
which ones I want to keep would be simpler and more straightforward,
if there is a tool for that.
So far I am doing a long step (I am creating a temporary vector to
avoid changing the input):
1) v.extract -t input=vector1 output=temp_vector (here I select only
the features, not attribute table)
2) v.db.addtable map=temp_vector columns=a,e (here I do not bother
with the names of the undesirable columns)
3) v.db.update map=temp_vector column=e value=1 (here I set a value
but I could take it from the original vector1)
Following what you suggest, I could do:
1) g.copy vector=vector1,temp_vector
2) (find out a way to list the undesirable column names)
Here's a possible solution. (Somewhat clunky, but workable)
You can get the column names using v.info -c, then grep out the column
names you want to keep. Then loop thru the column names that are left
and do v.db.dropcolumn for each.
i.e.:
# I have a vector "terraces" with 4 columns.
v.info -c terraces
Displaying column types/names for database connection of layer <1>:
INTEGER|cat
INTEGER|OBJECTID
DOUBLE PRECISION|Shape_Leng
INTEGER|Validated
#Keep only 2: "cat" and "Validated"
g.copy vect=terraces,terraces_tmp
Copying vector to current mapset as
# Get a list of columns to drop
to_drop=`v.info -c terraces_tmp | cut -d'|' -f2 | grep -E -v 'Validate|cat'`
Displaying column types/names for database connection of layer <1>:
echo $to_drop
OBJECTID Shape_Leng
# Loop thru columns to drop and run v.db.dropcolumn on each
for col in $to_drop; do v.db.dropcolumn terraces_tmp col=${col}; done
# Result
v.info -c terraces_tmp
Displaying column types/names for database connection of layer <1>:
INTEGER|cat
INTEGER|Validated
HTH,
Micha
3) v.db.dropcolumn columns=list_undesidable_columns
Neither of the solutions is so straightforward, that's why I thought
there should be (or could be) another way.
In R, for instance, I can easily subset columns of an sf object using
dplyr::select(vector1, a, e). I guess in PostGIS it is also possible
to do that with "SELECT statements", even though I am less skilled
there. It would be great to have a module in GRASS to do it as well...
Best
Bernardo
Em quarta-feira, 9 de fevereiro de 2022 09:28:06 GMT+1, Markus Neteler
escreveu:
Hi Bernardo,
On Wed, Feb 9, 2022 at 1:39 AM Bernardo Santos via grass-user
wrote:
>
> Dear list,
>
> Is there a GRASS GIS command (maybe a v.db.* one) to subset, in a
single command, the columns of a vector?
>
> What I have: vector "vect" with 5 columns "a, b, c, d, e" in the
attribute table
> What I want: vector "vect_sub" with only, for instance, "a, c, e"
>
> I can use v.extract to subsample rows, but not columns. What is the
easiest way of doing that, what needing many commands (like creating
or copying the vector to a new one, creating a new attribute table,
then copying only the columns I want).
Isn't this simply
https://grass.osgeo.org/grass80/manuals/vector.html
--> v.db.dropcolumn - Drops a column from the attribute table
connected to a given vector map.
--> It offers single and multiple column dropping:
columns=name[,name,...]
> I looked for that in the documentation but did not found it so easily.
Please suggest where to improve the documentation.
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] single window gui in main branch
Wow, impressive! I especially like the search option in the right panel toolbox. Also the ability to switch the python and command shell to full screen is great. Best regards, and thanks for the nice work! Micha On 11/01/2022 20:16, Veronica Andreo wrote: Hello everyone, Now that single window is merged into main branch I'd like to test :) Where's the switch? I just updated and compiled main branch and went through all tabs and options in the settings?preferences menu from the GUI, but I could not find anything saying single window something. What am I doing wrong here? Can this be related to https://github.com/OSGeo/grass/blob/f57940e8a096c593f23b2ce3f9653547f24b8e92/gui/wxpython/core/settings.py#L156 been set to False? Shall I change that to True to make it appear/work? Build info GRASS version: 8.0.dev <http://8.0.dev> Code revision: 563797cd3 Build date: 2022-01-11 Thanks much, Vero -- Dra. Verónica Andreo Investigadora Asistente de CONICET Instituto Gulich (CONAE - UNC) Centro Espacial Teófilo Tabanera (CETT) Falda del Cañete - Córdoba, Argentina +54 3547 40 int. 1153 https://veroandreo.gitlab.io/ ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how create new mapsets in grass bash scripts in parallel (equivalent of grass78 -c /path/location/PERMANENT -e)
Hi
On 10/21/21 11:39 PM, B H wrote:
I am trying to parallelize some scripts that currently run only one
way .( Currently scripts just create a new temporary mapset and run
some commands using --exec option of grass78)
My understanding is that I should follow this, however I am unable to
create a new mapset using this.
https://grasswiki.osgeo.org/wiki/GRASS_and_Shell#Automated_batch_jobs:_Setting_the_GRASS_environmental_variables
<https://grasswiki.osgeo.org/wiki/GRASS_and_Shell#Automated_batch_jobs:_Setting_the_GRASS_environmental_variables>
Here is what I have tried and failed
1) grass78 executable cannot be run parallely from bash even to just
create the mapset
2) g.mapset -c
3) g.proj -c
If there is a different way to create a new mapset, please let me know
(I am not sure if its as simple as copying some files from a template
location...)
This seems to work for me, using GNU parallel.
I created a list of shapefiles:
micha@RMS:tmp$ head -3 list_of_shapefiles.txt
/home/micha/GIS/Israel/cellular_antennas.shp
/home/micha/GIS/Israel/cities.shp
/home/micha/GIS/Israel/contour_20m.shp
to use as input. Then I prepared a script to run grass on each, in it's
own separate Location.
micha@RMS:tmp$ cat grass_process.sh
#!/bin/bash
if [ $# -eq 0 ]; then
echo "Input geospatial vector file is required."
echo "Syntax: grass_process.sh "
exit
fi
input=$1
output=`basename $input .shp`
# Prepare temporary name for Location (under the /tmp directory)
tmp_location=`mktemp -u`
# Create temporary GRASS location in that directory,
# using the shapefile as georeference, and run a command
grass78 -c $input ${tmp_location} --exec v.import input=$input
output=$output --overwrite
sleep 10
The sleep at the end is just to give me time to check with ps -ef that
all processes are running.
I made the script executable, of course.
Then here's the call to parallel:
micha@RMS:tmp$ parallel -j 10 ./grass_process.sh < list_of_shapefiles.txt
and after I fire it off, in a separate terminal I see:
micha@RMS:tmp$ ps -ef | grep grass
micha 45460 12434 0 10:04 pts/2 00:00:00 perl
/usr/bin/parallel -j 10 ./grass_process.sh
micha 45481 45460 0 10:04 pts/2 00:00:00 /bin/bash
./grass_process.sh /home/micha/GIS/Israel/cellular_antennas.shp
micha 45483 45460 0 10:04 pts/2 00:00:00 /bin/bash
./grass_process.sh /home/micha/GIS/Israel/cities.shp
micha 45485 45460 0 10:04 pts/2 00:00:00 /bin/bash
./grass_process.sh /home/micha/GIS/Israel/contour_20m.shp
micha 45488 45460 0 10:04 pts/2 00:00:00 /bin/bash
./grass_process.sh /home/micha/GIS/Israel/contour_50m.shp
micha 45492 45460 0 10:04 pts/2 00:00:00 /bin/bash
./grass_process.sh /home/micha/GIS/Israel/il_seas.shp
micha 45496 45460 0 10:04 pts/2 00:00:00 /bin/bash
./grass_process.sh /home/micha/GIS/Israel/mideast_cities.shp
micha 45500 45460 0 10:04 pts/2 00:00:00 /bin/bash
./grass_process.sh /home/micha/GIS/Israel/reshut_nikuz.shp
micha 45504 45460 0 10:04 pts/2 00:00:00 /bin/bash
./grass_process.sh /home/micha/GIS/Israel/roads_ITM.shp
micha 45508 45460 0 10:04 pts/2 00:00:00 /bin/bash
./grass_process.sh /home/micha/GIS/Israel/roads_negev.shp
micha 45512 45460 0 10:04 pts/2 00:00:00 /bin/bash
./grass_process.sh /home/micha/GIS/Israel/roads.shp
all merrily going on together.
This will leave you with separate Locations/mapsets for each input file.
I don't think you can get around that. GRASS itself is NOT parallelized,
so you cannot run more than one GRASS process in the same mapset.
If you need to do a more complicated procedure, then wrap all the GRASS
commands into another shell script and pass that script to the --exec
parameter instead of individual commands.
HTH
#current grass scripts
#Step 1: Create a new location with permanent mapset
grass78 -c /path/location/PERMANENT -e
#Step2: run some commands using--exec option
grass78--exec v.in.ogr input='$inputfile' output=$vecoutname
location=path/location/PERMANENT
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Raster null values unchanged by r.null
Hi On 10/20/21 4:52 PM, Eric Patton via grass-user wrote: I'm encountering some strange behaviour from r.null - when I use the setnull parameter to assign a particular value to be null in a raster, the raster areas just set to null are still visible and coloured according to their previous values when I refresh the display in the gui map window. Querying these values shows they haven't been set to null. Using version 7.8.5 on Linux Mint. Can anyone confirm? No problem here, 7.8.5 on Debian. Also checked on grass 8.0. -- Eric ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Change column data format from double precision to integer
Hi Rich On 10/5/21 7:59 PM, Rich Shepard wrote: A vector map's database table has a column named z_int and data type of double precision as presented in the map's attribute table. It was defined as an int in the v.in.ascii command. How do I change the data type to int? AFAIK coordinates in GRASS (including the z coord) are always DOUBLE. The v.in.ascii function reads the x,y,z columns as DOUBLE. If you declare the columns parameter in v.in.ascii, these attribute columns are created as DOUBLE. I checked the OGC specs for vector data and did not find any mention that coordinates should be DOUBLE, but that's usually the case in most GIS, to the best of my knowledge. Having said that, you can create a new attribute column, and populate it with integer values from the z coordinate, with the CAST sqlite3 function. Consider: echo "1,1,1" | v.in.ascii -z input=- output=p1 separator=comma x=1 y=2 z=3 v.report p1 option=coor cat|x|y|z 1|1|1|1 # However, no database connection defined: v.info -c p1 ERROR: Database connection for map is not defined in DB file # v.to.db creates new columns as DOUBLE v.to.db p1 option=coor column="east,north,elev" v.info -c p1 Displaying column types/names for database connection of layer <1>: INTEGER|cat DOUBLE PRECISION|east DOUBLE PRECISION|north DOUBLE PRECISION|elev # Now add a new INTEGER column v.db.addcolumn p1 column="z_int INTEGER" v.db.update p1 column=z_int query_col="CAST(elev as INTEGER)" v.info -c p1 Displaying column types/names for database connection of layer <1>: INTEGER|cat DOUBLE PRECISION|east DOUBLE PRECISION|north DOUBLE PRECISION|elev INTEGER|z_int I think that is what you wanted. The only option offered in that window is to delete a column by right-clicking on it. I assume there's a way within GRASS of changing the data type. TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Again, grass doen't find existing map to display
On 9/30/21 8:18 PM, Rich Shepard wrote: Only since about a week ago have I had grass tell me it could not display an existing map. They happen when I try to erase the monitor or display a map and exiting/re-starting GRASS doesn't resolve the issue. I get this response both when the map's in a different mapset that's available or in the mapset in which it's found: g.mapsets -l Available mapsets: PERMANENT bathymetry features fish hydraulics size=7 # window truncation Did you enter the full vector name with Mapset as property@bathymetry ?? ERROR: Vector map not found GRASS project/bathymetry:analyses > g.mapset map=features Mapset switched. GRASS project/features:analyses > g.list type=vect property size=7 python3: can't open file '/data/grassdata/project/features/.tmp/salmo/MONITORS/wx1/render.py': [Errno Did you start a new wx monitor after switching mapsets? 2] No such file or directory What might be the cause of these errors? Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Display point values
On 9/30/21 7:33 PM, Rich Shepard wrote: Rather than use raster DTM maps I decided to use depth measurement points themselves. The data look like this: lon,lat,depth 7709581.42,697951.64,24 7705545.87,698624.07,16 7709732.27,699488.73,27 7712090.79,699428.24,62 7716863.99,701238.89,32 7701540.85,698790.50,31 7713676.33,699192.82,58 7705283.41,697549.00,31 7705037.10,698489.22,16 The command I'm using is: d.vect map=lady_channel_sounding_points display=zcoor type=point zcolor=blue size=7 and the resulting map is attached. Here's what I did. Notice that I added the "-z=3" option to v.in.ascii so that the new points vector is 3D. Then the "zcolor=" option to d.vect works. # Create new Location/Mapset based on the georeference tiff file grass -c ~/Downloads/columbia_2010_e_dtm_35.tif --text ./columbia/PERMANENT #Points text file micha@RMS:tmp$ cat << EOF > depth_points.txt lon,lat,depth 7709581.42,697951.64,24 7705545.87,698624.07,16 7709732.27,699488.73,27 7712090.79,699428.24,62 7716863.99,701238.89,32 7701540.85,698790.50,31 7713676.33,699192.82,58 7705283.41,697549.00,31 7705037.10,698489.22,16 EOF # Create GRASS vector from CSV file # Note the 'z=3" parameter, to creaate a 3D vector with Z coord cat depth_points.txt | v.in.ascii input=- output=depth_points separator=comma z=3 skip=1 columns="x DOUBLE, y DOUBLE, depth DOUBLE" --o v.info depth_points | grep 3D | Map is 3D: Yes g.region -ap vect=depth_points # Display d.mon wx1 d.vect depth_points zcolor=byr size=10 icon=basic/diamond # Result attached Perhaps I should make the computational region smaller to make individual values visible, but are the display and color values what they should be? The values are displayed in red, not blue. TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.input and d.rast issues
ation withv.proj <https://grass.osgeo.org/grass78/manuals/v.proj.html>. Next the region in the target location is set to the extent of the new vector map withg.region <https://grass.osgeo.org/grass78/manuals/g.region.html>along with the desired raster resolution (g.region -mcan be used in Latitude/Longitude locations to measure the geodetic length of a pixel).r.projis then run for the raster map the user wants to reproject. In this case a little preparation goes a long way."/ 2. Then you used to `extent=` parameter to import columbia_2010_e_dtm_35.tif only within the current computational region, which you had set to match the raster `local_depth`. However it seems that these do not overlap at all, so the import failed. What does: gdalinfo ~/projects/washington/nevins-dock/data/topography/columbia_2010_e_dtm_35.tif | grep -A4 "Coordinates" show?? Does that help? TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] imported .tif maps lose all data
Hi Rich: On 9/26/21 2:36 AM, Rich Shepard wrote: All my previous work with GRASS since 4.0 had one large map that covered a larger region than needed for the project so I would define a project area within it. These LiDAR topography maps cover a very large spatial area and I have no idea with one (or two) actually include the project's area. So I need to import them all then find the appropriate one or two. If that's the case, perhaps a quick `gdalinfo` loop over all 77 topography maps in advance will help to find the relevant ones. You get the corner coordinates in the gdalinfo output, so you'll be able to find those that overlap the project region before importing to GRASS. Micha Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] imported .tif maps lose all data
I can echo Helmut: Freshly compiled 8.0-dev on Debian. I Imported the columbia dtm_35 tif and displayed the stats fine. On 9/25/21 9:42 PM, Helmut Kudrnovsky wrote: Then the issue is with 8.0.dev. just tested with 8.0.dev.; it works here the same as in 7.8 Helmut ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] imported .tif maps lose all data
On 9/25/21 9:27 PM, Rich Shepard wrote: On Sat, 25 Sep 2021, Helmut Kudrnovsky wrote: Helmut/Micha, Then the issue is with 8.0.dev. Where can I download the 7.8.x source so I can build it here? Following links from the web site's download for gneric linux From github: https://github.com/OSGeo/grass/tree/releasebranch_7_8 The first link in the list on this page points to the GRASS repo: https://grass.osgeo.org/download/ Choose the version you want by switching to a different branch. I find a zip file and an install shell script, but not the source that allows me to build it on this Slackware-14.2/x86_64 host. Are the source files available just like the 8.0.dev source tree is? Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Imported .tif maps lose all data
Hi Carlos: On 9/25/21 9:16 PM, Carlos Henrique Grohmann de Carvalho wrote: Rich I believe r.in.gdal will require the region to match each of the tifs you're importing. Try using r.import with the option extent set to "input", so it won't do region cropping I don't think that is correct. r.in.gdal is one of the (very few) raster modules that does NOT honor the current region settings. You can import a raster from "anywhere", but then, as always, you must set the current region to match that raster for further analysis. What's more, in your previous post you mentioned that r.import "overrides region settings". IMHO this is also not correct. r.import will reproject an input dataset to current Location's coordinate system, if necessary. Regarding the region settings, by default with the extent parameter left at "input", the whole input raster will be imported. If you set the the extent parameter to "region" then only that subset of the input raster that falls in the current region will be imported. But in both cases, the current region is not altered. Best, Micha C On Sat, Sep 25, 2021 at 1:43 PM Rich Shepard <rshep...@appl-ecosys.com> wrote: On Sat, 25 Sep 2021, Carlos Henrique Grohmann de Carvalho wrote: > How is your region settings? Do they match the DEMs? Maybe importing with > r.import will help, as it can override region settings Carlos, Initially it was the default region. But, I changed the region to a test map, dtm_35, and re-ran r.report and r.stats. There's still no data in any of the cells. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Prof. Carlos Henrique Grohmann Institute of Energy and Environment - Univ. of São Paulo, Brazil - Digital Terrain Analysis | GIS | Remote Sensing - http://carlosgrohmann.com http://orcid.org/-0001-5073-5572 Can’t stop the signal. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] imported .tif maps lose all data
#|description | |-| | 159.315659-162.759598|from to | | 162.759598-166.203537|from to | | 166.203537-169.647476|from to | | 169.647476-173.091415|from to | | 173.091415-176.535354|from to | | 176.535354-179.979293|from to | | 179.979293-183.423233|from to | | 183.423233-186.867172|from to | | 186.867172-190.31|from to | | 190.31-193.75505|from to | | 193.75505-197.198989|from to | (Lots more rows like above) Looks OK from here. \O/ On 9/25/21 9:03 PM, Rich Shepard wrote: On Sat, 25 Sep 2021, Helmut Kudrnovsky wrote: The data file sizes are all in the low 100Ks. I could upload an example to fileconvoy.com if that's helpful. could you make one of the data files available? Heelmut, Certainly. It's avalable from and will be there for 5 days. The file that can be retrieved with the above link is: columbia_2010_e_dtm_35.tif (138.85 MB) Regards, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Imported .tif maps lose all data
On 9/25/21 7:41 PM, Rich Shepard wrote: On Sat, 25 Sep 2021, Micha Silver wrote: Just to check: did you set the current region to the imported raster before running r.report? Micha, Just did set the region to dtm_35 and re-ran r.report: The data's still AWOL. Can we go back to your suggestion to post the original data somewhere? Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Imported .tif maps lose all data
Rich: Just to check: did you set the current region to the imported raster before running r.report? From the man page: Note that the statistics is always computed in the current geographical region. From the Y coordinates in the gdalinfo output and the region settings reported by r.report, it seems that there is almost no overlap. Maybe that's the reason the r.report is not showing anything? On 9/25/21 5:43 PM, Rich Shepard wrote: I have 77 LiDAR topo files in .tif format. What gdalinfo tells me about a representative file: $ gdalinfo columbia_2010_e_dtm_35.tif Corner Coordinates: Upper Left ( 1512164.000, 152311.000) (121d 0' 8.57"W, 45d44'59.58"N) Lower Left ( 1512164.000, 106519.000) (121d 0' 4.46"W, 45d37'27.52"N) Upper Right ( 1544399.000, 152311.000) (120d52'34.01"W, 45d45' 1.35"N) Lower Right ( 1544399.000, 106519.000) (120d52'30.94"W, 45d37'29.29"N) r.in.gdal in=/path/to/project/data/topography/columbia_2010_e_dtm_35.tif out=dtm_4 --o Also, in your example, you imported to a GRASS raster named dtm_4, but you then run r.report on a raster named dtm_35 ?? The problem is the imported maps have no elevation data. For example, r.report dtm_35 100% +-+ | RASTER MAP CATEGORY REPORT | |LOCATION: new_nevins_dock Sat Sep 25 07:28:25 2021| |-| | north: 106729 east: 1544180 | |REGION south: 60934 west: 1511876 | | res: 3 res: 3 | |-| |MASK: none | |-| |MAP: (untitled) (dtm_35 in topography) | |-| | Category Information | cell| % | |#|description | count| cover| |-| |*|no data. . . . . . . . . . . . . . . . . . . . . . . . . .|164373520|100.00| |-| |TOTAL |164373520|100.00| +-+ r.stats -l in=dtm_35 out=- 100% * no data r.stats also honors the current region The data file sizes are all in the low 100Ks. I could upload an example to fileconvoy.com if that's helpful. What have I done incorrectly that the imported maps have no elevation data while the raw .tif files do? TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Issues with 8.0.dev
Hi Rich: On 9/24/21 12:17 AM, Rich Shepard wrote: Today I pulled changes from the main branch, configured, built, and installed the latest source from the 8.0.dev source. When I start grass I see what I believe is the build number: Welcome to GRASS GIS 8.0.dev (63fca9fb2) There are some issues that did not occur before. For example, I reprojected a vector map from one location to another, but put it in the wrong mapset on the new location. I copied it from one mapset What do you mean by "put it in the wrong mapset"? You can't put the output of v.proj or r.proj into anything but the current mapset. If you tried to set the output name with a '/' then that's the source of the problem. Another point caught my eye in an earlier post. You mentioned the need to reproject some data twice. I can't imagine any workflow where that would be necessary. Suppose you got some data in three different coordinate systems, projA, projB and projC. And you chose to do all your work in projC. Then: * You create three locations, let's call them tmp_loc_A, tmp_loc_B and working_loc_C. * Start grass in tmp_loc_A: grass /tmp_loc_A/PERMANENT * and import the data that is in that CRS. Probably r.external and v.external would be OK to save disk space. * Switch to tmp_loc_B and get the data that is in that CRS:g.mapset loc=tmp_loc_B map=PERMANENT then r.external, v.external as needed * Switch to working_loc_C, g.mapset loc=working_loc_C map=PERMANENT * and reproject all vector and raster maps from each of tmp_loc_A and tmp_loc_B: v.proj loc=tmp_loc_A map=PERMANENT input=vector_1; r.proj loc=tmp_loc_A map=PERMANENT input=raster_1, etc. etc...Same for tmp_loc_B * Now you can blow away both tmp_loc_A and tmp_loc_B HTH, Micha to the other but when I try to remove it from the wrong mapset (g.mapset -p shows features) I get an error: g.remove -f type=vect name=channel_contour_lines Removing vector WARNING: Illegal filename . Character not allowed. WARNING: Illegal filename . Character not allowed. ERROR: Vector map not found in current mapset g.list type=vect WARNING: Illegal filename . Character not allowed. channel_contour_lines the_property Thoughts? Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Which EPSG code for location default?
On 9/23/21 3:38 PM, Rich Shepard wrote: Yet, ... I have a question: is there a way in grass to change the PROJ_INFO in the PERMANENT mapset of a location to a new projecion? Or, do I manually edit that file? IMHO you should *not* do that. Just create a new Location. Thanks in advance, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 https://orcid.org/-0002-1128-1325 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Startup issue: defaults to one mapset [RESOLVED]
On 9/22/21 8:57 PM, Rich Shepard wrote: On Wed, 22 Sep 2021, Rich Shepard wrote: Where do I look to find what's going on so I can fix it? I don't think there is anything to fix: At startup GRASS does not care about current working directory. The default LOCATION/MAPSET is read from the ~/.grass7/rc file. Here on my system: micha@RMS:~$ cat ~/.grass7/rc GISDBASE: /home/micha/GIS/grass LOCATION_NAME: ITM MAPSET: Arava GUI: wxpython DEBUG: 0 If you want to start GRASS from some other LOCATION/MAPSET you just add the full path to the different MAPSET on the command line, as you showed below. Never hurts to review: https://grass.osgeo.org/grass78/manuals/grass7.html especially: EXAMPLES The following are some examples of how you could start GRASS *grass78* Start GRASS using the default user interface. The user will be prompted to choose the appropriate location and mapset. *grass78 --gui* Start GRASS using the graphical user interface. The user will be prompted to choose the appropriate location and mapset. *grass78 --text* Start GRASS using the text-based user interface. Appropriate location and mapset must be set by environmental variables (see examples below) otherwise taken from the last GRASS session. *grass78 --gtext* Start GRASS using the text-based user interface. The user will be prompted to choose the appropriate location and mapset. *grass78 $HOME/grassdata/spearfish70/user1* What I'm now doing to start grass from /data/grassdata is: grass /data/grassdata// It works. Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Start grass, create new mapset
Hi Moritz: On 9/22/21 4:20 PM, Moritz Lennert wrote: Le 22 septembre 2021 14:40:45 GMT+02:00, Rich Shepard a écrit : On Wed, 22 Sep 2021, Moritz Lennert wrote: I also see that the description of the -c flag itself only speaks about locations, not mapsets. This should also be changed. Something in the direction of: "-c Creates new GRASS unprojected location in specified GISDBASE" [no idea why it says 'unprojected' must be long-term legacy] I think the reason here stems from the un-desirable case of creating a location without specifying any projection details (neither EPSG code nor a georeferenced file) then you'll get a more or less unusable Location. You will have to start manually to setup the Location's projection. What's more, I think that using the -c option to create a location and mapset in one go does not work. You will always get a Location with only the PERMANENT mapset: grass -text -c EPSG:32632 /home/micha/GIS/grass/UTM33/micha micha@RMS:Downloads$ g.mapsets -p Accessible mapsets: PERMANENT (No mapset "micha") The best approach is to do it in two stages: 1. Create the Location (using an EPSG code or georeferenced file) . You can add the -e option to exit immediately 2. Then restart grass with -c again to create the mapset, with the full path. should become "-c Creates new GRASS location or mapset respectively in specified GISDBASE or location" [if this is not too long] Moritz Regards, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS GIS 7.8.5 r.water.outlet
On 5/19/21 9:52 PM, Kelsey Wong wrote:
Hi,
I am trying to use the r.water.outlet function in a python script in GRASS. For
the ‘coordinates’ parameter my x,y coordinate values are stored in two columns
in the attribute table of another layer. Is there a way to access these values
from the attribute table directly?
The grass.script command 'parse_command' returns the module output as a
python dict, so something like:
import grass.script as gscript
xy = gscript.parse_command('v.db.select', map_="another_table",
columns=['x_coord'_column, 'y_coord_column'], separator="comma")
will probably get you on the right track. If you have multiple points in
the "another_table", then you'll have to loop thru the list, and run
r.water.outlet on each pair separately.
The addon `r.streams.basins`, on the other hand, can deal with a list of
coordinate pairs. So if you convert the output of v.db.select into a
comma separated list like: x1,y1,x2,y2, x3,y3... then you can get all
basins in one go. What's more, this addon can accept a point vector of
drainage outlet points, and prepare basins for each. So if your
"another_table" is indeed a point vector, and the two columns in the
attribute table are the point coordinates, then no need to extract
coordinate from the attrib table. just feed the point vector to the
`points` parameter of `r.streams.basins`.
Thanks,
Kelsey
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed identify inland watershed
On 4/2/21 5:37 PM, ming han wrote:
Maybe I am the only one who has this demand. Following is just a
recommendation to GRASS r.watershed function.
Maybe it is worth having an option to avoid r.watershed overcome
depressions.
The reasons are 1) there are many hydrologically pre condition DEM
data available globally, such as:HydroSHEDS, MERIT
2) the depression in these DEM are real
depressions, overcome these depressions will make the entire drainage
system
Regarding Hydrosheds, the documentation[1] in section 3.4 explains how
they overcame the problem of sinks. They performed a regular "fill
sinks" operation on areas that were SRTM artifacts. True natural
depressions were identified manually, then another manual procedure of
carving rivers was done to force flow thru these depressions and produce
hydrologically correct streams and basins. So pre-conditioning to
overcome depressions is not a magic bullet...
In my opinion, the best results are obtained when true depressions
(pits, salt playas or karst regions) are identified, and set to NULL in
the elevation raster. That will allow r.watershed to stop routing at
those locations, and produce correct stream and basin layers.
[1]https://hydrosheds.org/images/inpages/HydroSHEDS_TechDoc_v1_2.pdf
incorrectly.
I understand GRASS has other functions to solve this problem, but just
a user recommendation. I use GRASS a lot.
Thanks
Ming
ming han mailto:dustm...@gmail.com>>
于2021年3月30日周二 上午8:06写道：
Got it, thanks everyone~
Ming
Micha Silver mailto:tsvi...@gmail.com>>
于2021年3月29日周一 下午2:40写道：
Hello:
You might try `r.param.scale`, or even better `r.geomorphons`
modules to
identify geomorphology features, then filter out all pixels
identified
as pits.
r.watershed is purposely designed to overcome depressions, and
find flow
routing thru these spots. So I don't think you can use that
module to
identify depressions.
On 3/27/21 8:49 PM, ming han wrote:
> Hi Everyone
>
> When I do watershed delineation using r.watershed for
great salt
> lake watershed. I found r.watershed always tried to assign
an outlet
> for a great salt lake, which does actually not exist because
it is an
> inland lake and the great salt lake has no watershed outlet
at all.
>
> I noticed that there is a depression option. But is
there any
> way that r.watershed can automatically identify depressions
while
> defining flow accumulation and stream network?
>
> Thanks
> Ming
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/grass-user
<https://lists.osgeo.org/mailman/listinfo/grass-user>
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed identify inland watershed
Hello: You might try `r.param.scale`, or even better `r.geomorphons` modules to identify geomorphology features, then filter out all pixels identified as pits. r.watershed is purposely designed to overcome depressions, and find flow routing thru these spots. So I don't think you can use that module to identify depressions. On 3/27/21 8:49 PM, ming han wrote: Hi Everyone When I do watershed delineation using r.watershed for great salt lake watershed. I found r.watershed always tried to assign an outlet for a great salt lake, which does actually not exist because it is an inland lake and the great salt lake has no watershed outlet at all. I noticed that there is a depression option. But is there any way that r.watershed can automatically identify depressions while defining flow accumulation and stream network? Thanks Ming ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.mapcalc
On 3/14/21 11:07 AM, Enrico Gabrielli bonushenricus wrote: Hi How are you? After solving thanks to Stefan and his r.slope.direction how to calculate the slope along the keyline, now I have to solve how to create parallels to the keyline. Nothing easier: see parallel! But I have to create many. In the graphical modeler I can't learn how to use the loop. Damn if I'm ignorant. But maybe v.mapcalc would also be very handy. But it doesn't work for me. After installing ply it doesn't work anyway. Can you add some further information: What is your operating system? What version of GRASS? When you say "I have to create many", do you mean many parallel lines at different distances? Are you working with projected data? (I missed the previous thread on r.slope.direction, sorry if this has been mentioned before) What scripting language do you prefer? python? bash shell script? If python, what version is installed? (note that GRASS 7.8 has switched to python 3) What is "keyline"? (i.e. please show the output from `v.info keyline` Traceback (most recent call last): File "/usr/lib/grass76/scripts/v.mapcalc", line 429, in sys.exit(main()) File "/usr/lib/grass76/scripts/v.mapcalc", line 415, in main p.parse(expression) File "/usr/lib/grass76/scripts/v.mapcalc", line 191, in parse self.parser.parse(expression) File "/usr/lib/python2.7/dist-packages/ply/yacc.py", line 333, in parse return self.parseopt_notrack(input, lexer, debug, tracking, tokenfunc) File "/usr/lib/python2.7/dist-packages/ply/yacc.py", line 1063, in parseopt_notrack lookahead = get_token() # Get the next token File "/usr/lib/python2.7/dist-packages/ply/lex.py", line 393, in token newtok = self.lexerrorf(tok) File "/usr/lib/grass76/scripts/v.mapcalc", line 146, in t_error (t.lineno, t.value)) SyntaxError: syntax error on line 1 near ''buff_l(keyline@PERMANENT,5)'' I used all possible quotes in the expression, but the result is always the same I don't want to use qgis (where there would be offset) because r.slope.direction is in grass and it is very convenient, and also all the rasters I use have them in grass. I would like to learn how to do everything in GRASS. Well, who knows if I'll succeed. As soon as I have some pennies I pay a friend of mine who is a python developer: maybe it's better. Thanks -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.surf.idw Not Working
Hello:
On 2/19/21 6:46 PM, Michaela Lobato wrote:
Thanks for all your continued help. I did the steps you recommended
and was met with a different error this time:
ERROR: Database connection not defined for layer 1
Traceback (most recent call last):
File
"/Users/michaelalobato/Library/GRASS/7.8/Modules/scripts/r.mblend",
line 282, in
main()
File
"/Users/michaelalobato/Library/GRASS/7.8/Modules/scripts/r.mblend",
line 240, in main
gscript.run_command('v.db.dropcolumn', map=weight_points_edge, layer='1',
File
"/Applications/GRASS-7.8.app/Contents/Resources/etc/python/grass/script/core.py",
line 441, in run_command
return handle_errors(returncode, returncode, args, kwargs)
File
"/Applications/GRASS-7.8.app/Contents/Resources/etc/python/grass/script/core.py",
line 342, in handle_errors
raise CalledModuleError(module=None, code=code,
grass.exceptions.CalledModuleError: Module run None v.db.dropcolumn
map=tmp_8758116 layer=1 columns=along ended with error
Process ended with non-zero return code 1. See errors in the (error)
output.
WARNING: No data base element files found
WARNING: No data base element files found
WARNING: No data base element files found
WARNING: No data base element files found
WARNING: Table linked to vector map does not
exist
I was finally able to duplicate your error. This happens, it seems, only
when working in a longitude/latitude location. When I used two DEM
rasters in a *projected* location, the interpolation to high-resolution
in the area covered only by the lowres raster worked fine. (Also if the
lowres raster extends in two directions).
However in a Long/lat location, with units of degrees, the addon fails.
I looked thru the source code, and my guess is that there is something
in the conversion from interpolation area to vector lines that is
failing. I'll report to the maintainer.
In any case, would you want to try to transform your DEM rasters to a
projected location and rerun the module?
One caveat: be aware that interpolating a full SRTM tile (approx 110km x
110km) to a resolution of 1 meter will create a huge raster (if my
numbers are right, it would be about 50GB) and would take a very long
time. So I'd suggest to try this out first in a much smaller area.
On Thu, Feb 18, 2021 at 7:02 AM Micha Silver <mailto:tsvi...@gmail.com>> wrote:
No solution yet :-(, only more questions...
It looks to me that the plugin is intended to work when the lowres
raster extends the highres raster only in one direction. In your
case,
the 1 degree SRTM tile you are using totally contains the USGS 1
meter
region.
To test this I would try to clip out a section of the SRTM:
# Set the computation region to the highres raster, then extend
only in
one direction
g.region -p rast=USGS_one_meter_x39y445_IL_12_County_ChampaignCo_2008
g.region -p w=88:20:00W
# Now clip the SRTM to this new region
# But use the coarse resolution
g.region -p res=0:00:01
r.mapcalc "n40_w089_clip = n40_w089_1arc_v3"
# Now try r.mblend with this clipped SRTM
r.mblend high=USGS_one_meter_x39y445_IL_12_County_ChampaignCo_2008
low=n40_w089_clip out=blend
Please report back if this helps (or not...)
On 2/17/2021 2:52 AM, Michaela Lobato wrote:
> Here is the output for r.info <http://r.info>
<https://urldefense.com/v3/__http://r.info__;!!DZ3fjg!s23wIXUNs2hY7ZIpBfhbowUyUKf0QNHMqg0IZeaaHL7V9Tw8y2aYLaAANBXlarcJh-k$
<https://urldefense.com/v3/__http://r.info__;!!DZ3fjg!s23wIXUNs2hY7ZIpBfhbowUyUKf0QNHMqg0IZeaaHL7V9Tw8y2aYLaAANBXlarcJh-k$>
> for both maps:
>
> < r.info <http://r.info>
<https://urldefense.com/v3/__http://r.info__;!!DZ3fjg!s23wIXUNs2hY7ZIpBfhbowUyUKf0QNHMqg0IZeaaHL7V9Tw8y2aYLaAANBXlarcJh-k$
<https://urldefense.com/v3/__http://r.info__;!!DZ3fjg!s23wIXUNs2hY7ZIpBfhbowUyUKf0QNHMqg0IZeaaHL7V9Tw8y2aYLaAANBXlarcJh-k$>
>
> map=USGS_one_meter_x39y445_IL_12_County_ChampaignCo_2008@PERMANENT
>
>
++
>
> | Map:USGS_one_meter_x39y445_IL_12_Date: Tue Feb 16 18:44:21 2021|
>
> | Mapset: PERMANENTLogin of Creator: michaelalobato|
>
> | Location: champaign|
>
> | DataBase: /Users/michaelalobato/Documents/Research/grassdata |
>
> | Title:USGS_one_meter_x39y445_IL_12_County_ChampaignCo_2008 |
>
> | Timestamp: none|
>
>
||
>
> ||
>
> | Type of Map:raster Number of Categories: 0 |
>
> | Data Type:FCELL|
>
> | Rows: 9015 |
>
> | Columns:11748|
>
> | Total Cells:1059
Re: [GRASS-user] v.surf.idw Not Working
No solution yet :-(, only more questions... It looks to me that the plugin is intended to work when the lowres raster extends the highres raster only in one direction. In your case, the 1 degree SRTM tile you are using totally contains the USGS 1 meter region. To test this I would try to clip out a section of the SRTM: # Set the computation region to the highres raster, then extend only in one direction g.region -p rast=USGS_one_meter_x39y445_IL_12_County_ChampaignCo_2008 g.region -p w=88:20:00W # Now clip the SRTM to this new region # But use the coarse resolution g.region -p res=0:00:01 r.mapcalc "n40_w089_clip = n40_w089_1arc_v3" # Now try r.mblend with this clipped SRTM r.mblend high=USGS_one_meter_x39y445_IL_12_County_ChampaignCo_2008 low=n40_w089_clip out=blend Please report back if this helps (or not...) On 2/17/2021 2:52 AM, Michaela Lobato wrote: Here is the output for r.info <http://r.info> for both maps: < r.info <http://r.info> map=USGS_one_meter_x39y445_IL_12_County_ChampaignCo_2008@PERMANENT ++ | Map:USGS_one_meter_x39y445_IL_12_Date: Tue Feb 16 18:44:21 2021| | Mapset: PERMANENTLogin of Creator: michaelalobato| | Location: champaign| | DataBase: /Users/michaelalobato/Documents/Research/grassdata | | Title:USGS_one_meter_x39y445_IL_12_County_ChampaignCo_2008 | | Timestamp: none| || || | Type of Map:raster Number of Categories: 0 | | Data Type:FCELL| | Rows: 9015 | | Columns:11748| | Total Cells:105908220| |Projection: Latitude-Longitude| |N: 40:11:40.173254NS: 40:06:11.010398N Res: 0:00:00.03651 | |E: 88:10:23.5766WW: 88:17:32.519389W Res: 0:00:00.036512| | Range of data:min = 204.0563max = 244.8284 | || | Data Description:| |generated by r.proj | || | Comments:| |r.proj --quiet location="temp_import_location_4329" mapset="PERMANEN\ | |T" input="USGS_one_meter_x39y445_IL_12_County_ChampaignCo_2008" meth\ | |od="nearest" memory=300 resolution=1.0142500028210239e-05 | || ++ < r.info <http://r.info> map=n40_w089_1arc_v3@PERMANENT ++ | Map:n40_w089_1arc_v3@PERMANENT Date: Tue Feb 16 18:42:24 2021| | Mapset: PERMANENTLogin of Creator: michaelalobato| | Location: champaign| | DataBase: /Users/michaelalobato/Documents/Research/grassdata | | Title:n40_w089_1arc_v3 | | Timestamp: none| || || | Type of Map:raster Number of Categories: 0 | | Data Type:CELL | | Rows: 3601 | | Columns:3601 | | Total Cells:12967201 | |Projection: Latitude-Longitude| |N: 41:00:00.5NS: 39:59:59.5N Res: 0:00:01 | |E: 87:59:59.5WW: 89:00:00.5W Res: 0:00:01 | | Range of data:min = 163max = 305 | || | Data Description:| |generated by r.in.gdal| || | Comments:| |r.in.gdal -e input="/Users/michaelalobato/Documents/Research/grassda\ | |ta/n40_w089_1arc_v3.tif" output="n40_w089_1arc_v3" memory=300 offset\ | |=0 num_digits=0 | || +--------+ Michalea -- Micha Silver Remote Sensing Lab, Sde Boker Ben Gurion University cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.surf.idw Not Working
On 2/15/21 8:51 PM, Michaela Lobato wrote:
Thank you for your message. I was able to getv.surf.idw working. I
posted the original question because I am struggling to use the
r.mblend add-on module. I have reached out and worked with the
r.mblend authors on Github but still haven't been able to solve my
issue. The error I am getting has to do with v.surf.idw:
So you're trying to blend two overlapping rasters of different
resolution? Can we see the output of r.info for both of the rasters?
Traceback (most recent call last):
File
"/Users/michaelalobato/Library/GRASS/7.8/Modules/scripts/r.mblend",
line 282, in .
main()
File
"/Users/michaelalobato/Library/GRASS/7.8/Modules/scripts/r.mblend",
line 257, in main
gscript.run_command('v.surf.idw', input=points_edges,
column=COL_VALUE,
File
"/Applications/GRASS-7.8.app/Contents/Resources/etc/python/grass/script/core.py",
line 441, in run_command
return handle_errors(returncode, returncode, args, kwargs)
File
"/Applications/GRASS-7.8.app/Contents/Resources/etc/python/grass/script/core.py",
line 342, in handle_errors
raise CalledModuleError(module=None, code=code,
grass.exceptions.CalledModuleError: Module run None v.surf.idw
input=tmp_3289117 column=value output=tmp_3289118
power=2 npoints=50 ended with error
Process ended with non-zero return code -9. See errors in the (error)
output.
WARNING: No data base element files found
WARNING: No data base element files found
WARNING: No data base element files found
WARNING: No data base element files found
WARNING: No data base element files found
WARNING: Table linked to vector map does
not exist
The author said that "/The |v.surf.idw| module is failing because it
can not find the attribute table of one the vector layers. This
probably means something is going on with the GRASS bank-end
database./" and requested the following information:
db.connect -p
>driver: sqlite
>database:
/Users/michaelalobato/Documents/Research/grassdata/newChampaign/test_champaign/sqlite/sqlite.db
>schema:
>group:
sqlite3
/Users/michaelalobato/Documents/Research/grassdata/champaign/PERMANENT/sqlite/sqlite.db
sqlite> .tables
>sqlite>
As you can see, when I try to list the existing tables, nothing comes
up. After this issue, I started working with just v.surf.idwto see if it
The sqlite database is empty since you probably have no vector layers in
your mapset. That's not necessarily a problem.
might be an issue with the module itself, but that seems to be working
fine. Does anyone have any suggestions as to how to solve the
v.surf.idw issue that I'm having within the mblend module?
Thanks!
Michaela
--
A. Michaela Lobato
BS Systems Engineering and Design | Autonomous Systems and Robotics |
December 2019
MS Systems and Entrepreneurial Engineering | Decision and Control | In
Progress
Email: amlob...@illinois.edu <mailto:amlob...@illinois.edu> | Cell:
(815) 494-
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.contour
On 2/16/21 10:30 AM, Maris Nartiss
wrote:
Hello Dave,
your case is even easier – TIFF and ASC both are raster formats and
thus it is a simple task: import -> contour -> export (skipping all
point cloud related tweaking).
I'd like to just back what Maris already suggested: Try working
directly in GRASS. It does have a somewhat steep learning curve at
the beginning, but if you stick with it, you'll find in the long
run that it pays ("with interest"). You'll be able to perform
complex analyses on multiple maps relatively easily.
For example, if you post the name of the Lidar based elevation
raster that you have, someone on the list will probably help to
format the commands that Maris listed above into a detailed recipe
to get elevation contours.
Create a new location. Either select coordinate system directly or use
one from TIFF file. Import data with r.in.gdal – don't forget to
specify "-e" parameter – it will align the computational region with
the imported raster. Then proceed to use r.contour followed by
v.out.ogr.
In future – do not ask for help with LiDAR but ask for help with
raster data. Otherwise you'll get advices like you got from me – how
to work with point clouds although you are looking for how to work
with ordinary rasters.
Māris.
2021-02-15 22:58 GMT+02:00, Dave Marshall <43carn...@gmail.com>:
Maris,
Many thanks for your detailed reply. My LIDAR files are not in LAS format -
they are a mixture of ASC and TIF.
I spent a long time learning how to use QGIS and don't want to have to
repeat the process with GRASS unless I have to. If there isn't a simple way
to get r.contour to work from within the later versions of QGIS, then I'll
keep on using the old version as the solution requiring the least effort.
>From your comments, it would seem that it is how QGIS imports the LIDAR
data which has changed and this is why I see the problem I reported. I also
realise that QGIS is a global application whereas my work is restricted to
the UK using the Ordnance Survey grid so I can't expect a huge resource to
look at a narrow application.
Cheers,
Dave
On Mon, 15 Feb 2021 at 10:08, Maris Nartiss wrote:
Hello Dave,
QGIS hides a bit of GRASS complexity by making a guess for various
parameters. As with any guess – sometimes it works, sometimes it is a
miss (and user has no idea which is the case).
To get contours out of LAS files:
1) create a location with coordinate system matching one used by LAS
files (be ware – you might need to know it in advance from metadata as
LAS files quite often lack this information);
2) create a mapset for the area of interest (could be whole region or
a single file in case of parallel processing);
3) start GRASS in newly created mapset;
4) set up your computational region (this is most important part!)
with g.region. Don't forget to choose appropriate resolution.
a) if you know the extent in advance (e.g. from a map sheet grid) use
that;
b) if you don't know the extent in advance, use actual extent from the
LAS file. I would advocate to use r.in.lidar -s and set the extent
manually with g.region – you can “snap“ your raster to coordinates.
5) import data with r.in.lidar;
6) run r.contour on the map;
7) export with v.out.ogr to Shapefile (#teamshapefile).
Good luck,
Māris.
P.S. When you wander into area of 66000 LAS files occupying nice 14T
on your disk, only a few adjustments need to be done + a bit of Python
coding + a bit of cluster management :D
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.surf.idw Not Working
I tried with your shapefile, and got no errors. Here are the steps... First I created a new GRASS location matching the CRS of the shapefile: grass -c Coal-Test-Shapefile-main/coal_test.shp /home/micha/GIS/grass/michaela Check the projection: g.proj -p -PROJ_INFO- name : RD/83 / 3-degree Gauss-Kruger zone 5 ellps : bessel proj : tmerc lat_0 : 0 lon_0 : 15 k : 1 x_0: 550 y_0: 0 no_defs: defined -PROJ_EPSG- epsg : 3399 -PROJ_UNITS unit : meter units : meters meters : 1 Then I imported your shapefile, and *set the computational region*: v.import Coal-Test-Shapefile-main/coal_test.shp output=coal_test g.region -ap vect=coal_test # Resolution is 1 meter, 1500x1500 pixels Now run the IDW module v.surf.idw input=coal colu=dbl_1 out=coal_idw_1 81 points loaded Interpolating raster map (1500 rows, 1500 columns)... 100% v.surf.idw complete. Resulting image is attached. You can try other options to v.surf.idw to get a smoother interpolation, if necessary. HTH On Fri, Feb 12, 2021 at 8:35 PM Michaela Lobato wrote: > Hi Markus, > > Here is the information: > > v.info -c map=coal_test@PERMANENT > > INTEGER|cat > INTEGER|cat_ > INTEGER|int_1 > INTEGER|int_2 > DOUBLE PRECISION|dbl_1 > DOUBLE PRECISION|dbl_2 > DOUBLE PRECISION|dbl_3 > DOUBLE PRECISION|dbl_4 > DOUBLE PRECISION|dbl_5 > Displaying column types/names for database connection of layer <1>: > > > v.info -t map=coal_test@PERMANENT > > nodes=0 > points=96 > lines=0 > boundaries=0 > centroids=0 > areas=0 > islands=0 > primitives=96 > map3d=0 > > You can also find the file here > https://github.com/amlobat2/Coal-Test-Shapefile. Let me know if you need > any additional information. > > Best, > Michaela > > > On Fri, Feb 12, 2021 at 3:29 AM Markus Neteler wrote: > >> Hi Michaela, >> >> On Thu, Feb 11, 2021 at 11:47 PM Michaela Lobato >> wrote: >> > >> > Hello, >> > >> > I have recently been struggling with an issue in GRASS. I am a new >> GRASS user and recently downloaded version 7.8.5 for my MacBook (macOS >> Catalina). I converted this sample dataset to a shapefile. >> >> Could you make this shapefile available? Or post the data structure? >> >> # attribute table structure >> v.info -c coal_test >> >> # vector types >> v.info -t coal_test >> >> ? >> >> Best, >> Markus >> > > > -- > A. Michaela Lobato > BS Systems Engineering and Design | Autonomous Systems and Robotics | > December 2019 > MS Systems and Entrepreneurial Engineering | Decision and Control | In > Progress > Email: amlob...@illinois.edu | Cell: (815) 494- > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user > -- Micha Silver Ben Gurion Univ Sde-Boker Remote Sensing Lab cell: +972 (52) 3665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Using Python in GRASS GIS for analysis
Hello On Wed, Feb 3, 2021 at 8:51 AM Omkar Kadlag wrote: > Hello Sir/Ma'am, > > Warm Greetings. > > > Then I made a new environment in the anaconda prompt, where I installed > 'wxpython' and was successfully able to run GRASS GIS software, but now the > issue is I can't use the command prompt for my analysis. Then I tried to > give inputs in the anaconda command prompt but was still unable to get > correct outputs. > > First I think you are mixing up running GRASS commands in python, versus the command prompt. You do not necessarily need python (nor Anaconda) to run GRASS. Everything can be done from the command prompt or using the GRASS GUI. Furthermore, it's a good idea, in my opinion, to begin learning the GRASS modules by running commands at the command prompt, then once you have the details worked out, shift to writing python scripts. > C:\Program Files>r.in.gdal -e > input="D:\NRSC\Month_Jan\ASTGTMV003_N19E073-dem" output=DEM > ERROR: Unable to open datasource > C:\Program Files> > > Here, clearly you did not specify the full file name to the ASTER DEM file. Probably the ".TIF" extension is missing? Can you check and enter the full file name, then get back to the list if you encounter any more problems. I want solutions where I can run GRASS GIS directly from the command line > and implement my solutions on that. > > Yours Sincerely, > Omkar. > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user > -- Micha Silver Ben Gurion Univ Sde-Boker Remote Sensing Lab cell: +972 (52) 3665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.rast.stats error: "Unable to seek"
Hi Luis: On 2/1/21 5:30 PM, Luí s Moreira de Sousa wrote: Hi Micha, thank you for replying. I recreated the PSU layer in another mapset with the default SQLite back-end, v.rast.stats fails with the exact same error. So this is not related to the back-end. Below are the outputs you requested. Thank you. > v.info PSU ++ | Name: PSU | | Mapset: MAL | | Location: S4AHomolosine | | Database: /home/duque004/Work/GRASSDATA | | Title: | | Map scale: 1:1 | | Name of creator: duque004 | | Organization: | | Source date: Fri Jan 29 08:13:08 2021 | | Timestamp (first layer): none | || | Map format: native | || | Type of map: vector (level: 2) | | | | Number of points: 0 Number of centroids: 19468516 | | Number of lines: 0 Number of boundaries: 38945853 | | Number of areas: 19468516 Number of islands: 1 | | | | Map is 3D: No | | Number of dblinks: 1 | | | | Projection: unknown | | | | N: 4289569.27224353 S: -4452930.72775647 | | E: 6679312.25515029 W: -2226387.74484971 | | | | Digitization threshold: 0 | | Comment: | | | ++ > r.info MAL_Mode_5x5 ++ | Map: MAL_Mode_5x5 Date: Thu Jan 28 09:08:14 2021 | | Mapset: MAL Login of Creator: duque004 | | Location: S4AHomolosine | | DataBase: /home/duque004/Work/GRASSDATA | | Title: 5x5 neighborhood: mode of MAL_AFRICA | | Timestamp: none | || | | | Type of Map: raster Number of Categories: 0 | | Data Type: CELL | | Rows: 87425 | | Columns: 89057 | | Total Cells: 7785808225 | | Projection: unknown | | N: 4289569.27224353 S: -4452930.72775647 Res: 100 | | E: 6679312.25515029 W: -2226387.74484971 Res: 100 | | Range of data: min = 0 max = 1 | | | | Data Description: | | generated by r.neighbors | | | | Comments: | | r.neighbors input="MAL_AFRICA" output="MAL_Mode_5x5" method="mode" s\ | | ize=5 | | | ++ So the vector contains about 20 million polygons, and the raster about 8 billion cells. (~=32GB ?) Does you computer have enough muscle for this? -- Luís Sent with ProtonMail <https://protonmail.com> Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, January 29, 2021 3:31 PM, Micha Silver wrote: On Fri, Jan 29, 2021 at 3:53 PM Luís Moreira de Sousa via grass-user mailto:grass-user@lists.osgeo.org>> wrote: Dear all, I am getting the error "Unable to seek" with v.stats.error. There is not much information that could point the cause, just a warning saying that some data base files are not found. I checked the database connection and everything looks in order (see below). Any hints on what may be causing this error? Thank you. > v.rast.stats map=PSU raster=MAL_Mode_5x5 method=number column_prefix=mal ERROR: Unable to seek: Invalid argument ERROR: An error occurred while converting vector to raster WARNING: No data base element files found > db.connect -p driver: pg database: s4a schema: mal group: > psql -d s4a -p 5434 psql (12.5 (Ubuntu 12.5-0ubuntu0.20.04.1)) Type "help" for help. s4a=#
Re: [GRASS-user] compare a DCELL and FCELL question
> | > | > | > | Comments: > | > |r.stats.zonal --overwrite base="str_r" cover="cat1_acc_riv" method="\ > | > |min" output="cat1_minacc" > | > | > | > > ++ > (Sun Jan 24 04:46:50 2021) Command finished (0 sec) > > Thanks > Ming > > > Micha Silver 于2021年1月24日周日 上午3:29写道： >> >> Is there some reason that you expect the rasters to be the same? Maybe >> begin by posting the outputs of `r.info` for both rasters, and what >> command you used to compare them? >> >> On Sun, Jan 24, 2021 at 6:13 AM ming han wrote: >> > >> > Hi Everyone >> > >> > I tried to compare if grids in two rasters are the same, one raster is >> > FCELL and another raster is DCELL. I got different result when I int both >> > raster first before comparing them; and when I float() both raster first >> > before I comparing them >> > >> > Is there any reason for this? >> > >> > Thanks >> > Ming >> > ___ >> > grass-user mailing list >> > grass-user@lists.osgeo.org >> > https://lists.osgeo.org/mailman/listinfo/grass-user >> >> >> >> -- >> Micha Silver >> Ben Gurion Univ >> Sde-Boker Remote Sensing Lab >> cell: +972 (52) 3665918 -- Micha Silver Ben Gurion Univ Sde-Boker Remote Sensing Lab cell: +972 (52) 3665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] compare a DCELL and FCELL question
Is there some reason that you expect the rasters to be the same? Maybe begin by posting the outputs of `r.info` for both rasters, and what command you used to compare them? On Sun, Jan 24, 2021 at 6:13 AM ming han wrote: > > Hi Everyone > > I tried to compare if grids in two rasters are the same, one raster is > FCELL and another raster is DCELL. I got different result when I int both > raster first before comparing them; and when I float() both raster first > before I comparing them > > Is there any reason for this? > > Thanks > Ming > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ Sde-Boker Remote Sensing Lab cell: +972 (52) 3665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Export data from scatter plot ROI
Hi: The interactive supervised classification allows you to draw, by hand, polygons covering pixels of classes that you want to use in your classification. The scatterplot preview, like the histogram, is just for understanding how correlated two specific bands are, for use in preparing those polygon training areas. Once you have prepared the polygon classes, you can save that vector to GRASS (the "Export training areas to map" button), then you run the (first step) in the classification process: creating the signature file. After the process finishes You must save the signature file (the next button on the toolbar) for use as input to the i.maxlik module (second step) to actually do the classification. So it's not clear what you "want to export from ROI"? Perhaps if you explain what is your final goal, it might be easier for someone to help. There's plenty of documentation on image classification that explains the procedure, for example, did you find this wiki page: https://grasswiki.osgeo.org/wiki/Image_classification On 1/4/21 7:00 AM, mega saputra wrote: Hello guys, I create ROI from scatter plot using Interactive input for supervised classification. I want to export data from ROI. But, I don't find the menu or tool in Grass. Could someone tell me the tool or menu in Grass? Regards, mega ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Can GRASS create color table in16 bit?
On 1/2/21 9:13 AM, mega saputra wrote: Dear all, I try to create color table in 16 bit. That is in attachment. But, when I set color table interactively, then I input that file (in attachment), then I click Load. There is a message : "Invalid color table format". Do I missing something? I think you have the categories and colors backwards. RGB color tables are (throughout all GIS and image software) always three 8 bit numbers, with optionally a fourth alpha band, also 8 bit. In your rules file you attach raster values (16 bit numbers in your case) to certain RGB values. So, To define a color table for your raster you put the raster values in the left column and R:G:B (0-255) combinations in the right column. Here's an example of the srtm (elevation) builtin color table. Maybe you can use it as a template. -11000 0:0:0 -500 0:0:10 -300 0:0:20 -200 0:0:70 -100 0:0:130 -50 0:0:205 0 100:128:255 0.1 57:151:105 100 117:194:93 200 230:230:128 500 202:158:75 1000 214:187:98 2000 185:154:100 3000 220:220:220 5000 250:250:250 8850 255:255:255 nv 255:255:255 default 255:255:255 It spans the range of elevations from sea bottom (-11000 m) to the peak of the Himalaya Mts. (8850 m) HTH Thank you. Regards, mega ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] else if in GRASS GIS
On 1/1/21 3:25 PM, mega saputra wrote: Hello guys, I try to create conditional statement. When I running the formula in GRASS, there is error. Can someone help me to convert in GRASS formula format. The formula is something like : if ( rgb.1 > 1810.88) and ( rgb.1 < 23442.12 ) and (rgb.2 > 673.148594) and (rgb.2 < 22729.389558) then 0 else if rgb.1 = 0 then 255 else 100 I have try, but with error. My false formula : r.mapcalc --overwrite _expression_=awan = if ( rgb.1 > 1810.88 & rgb.1 < 23442.12 & rgb.2 > 673.148594 & rgb.2 < 22729.389558 , 0) else if ( rgb.1 = 0, 255, 100) There is no "else" in mapcalc. You put the else _expression_ after the second comma. Should be: r.mapcalc --o "awan = if(rgb.1 > 1810.88 && rgb.1 < 23442.12 && rgb.2 > 673.148594 & rgb.2 < 22729.389558 , 0, if(rgb.1 = 0, 255, 100)) syntax error, unexpected NAME, expecting $end Parse error ERROR: parse error Any suggestion? Regards, mega ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Scatter plot cannot be added in interactive scatter plot
On 12/29/20 3:05 AM, mega saputra
wrote:
Hello guys,
I have tried to add (passive) scatter plot with my data,
and it is succeed.
But, I want to add in interactive scatter plot, and not
succeed. The message :
"Scatter plot cannot be added. Multiple of bands ranges
is higher than maximum limit <1681> "
So, how to add in interactive scatter plot?
Here attached is the result I get using the interactive
scatterplot tool and choosing bands 3 and 5 in your rgb image.
My data in : https://1drv.ms/u/s!AjXAWS5maHffhyH0q9oTos1umy3D?e=bKa7mX
regards,
mega
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Scatter plot cannot be added
On 12/28/2020 1:38 AM, mega saputra wrote: Here is the output : g.proj -p . But, there is no scatter plot in Map Display. Then I click twice in vector > scatter_1_3 in Data tab. Then there is a message : "Unable to zoom to vector map Details: Illegal latitude for North: 65528" Yes, that's correct. You need to understand how r.scatterplot works. The X-Y coordinates in the newly created point vector layer are the raster values at each pixel of the original rasters. In this case, since the original are color bands, the values represent reflectance for each band. These values can go as high as 65528, which is way beyond the range in a latitude/longitude coordinate system (maximum long/lat of 360 X 180). If you want to carry on with this (in your next mail you are beginning with the interactive scatter plot), it might be helpful to export the X-Y "coordinates" to a text file for plotting in some other software. Just keep in mind that you will get a list of 12,000,000 rows with two columns of numbers-the reflectances of both bands. How to solve the problem? Regards, mega On Sun, Dec 27, 2020 at 3:22 PM Micha Silver <tsvi...@gmail.com> wrote: Here's my attempt: I downloaded the rgb.tif that you linked to, then used it to create a new, fresh location # Create a NEW location "mega" using the georeferenced rgb.tif file to define location # and import the file # Run at the command line, *before* starting grass: grass78 -c rgb.tif /home/micha/grass/mega # Now at the grass prompt: # Check projection settings g.proj -p -PROJ_INFO- name : WGS 84 datum : wgs84 ellps : wgs84 proj : ll no_defs : defined -PROJ_EPSG- epsg : 4326 -PROJ_UNITS unit : degree units : degrees meters : 1.0 # Install the scatterplot extension g.extension r.scatterplot Downloading precompiled GRASS Addons ... Updating extensions metadata file... Updating extension modules metadata file... Installation of successfully finished # Now run r.scatterplot on two bands r.scatterplot input=rgb.3,rgb.2 output=scatter_3_2 100% Building topology for vector map ... Registering primitives... 1183 # Almost 12 million points (!) The X-Y coordinates of the points are the scatterplot values. HTH, Micha On 12/26/2020 11:40 PM, mega saputra wrote: The result is the same. It cannot add scatterplot. Here is the output : (Sun Dec 27 05:20:25 2020) g.region -ap raster=rgb.1 projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 13:07:42.9N south: 27:38:15.5S west: 100:55:15.7E east: 131:15:38.1E nsres: 0:00:36.8 ewres: 0:00:36.8 rows: 3988 cols: 2968 cells: 11836384 (Sun Dec 27 05:20:25 2020) Command finished (0 sec) G__open(read): Unable to open '/home/mega/newLocation/PERMAN ENT/.tmp/mega/
Re: [GRASS-user] Scatter plot cannot be added
Here's my attempt:
I downloaded the rgb.tif that you linked to, then used it to
create a new, fresh location
# Create a NEW location "mega" using the georeferenced rgb.tif
file to define location
# and import the file
# Run at the command line, *before* starting grass:
grass78 -c rgb.tif /home/micha/grass/mega
# Now at the grass prompt:
# Check projection settings
g.proj -p
-PROJ_INFO-
name : WGS 84
datum : wgs84
ellps : wgs84
proj : ll
no_defs : defined
-PROJ_EPSG-
epsg : 4326
-PROJ_UNITS
unit : degree
units : degrees
meters : 1.0
# Install the scatterplot extension
g.extension r.scatterplot
Downloading precompiled GRASS Addons ...
Updating extensions metadata file...
Updating extension modules metadata file...
Installation of successfully finished
# Now run r.scatterplot on two bands
r.scatterplot input=rgb.3,rgb.2 output=scatter_3_2
100%
Building topology for vector map ...
Registering primitives...
1183
# Almost 12 million points (!)
The X-Y coordinates of the points are
the scatterplot values.
HTH,
Micha
On 12/26/2020 11:40 PM, mega saputra
wrote:
The result is the same. It cannot add scatterplot.
Here is the output :
(Sun Dec 27 05:20:25 2020)
g.region -ap raster=rgb.1
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 13:07:42.9N
south: 27:38:15.5S
west: 100:55:15.7E
east: 131:15:38.1E
nsres: 0:00:36.8
ewres: 0:00:36.8
rows: 3988
cols: 2968
cells: 11836384
(Sun Dec 27 05:20:25 2020) Command finished (0 sec)
G__open(read): Unable to open '/home/mega/newLocation/PERMAN
ENT/.tmp/mega/vector/trAreas54950/frmt': No such file or
directory
If you want to try my data, my data is in : https://1drv.ms/u/s!AjXAWS5maHffhyH0q9oTos1umy3D?e=bKa7mX
Thank you.
regards,
mega
On Sat, Dec 26, 2020 at 9:39
PM Micha Silver <tsvi...@gmail.com> wrote:
On 12/25/20 11:46 PM, mega saputra wrote:
> Sorry, there is holiday.
>
> I import the raster. Then set the region. This is my
syntax :
>
> g.region -up raster=rgb.1
The "-u" flag does not set the current computational region to
your
raster. It just reports what would happen if you do reset the
region.
Please try:
g.region -ap rast=rgb.1
and report back the output.
> projection: 3 (Latitude-Longitude)
> zone: 0
> datum: wgs84
> ellipsoid: wgs84
> north: 13:07:42.9N
> south: 27:38:15.5S
> west: 100:55:15.7E
> east: 131:15:38.1E
> nsres: 0:00:36.8
> ewres: 0:00:36.8
> rows: 3988
> cols: 2968
> cells: 11836384
> (Sat Dec 26 05:24:05 2020) Command finished (0 sec)
>
> Then, from menu Imagery > Classify image >
Interactive input for
> supervised classification. Then the output is like this :
>
> G__open(read): Unable to open
'/home/mega/newLocation/PERMAN
> ENT/.tmp/mega/vector/trAreas114130/frmt': No such file or
> directory
>
> I don't know why there is that message.
> Then in Plots Menu, I choose Scatter Plots. I click Add
scatter plot.
> In the Name of imagery group, I choose the raster. In the
Name of
> imagery subgroup, I type the name. I click Create/edit
group. In x and
> y axis, I choose a band. I click Add. Then there is a
m
Re: [GRASS-user] Scatter plot cannot be added
On 12/25/20 11:46 PM, mega saputra wrote: Sorry, there is holiday. I import the raster. Then set the region. This is my syntax : g.region -up raster=rgb.1 The "-u" flag does not set the current computational region to your raster. It just reports what would happen if you do reset the region. Please try: g.region -ap rast=rgb.1 and report back the output. projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 13:07:42.9N south: 27:38:15.5S west: 100:55:15.7E east: 131:15:38.1E nsres: 0:00:36.8 ewres: 0:00:36.8 rows: 3988 cols: 2968 cells: 11836384 (Sat Dec 26 05:24:05 2020) Command finished (0 sec) Then, from menu Imagery > Classify image > Interactive input for supervised classification. Then the output is like this : G__open(read): Unable to open '/home/mega/newLocation/PERMAN ENT/.tmp/mega/vector/trAreas114130/frmt': No such file or directory I don't know why there is that message. Then in Plots Menu, I choose Scatter Plots. I click Add scatter plot. In the Name of imagery group, I choose the raster. In the Name of imagery subgroup, I type the name. I click Create/edit group. In x and y axis, I choose a band. I click Add. Then there is a message that : "Scatter plot cannot be added. Multiple of bands ranges x53.1@PERMANENT:65529 = 4294049841 > is higher than maximum limit <1681> " In this case, I have defined the region. Thank you for your attention. Regards, mega On Wed, Dec 23, 2020 at 4:30 PM Micha Silver <mailto:tsvi...@gmail.com>> wrote: On 12/23/20 5:09 AM, mega saputra wrote: > Hello guys, > > I have MODIS data. It is sixteen bit unsigned integer. When I want to > add scatter plot, there is a warning : > > "Scatter plot cannot be added. > Multiple of bands ranges x53.1@PERMANENT:65529 = 4294049841 > is higher than maximum limit > <1681> " Please post your computation region (i.e. the output of g.region -p) and the command you used. > > So, how to make big maximum limit on Grass GIS, so that I can add > scatter plot of MODIS data? > > Regards, > mega > > ___ > grass-user mailing list > grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org> > https://lists.osgeo.org/mailman/listinfo/grass-user <https://lists.osgeo.org/mailman/listinfo/grass-user> -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Scatter plot cannot be added
On 12/23/20 5:09 AM, mega saputra wrote: Hello guys, I have MODIS data. It is sixteen bit unsigned integer. When I want to add scatter plot, there is a warning : "Scatter plot cannot be added. Multiple of bands ranges x53.1@PERMANENT:65529 = 4294049841 > is higher than maximum limit <1681> " Please post your computation region (i.e. the output of g.region -p) and the command you used. So, how to make big maximum limit on Grass GIS, so that I can add scatter plot of MODIS data? Regards, mega ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Add-Ons and batch job with the --exec interface
On 12/20/20 1:01 PM, Vincent Bain wrote: Hi dear Grass users, I'm wondering how/if one can run an Add-On command while invoking grass from the --exec interface. As an example, if I run : grass79 /path/to/my/location/mapset --exec g.list rast I succeed. As well as checking my GRASS_ADDON_PATH : Maybe it should be GRASS_ADDON_BASE. micha@RMS:~$ env | grep ADDON GRASS_ADDON_BASE=/home/micha/.grass7/addons/ Now before initializing GRASS: micha@RMS:~$ export GRASS_ADDON_BASE=/home/micha/.grass7/addons/ micha@RMS:~$ grass /home/micha/GIS/grass/ITM/Arava/ --exec r.stream.order Starting GRASS GIS... Cleaning up temporary files... Executing ... Calculates Strahler's and more streams hierarchy. Usage: r.stream.order [-zma] stream_rast=name direction=name [elevation=name] [accumulation=name] [stream_vect=name] [strahler=name] [horton=name] [shreve=name] [hack=name] [topo=name] [memory=value] [--overwrite] [--help] [--verbose] [--quiet] [--ui] Flags: -z Create zero-valued background instead of NULL -m Use memory swap (operation is slow) -a Use flow accumulation to trace horton and hack models Parameters: stream_rast Name of input raster map with stream network direction Name of input flow direction raster map elevation Name of input elevation raster map accumulation Name of input accumulation raster map stream_vect Name for output vector map to write stream attributes strahler Name for output Strahler's stream order raster map horton Name for output original Hortons's stream order raster map shreve Name for output Shereve's stream magnitude raster map hack Name for output Hack's streams or Gravelius stream hierarchy raster map topo Name for output topological dimension of streams raster map memory Max memory used in memory swap mode (MB) default: 300 Execution of finished. Cleaning up default sqlite database ... Cleaning up temporary files... echo $GRASS_ADDON_PATH /usr/local/grass-addons/ But : grass79 /path/to/my/location/mapset --exec r.my.addon fails : [Errno 2] No such file or directory: 'r.my.addon': 'r.my.addon' Exiting... Would anyone help me solve this issue ? Have a nice sunday, Vincent. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] More Fun Compiling & Installing GRASS on CentOS 8
I fully agree. There is no (obvious) point for me to have a separate "gdal-config64" script. Please check from which RPM it originates, with rpm -qf /usr/bin/gdal-config64 ? But honestly, I am getting lost with Centos. That's why we abandoned it earlier this year (which was an attempt after 10 years of Scientific Linux on our HPC infrastructure). However, I have good experience with Fedora and Ubuntu. Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to obtain list of all raster maps
You can use the grass.script module 'read_command' to save the output of
commands. i.e.
In [1]: import grass.script as gscript
In [2]: rast_list = gscript.read_command('g.list', type='rast',
mapset="shkharia").strip().split('\n')
In [3]: type(rast_list)
Out[4]: list
In [5]: rast_list
Out[6]: ['aspect_4m', 'dtm_08_4m', 'dtm_4m', 'geomorph', 'shade_4m',
'slope_4m']
Typically the output will be a string (or dict), but calling split('\n')
breaks it into a list.
On 12/12/20 1:07 PM, BHARATH RAM wrote:
Hello,
I have a list of raster files inside a mapset that I need to
interpolate to a different size. I am aware of the command *g.list
type='raster' mapset='.'*
and its equivalent python version. But the command prints the
filenames out on screen instead of returning it as a list (I am
talking wrt python API).
Am I missing something or is there any workaround for this?
Thank you.
Regards,
Bharath.
*Disclaimer: *This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email in
error please notify the system manager. This message contains
confidential information and is intended only for the individual
named. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this
e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action
in reliance on the contents of this information is strictly prohibited.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Research: Help improve the special mode for first-time users in GRASS GIS
Hi Linda
Thanks for your great work on the new first-time
use interface.
(I'd rather not logon to survey monkey, so I'm
responding directly)
A point regarding choosing Location is still not
clear: After startup and automatically going to the last used
Location, if I want to switch to another Location, I go to the
"Settings=>GRASS Working Environment" menu. There are now
three options that seem to be redundant: "Change working
environment:, "Change mapset", and "Change location and mapset".
If I choose the first (i.e. g.mapset) then:
The GUI does not reflect this change (original Location stays
Bold)
I can no longer load layers from the original
mapset, as expected.
but I can not load layers from the new mapset
thru the Data panel ("map is in different projection")
Perhaps this should be removed from the GUI.
(A user working on the CLI, running g.mapset, would probably
know what she's doing)
The options "Change location and mapset" or
"Change mapset" work as I expect.
But maybe these two could be merged to make
these changes more clear, unified.
Another point I notice: The warning "Move or copy
mapset isn't allowed" seems to popup often, when it's not
obvious what I did to cause that warning message.
Kind regards,
Micha
On 11/26/20 3:25 PM, L.Kladivova wrote:
Hello guys!
We created a new survey that presents the
proposal of a special mode for first-time users. :-)
This proposal was made based on your
responses from the survey "Help
create a better first-time user experience in GRASS
GIS" that we took about one month ago. :-)
The
survey is available here:
https://www.surveymonkey.com/r/DNC3HP2
and will be available until Monday 30
November.
Anyone is welcome to take part in the survey -
does not matter if a beginner or advanced user of GRASS
GIS.
We are looking forward to your responses!
:-)
Best,
Linda Kladivova
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
https://orcid.org/-0002-1128-1325
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass python problem
On 11/17/20 6:03 AM, ming han wrote:
Hi Everyone
Hope this email finds you well.
I can run r.cross in console with following command:
"r.cross -z --overwrite --quiet
input=Connect_Lake@PERMANENT,str_grass_r@PERMANENT
output=test"
But I got error by run r.cross in python with following
command:
grass.run_command('r.cross', input =
['str_grass_r@PERMANENT','Connect_Lake@PERMANENT'],output =
'test', quiet = True)
What is the correct format to use r.cross function in
Python? and how to obtain the output table generated by
r.cross?
This worked fine for me also, using GRASS 7.8.4
in the nc_basin_spm LOCATION:
In [2]: import grass.script as gscript
In [3]: gscript.run_command("r.cross",
input=["landuse@PERMANENT","basins@PERMANENT"], output="lu_bas",
overwrite=True)
r.cross: STEP 1 ...
100%
r.cross: STEP 2 ...
r.cross: STEP 3 ...
100%
Creating support files for ...
89 categories
Out[3]: 0
Just to be clear, you do not get a table output,
rather a raster. In your case you should see a new raster
"test".
Thanks
Ming
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Clarifying use of postgres/postgis
On 15/08/2020 16:22, Dheeraj Chand
wrote:
‘’’
When importing a shapefile or
other vector data, only the attrib tables get saved to some
database: sqlite by default, or PostgrSQL if you have
configured for that backend. But the geometry is still kept in
the GRASS vector format.
‘’’
1. How would one configure
that? Please assume that I am unfamiliar and uncomfortable
with GRASS when explaining, but able to read Java and Python
man pages with ease, also comfortable with PSQL and PostGIS.
In that case you might want to first go thru some tutorials on
using GRASS. We're here to help if encounter anything that is
unclear, or not working as you expected.
All GRASS commands can be called thru the GRASS-python bindings,
so that might be easiest for you. But do go into the beginning
tutorials first.
The GRASS module that sets the backend database connection is
`db.connect`. Have a look at the man page:
https://grass.osgeo.org/grass78/manuals/db.connect.html
You would choose the driver parameter as "pg", then set the
database and schema as required. This comes after running
`db.login` one time to save your DB auth credentials.
2. Would we get all the
speed benefits of PSQL, would it be used for computations
whenever possible?
Not sure how to answer here. GRASS in general sends SQL commands
back to the DB backend for any undates. If, for example, you had a
point vector of cities, with two columns "population" and
"number_hospitals" in the attribute table, and you wanted to
calculate number of hospitals per 1000 people, then you would
construct a regular SQL query that would be sent to the backend.
So I guess that the speed would be determined by PostgreSQL.
3. Is there a way to easily
move from GRASS and PSQL geometry and topology models when
doing this?
Sorry to repeat again: GRASS maintains all geometry (and
topology) within its own internal vector data structure. NO
PostGIS involved here. But You could easily export GRASS vectors
to a PostGIS database using the `v.out.postgis` module.
https://grass.osgeo.org/grass78/manuals/v.out.postgis.html
To pull a PostGIS vector table into GRASS would require either
`v.in.ogr` or `v.import`
Sent from my iPhone
On Aug 15, 2020, at 7:50 AM, Rich
Shepard wrote:
On Sat, 15 Aug 2020, Micha Silver wrote:
But again, don't confuse -
this is NOT PostGIS, and GRASS does not
need/use PostGIS for geometry.
GRASS geometry is always independent of any
external geospatial format.
Micha,
Thanks for clarifying; I must have mis-understood what
I read. I assumed the
geometry was kept by GRASS and didn't know why PostGIS
was mentioned ... and
I don't recall just where I read all this.
It's the other way around:
When you export GRASS map layers, you can, as
you know, choose to save out
to several formats: shp, Geopackage (the
current default) or to
PostGIS. PostGIS is the best choice when you need
multiuser access to the
geospatial data. But you point out that you're the
only user, so why would you
need the overhead of PostGIS?
Ah, so. I don't.
To repeat, you can set the
default for saving attribute tables to
PostgreSQL, but do not try to
save a GRASS layer to PostGIS in the same
database! That will definitely
lead to trouble. If you want/need a PostGIS
instance for some reason
independent of GRASS, then keep it totally
separated from GRASS. i.e. at
least in a separate schema or even separate
database.
No, I want the attribute data in postgres so I need to
learn to make that
the default.
The main reasons for choosing
PostgreSQL as your database backend would be
1. to allow fancy SQL queries
Re: [GRASS-user] Clarifying use of postgres/postgis
Hi Rich On 8/14/20 5:41 PM, Rich Shepard wrote: I'm starting a large project and want all data (geometric and attributes) to be stored in a new postgres database I just created: washington_state. Both postgresql-12.2 and postgis-3.0.1 are installed. To be clear from the start, GRASS *always* stores geometry in its own database structure. The attributes can be stored in a number of ways: back in GRASS 6.x days, attrib tables were kept in the old dbf format. Since 7.x, sqlite is the default file format for attrib tables. You can alternatively choose to save your attribute tables to PostgreSQL (db.connect...). But again, don't confuse - this is NOT PostGIS, and GRASS does not need/use PostGIS for geometry. GRASS geometry is always independent of any external geospatial format. All my previous work has used the default GRASS database so I've read the manual page, PostgreSQL DATABASE DRIVER, and I'm still unsure how to proceed. I'm the only postgres user so I access all my databases without entering a username or password. When I start a grass session, create a new location, and mapset then want to import .shp or .gdb files how do I specify using the postgres/postgis database I just created? When do I use PostGIS with shp2pgsql? It's the other way around: When you export GRASS map layers, you can, as you know, choose to save out to several formats: shp, Geopackage (the current default) or to PostGIS. PostGIS is the best choice when you need multiuser access to the geospatial data. But you point out that you're the only user, so why would you need the overhead of PostGIS? When importing a shapefile or other vector data, only the attrib tables get saved to some database: sqlite by default, or PostgrSQL if you have configured for that backend. But the geometry is still kept in the GRASS vector format. Since I've used the db.* modules before I'm familiar with them. What I need to learn is how to expand my grass experiences to using post* as the databases rather than the defaults. To repeat, you can set the default for saving attribute tables to PostgreSQL, but do not try to save a GRASS layer to PostGIS in the same database! That will definitely lead to trouble. If you want/need a PostGIS instance for some reason independent of GRASS, then keep it totally separated from GRASS. i.e. at least in a separate schema or even separate database. The main reasons for choosing PostgreSQL as your database backend would be 1. to allow fancy SQL queries on the database tables 2. huge, complex data tables or triggers 3. multiuser access to the attribute tables But keep in mind that the default sqlite database is quite powerful, and you would have to look very deeply to find a PostgreSQL feature that is missing in sqlite. Best regards, Micha A pointer to other docs would be great. Regards, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [R] Need help using GRASS within R - error when running the script for a second time
Hello Loïc
Let's keep the discussion on the list, so others can help and
benefit from responses.
BTW, you might want to post to the r-sig-geo list also. If you
come across questions specific to R and spatial functions, that's
the best place to ask.
Below,inline, some guesses as to what is happening...
On 07/07/2020 0:03, Loïc Valéry wrote:
Dear Micha,
As you expected, I should have kept a few thanks in stock ! ;-) because I have a new little problem with rgrass7 !
In fact, when I run the script that you kindly corrected me (as a reminder, our exchange of previous emails is below) , everything goes fine...the first time. If I run the script a second time, I get an error message from Windows and another one from R (see below).
For the script to work properly again I have to close and open R (or use the .rs.rstartR() command from RStudio) which is not very convenient because it stops the script.
I tried to fix this error but without success. That's why I'm contacting you, hoping you will have an idea on how to "reset" rgrass7 without having to restart a new session.
I thank you in advance for your answer and remain at your disposal if you need additional information to find the solution.
Kind regards,
Loïc
ERRORS WHEN I RUN THE SCRIPT FOR A SECOND TIME :
- FROM WINDOWS : g.region.exe : the procedure entry point GEOSMakeValid_r could not be located in the dynamic link library C:\Program Files\GRASS GIS 7.8\extrabin\gdal300.dll
- FROM R :
# Link to GRASS GIS software v.7.8.3
initGRASS(gisBase ="C:/Program Files/GRASS GIS 7.8",
+ home="temp/GRASS_tmp", use_g.dirseps.exe=F,
+ gisDbase="temp/GRASS_tmp", mapset="PERMANENT",
+ remove_GISRC=T, override=T)
Error in if (is.na(projstr)) uprojargs <- projstr else uprojargs <- paste(unique(unlist(strsplit(projstr, :
l'argument est de longueur nulle
De plus : There were 50 or more warnings (use warnings() to see the first 50)
I'm not sure, but I don't think you want to rerun initGRASS()
a second time. In your script, you do initGRASS only once,
then if you need to perform several analyses, do them in the same
(running) GRASS session.
# Specifying the projection reference for the GRASS working environment
p4str<-sp::proj4string(seg_poly)
Warning message:
In sp::proj4string(seg_poly) :
CRS object has comment, which is lost in output
execGRASS("g.proj", flags = "c", proj4 = p4str)
rgrass7::use_sp()
# Converting the 'sp' object into a GRASS-readable file format (here, 'vec1.shp')
writeVECT(seg_poly,"vec1",v.in.ogr_flags=c("o", "overwrite"),
+ driver="ESRI Shapefile")
The driver name is "ESRI_Shapefile" (note the underscore).
Perhaps that is the problem here?
Error in writeVECT(seg_poly, "vec1", v.in.ogr_flags = c("o", "overwrite"), :
driver %in% candDrivers is not TRUE
De plus : Warning message:
In system(syscmd, intern = intern, ignore.stderr = ignore.stderr, :
l'exécution de la commande 'v.in.ogr.exe -f' renvoie un statut 313
# Run the 'v.generalize' function
execGRASS("v.generalize",flag=c("overwrite"),
+ parameters=list(input="vec1",
+ output="GRASS_smooth_seg_poly",
+ error="GRASS_smooth_seg_poly_error",
+ method="distance_weighting",
+ threshold=1))
# Converting the shapefile 'GRASS_smooth_seg_poly.shp' into a R-readable object
# (here, a SpatialPolygonDataFrame named 'smooth_seg_poly')
smooth_seg_poly<-readVECT("GRASS_smooth_seg_poly", with_prj=T,
+ driver="ESRI Shapefile")
Same here, the driver name for shapefile is wrong.
I would also add that both R and GRASS have switched to the
better Geopackage format for exchanging spatial data. You might
want to try, the driver name is "GPKG"
See details about Geopackage here:
https://www.gis-blog.com/geopackage-vs-shapefile/
and in French here:
https://www.sigterritoires.fr/index.php/le-format-geopackage-et-qgis-3/
Best, Micha
Error in .read_vect_non_plugin(vname = vname, layer = layer, type = type, :
driver %in% candDrivers is not TRUE
De pl
Re: [GRASS-user] Question about Datum not recognised by GRASS
On 03/07/2020 12:33, 李泽浩 wrote:
Thanks for your advice! But I fail to run the "
grass -c
" code in the GRASS console. Is it should be run elsewhere?
(Keeping the thread on the list)
Sorry, you need to run the grass -c command *outside of grass*,
at the regular command prompt (OSGeo2W shell if you installed from
OSGeo4W)
Micha Silver <tsvi...@gmail.com>
于2020年7月3日周五 下午5:07写道：
On 03/07/2020 11:53, 李泽浩 wrote:
Hi Micha,
Thanks for your reply! Here is the output from gdalinfo:
This DEM is projected from WGS84 to CGCS 2000 in
ArcMap first and then imported in GRASS.
gdalinfo
C:\Users\zhangtong\Desktop\Zehao_DEM.tif
Driver: GTiff/GeoTIFF
Files: C:\Users\zhangtong\Desktop\Zehao_DEM.tif
Size is 3353, 1748
Coordinate System is:
PROJCS["CGCS2000_3_Degree_GK_CM_120E",
GEOGCS["GCS_China_Geodetic_Coordinate_System_2000",
DATUM["China_2000",
SPHEROID["CGCS2000",6378137,298.257222101]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",120],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",50],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (118.6708334,42.9966670)
Pixel Size = (0.0008333,-0.0008333)
Metadata:
AREA_OR_POINT=Area
DataType=Generic
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 118.6708333, 42.997)
(115d30'50.80"E, 0d 0' 1.40"N)
Lower Left ( 118.6708333, 41.540)
(115d30'50.80"E, 0d 0' 1.35"N)
Upper Right ( 121.465, 42.997)
(115d30'50.89"E, 0d 0' 1.40"N)
Lower Right ( 121.465, 41.540)
(115d30'50.89"E, 0d 0' 1.35"N)
Center ( 120.0679167, 42.268)
(115d30'50.84"E, 0d 0' 1.37"N)
Band 1 Block=128x128 Type=Int16, ColorInterp=Gray
NoData Value=32767
OK, that looks
good.
Now you can create
a new LOCATION for your GRASS data using that DEM
projection information as follows:
(I'll assume you
want your GRASS database under: C:\Users\zhangtong\grassdata)
grass -c C:\Users\zhangtong\Desktop\Zehao_DEM.tif -e
C:\Users\zhangtong\grassdata\CGCS2000\PERMANENT
THis command creates a new LOCATION based on the DEM
coordinate system, then exits (-e option).
Now start GRASS in that new location and you should be
able to import your DEM without problem:
grass C:\Users\zhangtong\grassdata\CGCS2000\PERMANENT
and then at the GRASS command prompt:
r.import C:\Users\zhangtong\Desktop\Zehao_DEM.tif
output=zehao_dem
g.region -ap rast=zehao_dem
Zac
Micha Silver <tsvi...@gmail.com>
于2020年7月3日周五 下午4:43写道：
On 02/07/2020 20:58, Zac45 wrote:
Re: [GRASS-user] Question about Datum not recognised by GRASS
On 03/07/2020 11:53, 李泽浩 wrote: Hi Micha, Thanks for your reply! Here is the output from gdalinfo: This DEM is projected from WGS84 to CGCS 2000 in ArcMap first and then imported in GRASS. gdalinfo C:\Users\zhangtong\Desktop\Zehao_DEM.tif Driver: GTiff/GeoTIFF Files: C:\Users\zhangtong\Desktop\Zehao_DEM.tif Size is 3353, 1748 Coordinate System is: PROJCS["CGCS2000_3_Degree_GK_CM_120E", GEOGCS["GCS_China_Geodetic_Coordinate_System_2000", DATUM["China_2000", SPHEROID["CGCS2000",6378137,298.257222101]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",120], PARAMETER["scale_factor",1], PARAMETER["false_easting",50], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]]] Origin = (118.6708334,42.9966670) Pixel Size = (0.0008333,-0.0008333) Metadata: AREA_OR_POINT=Area DataType=Generic Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 118.6708333, 42.997) (115d30'50.80"E, 0d 0' 1.40"N) Lower Left ( 118.6708333, 41.540) (115d30'50.80"E, 0d 0' 1.35"N) Upper Right ( 121.465, 42.997) (115d30'50.89"E, 0d 0' 1.40"N) Lower Right ( 121.465, 41.540) (115d30'50.89"E, 0d 0' 1.35"N) Center ( 120.0679167, 42.268) (115d30'50.84"E, 0d 0' 1.37"N) Band 1 Block=128x128 Type=Int16, ColorInterp=Gray NoData Value=32767 OK, that looks good. Now you can create a new LOCATION for your GRASS data using that DEM projection information as follows: (I'll assume you want your GRASS database under: C:\Users\zhangtong\grassdata) grass -c C:\Users\zhangtong\Desktop\Zehao_DEM.tif -e C:\Users\zhangtong\grassdata\CGCS2000\PERMANENT THis command creates a new LOCATION based on the DEM coordinate system, then exits (-e option). Now start GRASS in that new location and you should be able to import your DEM without problem: grass C:\Users\zhangtong\grassdata\CGCS2000\PERMANENT and then at the GRASS command prompt: r.import C:\Users\zhangtong\Desktop\Zehao_DEM.tif output=zehao_dem g.region -ap rast=zehao_dem Zac Micha Silver <tsvi...@gmail.com> 于2020年7月3日周五 下午4:43写道： On 02/07/2020 20:58, Zac45 wrote: Hi, I am quite new to GRASS and this is my first post, looking for some help here! Welcome I am now processing the dataset under *CGCS2000 / 3-degree Gauss-Kruger CM 120E*. But the dataset could not be recognised by GRASS when I trying to import the DEM data. The warning message kept poping up: Can you show the CRS of your original DEM before import into GRASS. What's the output from: gdalinfo ? WARNING: Datum not recognised by GRASS and no parameters found And the output from g.region -p is: projection: 99 (CGCS2000 / 3-degree Gauss-Kruger CM 120E) zone: 0 datum: ** unknown (default: WGS84) ** ellipsoid: grs80 north: 1 south: 0 west: 0 east: 1 nsres: 1 ewres: 1 rows: 1 cols: 1 cells: 1 How can I fix it? Best, Zac45 -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 https://orcid.org/-0002-1128-1325 -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cel
Re: [GRASS-user] Question about Datum not recognised by GRASS
On 02/07/2020 20:58, Zac45 wrote: Hi, I am quite new to GRASS and this is my first post, looking for some help here! Welcome I am now processing the dataset under *CGCS2000 / 3-degree Gauss-Kruger CM 120E*. But the dataset could not be recognised by GRASS when I trying to import the DEM data. The warning message kept poping up: Can you show the CRS of your original DEM before import into GRASS. What's the output from: gdalinfo ? WARNING: Datum not recognised by GRASS and no parameters found And the output from g.region -p is: projection: 99 (CGCS2000 / 3-degree Gauss-Kruger CM 120E) zone: 0 datum: ** unknown (default: WGS84) ** ellipsoid: grs80 north: 1 south: 0 west: 0 east: 1 nsres: 1 ewres: 1 rows: 1 cols: 1 cells: 1 How can I fix it? Best, Zac45 -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 https://orcid.org/-0002-1128-1325 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.what.rast - solved
On 29/05/2020 9:42, Uwe Fischer wrote: Hello list, thanks to Micha Silver and Helmut Kudrnovsky, the problem ist solved. I did not set g.region prior to using v.what.rast. Seems to be a typical non-Grass-Professional mistake. Now it works fine. But to be honest, I do not really understand what it is good for. When the raster image and the points to be updated share the same Grass location and CRS, why do I have to set a region in addition? Glad you got it worked out. The only thing I would add to Stefan's explanation is a pointer to the GRASS wiki on region settings: https://grasswiki.osgeo.org/wiki/Computational_region Regards, Micha Best regards and thanks again, Uwe ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 https://orcid.org/-0002-1128-1325 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Let's talk about releases - 7.8.3, 7.10, 8.0
7.8 will be EOL in 7 months ?? or is that referring only to the
minor version 7.8.5?
On 02/05/2020 16:32, Markus Neteler
wrote:
Hi,
On Sat, May 2, 2020 at 12:57 PM Martin Landa wrote:
pá 1. 5. 2020 v 14:21 odesílatel Vaclav Petras napsal:
There was couple related discussions in the past here and there (see below), so it's time to discuss this properly.
https://grasswiki.osgeo.org/wiki/Talk:GRASS_GIS_Community_Sprint_Prague_2019#Also_discussed
https://github.com/OSGeo/grass/pull/333#issuecomment-584859963
https://lists.osgeo.org/pipermail/grass-dev/2020-April/094340.html
thanks for links.
Yes, great initiative!
We miss a clear plan, probably less strict than QGIS
[1], but currently we have no long-term roadmap. I have created a
draft page, please extend, add new suggestions [2]
I have taken liberty to add a "remarks" page with EOL (end of life)
and added the links to the respective roadmap pages (which will move
to gitHub in the long run).
Markus
PS: remember the Doodle poll for the date and time of the discussion:
https://doodle.com/poll/bd3g9nfzurtdeg6i
Martin
[1] https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule
[2] https://trac.osgeo.org/grass/wiki/Release/Schedule
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
https://orcid.org/-0002-1128-1325
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Merge spatially connected features
On 3/5/20 10:47 AM, Johannes Radinger wrote:
Hi Micha, hi all,
sorry for my late response...however, just today I managed to try your
approach of building polylines to connect "touching stream lines"...but...
On 24.02.20 16:48, Micha Silver wrote:
On 24/02/2020 10:45, Johannes Radinger wrote:
Hi all,
I have a large river network dataset (lines). Now I'd to assign
unique categories to each group of connected lines that have an
attribute in common.
For example, my rivers are categorized based on some kind of stream
order. I want to group all rivers that belong to stream order 2 and
are spatially connected; each group should get a unique category
value. I thought that I could first extract all rivers with a
particular attribute (e.g. stream order = 2) which will provide me
some scattered pattern of lines. Then I need a spatial join tool to
make subgroups of lines that are connected. How can I achieve the
latter? Any idea?
Here's a procedure that might work for you. Somewhat clunky, but I
think it gets what you want.
It's based on the v.build.polylines module to connect all touching
stream reaches. First extract each order from the stream vector into
a new vector. Then build polylines. Patch them all together. Now you
have a polyline vector with a single cat value for each set of
original stream reaches that had the same order and that were touching.
Unfortunately, the v.build.polylines tool does not work as it only
does not connect multiple (intersecting) lines like in a river
network. As an example I tried to build polylines from the stream
network of the NC dataset. Yous suggested approach should result that
each sub-network (i.e. river network that is not connected to another
one) should get its own ID/cat...however, v.build.polylines results in
a connected stream network that consists of multiple cats:
Maybe I misunderstood your question. The steps I tried use a
stream_order column to group stream segments, then apply a new attribute
"merged_id" to those stream orders that touch. i.e. that connect to the
same confluence point.
Here's what I get using the nc_basic_spm mapset:
r.watershed elev=elevation accum=nc_facc drain=nc_fdir bas=nc_bas
stream=nc_str thresh=1000
r.stream.order stream_rast=nc_str direct=nc_fdir elev=elevation
accum=nc_facc stream_vect=nc_streams
ORDERS=`v.db.select -c nc_streams group=strahler column=strahler`
echo $ORDERS
# Create a new stream vector for each stream order
for o in $ORDERS; do
v.extract input=nc_streams output=streams_${o} where="strahler=${o}"
# Give each polyline it's own cat value
v.build.polylines input=streams_${o} output=streams_${o}_polyline
type=line cat=first
done
# patch the stream orders back together
POLYLINES=`g.list vect pattern="streams*polyline" separator=comma`
v.patch input=$POLYLINES output=streams_polylines
v.db.addcolumn map=streams column="merged_id INTEGER"
# And use v.distance to update that merged_id column from cat values in
polylines vector
v.distance from=streams to=streams_polylines upload=cat column=merged_id
v.db.addcolumn map=nc_streams column="merged_id INTEGER"
v.distance from=nc_streams to=streams_polylines upload=cat column=merged_id
Now, all stream reaches that have the same order and are "touching" have
the same merged_id. See the attached image.
If that's not your purpose, then just ignore...
v.clean --overwrite input=streams@PERMANENT output=streams_break
tool=break
v.build.polylines --overwrite input=streams_break@test
output=streams_poly cats=first type=line
d.vect -c map=streams_poly
So what would be needed here is some kind of tool that connects all
touching lines and assigns a common category value, similar to the
v.dissolve tool for polygon features. I can imagine that such a task
might be not that uncommon also in another context? Any suggestions
how to achieve this in GRASS?
A workaround that came into my mind was to create buffers around lines
in order to make areas out of lines. Subsequently these touching areas
can be merged using v.dissolve and the information about the common
category can be queried using v.distance. Nevertheless, a rather
cumbersome way to just assign a common category value to all lines
that are touching...
Any further ideas?
cheers,
Johannes
Cheers,
Johannes
___
grass-user mailing list
grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Merge spatially connected features
On 24/02/2020 10:45, Johannes Radinger wrote:
Hi all,
I have a large river network dataset (lines). Now I'd to assign unique
categories to each group of connected lines that have an attribute in
common.
For example, my rivers are categorized based on some kind of stream
order. I want to group all rivers that belong to stream order 2 and
are spatially connected; each group should get a unique category
value. I thought that I could first extract all rivers with a
particular attribute (e.g. stream order = 2) which will provide me
some scattered pattern of lines. Then I need a spatial join tool to
make subgroups of lines that are connected. How can I achieve the
latter? Any idea?
Here's a procedure that might work for you. Somewhat clunky, but I think
it gets what you want.
It's based on the v.build.polylines module to connect all touching
stream reaches. First extract each order from the stream vector into a
new vector. Then build polylines. Patch them all together. Now you have
a polyline vector with a single cat value for each set of original
stream reaches that had the same order and that were touching.
Finally, with v.distance you can upload that cat value to the original
streams.
# Get a list of stream orders
ORDERS=`v.db.select -c streams group=strahler column=strahler`
echo $ORDERS
#1 2 3 4 5 6
# How many stream segments in original
v.info -t streams | grep lines
# lines=1420
# Now loop thru list of stream orders and extract stream segments for
each order
for o in $ORDERS; do
v.extract input=streams output=streams_${o} where="strahler=${o}"
# Create polyline for each stream order
# Line "connects" all touching stream segments
v.build.polylines input=streams_${o}
output=streams_${o}_polyline type=line cat=first
done
# Patch stream order polylines together
POLYLINES=`g.list vect pattern="streams*polyline" separator=comma`
echo $POLYLINES
v.patch input=$POLYLINES output=streams_polylines
v.info -t streams_polylines | grep lines
# lines=738
# Add a new column to the original streams for new ID value
v.db.addcolumn map=streams column="merged_id INTEGER"
# And use v.distance to update that column from cat values in polylines
vector
v.distance from=streams to=streams_polylines upload=cat column=merged_id
HTH
Cheers,
Johannes
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
https://orcid.org/-0002-1128-1325
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Area between drainage networks
On 12/20/19 5:40 PM, Luis Moreira wrote: Hello everyone, I'd like to obtain the area between two drainage networks. The difference between them is due to different calculation methods. <http://osgeo-org.1560.x6.nabble.com/file/t385794/photo5181593200849168458.jpg> The image above illustrates the methodology of mesuring the "error" between two drainage networks. Each one of the drainage networks is in a shapefile, and I need the sum of all the areas between the segments of the drainage networks, so that I can mesure the difference between them. How could I do that with GRASS? It seems that you want to get the area between two criss-crossing line vectors. To do this in GRASS, you can try the procedure below. (Note that there will always be some dangling line segments at the end that are not closed, unless the two line vectors end exactly at the same point) Assuming I have two line vectors 'streams1' and 'streams2'... # First patch the two lines together micha@RMS tmp $ v.patch input=streams1,streams2 output=streams_patch --o WARNING: Vector map already exists and will be overwritten Patching vector map ... Patching vector map ... Building topology for vector map ... Registering primitives... Building topology for vector map ... Intersections at borders will have to be snapped Lines common between files will have to be edited The header information also may have to be edited v.patch complete. 2 vector maps patched # Use v.clean to break lines at each intersection micha@RMS tmp $ v.clean streams_patch output=streams_clean tool=break,rmdangle --o -- Tool: Threshold Break: 0 Remove dangles: 0 -- WARNING: Vector map already exists and will be overwritten Copying features... 100% Rebuilding parts of topology... Building topology for vector map ... Registering primitives... -- Tool: Break lines at intersections 100% -- Building topology for vector map ... -- Tool: Remove dangles 100% -- Rebuilding topology for output vector map... Building topology for vector map ... Registering primitives... # Now change the line to a boundary. This creates enclosed polygon areas micha@RMS tmp $ v.type input=streams_clean output=streams_boundary from=line to=boundary --o WARNING: Vector map already exists and will be overwritten Building topology for vector map ... Registering primitives... Building areas... 100% Attaching centroids... 100% WARNING: Number of incorrect boundaries: 24 # Run v.centroids to get individual areas each with a centroids micha@RMS tmp $ v.centroids input=streams_boundary output=streams_areas --o WARNING: Vector map already exists and will be overwritten Processing features... 10 new centroids placed in output map Copying attribute table(s)... Building topology for vector map ... Registering primitives... Building areas... 100% Attaching centroids... 100% WARNING: Number of incorrect boundaries: 24 v.category complete. 10 features modified. # Add an attribute table to hold the area of each polygon micha@RMS tmp $ v.db.addtable streams_areas column="area_sqm REAL" WARNING: Values in column will be overwritten Reading features... 100% Updating database... 100% 10 categories read from vector map (layer 1) 10 categories read from vector map don't exist in selection from table 10 records updated/inserted (layer 1) micha@RMS tmp $ v.to.db streams_areas option=area unit=meters column=area_sqm Reading areas... 100% Updating database... 100% 10 categories read from vector map (layer 1) 10 records selected from table (layer 1) 10 categories read from vector map exist in selection from table 10 records updated/inserted (layer 1) # Check results: micha@RMS tmp $ v.db.select streams_areas cat|area_sqm 1|483620.195889 2|320097.009754 3|440533.925655 4|330833.778807 5|472005.399364 6|80935.144153 7|130299.225048 8|275763.239 9|281143.425416 10|446053.906035 HTH, Micha Thanks in advance. -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SQL: generating numeric class numbers from class text labels?
How about doing this in R? The labels will be read into R as factors,
and the factor levels can easily be extracted as numbers.
Something like this:
micha@tp480:~$ v.info -c stations
Displaying column types/names for database connection of layer <1>:
INTEGER|cat
INTEGER|station_num
TEXT|station_he
TEXT|station_en
TEXT|type
INTEGER|x_coord
INTEGER|y_coord
DOUBLE PRECISION|long
DOUBLE PRECISION|lat
INTEGER|elev
TEXT|date_open
DOUBLE PRECISION|dist
DOUBLE PRECISION|azim
micha@tp480:~$ R
R version 3.5.2 (2018-12-20) -- "Eggshell Igloo"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
.
> library(rgrass7)
Loading required package: XML
GRASS GIS interface loaded with GRASS version: GRASS 7.6.0 (2019)
and location: ITM
> use_sf()
> stations = readVECT("stations")
WARNING: Vector map is 3D. Use format specific layer creation
options (parameter 'lco') to export stations['new_station_num'] = as.numeric(stations$station_en)
> stations$new_station_num
[1] 71 26 6 55 54 63 7 8 31 30 46 84 92 38 32 88 27 12 67 62 47 33
53 76 89
[26] 2 86 11 40 65 64 45 13 85 60 59 1 74 73 22 19 15 39 50 56 14 44
23 36 83
[51] 41 42 43 18 17 75 16 82 81 37 48 28 87 3 66 10 34 91 61 93 94 72
5 4 68
[76] 78 77 9 29 51 58 57 49 52 24 25 80 79 35 70 69 90 21 20
> writeVECT(SDF=stations, vname="new_stations")
Best regards, Micha
On 04/12/2019 19:11, Markus Neteler wrote:
Hi,
I have a landuse map with text labels (forest, street, ...). For
r.learn.ml I need to have them as numeric classes.
It is not important for me which number is assigned but I search for
an automated solution, i.e. SQL statement unless there is a different
way.
So:
cat|label|label_int
1|forest|1
2|forest|1
3|street|2
4|forest|1
5|street|2
6|urban|3
...
I guess I have done that already some years ago but I can't remember
the trick :-)
thanks for a hint,
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
https://orcid.org/-0002-1128-1325
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SQL: generating numeric class numbers from class text labels?
How about doing this in R? The labels will be read into R as
factors, and the factor levels can easily be extracted as numbers.
Something like this:
micha@tp480:~$ v.info -c stations
Displaying column types/names for database connection of layer
<1>:
INTEGER|cat
INTEGER|station_num
TEXT|station_he
TEXT|station_en
TEXT|type
INTEGER|x_coord
INTEGER|y_coord
DOUBLE PRECISION|long
DOUBLE PRECISION|lat
INTEGER|elev
TEXT|date_open
DOUBLE PRECISION|dist
DOUBLE PRECISION|azim
micha@tp480:~$ R
R version 3.5.2 (2018-12-20) -- "Eggshell Igloo"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
.
> library(rgrass7)
Loading required package: XML
GRASS GIS interface loaded with GRASS version: GRASS 7.6.0 (2019)
and location: ITM
> use_sf()
> stations = readVECT("stations")
WARNING: Vector map is 3D. Use format specific
layer creation
options (parameter 'lco') to export
(default).
Exporting 94 features...
100%
.
> stations['new_station_num'] =
as.numeric(stations$station_en)
> stations$new_station_num
[1] 71 26 6 55 54 63 7 8 31 30 46 84 92 38 32 88 27 12 67 62
47 33 53 76 89
[26] 2 86 11 40 65 64 45 13 85 60 59 1 74 73 22 19 15 39 50 56
14 44 23 36 83
[51] 41 42 43 18 17 75 16 82 81 37 48 28 87 3 66 10 34 91 61 93
94 72 5 4 68
[76] 78 77 9 29 51 58 57 49 52 24 25 80 79 35 70 69 90 21 20
> writeVECT(SDF=stations, vname="new_stations")
Best regards, Micha
On 04/12/2019 19:11, Markus Neteler
wrote:
Hi,
I have a landuse map with text labels (forest, street, ...). For
r.learn.ml I need to have them as numeric classes.
It is not important for me which number is assigned but I search for
an automated solution, i.e. SQL statement unless there is a different
way.
So:
cat|label|label_int
1|forest|1
2|forest|1
3|street|2
4|forest|1
5|street|2
6|urban|3
...
I guess I have done that already some years ago but I can't remember
the trick :-)
thanks for a hint,
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
https://orcid.org/-0002-1128-1325
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] deleting lines by length, from a vector map
On 30/11/2019 16:11, Zoltan Szecsei
wrote:
Hi,
I'm trying to write my first Grass python script to load Shape
files and delete all lines shorter than 50m
I'm trying various permutations of the command below, but no
success (No error message and no lines deleted).
Any guidance would be welcome.
gscript.run_command('v.extract','r',input=gen,output=lin,
where="( $LENGTH > 50 )",overwrite=True)
gscript.run_command('v.out.ogr', 'sce2', input=lin, type='line',
output=dir_rclout + rcl + '.shp', format='ESRI_Shapefile',
output_type='line',overwrite=True)
The term $LENGTH looks wrong to me.
In python I usually would do something like:
In [1]: import grass.script as gscript
In [4]: where_expr = "%s > %d" % ("'length'", 5000)
In [5]: where_expr
Out[5]: "'length' > 5000"
In [6]: gscript.run_command('v.extract', input="roads",
output="roads_long", where=where_expr)
Data element 'vector/roads' was found in more mapsets
(also found in
)
Using ...
Data element 'vector/roads' was found in more mapsets
(also found in
)
Using ...
Extracting features...
100%
Building topology for vector map
...
Registering primitives...
Writing attributes...
Out[6]: 0
Note the quoting around the column header "length": One double
quote and one single quote. The inner single quote is for the SQL
_expression_.
Cheers, Micha
Thanks
and regards,
Zoltan
PS: Should these type of questions go to grass-dev ??
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
https://orcid.org/-0002-1128-1325
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Create line perpendicular to other line at specific point
I have a python script from some years ago that should prepare
"station lines" perpendicular to stream reaches at regular
intervals. If you're interested in trying, I'll gladly send it. I
originally wrote the script to work in python 2, so if it's
helpful, I should do the changes needed for python 3.
Regards, Micha
On 08/11/2019 11:02, Johannes Radinger
wrote:
Hi all,
I've vector lines representing rivers and a set of points.
Now, I'd like to create short lines (e.g. 150 m) that are
perpendicular to the river lines and cross at the coordinates
of the points vector. This is basically to create transects
similar to the tool v.transect. However v.transect creates the
perpendicular lines at regular intervals and I'd like to
create them only for the locations of the points on the river
line. Is there any straight forward tool to accomplish this? I
could retrieve the azimuth of the river lines at each point
(using v.to.db), but how can I extrude a point into a line
with a given length and azimuth? Any suggestions?
cheers,
Johannes
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
https://orcid.org/-0002-1128-1325
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Null values in attribute table get converted to 0 (zero) during v.to.rast
On 01/11/2019 9:38, Markus Metz wrote: On Fri, Nov 1, 2019 at 12:11 AM Veronica Andreo <veroand...@gmail.com> wrote: > > Hi Micha > > El jue., 31 oct. 2019 a las 22:36, Micha Silver (<tsvi...@gmail.com>) escribió: >> >> >> On 31/10/2019 22:20, Markus Metz wrote: >> >> >> >> On Tue, Oct 29, 2019 at 7:40 PM Veronica Andreo <veroand...@gmail.com> wrote: >> > >> > Hi Daniel, >> > >> > I agree that if there's a NULL in the column, there should be NULL in the resulting raster. I suggest to open a ticket here: https://trac.osgeo.org/grass/ >> >> easy solution: v.to.rast where=" is not null" >> >> or the new PR #173 >> https://github.com/OSGeo/grass/pull/173 >> if an attribute value is null, the corresponding vector features will not be rasterized >> >> Markus M >> >> I'm not sure I agree with the approach that a polygon with missing attribute should become NULL. In my view, NULL should be used only for pixels not covered at all by any polygon. > > but in the resulting raster (in rasters in general), there's no difference, it's rather NULL or it has a value... it does not matter if the null comes from areas originally covered by a polygon or not... I think it depends on the particular use case if it matters where a NULL raster value comes from: a polygon with empty attribute or no polygon at all for that cell. >> >> Perhaps an additional input parameter "missing_attribute" so the user can choose a value to enter into the raster if the attribute is missing. If no parameter is supplied, and the chosen attribute column has missing values, I'd prefer that the script exit gracefully, with a message that a "missing_attribute" value is required. This can easily be done with existing tools: - convert only those polygons with a valid attribute value: v.to.rast where="attribute is not null" - replace missing attribute values with a valid value: v.db.update where="attribute is null", then v.to.rast I'm changing my PR to issue a warning if empty attribute values are found and replaced with zero. IMHO, that's probably the best way to deal with this. Markus M > > yes, this could be a solution to keep track of where you had polygons, but then you would need to use r.null anyway, no? I try to think of use cases in which one uses a vector attribute to convert to raster, but then still needs to know where the polygons were... because, for example, to query a raster map with another raster map representing zones one would convert the vector of polygons using cat and not an attribute, no? > > cheers, > Vero >> >> >> > El jue., 24 oct. 2019 a las 14:40, Daniel Victoria (<daniel.victo...@gmail.com>) escribió: >> >> >> >> Hi list, >> >> >> >> I have a vector polygon map that I'm converting to raster. The attribute column that I process has some empty rows (no data / null). When I run v.to.rast, these empty rows become 0 (zero) on my resulting raster map. >> >> >> >> Shouldn't v.to.rast respect the empty attribute table and create null values for those polygons? >> >> >> >> For now I'll use r.null to fix this problem. But what if 0 is a valid value? >> >> >> >> Cheers >> >> Daniel >> >> >> >> PS - Running Grass 7.6.1 on Ubuntu >> >> ___ >> >> grass-user mailing list >> >> grass-user@lists.osgeo.org >> >> https://lists.osgeo.org/mailman/listinfo/grass-user >> > >> > ___ >> > grass-user mailing
Re: [GRASS-user] Null values in attribute table get converted to 0 (zero) during v.to.rast
On 31/10/2019 22:20, Markus Metz wrote:
On Tue, Oct 29, 2019 at 7:40 PM Veronica Andreo <veroand...@gmail.com>
wrote:
>
> Hi Daniel,
>
> I agree that if there's a NULL in the column, there should
be NULL in the resulting raster. I suggest to open a ticket
here: https://trac.osgeo.org/grass/
easy solution: v.to.rast where=" is
not null"
or the new PR #173
https://github.com/OSGeo/grass/pull/173
if an attribute value is null, the corresponding vector
features will not be rasterized
Markus M
I'm not sure I agree with the approach that a polygon with
missing attribute should become NULL. In my view, NULL should be
used only for pixels not covered at all by any polygon.
Perhaps an additional input parameter "missing_attribute" so the
user can choose a value to enter into the raster if the attribute
is missing. If no parameter is supplied, and the chosen attribute
column has missing values, I'd prefer that the script exit
gracefully, with a message that a "missing_attribute" value is
required.
>
> Cheers,
> Vero
>
> El jue., 24 oct. 2019 a las 14:40, Daniel Victoria (<daniel.victo...@gmail.com>)
escribió:
>>
>> Hi list,
>>
>> I have a vector polygon map that I'm converting to
raster. The attribute column that I process has some empty rows
(no data / null). When I run v.to.rast, these empty rows become
0 (zero) on my resulting raster map.
>>
>> Shouldn't v.to.rast respect the empty attribute table
and create null values for those polygons?
>>
>> For now I'll use r.null to fix this problem. But what
if 0 is a valid value?
>>
>> Cheers
>> Daniel
>>
>> PS - Running Grass 7.6.1 on Ubuntu
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.kernel - Points weighted with attribute ?
On 28/10/2019 14:08, Taïs wrote:
Hi Micha, Moritz,
I successfully create the kernel density raster. Thanks a lot
for your support ;)
I tried with ~62.000 points on a computational region of +-
1000 cols by 1000 rows, with 10 m. spatial resolution.
How long was the processing?
FYI, I had to change the type of the weights column from
"double precision" to "integer" because I had this error message
when it was on double precision:
I'll have to think about how to handle that...
Error in matrix(rep(w, n[1]), nrow = n[1],
ncol = nx, byrow
= TRUE) * :
non-numeric argument to binary operator
Calls: sp.kde -> fhat
Taïs
Le 25/10/19 à 13:36, Micha Silver a
écrit :
Hi Taïs
Thanks for testing.
As Moritz mentioned, the important parameter in spatial
kernel density is the bandwidth.
Here attached is an improved script that uses the spatialEco
R package (instead of density.ppp from spatstat). To run this,
you'll need to install spatialEco in your R environment.
This package allows to specify both the bandwidth and the
target raster extents and resolution. In this script I take
the extents and resolution from the GRASS region. Bandwidth is
specified on the command line.
So to try this, in your running GRASS session:
Rscript kernel_density.R
I also attached two images in a test I did, with bandwidths
of 10,000 and 20,000.
Hope this helps,
Micha
On 10/25/19 12:17 PM, Taïs wrote:
Hi Micha,
I successfully run your R script. However to output is
weird and I don't know how to fix it.
In v.kernel, you can setup the "raduis" parameter to
control what I assume to be the size of the kernel (of the
moving window). I made one test with radius=300 and another
with value 3000. The result of the first is more what I
would expect in terms of spatial variability.
When I try your script, the output raster has a size of
128x128 which did not correspond at all to my computational
region, and thus the resolution is not the same as the one
defined in the computational region.
The other thing is that I'm wondering if it is possible to
control the size of the moving window with the "density"
function in R. I already tried the 'n' parameter but it
doesn't change anything..
I also tried with real weights (the number of inhabitants)
and a unity weighting (value 1 for all points) to see it
there is a change and there is which proof the weights
affect the output :)
Le 22/10/19 à 13:41, Micha Silver
a écrit :
Here is the script.
Let me know how it goes. (I might try to take time to
make it into a GRASS addon)
On 10/22/19 2:33 PM, Taïs
wrote:
Hi Micha, thanks for your repply.
For my own need, I think your solution is enough and I
would like to try if you agree to send the R script.
Le 22/10/19 à 12:53, Micha
Silver a écrit :
On 10/21/19 1:33 PM, Tais
wrote:
Hi
all,
I would like to compute a raster density map ("heat
map") from vector points using v.kernel. The points
represent house addresses. However, I would need to
weight the points with a value stored in the attribute
table (number of inhabitants). I saw on the module
manual page that this functionality is a "known
issue".
I imagined a solution to
Re: [GRASS-user] v.kernel - Points weighted with attribute ?
Hi Taïs
Thanks for testing.
As Moritz mentioned, the important parameter in spatial kernel
density is the bandwidth.
Here attached is an improved script that uses the spatialEco R
package (instead of density.ppp from spatstat). To run this,
you'll need to install spatialEco in your R environment.
This package allows to specify both the bandwidth and the target
raster extents and resolution. In this script I take the extents
and resolution from the GRASS region. Bandwidth is specified on
the command line.
So to try this, in your running GRASS session:
Rscript kernel_density.R
I also attached two images in a test I did, with bandwidths of
10,000 and 20,000.
Hope this helps,
Micha
On 10/25/19 12:17 PM, Taïs wrote:
Hi Micha,
I successfully run your R script. However to output is weird
and I don't know how to fix it.
In v.kernel, you can setup the "raduis" parameter to control
what I assume to be the size of the kernel (of the moving
window). I made one test with radius=300 and another with value
3000. The result of the first is more what I would expect in
terms of spatial variability.
When I try your script, the output raster has a size of 128x128
which did not correspond at all to my computational region, and
thus the resolution is not the same as the one defined in the
computational region.
The other thing is that I'm wondering if it is possible to
control the size of the moving window with the "density"
function in R. I already tried the 'n' parameter but it doesn't
change anything..
I also tried with real weights (the number of inhabitants) and
a unity weighting (value 1 for all points) to see it there is a
change and there is which proof the weights affect the output :)
Le 22/10/19 à 13:41, Micha Silver a
écrit :
Here is the script.
Let me know how it goes. (I might try to take time to make it
into a GRASS addon)
On 10/22/19 2:33 PM, Taïs wrote:
Hi Micha, thanks for your repply.
For my own need, I think your solution is enough and I
would like to try if you agree to send the R script.
Le 22/10/19 à 12:53, Micha Silver
a écrit :
On 10/21/19 1:33 PM, Tais
wrote:
Hi
all,
I would like to compute a raster density map ("heat map")
from vector points using v.kernel. The points represent
house addresses. However, I would need to weight the
points with a value stored in the attribute table (number
of inhabitants). I saw on the module manual page that this
functionality is a "known issue".
I imagined a solution to by-passe the limitation:
duplicate each point as many time as needed (according to
the value stored in the attribute table) and use this new
layer directly in v.kernel. However, I think it will
definitely not be the most efficient way to do the trick.
Do you have an alternative in mind ?
Of course the best solution would be that someone in the
development community would have the time and the kindness
to implement this function directly in the module (I'm not
skilled in C and thus cannot try myself).
Maybe not the answer you are looking for, but you can
create a weighted kernel density in R. I can send an R
script that is intended to be run from within a GRASS
session. It accepts a point vector and attrib column, and
creates a kernel density raster, weighted by the attribute
values (using the R defaults for bandwidth and Gaussian
kernel)
Requires, of course, that R is installed, with the
packages: spatstat, raster, rgrass7.
NB:
Sorry if I should have posted this on the developer
mailing list. I hesitated but decided to post here
finally.
Best,
--
Re: [GRASS-user] v.kernel - Points weighted with attribute ?
Here is the script.
Let me know how it goes. (I might try to take time to make it
into a GRASS addon)
On 10/22/19 2:33 PM, Taïs wrote:
Hi Micha, thanks for your repply.
For my own need, I think your solution is enough and I would
like to try if you agree to send the R script.
Le 22/10/19 à 12:53, Micha Silver a
écrit :
On 10/21/19 1:33 PM, Tais wrote:
Hi
all,
I would like to compute a raster density map ("heat map") from
vector points using v.kernel. The points represent house
addresses. However, I would need to weight the points with a
value stored in the attribute table (number of inhabitants). I
saw on the module manual page that this functionality is a
"known issue".
I imagined a solution to by-passe the limitation: duplicate
each point as many time as needed (according to the value
stored in the attribute table) and use this new layer directly
in v.kernel. However, I think it will definitely not be the
most efficient way to do the trick. Do you have an alternative
in mind ?
Of course the best solution would be that someone in the
development community would have the time and the kindness to
implement this function directly in the module (I'm not
skilled in C and thus cannot try myself).
Maybe not the answer you are looking for, but you can create
a weighted kernel density in R. I can send an R script that is
intended to be run from within a GRASS session. It accepts a
point vector and attrib column, and creates a kernel density
raster, weighted by the attribute values (using the R defaults
for bandwidth and Gaussian kernel)
Requires, of course, that R is installed, with the packages:
spatstat, raster, rgrass7.
NB:
Sorry if I should have posted this on the developer mailing
list. I hesitated but decided to post here finally.
Best,
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
# Weighted Kernel Density in R
# execute from a GRASS session
# Command line arguments: GRASS point vector, column of weights
#
suppressPackageStartupMessages(c(library(rgrass7),
library(spatstat),
library(sp),
library(raster)))
# Test case, in GRASS location nc_basic_spm, using the schools vector
# This vector has attribut CORECAPACI, used as weight in this case
args = commandArgs(trailingOnly=TRUE)
if (length(args) < 2) {
print("Enter GRASS point vector and weight attribute column as command line arguments")
print("Exiting...")
quit(save="no")
} else {
input_vect = args[1]
output_rast = paste0(input_vect, "_density")
weights_col = args[2]
}
use_sp()
points = readVECT(input_vect)
# Check geometry type and weight attribute column
if (class(points)!= "SpatialPointsDataFrame") {
print("Wrong geometry type. Must be POINT")
quit(save="no")
}
weights_idx = which(names(points) == weights_col)
if (is.empty(weights_idx)) {
print(paste("No attribute column:", weights_col))
quit(save="no")
}
# Remove NA
points = points[!is.na(points[[weights_idx]]),]
wts = points[[weights_idx]]
print(paste("Using:", length(wts), "points"))
# Prepare ppp object
pts_coords = coordinates(points)
pts_ext = c(min(pts_coords[,1]), max(pts_coords[,1]), min(pts_coords[,2]), max(pts_coords[,2]))
pts_ppp = as.ppp(pts_coords, pts_ext)
# Density (default Gaussian kernel)
pts_dens = density(pts_ppp, weights = wts)
# Convert to SGDF to save back to GRASS
pts_sgdf = as(raster(pts_dens), "SpatialGridDataFrame")
writeRAST(x = pts_sgdf, vname = output_rast)
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.kernel - Points weighted with attribute ?
On 10/21/19 1:33 PM, Tais wrote:
Hi all,
I would like to compute a raster density map ("heat map") from
vector points using v.kernel. The points represent house
addresses. However, I would need to weight the points with a value
stored in the attribute table (number of inhabitants). I saw on
the module manual page that this functionality is a "known issue".
I imagined a solution to by-passe the limitation: duplicate each
point as many time as needed (according to the value stored in the
attribute table) and use this new layer directly in v.kernel.
However, I think it will definitely not be the most efficient way
to do the trick. Do you have an alternative in mind ?
Of course the best solution would be that someone in the
development community would have the time and the kindness to
implement this function directly in the module (I'm not skilled in
C and thus cannot try myself).
Maybe not the answer you are looking for, but you can create a
weighted kernel density in R. I can send an R script that is
intended to be run from within a GRASS session. It accepts a point
vector and attrib column, and creates a kernel density raster,
weighted by the attribute values (using the R defaults for
bandwidth and Gaussian kernel)
Requires, of course, that R is installed, with the packages:
spatstat, raster, rgrass7.
NB:
Sorry if I should have posted this on the developer mailing list.
I hesitated but decided to post here finally.
Best,
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.stream.* questions
On 03/10/2019 23:56, Rich Shepard wrote: Reading the manual pages for v.stream.network, v.stream.order, and v.stream.profiler in the extensions doc I see details for the input options but all descriptions refer to raster files. The v.stream.* modules all take vector maps as input. Are there more detailed docs that show examples using the vector modules along with the raster modules? I've a complex, extensive, river network as a vector file. I've not extracted streams, basins, or watersheds from the DEM and I'd like to run the v.stream.* modules on my vector stream network. Possible? Maybe yes, but if this refers to the project that you've posted about recently, then you have a high resolution LIDAR-based DEM of the basin. These v.stream.* modules are intended to work with vector outputs from the r.stream.* modules. If you are going to ignore that and use a vector stream network from some other source, then be aware: 1- This alternate stream network must be topologically correct 2- Stream vector segments should all be in downstream direction (the outlet reach *must* be directed downstream). 3- You might not be able to make use of the DEM for other analyses, since it won't match the stream network. TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Basin DEM advice needed
Hi Rich
A couple of thoughts, below
On 03/10/2019 01:22, Rich Shepard
wrote:
Attached
are two maps using 1m LiDAR data. The annotated map,
basin-elevations.png, was drawn by individually applying d.rast to
each of
the 70 maps covering the basin. Sharp breaks can be seen where the
data
cross quads or flights didn't match up smoothly.
Can you first zoom in closely to one of the discontinuity areas
between two tiles and examine the actual values on both sides of
the "break". As Ken pointed out, it might be just a coloring
problem, and NOT really a discontinuous step in elevation values.
The
un-annotated map, nehalem-dem-patched.png, displays the results of
running r.patch on all 70 maps. Topographically it's quite
different from
the individual maps; almost flat when the north, east, and south
edges
should have elevations similar to the other map.
I think I should apply r.resamp.stats to aggregate the 1m
resolution to 5m.
I'd like your thoughts on this.
I would NOT use resampling to try to overcome discontinuity in
the tiles. That won't solve the problem, just smear it out a bit.
If there really are breaks in the data, then (you won't like
this...) back to the data provider to clarify why there are these
breaks in elevation.
If the region is too large to keep data at 1 m, then you can
decide to down-sample to a lower resolution to make the data more
manageable.
Also, if there are sliver gaps between the tiles, then you'll
want to run r.fill.nulls to get these gaps filled by
interpolation. In order to save time, I suggest to recursively set
the region to a very small area surrounding each gap, run the
r.fill.nulls and patch the filled area back into the
original. Then move on to the next gap. This will be much faster
than trying to do r.fill.nulls on the whole region. When finished,
don't forget to go back to the full region.
I
assume that I should resample each individual map, then re-run
r.patch on
the coarser maps because r.slope.aspect and r.info need a single
map as
input.
Would this be an appropriate process? I'm completely open to all
suggestions
and recommendations.
I think the best approach would be creating a VRT, outside of
GRASS, using the gdalbuildvrt utility: Dump the list of
your 70 rasters into a text file. Use the -input_file_list
parameter to gdalbuildvrt, and you'll have one virtual raster for
import into GRASS. You can reference it with r.external (to avoid
importing and duplicating the disk space required). Then do
whatever hydrological analysis you need with that.
Best, Micha
Regards,
Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
+972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.gps issue
Hi Tom:
On 02/09/2019 2:11, Thomas Adams wrote:
All:
I'm running GRASS 7.6.0, I built from source, on Ubuntu
19.04. No issues up to this point. However, for the first time
-ever-, I'm trying to use v.in.gps:
v.in.gps -t input=/home/teaiii/Current.gpx
output=slv_test_track
I don't know what the story is with v.in.gps. The code looks
strange:
if format == 'gpx':
# short circuit, we have what we came for.
#todo
#grass.try_remove(output)
#os.rename(tmp_gpx, output)
grass.verbose("Fast exit.")
sys.exit()
But this seems to work fine:
micha@TP480:work$ v.in.ogr input=Current.gpx
output=test_trk layer=tracks
Check if OGR layer contains polygons...
100%
Creating attribute table for layer ...
Importing 1 features (OGR layer )...
100%
-
Building topology for vector map
...
Registering primitives...
the Current.gpx file looks very reasonable (attached). When
I run the above command, I get no errors, but the
slv_test_track vector file is not created either -- no errors
are generated. I installed GPSBabel *after* building GRASS
7.6. Any thoughts what I'm doing or have done wrong?
Thank you,
Tom
--
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
