Re: [GRASS-user] r.watershed identify inland watershed
I'm on mobile and can't fully reply, but isn't there an r.lakes or r.fill module (possibly add on) that does this? Generic answer: r.watershed is the wrong tool, but GRASS has support for this. Please excuse brevity. Sent from tiny pocket computer with non-haptic feedback keyboard. On Mon, Mar 29, 2021, 11:40 Micha Silver wrote: > 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 > ___ 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.select incredibly slow
Hi Moritz, thank you again for your explanations. I have a basic understanding of topological and other formats (even if it does not always look like that -:). I have some python scripts with GRASS commands for important tasks, but I do not use the GRASS ui on a day-to-day basis. That is why I am not familiar with all concepts and terms. To sum things up: - the initial problem (v.select) is solved (thank you again), I found my error and I will try the newer versions - QGIS and shapefiles are NOT topological, but GRASS and its maps are - I cannot work topologically with QGIS, but I can view GRASS maps: # a simple GRASS map with boundaries and centroids is shown as area polygons in QGIS (no lines) # I have a GRASS map that is shown with such polygons PLUS lines in QGIS # GRASS v.info tells me there are bounds and cents, but no lines in that same map -> that is what I do not understand # maybe the reason is that QGIS maps GRASS items into something else. What I'd like to learn is: How can I create a GRASS map with boundaries, centroids and clean lines from polygon shapes? As easy and streamlined as possible? Ages ago, when I worked with ARC/INFO Coverages, there was the CLEAN command: - you could use CLEAN with the ARC option and it writes clean arcs (=lines) to the coverage - you could use CLEAN with the POLY option on the same coverage and it writes out polygons, which exist along with the arcs. Is there a way to do it similar in GRASS? Maybe v.to.lines? Best regards, Uwe -Ursprüngliche Nachricht- Von: Moritz Lennert [mailto:mlenn...@club.worldonline.be] Gesendet: Montag, 29. März 2021 16:22 An: Uwe Fischer ; grass-user@lists.osgeo.org Betreff: Re: AW: [GRASS-user] v.select incredibly slow Hi Uwe, On 29/03/21 15:59, Uwe Fischer wrote: > Hi Moritz, > > for the question about lines and polys: I believe that confusion may come up > when one looks at a GRASS dataset in the QGIS browser panel (please see > attachment): there are lines and polygons in one map! And I can load them > exactly that way in QGIS. That is: when I load the lines in QGIS, I only get > lines! GRASS GIS' vector format supports mixing all types of features in one single map, so you can have points, lines and areas (boundary lines + centroids) in one single map. The shapefile format does not support this. AFAIK, QGIS follows the shapefile logic and does not allow different geometry types in one single layer. Any area map in GRASS GIS can actually be represented in three ways: 1) As what we generally would call polygons 2) The lines that constitute the contours of these polygons (called boundaries in GRASS GIS) 3) Points that lie within the polygon (and are called centroids in GRASS GIS, although they are not necessarily actual centroids in the geometrical sense) QGIS only provides 1 & 2. You can see the effect of this format by playing around with 'type' option in d.vect, directly in GRASS GIS. > > And they ARE lines. That means: when I select a linear feature that > separates two areas with the mouse, I select only one feature! (attachment) > Were they boundaries, the mouse would grab two features, one for the left and > one for the right area?? Again, in GRASS GIS boundaries are lines, not polygons. And in QGIS they are displayed as simple lines. Because of its topological data format GRASS GIS does not have the notion of polygons as such. It has the notion of areas which are the combination of a boundary line with a centroid. Boundary lines without centroids are not considered areas aka polygons. AFAIK, QGIS does not support topological formats as such and so the topological vector format of GRASS GIS (with points, centroids, lines, boundaries, (virtual) areas) is mapped into simple features in QGIS: points, lines, polygons. If you want to make use of the GRASS GIS' topological format directly, you will have to use GRASS GIS. > > Maybe it has to do with the way the dataset was imported: it came via > v.in.ogr using CAD data made up of lines and points using > type='centroid,boundary'. > > On the other hand, GRASS v.info for that same map gives me: > > v.info -t map=forst_f_035980@lwk_work > nodes=86 > points=0 > lines=0 > boundaries=109 > centroids=42 > areas=43 > islands=20 > primitives=151 > map3d=0 > > No line features at all ! > > So is the QGIS representation misleading? How can QGIS see lines while GRASS > does not? > Boundaries are lines which have a special status. But geometrically they are lines, not polygones. > On the other hand, I learned from your example that v.select can use > boundaries as linear features. I checked the same for v.buffer and found that > it works: for type=boundary, v.buffer will put out tubular buffers around > linear features (it will not buffer the areas as a whole!) I did not expect > that, because I thougt that buffering boundarys gives me area buffers, since > the bound
Re: [GRASS-user] v.select incredibly slow
Hi Uwe, On 29/03/21 15:59, Uwe Fischer wrote: Hi Moritz, for the question about lines and polys: I believe that confusion may come up when one looks at a GRASS dataset in the QGIS browser panel (please see attachment): there are lines and polygons in one map! And I can load them exactly that way in QGIS. That is: when I load the lines in QGIS, I only get lines! GRASS GIS' vector format supports mixing all types of features in one single map, so you can have points, lines and areas (boundary lines + centroids) in one single map. The shapefile format does not support this. AFAIK, QGIS follows the shapefile logic and does not allow different geometry types in one single layer. Any area map in GRASS GIS can actually be represented in three ways: 1) As what we generally would call polygons 2) The lines that constitute the contours of these polygons (called boundaries in GRASS GIS) 3) Points that lie within the polygon (and are called centroids in GRASS GIS, although they are not necessarily actual centroids in the geometrical sense) QGIS only provides 1 & 2. You can see the effect of this format by playing around with 'type' option in d.vect, directly in GRASS GIS. And they ARE lines. That means: when I select a linear feature that separates two areas with the mouse, I select only one feature! (attachment) Were they boundaries, the mouse would grab two features, one for the left and one for the right area?? Again, in GRASS GIS boundaries are lines, not polygons. And in QGIS they are displayed as simple lines. Because of its topological data format GRASS GIS does not have the notion of polygons as such. It has the notion of areas which are the combination of a boundary line with a centroid. Boundary lines without centroids are not considered areas aka polygons. AFAIK, QGIS does not support topological formats as such and so the topological vector format of GRASS GIS (with points, centroids, lines, boundaries, (virtual) areas) is mapped into simple features in QGIS: points, lines, polygons. If you want to make use of the GRASS GIS' topological format directly, you will have to use GRASS GIS. Maybe it has to do with the way the dataset was imported: it came via v.in.ogr using CAD data made up of lines and points using type='centroid,boundary'. On the other hand, GRASS v.info for that same map gives me: v.info -t map=forst_f_035980@lwk_work nodes=86 points=0 lines=0 boundaries=109 centroids=42 areas=43 islands=20 primitives=151 map3d=0 No line features at all ! > > So is the QGIS representation misleading? How can QGIS see lines while GRASS does not? > Boundaries are lines which have a special status. But geometrically they are lines, not polygones. On the other hand, I learned from your example that v.select can use boundaries as linear features. I checked the same for v.buffer and found that it works: for type=boundary, v.buffer will put out tubular buffers around linear features (it will not buffer the areas as a whole!) I did not expect that, because I thougt that buffering boundarys gives me area buffers, since the boundaries are the area borders. Creating buffers around "areas" will give you area buffers, creating buffers around boundaries will give you exactly that: buffers around the lines that are defined as boundary lines. Have you had the opportunity to read through https://grass.osgeo.org/grass78/manuals/vectorintro.html#vector-model-and-topology ? And for the data conversion tasks: such tasks come up in my projects from time to time. You are right, there are only lines or only polygons in a shapefile. But I sometimes need to perform typical polygon tasks first (like selecting by attributes or dissolving or buffering) and then line tasks on the same dataset (like retrieving the clean lines, broken up and without duplicates or other errors for exporting and further processing in CAD). The second part cannot be done with boundaries, right? That is why i was looking for a good way to deal with both. Most GRASS GIS vector commands allow you to choose which aspect of the vector map you want to work with, generally through a 'type' parameter. This allows to do what I showed you with v.select, but also with v.buffer, v.clean, etc. When you change boundaries, however, you have to be aware that you might change them in a way that you break topology. So some additional care might be necessary. Moritz -Ursprüngliche Nachricht- Von: Moritz Lennert [mailto:mlenn...@club.worldonline.be] Gesendet: Montag, 29. März 2021 12:01 An: Uwe Fischer ; grass-user@lists.osgeo.org Betreff: Re: [GRASS-user] v.select incredibly slow Hi Uwe, On 29/03/21 09:53, Uwe Fischer wrote: But it led me again to some kind of misunderstanding that I cannot figure out: My data are imported from polygon shapefiles. First question: using v.in.ogr, what does the "type=" parameter mean exactly? In the manual, it reads: "Optionally change d
Re: [GRASS-user] v.select incredibly slow
Hi Uwe, On Mon, Mar 29, 2021 at 9:54 AM Uwe Fischer wrote: > > Hi Moritz & hi list, > > shame on me, I use 7.0.4. It has to do with some old clumsy scripts I > produced and I never found the time to update > (I'm not a GRASS professional or programmer, so things are quite hard for > me). I am sure the v.select issue has to do with the old version. I will try > soon with a newer one. If you need support with the update, let us know. Likely only minor changes are needed. It is definitely worth to reach GRASS GIS 7.8.x! Best, Markus -- Markus Neteler, PhD https://www.mundialis.de - free data with free software https://grass.osgeo.org https://courses.neteler.org/blog ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.select incredibly slow
Hi Moritz & hi list,
shame on me, I use 7.0.4. It has to do with some old clumsy scripts I produced
and I never found the time to update (I'm not a GRASS professional or
programmer, so things are quite hard for me). I am sure the v.select issue has
to do with the old version. I will try soon with a newer one.
Furthermore, I changed the way the tubular buffers are prepared and now I have
a much smaller and better fitting number of buffers. That helped a lot.
The trash output was produced by me myself because i did something wrong in
preparing the data before they went into v.select. Problem is solved.
But it led me again to some kind of misunderstanding that I cannot figure out:
My data are imported from polygon shapefiles.
First question: using v.in.ogr, what does the "type=" parameter mean exactly?
In the manual, it reads: "Optionally change default input type". But imho, the
input is the input. You cannot change it. What can be changed is the output or
the way you process the input. This question prevents me from really
understanding what v.in.ogr does with my polygons.
Second question: I thought a GRASS map is able to hold areas and lines together
in one map at the same time. How can I achieve such a mixed map using v.in.ogr
from my polygon Shapes?
When I use it without "type=", it will produce polys only.
When I use it with "type=line", it will produce lines only, some of which are
holding former area attributes (which makes no sense for lines)
When I use it with "type=line, boundary", it will also produce lines only.
Using "type=centroid, boundary" makes no sense because the input polygon
shapefile has only polygons, but no centroids.
Maybe I have to go another way?
Thanks for help and best regards,
-Ursprüngliche Nachricht-
Von: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
Gesendet: Sonntag, 28. März 2021 13:50
An: grass-user@lists.osgeo.org; Uwe Fischer
Betreff: Re: [GRASS-user] v.select incredibly slow
Hi Uwe,
Am 27. März 2021 14:58:01 MEZ schrieb Uwe Fischer :
>Hello list,
>
>I have trouble selecting line features using their location compared to
>a polygon layer using v.select. The line features I want to select from
>are parcel borders, and the polygon layer is made up of tubular-shaped
>buffers around municipal borders. I need to find the parcel borders
>which are inside this buffer.
>
>The command line in a Python script I use is:
>
>grass.run_command('v.select', ainput='temp5', atype='line',
>binput='buff', blayer=1, btype='area', output='grenz',
>operator='within', overwrite=True)
>
>The process starts, but it runs incredibly slow (> 15 min) and it
>brings not the desired result (but trash data). When I start it in the
>GRASS ui, it also works very very slow.
>
>I have only about 2000 parcel borders, so it cannot be a problem of too
>much features. Furthermore, the exact same selection task is processed
>in QGIS 3 in a second with perfect results.
>
>I used v.build on both maps before v.select, but it does not help.
>
>I would like to perform it in GRASS because it is part of a bigger data
>preparation script which makes my work a lot easier. So I need to
>integrate it here rather than selecting in QGIS manually.
First of all: which version of GRASS GIS are you using ?
I filed a bug about this same issue a few years ago [1] and Markus Metz
reorganized the code at the time to speed things up. I don't remember which
version was the first to include the fixes (7.6 ?). However, even though it was
slow, results were ok which doesn't seem to be the case for you, so that is a
bit worrying.
Can you reproduce the same issue with the example given in that bug report ? If
not can you provide a reproducible example, including relevant data ? Ideally
as a GitHub issue ?
As a workaround you could try either the alternative provided in the bug
report, or you could try to reduce the number of line candidates first using
v.select operator=overlap and using operator=within only on those selected in
the first call.
Moritz
[1] https://trac.osgeo.org/grass/ticket/3361
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
