[GRASS-user] v.extract fails for long strings in sql where or cat
Dear list, is there a max length in the where statement for v.extract? I want to extract many line features depending on the value of an id field and get: "[Errno 7] Argument list too long: 'v.extract'" when I run v.extract with a long sql statement. It works if I use id < 7, hence the number of extracted items is not the problem. However, this does not help because I need a selection like "id in (1,5,7,...,7)". Similarly, cat = 1-7 works but cat = 1,2,3,,7 does not. I found an old posting about this (https://lists.osgeo.org/pipermail/grass-user/2010-January/054361.html) and wonder if anything has changed since then and if there is any work around if not. I am running GRASS 7.8.5 on Linux Mint 19. Thanks a lot, Mira -- Dr. Mira Kattwinkel Quantitative Landscape Ecology iES Landau, Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] error in g.proj on Windows 10 via R (rgrass7) in GRASS 7.8
Dear list, This is a GRASS - R - Windows problem. I would be grateful for any hint. I try to modify my current location using g.proj, flag c and a georeferenced file. This works fine when I do it directly in GRASS. However, when calling from R (via the rgrass7 package) I get the following error message: ERROR 1: PROJ: proj_create_geographic_crs: SQLite error on SELECT name, ellipsoid_auth_name, ellipsoid_code, prime_meridian_auth_name, prime_meridian_code, area_of_use_auth_name, area_of_use_code, publication_date, deprecated FROM geodetic_datum WHERE auth_name = ? AND code = ?: no such column: area_of_use_auth_name The problem occurs using GRASS 7.8 but NOT using 7.6. Likewise, there is no problem under Linux, only Windows 10. It might be related to some Windows environmental variables, but I don't have a clue which ones. As the older version works, I wonder if it is due to any changes from GRASS 7.6 to 7.8. Could anybody give me a hint? Thanks a lot, Mira ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to add a new column based of polyline cat.
Dear Kenneth db.execute might be an option to fill a new column with what you want. I am not an SQL expert, but I suppose it is possible to concatenate the right strings if you do it for each order separately and count the number of currents first. Cheers, Mira On 10/12/2020 17.15, Kenneth Roy Cabrera Torres wrote: Dear GRASS users: Can you give any suggestions to solve this problem? I have an ordered dataset of segments of river currents output from r.stream.order command. I will like to add a column to this dataset that identifies each current according to Horton ordering. I mean it actually identifies the Horton number. But what I want to do is to separate each Horton current from each order. For example, if I have, say 4 Horton currents of order 5, then I will like to have an additional column that identifies each Horton current (5-1, 5-2, ..., 5-4). I try with v.build.polyline and indeed it separates the individual currents of the same Horton order. But I don't know how to incorporate that new cat ID to the current segments' dataset. Thank you for your help. -- Kenneth Roy Cabrera Torres Cel 315 504 9339 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Dr. Mira Kattwinkel Quantitative Landscape Ecology iES Landau, Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Plugin GRASS7 not working in QGIS 3.10 - Ubuntu
Dear Mauricio Some time ago, I had a similar problem with older versions. It might be that there is not yet a working plugin for QGIS for the newest version of GRASS. Maybe you could try an older GRASS version. I remember that I also found it difficult to find out which version is currently supported in QGIS because I only found older web pages or very general ones. It might be nice to have a place where the current working pairs are listed. All the best, Mira Am 20.11.2020 um 16:40 schrieb Maurício Vancine: Hi guys, I'm trying to open a GRASS GIS mapset in QGIS, but the GRASS 7 plugin doesn't seem to work in QGIS. I talked to other users here in Brazil, and they are having the same problem. Details: Ubuntu 20.04 GRASS GIS 7.8.4 QGIS 3.10.10 (ppa: ubuntugis / ubuntugis-unstable) Kind regards. -- *Maurício Vancine* Ecólogo (ABE n. 2018007), Mestre em Zoologiae Doutorando em Ecologia, Evolução e Biodiversidade Universidade Estadual Paulista (UNESP), Rio Claro/SP, Brasil Site <https://mauriciovancine.netlify.com/> | Lattes <http://lattes.cnpq.br/9761288418931193> | Google Scholar <https://scholar.google.com/citations?user=i-2xZBQJ> | ORCID <https://orcid.org/-0001-9650-7575>|Publons <https://publons.com/researcher/1391845/mauricio-vancine/> |GitHub <https://github.com/mauriciovancine> ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Fon: + 49 6341 280-31553 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.to.db in GRASS 7.8 requires 'overwrite' if column exists but flag is invalid
Sorry to open this again: Was the change really backported to GRASS 7.8? I still cannot set an overwrite flag in the gui. I use 7.8.3-1~bionic1 on linux mint 19 from http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu bionic/main amd64 Is that the wrong source? Thanks, Mira On 20/07/2020 22.35, Markus Neteler wrote: On Thu, Jul 16, 2020 at 12:34 PM Helmut Kudrnovsky wrote: Mira Kattwinkel wrote Dear list, in GRASS 7.8 v.to.db creates a new column in contrast to previous versions where it column had to exist before. ... yes there was a change in the module behaviour, see https://github.com/OSGeo/grass/issues/770 I had the same issue. ... please open an issue about that. For the list record: reported issue has been fixed by Huidae and backported. Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Dr. Mira Kattwinkel Quantitative Landscape Ecology iES Landau, Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.to.db in GRASS 7.8 requires 'overwrite' if column exists but flag is invalid
Dear list, in GRASS 7.8 v.to.db creates a new column in contrast to previous versions where it column had to exist before. According to the manual "If the /column/ exists, the *--overwrite* flag is required to overwrite it". However, this flag does not exist. Hence, if the column is present, it is not upated, giving: ERROR: Column exists. To overwrite, use the --overwrite flag When useing "overwrite", it gives: Invalid flag value: overwrite Another issue is that even if the flag would work, it would no longer be compatible with previous versions that also do not know the flag but need the column to exist. Can anybody please advice me what to do? Thanks, Mira -- Dr. Mira Kattwinkel Quantitative Landscape Ecology iES Landau, Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] cannot install extension on Windows 10
Hello, yes, I assumed that the metadata is available, but on my system they seem to be not found. And I do not know what settings to change. What would be the correct proxy settings? Indeed, the installation was successful, I can use the extension. However Settings / Addons extensions / Manage installed extensions gives me an empty list. Any ideas? Thanks a lot, Mira On 15/04/2019 20.20, Martin Landa wrote: Hi, po 15. 4. 2019 v 18:18 odesílatel Mira Kattwinkel napsal: For example g.extension extension=r.hydrodem operation=add Updating addons metadata file... ERROR: Unable to read addons metadata file from the remote server: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661) WARNING: NO addons metadate available. Addons metadate file not updated. hm, metadata seems to be available [0]. I tested installing r.hydrodem on my Windows 10 machine. No error, addons installed, possible to launch. Something related to proxy or? Installation of successfully finished (it is not!) Are you sure about that? Binary package [1] is available. Have you tried to launch the module? Ma [0]https://grass.osgeo.org/addons/grass7/modules.xml [1]https://wingrass.fsv.cvut.cz/grass76/x86_64/addons/grass-7.6.0/r.hydrodem.zip -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] cannot install extension on Windows 10
Dear list, I cannot install extensions in a new and clean GRASS 7.6.0 installation on Windows 10, because the list of extensions is empty. g.extension-l results in: List of available extensions (modules): Fetching list of modules from GRASS-Addons SVN (be patient)... (Mon Apr 15 16:54:16 2019) Command finished (10 sec) For example g.extension extension=r.hydrodem operation=add results in: Downloading precompiled GRASS Addons ... Updating addons metadata file... ERROR: Unable to read addons metadata file from the remote server: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661) WARNING: NO addons metadate available. Addons metadate file not updated. Installation of successfully finished (it is not!) Can anybody please help me out? All the best, Mira -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.out.ogr warning when exporting to shapefile
Dear list, I need to export some vector data to ESRI shapefiles. I use v.out.ogr and get several times warnings like: "Warning 1: Value 15246.47989 of field areaArabA of feature 6 not successfully written. Possibly due to too larger number with respect to field width" However, this field contains values with 2 decimal places and v.db.select correctly returns 15246.48. I create the column using v.db.addcolumn and column type double precision, and fill it using db.execute and an sql statement including ROUND. I suppose, this is a shapefile issue, but is there any workaround? Thanks a lot, Mira -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.patch and keeping the attributes
Sounds good and precise to me. Mira On 30/10/2018 21:34, Markus Metz wrote: On Tue, Oct 30, 2018 at 9:13 PM Markus Neteler <mailto:nete...@osgeo.org>> wrote: > > On Tue, Oct 30, 2018 at 5:36 PM Markus Neteler <mailto:nete...@osgeo.org>> wrote: > > On Tue, Oct 30, 2018 at 10:26 AM Mira Kattwinkel: > > > > > > Thanks a lot! > > > > > > I just did not interpret the paragraph "When using the -a flag..." correctly. > > > > > > Maybe a note in the manual that v.patch takes care of the cats etc. would be helpful. > > > > if you could send a (draft) text addition to me, I'll merge it into the manual. > > Based on Mira's offlist sent text snippet, I would add this text under "NOTES": > > "When using the -e flag, v.patch assigns new, unique category (cat) > values so that no overlapping category numbers occur in the > output. Hence, there is no need to run v.category beforehand." > > Is that correct? How about: "When using the -e flag, v.patch shifts category (cat) values in the output so that category numbers from the different input maps do not overlap. This shift is applied to both the category values of the features and the category values in the attribute tables. Hence, there is no need to run v.category and v.db.update beforehand." Markus M > > thanks > markusN -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.patch and keeping the attributes
Dear Markus, I saw that you updated v.patch to ignore the order of columns some months ago. However, I updated my grass to version 7.4.2. (on Linux Mint 18) and still get "ERROR: Column names differ" I am sure that they are the same, only the order is different. Do you have any suggestions? Mira On 29/10/2018 20:35, Markus Metz wrote: On Mon, Oct 29, 2018 at 6:13 PM Mira Kattwinkel mailto:kattwinkel-m...@uni-landau.de>> wrote: > > Dear list, > > I would like to patch two vector maps together and keep their attributes > (with the same columns but not in identical order) using v.patch with > flag -e. Granted that the two vector maps have attributes in layer 1 which you want to keep, you can use v.patch -e directly. v.patch will change category values of all but the first map such that no conflicts with identical categories from different input maps arise. There is no need to prepare the input maps with v.category. v.patch takes care of different column ordering. HTH, Markus M > > Both maps have cats starting with 1. Hence, I thought I use v.category, > option 'add' to add a fixed (large enough value) to the categories and > creating a second layer to keep the attribute values like this: > v.category input=map1 layer=2 type=line output=map1_cat option=add > cat=11 > > Then I add a table to layer 2 with a column for the old cat: > v.db.addtable map=map1_cat layer=2 columns="cat_lyr1 integer" > > Next, I fill this column (I want to use this column to be able to later > join the attributes from the original maps): > v.to.db map=map1_cat layer=2 type=line option=query columns=cat_lyr1 > query_column=cat > > Finally, I would like to use v.patch with flag e. However, this works > only for the table in layer 1. Hence, I wanted to use v.categroy to > change the layer numbers: > v.category input=map1_cat layer=2,1 type=line output=map1_cat2 > option=chlayer > > And get the warning: WARNING: Database connection and attribute tables > for concerned layers are not changed > > I tried to first drop the table in layer 1 with: > v.db.droptable -f map=map1_cat > and then use v.category but that results in the same warning as before. > Layer 2 is still layer 2. > > Can anybody please explain to me what is wrong? I am still struggling to > get my head around categories and layers but I thought I found a way to > do it correctly. > > Thanks a lot, > Mira > > > -- > Dr. Mira Kattwinkel > Quantitative Landscape Ecology > Institute for Environmental Sciences > University of Koblenz-Landau > Fortstraße 7 > 76829 Landau > Germany > Phone: + 49 6341 280-31553 > Office: Building I, Room 2.02 > > _______ > grass-user mailing list > grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org> > https://lists.osgeo.org/mailman/listinfo/grass-user -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.patch and keeping the attributes
Thanks a lot! I just did not interpret the paragraph "When using the /-a/ flag..." correctly. Maybe a note in the manual that v.patch takes care of the cats etc. would be helpful. Mira On 29/10/18 20:35, Markus Metz wrote: On Mon, Oct 29, 2018 at 6:13 PM Mira Kattwinkel mailto:kattwinkel-m...@uni-landau.de>> wrote: > > Dear list, > > I would like to patch two vector maps together and keep their attributes > (with the same columns but not in identical order) using v.patch with > flag -e. Granted that the two vector maps have attributes in layer 1 which you want to keep, you can use v.patch -e directly. v.patch will change category values of all but the first map such that no conflicts with identical categories from different input maps arise. There is no need to prepare the input maps with v.category. v.patch takes care of different column ordering. HTH, Markus M > > Both maps have cats starting with 1. Hence, I thought I use v.category, > option 'add' to add a fixed (large enough value) to the categories and > creating a second layer to keep the attribute values like this: > v.category input=map1 layer=2 type=line output=map1_cat option=add > cat=11 > > Then I add a table to layer 2 with a column for the old cat: > v.db.addtable map=map1_cat layer=2 columns="cat_lyr1 integer" > > Next, I fill this column (I want to use this column to be able to later > join the attributes from the original maps): > v.to.db map=map1_cat layer=2 type=line option=query columns=cat_lyr1 > query_column=cat > > Finally, I would like to use v.patch with flag e. However, this works > only for the table in layer 1. Hence, I wanted to use v.categroy to > change the layer numbers: > v.category input=map1_cat layer=2,1 type=line output=map1_cat2 > option=chlayer > > And get the warning: WARNING: Database connection and attribute tables > for concerned layers are not changed > > I tried to first drop the table in layer 1 with: > v.db.droptable -f map=map1_cat > and then use v.category but that results in the same warning as before. > Layer 2 is still layer 2. > > Can anybody please explain to me what is wrong? I am still struggling to > get my head around categories and layers but I thought I found a way to > do it correctly. > > Thanks a lot, > Mira > > > -- > Dr. Mira Kattwinkel > Quantitative Landscape Ecology > Institute for Environmental Sciences > University of Koblenz-Landau > Fortstraße 7 > 76829 Landau > Germany > Phone: + 49 6341 280-31553 > Office: Building I, Room 2.02 > > _______ > grass-user mailing list > grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org> > https://lists.osgeo.org/mailman/listinfo/grass-user -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.patch and keeping the attributes
Dear list, I would like to patch two vector maps together and keep their attributes (with the same columns but not in identical order) using v.patch with flag -e. Both maps have cats starting with 1. Hence, I thought I use v.category, option 'add' to add a fixed (large enough value) to the categories and creating a second layer to keep the attribute values like this: v.category input=map1 layer=2 type=line output=map1_cat option=add cat=11 Then I add a table to layer 2 with a column for the old cat: v.db.addtable map=map1_cat layer=2 columns="cat_lyr1 integer" Next, I fill this column (I want to use this column to be able to later join the attributes from the original maps): v.to.db map=map1_cat layer=2 type=line option=query columns=cat_lyr1 query_column=cat Finally, I would like to use v.patch with flag e. However, this works only for the table in layer 1. Hence, I wanted to use v.categroy to change the layer numbers: v.category input=map1_cat layer=2,1 type=line output=map1_cat2 option=chlayer And get the warning: WARNING: Database connection and attribute tables for concerned layers are not changed I tried to first drop the table in layer 1 with: v.db.droptable -f map=map1_cat and then use v.category but that results in the same warning as before. Layer 2 is still layer 2. Can anybody please explain to me what is wrong? I am still struggling to get my head around categories and layers but I thought I found a way to do it correctly. Thanks a lot, Mira -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Problem with v.to.db after v.dissolve and v.category
Dear list, I dissolve a vector map of lakes based on the names of the features (v.dissolve). As many of the features do not have names, I get, among the others, one new feature built up by many parts. v.dissolve input=lakes@PERMANENT column=name output=lakes_diss I do get a warning during the dissolve: ... WARNING: Number of centroids exceeds number of areas: 44345 > 43502 WARNING: Number of duplicate centroids: 1237 This results in 932 features with one containing the majority of lakes (those without a name). Then, I want to calculate the area (v.to.db) but this gives a wrong result because I need the area of every single lake. This is the same problem as described here https://lists.osgeo.org/pipermail/grass-user/2011-January/059282.html and I followed the advice given by Markus. However, I still get one big feature without a name and get error messages when calculating the area. Can anybody please give me an hint what's going wrong? Here are the steps: 1. delete categories: v.category input=lakes_diss@PERMANENT output=lakes_diss_wocat option=del cat=-1 Processing features... Copying attribute table(s)... Building topology for vector map ... Registering primitives... 88399 primitives registered 1409269 vertices registered Building areas... 43502 areas built 43426 isles built Attaching islands... Attaching centroids... Number of nodes: 45215 Number of primitives: 88399 Number of points: 0 Number of lines: 0 Number of boundaries: 45291 Number of centroids: 43108 Number of areas: 43502 Number of isles: 43426 v.category complete. 43108 features modified. (Mon Aug 20 15:59:30 2018) Command finished (3 sec) --> still 932 features in attribute table 2. add category v.category input=lakes_diss_wocat@PERMANENT output=lakes_diss_wcat option=add Processing features... Copying attribute table(s)... Building topology for vector map ... Registering primitives... 88399 primitives registered 1409269 vertices registered Building areas... 43502 areas built 43426 isles built Attaching islands... Attaching centroids... Number of nodes: 45215 Number of primitives: 88399 Number of points: 0 Number of lines: 0 Number of boundaries: 45291 Number of centroids: 43108 Number of areas: 43502 Number of isles: 43426 v.category complete. 43108 features modified. (Mon Aug 20 16:02:07 2018) Command finished (3 sec) --> 932 features in attribute table 3. add new column and populate with area v.db.addcolumn map=lakes_diss_wcat@PERMANENT columns=area double v.to.db map=lakes_diss_wcat@PERMANENT option=area columns=area Reading areas... Updating database... WARNING: Record (cat 933) does not exist (not updated) [a long long list...] 43108 categories read from vector map (layer 1) 932 records selected from table (layer 1) 932 categories read from vector map exist in selection from table 42176 categories read from vector map don't exist in selection from table 932 records updated/inserted (layer 1) Thanks a lot, Mira ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] limit number of confluent streams in r.steam.extract or r.watershed
Dear Markus, thanks for your advice. You are right, the best thing would be to enhance the statistical package. No, it is not about major streams only but the method is just implemented in a way that it can only deal with two confluences at one point. All the best, Mira On 11/07/18 22:01, Markus Metz wrote: On Wed, Jul 11, 2018 at 3:55 AM, Huidae Cho <mailto:gras...@gmail.com>> wrote: > > Hello, > > Not sure if I understood your question. Are you trying to extract major streams only? r.stream.extract already returns a valid stream network with confluences snapped to the main stem. Also, limiting the number of confluent streams and moving (?) streams at the confluences are two different tasks, I believe. Maybe, you need to be more specific with some examples. Limiting the number of confluent streams would conflict with both the method to determine flow directions and the method to extract streams. Moving streams at confluences a tiny little bit is IMHO a custom post-processing step. I would rather suggest to enhance the R package SSN such that it can deal with more than two streams joining at a confluence. But maybe SSN is meant to work with major streams only, in which case the threshold to extract streams would need to be increased. Markus M > > Regards, > Huidae > > > On Thu, Jul 5, 2018 at 6:40 AM, Mira Kattwinkel mailto:kattwinkel-m...@uni-landau.de>> wrote: >> >> Dear list, >> >> is there any way to limit the number of confluent streams in r.stream.extract or r.watershed? >> >> I am working with statistical models (R package SSN) that can only deal with such dichotomous networks. Currently, I am developing a method to move streams a tiny bit at the confluences to get a valid network, but I wonder if something like this already exists. That would make my life much easier. >> >> All the best, >> >> Mira >> >> --- >> >> Dr. Mira Kattwinkel >> Quantitative Landscape Ecology >> Institute for Environmental Sciences >> University of Koblenz-Landau >> Fortstraße 7 >> 76829 Landau >> Germany >> Phone: + 49 6341 280-31553 >> Office: Building I, Room 2.02 >> >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org> >> https://lists.osgeo.org/mailman/listinfo/grass-user > > > > > -- > Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP > Senior Geospatial Engineer, MapAnything > Open Source GIS Developer, GRASS GIS Development Team > > ___ > grass-user mailing list > grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org> > https://lists.osgeo.org/mailman/listinfo/grass-user -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] limit number of confluent streams in r.steam.extract or r.watershed
Dear list, is there any way to limit the number of confluent streams in r.stream.extract or r.watershed? I am working with statistical models (R package SSN) that can only deal with such dichotomous networks. Currently, I am developing a method to move streams a tiny bit at the confluences to get a valid network, but I wonder if something like this already exists. That would make my life much easier. All the best, Mira --- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot re-install Grass 7.2
I tried this but still get the same error. On 16/02/18 15:20, Moritz Lennert wrote: On 16/02/18 15:11, Moritz Lennert wrote: On 16/02/18 15:01, Mira Kattwinkel wrote: Hi, qgis-plugin-grass depends on Grass 7.2, hence when I try to install it I get the following message: mira@mira-mint ~ $ sudo apt-get install qgis-plugin-grass Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: qgis-plugin-grass : Depends: grass722 but it is not installable E: Unable to correct problems, you have held broken packages. But I'm a bit surprised by this. Looking at the ubuntugis-unstable page, I don't see any dependency to qgis-plugin-grass to grass 7.2. On the contrary, it depends on grass-core (>= 7.4.0). Maybe there was just a missing "apt-get update" before trying to install the plugin ? Try again with ubuntugis-unstable, apt-get update, apt-get upgrade and see what happens. Moritz -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot re-install Grass 7.2
Using the nightly build of QGIS did the trick. Mira On 16/02/18 15:11, Moritz Lennert wrote: On 16/02/18 15:01, Mira Kattwinkel wrote: Hi, qgis-plugin-grass depends on Grass 7.2, hence when I try to install it I get the following message: mira@mira-mint ~ $ sudo apt-get install qgis-plugin-grass Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: qgis-plugin-grass : Depends: grass722 but it is not installable E: Unable to correct problems, you have held broken packages. I think I cannot fix this from the QGIS side. You are right. This nees to be handled by the ubuntugis packagers. Unless you compile GRASS and QGIS on your own. But do you really need the plugin ? You might be able to do what you want using the access to GRASS GIS commands via the Processing toolbox in QGIS. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot re-install Grass 7.2
Hi, qgis-plugin-grass depends on Grass 7.2, hence when I try to install it I get the following message: mira@mira-mint ~ $ sudo apt-get install qgis-plugin-grass Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: qgis-plugin-grass : Depends: grass722 but it is not installable E: Unable to correct problems, you have held broken packages. I think I cannot fix this from the QGIS side. Best, Mira On 16/02/18 14:48, Markus Neteler wrote: On Fri, Feb 16, 2018 at 2:35 PM, Mira Kattwinkel <kattwinkel-m...@uni-landau.de> wrote: Dear list I would like to go back from Grass 7.4 to Grass 7.2 (because the new version is incompatible with QGIS). In which sense it is not compatibe? Better to fix that if needed. Markus -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Cannot re-install Grass 7.2
Dear list I would like to go back from Grass 7.4 to Grass 7.2 (because the new version is incompatible with QGIS). However, I have severe problems. I am running Linux Mint 18.2(Sonja). When I try to add the correct ppa I get the following: mira@mira-mint ~ $ sudo add-apt-repository ppa:ubuntugis/ubuntugis-stable Cannot add PPA: 'No JSON object could be decoded'. Changing the source manually in /etc/apt/sources.list.d/ubuntugis-ubuntugis-unstable-xenial.list to deb http://ppa.launchpad.net/ubuntugis/ubuntugis-stable/ubuntu xenial main deb-src http://ppa.launchpad.net/ubuntugis/ubuntugis-stable/ubuntu xenial main has the following effect when running sudo apt-get update: ... Err:16 http://ppa.launchpad.net/ubuntugis/ubuntugis-stable/ubuntu xenial/main Sources 403 Forbidden ... W: The repository 'http://ppa.launchpad.net/ubuntugis/ubuntugis-stable/ubuntu xenial Release' does not have a Release file. N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use. N: See apt-secure(8) manpage for repository creation and user configuration details. E: Failed to fetch http://ppa.launchpad.net/ubuntugis/ubuntugis-stable/ubuntu/dists/xenial/main/source/Sources 403 Forbidden E: Some index files failed to download. They have been ignored, or old ones used instead. Can anybody please point me into the right direction? Thanks a lot, Mira ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error in v.in.ogr with null values
Dear Jonas, thanks for your suggestion. This looks like a useful workaround but it seems to be a more general issue. Is it a wanted behaviour that it is not possible without tricks to import shapes with empty table cells? As I wrote, it used to work just fine. All the best, Mira Am 16.08.2017 um 22:41 schrieb Jeshua Lacock: On Aug 16, 2017, at 2:36 PM, Jeshua Lacock <jes...@3dtopo.com> wrote: #convert DBF to CSV file to properly handle blank fields ogr2ogr -f 'CSV' fileName.csv fileName.dbf Ooops - first line of the example should be this instead: #convert DBF to CSV file to properly handle blank fields ogr2ogr -f 'CSV' fileName.csv fileName_fixed.dbf Am 16.08.2017 um 22:36 schrieb Jeshua Lacock: On Aug 15, 2017, at 10:06 AM, Mira Kattwinkel <kattwinkel-m...@uni-landau.de> wrote: I was able to nail it down to empty cells in the attribute table (NULL). When filling those the error disappears. Have there been any changes to v.in.ogr that may cause this behaviour? Or could this be related to OGR / GDAL? Hi Mira, I am not sure if it will work for you, but I have found that when I have empty cells, I can get around the issue by converting the file to import to CSV then back using ogr2ogr. For instance (I have only done this with shape files): #convert DBF to CSV file to properly handle blank fields ogr2ogr -f 'CSV' fileName.csv fileName.dbf #convert back to DBF ogr2ogr fileName_fixed.dbf fileName.csv #back up original DBF file before replacing: mv fileName.dbf fileName_original.dbf #then move “fixed” DBF file back to original filename: mv fileName_fixed.dbf fileName.dbf I hope this helps! Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Fon: + 49 6341 280-31553 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] wrong result in v.net.iso for backward direction
Dear list members, has nobody any idea what's going on (see below)? When using forward and backward costs or only backward costs in v.net.iso the backward end (i.e. upstream) always gets too short / too few segments. Can anybody please point me into the right direction. All the best, Mira Subject:wrong result in v.net.iso for backward direction Date: Thu, 8 Jun 2017 10:46:42 +0200 From: Mira Kattwinkel <kattwinkel-m...@uni-landau.de> To: grass-user <grass-user@lists.osgeo.org> Dear list members I am using v.net.iso to split a stream network at a certain distance from sampling points. First, I create a network from vector lines (streams) and vector points (sampling sites) using v.net. The lines feature have a 'cat' column, 'length', 'backward_cost' and 'forward_cost'. I would use -1 for forward costs because I am only interested in the upstream part, and length for backward costs in v.net.iso: v.net.iso input=test_edges arc_layer=2 node_layer=3 output=test_edges_bw_2000 center_cats=55 arc_column=forw_cost arc_backward_column=backw_cost costs=2000 However, the backward part of the resulting lines with cat 1 is always too short. Likewise, if I give just 1 for the backward costs and set the costs to 5, it gets 4 segments with cat 1. Working in both directions at the same time gives correct values for the forward end, but too short for the backward end. I then realised that the numbers would be correct if the first part of the forward end was added to the backward part (see attached example). The forward part all the costs (lengths) sum up correctly to 2000 (1443.19 + 556.81). For the backward part it would be 45.72 + 511.09 = 556.81. However, if the first segment of the forward part is added, it gives the correct cost sum (45.72 + 511.09 + 1443.19 = 2000). Do I use the function in the wrong way or is this a bug? Thanks a lot, Mira URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20170608/97469a58/attachment.png> URL:<http://lists.osgeo.org/pipermail/grass-user/attachments/20170608/97469a58/attachment-0001.png> PS I just realized that it works correctly for length in both direction if the parameters arc_column and arc_backward_column are not given. However, for me this is inefficient because I only need the backward end. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] addendum: wrong result in v.net.iso for backward direction
Hello I just realized that it works correctly for length in both direction if the parameters arc_column and arc_backward_column are not given. However, for me this is inefficient because I only need the backward end. Thanks for any suggestions, Mira Forwarded Message Subject:wrong result in v.net.iso for backward direction Date: Thu, 8 Jun 2017 10:46:42 +0200 From: Mira Kattwinkel <kattwinkel-m...@uni-landau.de> To: grass-user <grass-user@lists.osgeo.org> Dear list members I am using v.net.iso to split a stream network at a certain distance from sampling points. First, I create a network from vector lines (streams) and vector points (sampling sites) using v.net. The lines feature have a 'cat' column, 'length', 'backward_cost' and 'forward_cost'. I would use -1 for forward costs because I am only interested in the upstream part, and length for backward costs in v.net.iso: v.net.iso input=test_edges arc_layer=2 node_layer=3 output=test_edges_bw_2000 center_cats=55 arc_column=forw_cost arc_backward_column=backw_cost costs=2000 However, the backward part of the resulting lines with cat 1 is always too short. Likewise, if I give just 1 for the backward costs and set the costs to 5, it gets 4 segments with cat 1. Working in both directions at the same time gives correct values for the forward end, but too short for the backward end. I then realised that the numbers would be correct if the first part of the forward end was added to the backward part (see attached example). The forward part all the costs (lengths) sum up correctly to 2000 (1443.19 + 556.81). For the backward part it would be 45.72 + 511.09 = 556.81. However, if the first segment of the forward part is added, it gives the correct cost sum (45.72 + 511.09 + 1443.19 = 2000). Do I use the function in the wrong way or is this a bug? Thanks a lot, Mira -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] wrong result in v.net.iso for backward direction
Dear list members I am using v.net.iso to split a stream network at a certain distance from sampling points. First, I create a network from vector lines (streams) and vector points (sampling sites) using v.net. The lines feature have a 'cat' column, 'length', 'backward_cost' and 'forward_cost'. I would use -1 for forward costs because I am only interested in the upstream part, and length for backward costs in v.net.iso: v.net.iso input=test_edges arc_layer=2 node_layer=3 output=test_edges_bw_2000 center_cats=55 arc_column=forw_cost arc_backward_column=backw_cost costs=2000 However, the backward part of the resulting lines with cat 1 is always too short. Likewise, if I give just 1 for the backward costs and set the costs to 5, it gets 4 segments with cat 1. Working in both directions at the same time gives correct values for the forward end, but too short for the backward end. I then realised that the numbers would be correct if the first part of the forward end was added to the backward part (see attached example). The forward part all the costs (lengths) sum up correctly to 2000 (1443.19 + 556.81). For the backward part it would be 45.72 + 511.09 = 556.81. However, if the first segment of the forward part is added, it gives the correct cost sum (45.72 + 511.09 + 1443.19 = 2000). Do I use the function in the wrong way or is this a bug? Thanks a lot, Mira -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.mask: no MASK created when using many categories
Thanks for that. So, the limitation is not the number of categories but the string that defines them? The 1 to 106 was just an example. In reality, I have various numbers with no ordering, up to more than 100 different ones. Mira On 07/04/17 10:38, Moritz Lennert wrote: On 07/04/17 09:56, Mira Kattwinkel wrote: Dear Anna, great! Thanks a lot. If I understand it correctly, the limit is now 1024. Btw, how would I update such a single function? Updating Grass does not work (linux' apt-get upgrade does not see a new version)? You have to compile GRASS yourself [1] or wait for the next release which will then show up in your distribution. But as Anna mentioned, in your case you might not need this as you could formulate your list of cats more efficiently using 'thru', i.e.: r.mask raster=basins_new@PERMANENT maskcats="1 thru 107" instead of listing them all. Or, if the series is not continuous: r.mask raster=basins_new@PERMANENT maskcats="1 thru 25 53 thru 75" Moritz [1] https://grasswiki.osgeo.org/wiki/Compile_and_Install On 07/04/17 03:53, Anna Petrášová wrote: On Thu, Apr 6, 2017 at 5:47 AM, Micha Silver <tsvi...@gmail.com> wrote: Interesting... I can duplicate the problem (but only up to 100 cats). Above that I get an error of "stack smashing": I tried to fix it in r70847 (or at least allow longer sequences, the arrays are still statically allocated). But in this case you can also use "1 thru 106". Anna GRASS 7.2.0 (ITM):~ > r.mask raster=farm_bas maskcats="`seq -s " " 1 100`" --o All subsequent raster operations will be limited to the MASK area. Removing or renaming raster map named 'MASK' will restore raster operations to normal. [Raster MASK present] GRASS 7.2.0 (ITM):~ > r.info -g MASK north=53 south=51 east=185000 west=17 nsres=4 ewres=4 rows=5000 cols=3750 cells=1875 datatype=CELL ncats=0 [Raster MASK present] But with 103 cats... GRASS 7.2.0 (ITM):~ > r.mask raster=farm_bas maskcats="`seq -s " " 1 103`" --o WARNING: MASK already exists and will be overwritten *** stack smashing detected ***: r.reclass terminated All subsequent raster operations will be limited to the MASK area. Removing or renaming raster map named 'MASK' will restore raster operations to normal. GRASS 7.2.0 (ITM):~ > r.info -g MASK ERROR: Raster map not found On 04/06/2017 12:12 PM, Mira Kattwinkel wrote: Dear Anna, dear list I used the NC basic sample data set to replicate my case. Unfortunately, I get the same problem. Can anybody give me a hint? Thanks a lot! Here is what I did and the output: r.watershed elevation=elevation@PERMANENT threshold=500 basin=basins_new SECTION 1a (of 5): Initiating Memory. SECTION 1b (of 5): Determining Offmap Flow. SECTION 2: A* Search. SECTION 3a: Accumulating Surface Flow with MFD. SECTION 3b: Adjusting drainage directions. SECTION 4: Watershed determination. SECTION 5: Closing Maps. ## creating mask with 106 categories works fine r.mask raster=basins_new@PERMANENT maskcats=1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 All subsequent raster operations will be limited to the MASK area. Removing or renaming raster map named 'MASK' will restore raster operations to normal. r.mapcalc expression=r106 = MASK r.mask -r Raster MASK removed ## creating mask with 107 categories seems to work without error but there is no MASK output r.mask raster=basins_new@PERMANENT maskcats=1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 All subsequent raster operations will be limited to the MASK area. Removing or renaming raster map named 'MASK' will restore raster operations to normal. r.mapcalc expression=m107 = MASK Invalid map Parse error ERROR: parse error g.list type=raster basins basins_new elevation elevation_shade geology lakes landuse r106 soils On 06/04/17 05:06, Anna Petrášová wrote: On Wed, Apr 5, 2017 at 8:22 AM, Mira Kattwinkel <kattwinkel-m...@uni-landau.de> wrote: Dear List, I am using r.mask to create a new raster map that only contains certain categories given in 'maskcats'. Then, I use r.mapcalc to save the map under a new name and (to be on the save side) delete the MASK with r.mask flag '-r'. I do this in a loop and it works fine until a case when the number of categories to combine is 213 (trail and error lead to 106 as the maximum number that works
Re: [GRASS-user] r.mask: no MASK created when using many categories
Dear Anna, great! Thanks a lot. If I understand it correctly, the limit is now 1024. Btw, how would I update such a single function? Updating Grass does not work (linux' apt-get upgrade does not see a new version)? Mira On 07/04/17 03:53, Anna Petrášová wrote: On Thu, Apr 6, 2017 at 5:47 AM, Micha Silver <tsvi...@gmail.com> wrote: Interesting... I can duplicate the problem (but only up to 100 cats). Above that I get an error of "stack smashing": I tried to fix it in r70847 (or at least allow longer sequences, the arrays are still statically allocated). But in this case you can also use "1 thru 106". Anna GRASS 7.2.0 (ITM):~ > r.mask raster=farm_bas maskcats="`seq -s " " 1 100`" --o All subsequent raster operations will be limited to the MASK area. Removing or renaming raster map named 'MASK' will restore raster operations to normal. [Raster MASK present] GRASS 7.2.0 (ITM):~ > r.info -g MASK north=53 south=51 east=185000 west=17 nsres=4 ewres=4 rows=5000 cols=3750 cells=1875 datatype=CELL ncats=0 [Raster MASK present] But with 103 cats... GRASS 7.2.0 (ITM):~ > r.mask raster=farm_bas maskcats="`seq -s " " 1 103`" --o WARNING: MASK already exists and will be overwritten *** stack smashing detected ***: r.reclass terminated All subsequent raster operations will be limited to the MASK area. Removing or renaming raster map named 'MASK' will restore raster operations to normal. GRASS 7.2.0 (ITM):~ > r.info -g MASK ERROR: Raster map not found On 04/06/2017 12:12 PM, Mira Kattwinkel wrote: Dear Anna, dear list I used the NC basic sample data set to replicate my case. Unfortunately, I get the same problem. Can anybody give me a hint? Thanks a lot! Here is what I did and the output: r.watershed elevation=elevation@PERMANENT threshold=500 basin=basins_new SECTION 1a (of 5): Initiating Memory. SECTION 1b (of 5): Determining Offmap Flow. SECTION 2: A* Search. SECTION 3a: Accumulating Surface Flow with MFD. SECTION 3b: Adjusting drainage directions. SECTION 4: Watershed determination. SECTION 5: Closing Maps. ## creating mask with 106 categories works fine r.mask raster=basins_new@PERMANENT maskcats=1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 All subsequent raster operations will be limited to the MASK area. Removing or renaming raster map named 'MASK' will restore raster operations to normal. r.mapcalc expression=r106 = MASK r.mask -r Raster MASK removed ## creating mask with 107 categories seems to work without error but there is no MASK output r.mask raster=basins_new@PERMANENT maskcats=1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 All subsequent raster operations will be limited to the MASK area. Removing or renaming raster map named 'MASK' will restore raster operations to normal. r.mapcalc expression=m107 = MASK Invalid map Parse error ERROR: parse error g.list type=raster basins basins_new elevation elevation_shade geology lakes landuse r106 soils On 06/04/17 05:06, Anna Petrášová wrote: On Wed, Apr 5, 2017 at 8:22 AM, Mira Kattwinkel <kattwinkel-m...@uni-landau.de> wrote: Dear List, I am using r.mask to create a new raster map that only contains certain categories given in 'maskcats'. Then, I use r.mapcalc to save the map under a new name and (to be on the save side) delete the MASK with r.mask flag '-r'. I do this in a loop and it works fine until a case when the number of categories to combine is 213 (trail and error lead to 106 as the maximum number that works fine). Flag 'verbose' gives the message that a MASK was created, but none is there. The problem arises in both cases when I directly use Grass or through R using execGrass. I tried it on landsat raster from NC sample dataset and it worked. Perhaps you could try to replicate it with this sample dataset? Anna Is there a limit in the number of categories that can be passed to r.mask? I did not find any hint about that. Additionally, I wonder why there is no error message but in the contrary one that tells me that a MASK was created even when it failed. In case the details are important (or if anybody has a better idea how to achieve what I want): I have a raster map of subcatchemts belonging to stream segments created with r.stream.basins. For the endpoints of segments, I want to combine these subcatchments to a total catchment raster map containing all upstream catchments. T
Re: [GRASS-user] Temporal framework: calculating annual 5-day extremes
Hi Richard t.rast.aggregate might be the function you are looking for. It has the method 'max'. For the cycling you might need to somehow loop over the data with different starting days. Best, Mira On 06/04/17 11:09, RichardCooper wrote: I have a time series of rainfall data, and for each year I want to calculate the five-day period with maximum rainfall. So I would need to calculate the sum of day1 to day5, then day2 to day6, then day3 to day7 etc for the whole year, and then output the maximum grid cell 5-day values for each year into a single raster. To do this in t.rast.accumulate, I can see how to set a temporal cycle of 1 year (cycle= "12 months"), but not sure how to specify such a rolling sum calculation of 5 days as described above. The default method is the 'mean' as indicated in r.series.accumulation? I'm not too sure how the accumulation is applied in the module. Best regards, Richard -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Temporal-framework-calculating-annual-5-day-extremes-tp5316014p5316076.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.mask: no MASK created when using many categories
Dear Anna, dear list I used the NC basic sample data set to replicate my case. Unfortunately, I get the same problem. Can anybody give me a hint? Thanks a lot! Here is what I did and the output: r.watershed elevation=elevation@PERMANENT threshold=500 basin=basins_new SECTION 1a (of 5): Initiating Memory. SECTION 1b (of 5): Determining Offmap Flow. SECTION 2: A* Search. SECTION 3a: Accumulating Surface Flow with MFD. SECTION 3b: Adjusting drainage directions. SECTION 4: Watershed determination. SECTION 5: Closing Maps. ## creating mask with 106 categories works fine r.mask raster=basins_new@PERMANENT maskcats=1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 All subsequent raster operations will be limited to the MASK area. Removing or renaming raster map named 'MASK' will restore raster operations to normal. r.mapcalc expression=r106 = MASK r.mask -r Raster MASK removed ## creating mask with 107 categories seems to work without error but there is no MASK output r.mask raster=basins_new@PERMANENT maskcats=1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 All subsequent raster operations will be limited to the MASK area. Removing or renaming raster map named 'MASK' will restore raster operations to normal. r.mapcalc expression=m107 = MASK Invalid map Parse error ERROR: parse error g.list type=raster basins basins_new elevation elevation_shade geology lakes landuse r106 soils On 06/04/17 05:06, Anna Petrášová wrote: On Wed, Apr 5, 2017 at 8:22 AM, Mira Kattwinkel <kattwinkel-m...@uni-landau.de> wrote: Dear List, I am using r.mask to create a new raster map that only contains certain categories given in 'maskcats'. Then, I use r.mapcalc to save the map under a new name and (to be on the save side) delete the MASK with r.mask flag '-r'. I do this in a loop and it works fine until a case when the number of categories to combine is 213 (trail and error lead to 106 as the maximum number that works fine). Flag 'verbose' gives the message that a MASK was created, but none is there. The problem arises in both cases when I directly use Grass or through R using execGrass. I tried it on landsat raster from NC sample dataset and it worked. Perhaps you could try to replicate it with this sample dataset? Anna Is there a limit in the number of categories that can be passed to r.mask? I did not find any hint about that. Additionally, I wonder why there is no error message but in the contrary one that tells me that a MASK was created even when it failed. In case the details are important (or if anybody has a better idea how to achieve what I want): I have a raster map of subcatchemts belonging to stream segments created with r.stream.basins. For the endpoints of segments, I want to combine these subcatchments to a total catchment raster map containing all upstream catchments. Thanks a lot, Mira -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.mask: no MASK created when using many categories
Dear Micha thanks for your suggestion. Actually, that's is what I usually do. However, I am not really interested in the catchment of the endpoints of the edges but in sampling points lying at the streams. If a point lies within the dem cell of the outlet, which can be a confluence of two streams, the coordinate approach will result in the catchment of both confluences, although the point lies just at one of them. That's why I came up with the idea of summing up the subcatchments of only the relevant branch of the stream network. Maybe there are other thoughts on that? Mira On 05/04/17 15:25, Micha Silver wrote: On 04/05/2017 03:22 PM, Mira Kattwinkel wrote: Dear List, I am using r.mask to create a new raster map that only contains certain categories given in 'maskcats'. Then, I use r.mapcalc to save the map under a new name and (to be on the save side) delete the MASK with r.mask flag '-r'. I do this in a loop and it works fine until a case when the number of categories to combine is 213 (trail and error lead to 106 as the maximum number that works fine). Flag 'verbose' gives the message that a MASK was created, but none is there. The problem arises in both cases when I directly use Grass or through R using execGrass. Is there a limit in the number of categories that can be passed to r.mask? I did not find any hint about that. Additionally, I wonder why there is no error message but in the contrary one that tells me that a MASK was created even when it failed. In case the details are important (or if anybody has a better idea how to achieve what I want): I have a raster map of subcatchemts belonging to stream segments created with r.stream.basins. For the endpoints of segments, I want to combine these subcatchments to a total catchment raster map containing all upstream catchments. If you have the endpoint of of the outlet segment, you might use that as the "coordinates" parameter to r.stream.basins to create a single large drainage basin. Then use that as the mask to get out the subcatchments. Thanks a lot, Mira -- Micha Silver cell: +972-523-665918 -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.mask: no MASK created when using many categories
Dear List, I am using r.mask to create a new raster map that only contains certain categories given in 'maskcats'. Then, I use r.mapcalc to save the map under a new name and (to be on the save side) delete the MASK with r.mask flag '-r'. I do this in a loop and it works fine until a case when the number of categories to combine is 213 (trail and error lead to 106 as the maximum number that works fine). Flag 'verbose' gives the message that a MASK was created, but none is there. The problem arises in both cases when I directly use Grass or through R using execGrass. Is there a limit in the number of categories that can be passed to r.mask? I did not find any hint about that. Additionally, I wonder why there is no error message but in the contrary one that tells me that a MASK was created even when it failed. In case the details are important (or if anybody has a better idea how to achieve what I want): I have a raster map of subcatchemts belonging to stream segments created with r.stream.basins. For the endpoints of segments, I want to combine these subcatchments to a total catchment raster map containing all upstream catchments. Thanks a lot, Mira -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance
Hi,
On 24/09/16 22:56, Markus Metz wrote:
On Thu, Sep 22, 2016 at 4:17 PM, Mira Kattwinkel
<kattwinkel-m...@uni-landau.de> wrote:
Dear Markus, dear List
It is much better now but still not exactly the same. Close to the outlet,
the difference in distance to the outlet is about 30 cm (Fig_1b) and in the
middle of the network it's about 80 cm (Fig_2b). The upDist raster produced
with r.stream.distance gives the exact length I would expect (for Fig_1b: 6
* sqrt(2 * 25.0235 ^2) = 212.33) while r.stream.order still results in
slightly to high values. .
That's good enough for the task I am working on but I wonder why this is the
case.
r.stream.order used single precision floating point values for easting
and northing while r.stream.distance uses double precision. This can
make a difference when calculating distances. I changed r.stream.order
with r69566 to also use double precision for distance calculations.
Can you please test after reinstalling r.stream.order? Thanks!
Yes, now the distances are exactly the same everywhere in the network.
Thank you!
Mira
Btw, I checked and my dem really has a cell size of 25.0235. I do not know
why this is the case.
Such odd numbers typically occur when raster data are reprojected with
default settings and can cause various problems (calculating extents,
distance calculations, exact export to other data formats etc). The
default settings for reprojection, e.g with r.proj -g or gdalwarp,
will produce some output (in the past I have received DEMs with
strange reprojection settings from someone else in your group), but it
is worth to fine-tune the output grid geometry (extents and
resolution) and select an appropriate resampling method which in turn
depends on the kind of input data and the desired output resolution.
Markus M
Cheers,
Mira
On 21/09/16 14:33, Markus Metz wrote:
On Wed, Sep 21, 2016 at 1:26 PM, Mira Kattwinkel
<kattwinkel-m...@uni-landau.de> wrote:
Thanks a lot!
I saw that you uploaded a revision. Can you please give me a hint how I
upgrade to the revised version of r.stream.order? I am running Linux Mint
17.3 and Windows 7.
I have fixed another bug in r.stream.order (r69543): the stream
segment lengths are now identical to the lengths of the vector lines
and the out_dist value of r.stream.order matches now the output of
r.stream.distance. BTW, any reason why the resolution is 25.023 and
not exactly 25?
Markus M
I found that there are nightly pre-built Addon executables for Windows, so I
will try that tomorrow. What about Linux? Is it sufficient to just reinstall
the addon?
All the best,
Mira
Am 21.09.2016 um 11:08 schrieb Markus Metz:
On Tue, Sep 20, 2016 at 10:53 AM, Mira Kattwinkel
<kattwinkel-m...@uni-landau.de> wrote:
Dear List
r.stream.order gives, among other output, the distance of current the
stream
init from the outlet of the catchment ('out_dist'). So for the most
downstream segment this is identical to the length of the segment.
r.stream.distance calculates the distance to the outlet and results in a
raster file. Both are based on a stream raster and a direction raster.
When I compare the results, they are slightly different, although based
on
the same input files (see the attached Fig1). The raster value is 212.33
at
the junction, while the out_dist of the line is 237.69. The difference is
one cellsize (25.023 in may example), probably due to the horizontal bit
of
the line at the end (upper right of the figure).
Yes, this horizontal bit of the line is a bug in r.stream.order, the
stream vector is leaving the current region or going into a NULL cell.
All other r.stream.* modules place the outlet on a valid cell. Fixed
in r69542.
However, this difference is
not fixed. In the middle of the network (Fig2) it is larger (81028.9 -
81002.89 = 27).
What is the difference in the middle of the network now with r69542?
Markus M
What is the reason for this difference? Is this a bug or a wanted
behaviour?
I want to extract the position of points on the network (i.e. upstream of
a
junction on the lines). To this end, I planned to use the upstream
distance
of the points and the out_dist of the segments (length(segment) -
(out_dist(segment) - upDist(point)) = position(point)).
Has anybody another idea how to accomplish this?
Thanks a lot,
Mira
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance
Dear Markus, dear List
It is much better now but still not exactly the same. Close to the
outlet, the difference in distance to the outlet is about 30 cm (Fig_1b)
and in the middle of the network it's about 80 cm (Fig_2b). The upDist
raster produced with r.stream.distance gives the exact length I would
expect (for Fig_1b: 6 * sqrt(2 * 25.0235 ^2) = 212.33) while
r.stream.order still results in slightly to high values. .
That's good enough for the task I am working on but I wonder why this is
the case.
Btw, I checked and my dem really has a cell size of 25.0235. I do not
know why this is the case.
Cheers,
Mira
On 21/09/16 14:33, Markus Metz wrote:
On Wed, Sep 21, 2016 at 1:26 PM, Mira Kattwinkel
<kattwinkel-m...@uni-landau.de> wrote:
Thanks a lot!
I saw that you uploaded a revision. Can you please give me a hint how I
upgrade to the revised version of r.stream.order? I am running Linux Mint
17.3 and Windows 7.
I have fixed another bug in r.stream.order (r69543): the stream
segment lengths are now identical to the lengths of the vector lines
and the out_dist value of r.stream.order matches now the output of
r.stream.distance. BTW, any reason why the resolution is 25.023 and
not exactly 25?
Markus M
I found that there are nightly pre-built Addon executables for Windows, so I
will try that tomorrow. What about Linux? Is it sufficient to just reinstall
the addon?
All the best,
Mira
Am 21.09.2016 um 11:08 schrieb Markus Metz:
On Tue, Sep 20, 2016 at 10:53 AM, Mira Kattwinkel
<kattwinkel-m...@uni-landau.de> wrote:
Dear List
r.stream.order gives, among other output, the distance of current the
stream
init from the outlet of the catchment ('out_dist'). So for the most
downstream segment this is identical to the length of the segment.
r.stream.distance calculates the distance to the outlet and results in a
raster file. Both are based on a stream raster and a direction raster.
When I compare the results, they are slightly different, although based
on
the same input files (see the attached Fig1). The raster value is 212.33
at
the junction, while the out_dist of the line is 237.69. The difference is
one cellsize (25.023 in may example), probably due to the horizontal bit
of
the line at the end (upper right of the figure).
Yes, this horizontal bit of the line is a bug in r.stream.order, the
stream vector is leaving the current region or going into a NULL cell.
All other r.stream.* modules place the outlet on a valid cell. Fixed
in r69542.
However, this difference is
not fixed. In the middle of the network (Fig2) it is larger (81028.9 -
81002.89 = 27).
What is the difference in the middle of the network now with r69542?
Markus M
What is the reason for this difference? Is this a bug or a wanted
behaviour?
I want to extract the position of points on the network (i.e. upstream of
a
junction on the lines). To this end, I planned to use the upstream
distance
of the points and the out_dist of the segments (length(segment) -
(out_dist(segment) - upDist(point)) = position(point)).
Has anybody another idea how to accomplish this?
Thanks a lot,
Mira
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Mira Kattwinkel
Quantitative Landscape Ecology
Institute for Environmental Sciences
University of Koblenz-Landau
Fortstraße 7
76829 Landau
Germany
Fon: + 49 6341 280-31553
--
Dr. Mira Kattwinkel
Quantitative Landscape Ecology
Institute for Environmental Sciences
University of Koblenz-Landau
Fortstraße 7
76829 Landau
Germany
Phone: + 49 6341 280-31553
Office: Building I, Room 2.02
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance
Thanks a lot!
I saw that you uploaded a revision. Can you please give me a hint how I
upgrade to the revised version of r.stream.order? I am running Linux
Mint 17.3 and Windows 7.
I found that there are nightly pre-built Addon executables for Windows,
so I will try that tomorrow. What about Linux? Is it sufficient to just
reinstall the addon?
All the best,
Mira
Am 21.09.2016 um 11:08 schrieb Markus Metz:
On Tue, Sep 20, 2016 at 10:53 AM, Mira Kattwinkel
<kattwinkel-m...@uni-landau.de> wrote:
Dear List
r.stream.order gives, among other output, the distance of current the stream
init from the outlet of the catchment ('out_dist'). So for the most
downstream segment this is identical to the length of the segment.
r.stream.distance calculates the distance to the outlet and results in a
raster file. Both are based on a stream raster and a direction raster.
When I compare the results, they are slightly different, although based on
the same input files (see the attached Fig1). The raster value is 212.33 at
the junction, while the out_dist of the line is 237.69. The difference is
one cellsize (25.023 in may example), probably due to the horizontal bit of
the line at the end (upper right of the figure).
Yes, this horizontal bit of the line is a bug in r.stream.order, the
stream vector is leaving the current region or going into a NULL cell.
All other r.stream.* modules place the outlet on a valid cell. Fixed
in r69542.
However, this difference is
not fixed. In the middle of the network (Fig2) it is larger (81028.9 -
81002.89 = 27).
What is the difference in the middle of the network now with r69542?
Markus M
What is the reason for this difference? Is this a bug or a wanted behaviour?
I want to extract the position of points on the network (i.e. upstream of a
junction on the lines). To this end, I planned to use the upstream distance
of the points and the out_dist of the segments (length(segment) -
(out_dist(segment) - upDist(point)) = position(point)).
Has anybody another idea how to accomplish this?
Thanks a lot,
Mira
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Mira Kattwinkel
Quantitative Landscape Ecology
Institute for Environmental Sciences
University of Koblenz-Landau
Fortstraße 7
76829 Landau
Germany
Fon: + 49 6341 280-31553
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problems with v.to.db after breaking with v.edit
Hello Thanks for the advice. The first step suggested does produce a new vector map with the old information in layer 1 and new categories in layer 2 (nothing else). However, I do not understand the 2nd step. Do you really mean to connect table2 (I guess that is the one belonging to map2) to map2? It is already connected. Connecting it to map_of_vedit also does not work (i.e. nothing happens): 0 categories read from vector map (layer 2) 7759 records selected from table (layer 2) 0 records updated/inserted (layer 2) Current attribute table links: Maybe I should give a bit more information: I have a stream network with a few junctions with more than two inflows. For the things I want to do afterwards, only two inflows are allowed. Therefore, I cut the outflow segment close to the junction and reconnect one of the inflows to the cut point to create a new junction with only tow inflows (the moved one and the short bit of the old outflow). Now I need to correct the relations of the streams (originally output of r.stream.order with columns stream, next, prev_str01, prev_str02,...). To this end, I want to change the stream id of the new shorter bit. To do this I have to calculate the lengths of the pieces, which seems not to work properly because the two pieces of the cut segment have the same cat. Has anybody another idea? Mira On 12/08/16 05:38, Daniel Torres wrote: Does this helps you? v.category input=map_of_vedit output=map2 option=add layer=2 v.db.addtable map=map2 layer=2 table=table2 In that way you preserve original information in layer1, and new categories in layer2 Hopefully that will be useful. Maybe someone has a better idea. Daniel >Dear list >I break a number of features in a vector map into two pieces using >v.edit, tool=break and specific coordinates. This results in two parts >with identical attributes after breaking (which is what I want) but also >the cat is identical. >I think, this is the reason why I get exactly the same length for the >two parts when calculating it using v.to.db, tool=length. Likewise, the >end coordinates cannot be computed as there is more than one element for >some categories. >How can I update the category to unique values for each feature? >Thanks for any suggestions, >Mira -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.stream.segement: DBMI-SQLite driver errors
Dear list
When using r.stream.segment with specific combinations of the length and
skip parameters (skip = 0 and length >5) I get the following error message:
DBMI-SQLite driver error:
Error in sqlite3_prepare():
no such column: inf
DBMI-SQLite driver error:
Error in sqlite3_prepare():
no such column: inf
ERROR: Unable to inset new row: 'insert into streams_sectors_g5 values(
3, 3, 1, 3303, 180, 5.00896e-06, 0, 0, null, 51.465, 51.572, -0.106998,
-inf )'
When subsequently trying (with the --overwrite flag) other values for
length and skip that used to work before, I get also an error:
DBMI-SQLite driver error:
Error in sqlite3_prepare():
table streams_sectors_g5 already exists
DBMI-SQLite driver error:
Error in sqlite3_prepare():
table streams_sectors_g5 already exists
ERROR: Unable to create table: 'create table streams_sectors_g5 (cat
integer, segment integer, sector integer, s_order integer, direction
double precision, azimuth double precision, length double precision,
stright double precision, sinusoid double precision, elev_min double
precision, elev_max double precision, s_drop double precision, gradient
double precision)'
Hence, it seems that the table is locked due to the first failure.
When calling the same functions from R using execGRASS and --verbose
flag, the error is even less informative:
Error in execGRASS("r.stream.segment", flags = c("overwrite",
"verbose"), :
The command:
r.stream.segment --overwrite --verbose stream_rast=streams_r
direction=dirs elevation=dem segments=streams_segments20
sectors=streams_sectors20 length=10 skip=0
produced an error (1) during execution:
All in RAM calculation...
Reading raster map ...
Reading raster map ...
99
and
Error in execGRASS("r.stream.segment", flags = c("overwrite",
"verbose"), :
The command:
r.stream.segment --overwrite --verbose stream_rast=streams_r
direction=dirs elevation=dem segments=streams_segments20
sectors=streams_sectors20 length=1 skip=0
produced an error (1) during execution:
All in RAM calculation...
Reading raster map ...
Reading raster map ...
9
Is this an error in my settings or maybe a bug in the r.stream.segment
function?
I am using GRASS 7.0.4 and rgrass7 on Linux Mint 17.3.
Thanks for any suggestions,
Mira
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
