Re: [GRASS-user] Global Hydrological modeling with r.watershed, r.stream.extract, r.stream.extract
Dear all, after several tests and a bit of inverse-engineering, Longzhu and I have understood the reason of such as a small difference in the delineation of the polygons basins. All the process beyond r.watershed are computed in 3x3 moving window (e.g. slope, flow accumulation, etc.), therefore if we change the extent of study area we change the starting point of the mowing window and of course the values of the flow accumulation change a bit. These changes in the flow accumulation cause variation on the delineations of the basin borders, of adjacent tiles. The reason, it is a bit obvious but did not come into my mind, immediately. Now I'm trying to figure out a clever way to merge these flow accumulations that come from different tiles and that are slightly different. Ciao Giuseppe On Fri, 5 Jun 2020 at 02:21, Markus Neteler wrote: > Hi Giuseppe, > > On Wed, May 13, 2020 at 2:16 AM Giuseppe Amatulli > wrote: > > > > Hi Markus, > > > > I use GRASS 7.6.0 > > under a HPC running > > Distributor ID: RedHatEnterpriseServer > > Description: Red Hat Enterprise Linux Server release 7.7 (Maipo) > > Release: 7.7 > > Codename: Maipo > > > > The compression is: > > > > GRASS 7.6.0 (nc_spm_08_grass7):~ > r.compress -p map=flow > > is compressed (method 5: ZSTD). Data type: DCELL > > has a compressed NULL file > > [Raster MASK present]. > > > > My option in selecting r.watershed with out the -m is manly due to be > able to use the -b option and also be able to run the tile-computation in 6 > hours vs several days (probably weeks) of the full globe (or continents) > run in segmentation mode - made quit hard to do debugging and re-running. > > > > Do you have any suggestions for the mismatching of the borders? > > I have no idea but it is recommended to update to GRASS GIS 7.8.3. > > Best, > markusN > -- Giuseppe Amatulli, Ph.D. Research scientist at School of Forestry & Environmental Studies Center for Research Computing Yale University New Haven, CT, USA 06511 Teaching: http://spatial-ecology.net Work: https://environment.yale.edu/profile/giuseppe-amatulli/ ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] about r.threhold
Dear Grass community First of all thanks for this great piece of software such as GRASS GIS!Recently I have been using the r.threshold module to extract a river networks at different DTM resolutions and different areal extent. I noticed that r.threshold values varies widely as a function DEM resolution and extent of watershed (areal extent). So , I have some questions, and hope someone in the community can shed some light on them. Looking at the description of the module it says : "This approach provides a best guess about what makes sense when looking only at the DEM" Question 1: means that the results of the r.threshold module will depend on the resolution and the extent of the watershed? Looking at the source code, I realised that r.threshold used r.stats to generate a flowacc text.file ordered in ascendent order and put into a matrix called mappatella, with 3 columns defined as: mappatella is a matrix, in the first column the value of upslope area is stored, in the second the number of cells, in the third the distance from origin is calculated further in the script the distance is defined as : calculating distance from origin of each point; origin of the plot is in low left point Question 2 : which is the origin? is the center of a cell of the corner of a cell?Question 3: which plot? and why the low left point of the plot? Although I understand the general aspect of the module I still struggle to understand its details. I would appreciate some explanation to crarify it further, since I am using it as part of workflow within GRASS GIS to produce inputs to a Distance Distribution Dynamics( DDD) model for urban enviroments. https://onlinelibrary.wiley.com/doi/full/10.1002/hyp.10315?casa_token=ETYV_ojgMb4A%3AMWgGgX_jqbylpF6pHLoafciVZrlmCBiLCmxb7gRpsCV1F3SY7QQmOkBOIrhLzhj5BFCDSLobabm7Xw Any help would be appreciated. Thanks in advance ! Best regards Rengifo Ortega ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] i.segment vs. i.segment.gsoc
On 11/06/20 13:36, mbrauch...@posteo.de wrote: Thank you for the explanation! I assumed gsoc version is build upon i.segment. Is there any way to include the shape parameters in i.segment? I am very fond of the gsoc version as it helps surpress segments growing to very complex geometries (shadows through the forest patches for example). There was some reasons why the shape parameters were not integrated in i.segment, but I can't remember why. Some code is actually there, but currently it is not used. MarkusM, do you remember ? And how complicated would it be to integrate them ? Moritz Kind regards, Melanie On Jun 11, 2020 12:52 PM, Moritz Lennert wrote: i.segment.gsoc is the original version developed during GSoC. i.segment is ann optimized version that was originally based on the GSoC work, but has known different developments since, including in the way the threshold parameter is applied. I would recommend using i.segment. Moritz Am 10. Juni 2020 13:13:33 MESZ schrieb mbrauch...@posteo.de: >Hello list, >I am working on segmentation of aerial imagery in forest areas and have > >used both modules (i.segment and i.segment.gsoc) for some experiments. >When running i.segment and i.segment.gsoc with radioweight = 1 on the >same dataset with a threshold of 0.3, I assumed the output should be >similar, but it isn't. >In the manual of i.segment.gsoc it is stated that the threshold will be > >multiplied by the number of rasters in the image group, so I tried a >threshold of 0.1 in i.segment.gsoc vs a threshold of 0.3 in i.segment >as >I have 3 rasters in my image group. Although the results are now more >similar, they still vary a lot. >I have attached the images to show the derived segments from i.segment >0.3 and i.segment.gsoc 0.1. Can someone help me to understand why this >is happening? I would appreciate it. >Kind regards, >Melanie Brauchler ___ 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] about r.threhold
Dear Rengifo Ortega, On Thu, Jun 11, 2020 at 1:08 PM Rengifo Ortega wrote: > Dear Grass community > > First of all thanks for this great piece of software such as GRASS GIS! > Recently I have been using the r.threshold module to extract a river > networks at different DTM resolutions and different areal extent. I > noticed that r.threshold values varies widely as a function DEM > resolution and extent of watershed (areal extent). So , I have some > questions, and hope someone in the community can shed some light on them. > > Looking at the description of the module it says : "This approach > provides a *best guess *about what makes sense when looking only at the > DEM" > > Question 1: means that the results of the r.threshold module will > depend on the resolution and the extent of the watershed? > > Looking at the source code, I realised that r.threshold used r.stats to > generate a flowacc text.file ordered in ascendent order and put into a > matrix called mappatella, with 3 columns defined as: > > *mappatella is a matrix, in the first column the value of upslope area is > stored, * > > > *in the second the number of cells, in the third the distance from origin > is calculated* > > further in the script the distance is defined as : > > > *calculating distance from origin of each point; origin of the plot is in > low left point * > > > Question 2 : which is the origin? is the center of a cell of the > corner of a cell? > Question 3: which plot? and why the low left point of the plot? > > Although I understand the general aspect of the module I still struggle > to understand its details. I would appreciate some explanation to crarify > it further, since I am using it as part of workflow within GRASS GIS to > produce inputs to a Distance Distribution Dynamics( DDD) model for urban > enviroments. > https://onlinelibrary.wiley.com/doi/full/10.1002/hyp.10315?casa_token=ETYV_ojgMb4A%3AMWgGgX_jqbylpF6pHLoafciVZrlmCBiLCmxb7gRpsCV1F3SY7QQmOkBOIrhLzhj5BFCDSLobabm7Xw > > Thank you for your interest in r.threshold. It's been written some time ago but the principle is the following: in order to find the point "where the stream begins" you can look at where you have an abrupt change in the slope and flow accumulation increases. In order to do that, you can plot slope and flow accumulation in a graph and pick the point that is the closest to the origin. This is a very naive and preliminary guess but somehow allows to start from a plausible value in order to find a better threshold. Hope this helps Kind regards, Any help would be appreciated. > Thanks in advance ! > > Best regards > Rengifo Ortega > > > > > > > > -- Margherita Di Leo ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] i.segment vs. i.segment.gsoc
Thank you for the explanation! I assumed gsoc version is build upon i.segment.Is there any way to include the shape parameters in i.segment? I am very fond of the gsoc version as it helps surpress segments growing to very complex geometries (shadows through the forest patches for example). Kind regards,MelanieOn Jun 11, 2020 12:52 PM, Moritz Lennert wrote:i.segment.gsoc is the original version developed during GSoC. i.segment is ann optimized version that was originally based on the GSoC work, but has known different developments since, including in the way the threshold parameter is applied. I would recommend using i.segment. Moritz Am 10. Juni 2020 13:13:33 MESZ schrieb mbrauch...@posteo.de: >Hello list, >I am working on segmentation of aerial imagery in forest areas and have > >used both modules (i.segment and i.segment.gsoc) for some experiments. >When running i.segment and i.segment.gsoc with radioweight = 1 on the >same dataset with a threshold of 0.3, I assumed the output should be >similar, but it isn't. >In the manual of i.segment.gsoc it is stated that the threshold will be > >multiplied by the number of rasters in the image group, so I tried a >threshold of 0.1 in i.segment.gsoc vs a threshold of 0.3 in i.segment >as >I have 3 rasters in my image group. Although the results are now more >similar, they still vary a lot. >I have attached the images to show the derived segments from i.segment >0.3 and i.segment.gsoc 0.1. Can someone help me to understand why this >is happening? I would appreciate it. >Kind regards, >Melanie Brauchler ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] i.segment vs. i.segment.gsoc
i.segment.gsoc is the original version developed during GSoC. i.segment is ann optimized version that was originally based on the GSoC work, but has known different developments since, including in the way the threshold parameter is applied. I would recommend using i.segment. Moritz Am 10. Juni 2020 13:13:33 MESZ schrieb mbrauch...@posteo.de: >Hello list, >I am working on segmentation of aerial imagery in forest areas and have > >used both modules (i.segment and i.segment.gsoc) for some experiments. >When running i.segment and i.segment.gsoc with radioweight = 1 on the >same dataset with a threshold of 0.3, I assumed the output should be >similar, but it isn't. >In the manual of i.segment.gsoc it is stated that the threshold will be > >multiplied by the number of rasters in the image group, so I tried a >threshold of 0.1 in i.segment.gsoc vs a threshold of 0.3 in i.segment >as >I have 3 rasters in my image group. Although the results are now more >similar, they still vary a lot. >I have attached the images to show the derived segments from i.segment >0.3 and i.segment.gsoc 0.1. Can someone help me to understand why this >is happening? I would appreciate it. >Kind regards, >Melanie Brauchler ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
