[GRASS-user] How can I remove steps artefacts in digital elevation model?
Hello everyone I have a problem with an artefact in the dem I build from the data as a geopackage here https://www.dropbox.com/scl/fi/7vzgupxszpg2sw7ib08p4/point_survey.gpkg?rlkey=7u1bv3rx8vcvkruq6z8zeezf0=0 the problem has already described here https://www.mail-archive.com/grass-user@lists.osgeo.org/msg40869.html in which I had operated with "v.surf.rst --overwrite input=point_survey zcolumn=z elevation=dem mask=MASK tension=36. smooth_column=rms segmax=500 npmin=600 dmin=0.5 dmax=5" First of all I deleted dmax from v.surf.rst. Now I have tried raising the tension, even by a lot, but it does not change. I tried lowering the tension, but the steps still occur. Then I tried v.surf.rst on a higher resolution, at 5 cm, and then resample to 20 cm. I tried with r.resample.interpol, r.resample.rst and r.resample.tsp, with various parameters, various interpolation methods, various tensions or various smoothness indices, but I was unable to create a profile without these artefacts, which are in the order of only a few centimetres, but enough to create problems in the simulation with r.sim.water. I finally tried another approach: I created the contours, transformed the vector to raster, at a resolution of 5 cm (to get thin contours) and then used r.fillnulls to a 20 cm resolution region. With method=rst (which is the default) it gives me an error: "Growing NULL areas Assigning IDs to NULL areas Processing 1 map holes Filling hole 1 of 1 ERROR: Invalid input " With method=bicubic it works but makes the steps. r.resample.bspline create other artefacts at the limit of the calculation regions. I should probably try anisotropy in v.surf.rst? Anyone have a solution? Thank you thank you!! -- -- Perito agrario Enrico Gabrielli progetto F.A.R.M. www.farm-agroecologia.it Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://www.inaturalist.org/observations/bonushenricus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] How can I remove step artefacts in digital elevation model? Re: how to calculate volume of water stored in water storage with r.sim.water?
Hello again. I continue with my process of "How to calculare volume of water stored in water storage" but with a change in object. I was able to improve my final dem again, by improving the ditch profile, through a script based on this discussion https://www.mail-archive.com/grass-user@lists.osgeo.org/msg40844.html But still the simulation with hmax=1 poses problems for the dem I built. I didn't have that many points in the survey. Ponds form in the simulation with water_depths up to almost 1m, along the ditches. I attach a pdf of a profile of 7 metres. In red is the ditch I managed to obtain with the script based on the discussion above linked, much better than the old ditch in blue. The problem is the dem on which this ditch interacts. The dem is built with "v.surf.rst --overwrite input=point_survey zcolumn=z elevation=dem mask=MASK tension=36. smooth_column=rms segmax=500 npmin=600 dmin=0.5 dmax=5" Tension 36. is taken from a validation script. To smooth it I tried to reconstruct it with r.surf.contour, after creating a contour with resolution 0.05, level at 0.1. I tried to make from this an r.resample.rst with tension 50. The result, however, is not good. What can I do to remove the steps? Thanks -- -- Perito agrario Enrico Gabrielli progetto F.A.R.M. www.farm-agroecologia.it Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://www.inaturalist.org/observations/bonushenricus Il giorno dom, 06/08/2023 alle 07.09 +0200, bonushenricus ha scritto: > Hello > I made two better digital elevation models for my tests, > here https://cubeatic.com/index.php/s/dYzjRdLGD7wksQt attached. > There are two designs, each with a pond about 1 metre deep, the same > position on the slope, and two ditches reaching the pond. > One design has a pond with a surface area of 63m², and the other has > a surface area of 131m², with a depth of about 1 metre, with a volume > of 52m³ and 118m³, respectively. > I expect that having the same slope and ditches upstream, the two > ponds will be filled with a similar volume of water. > Seen infil_rast for make waterproof the ponds doesn't run, I tried > using flow_control, and it work. > And I tried with hmax=1 > Here the "script" (after import geotiff attached) > > r.lake --overwrite elevation=dem_pondB water_level=480.7 lake=pondB > > coordinates=687064.2576117209,4910526.453118301 > > #results 118m³ 131m² > > r.lake --overwrite elevation=dem_pondA water_level=480.9 lake=pondA > > coordinates=687064.2576117209,4910526.453118301 > > #results 52m³ 63m² > > r.mapcalc expression="flow_control_pondA = if(pondA,0)" --overwrite > > r.mapcalc expression="flow_control_pondB = if(pondB,0)" --overwrite > > r.slope.aspect --overwrite elevation=dem_pondB dx=dx_pondB > > dy=dy_pondB > > r.slope.aspect --overwrite elevation=dem_pondA dx=dx_pondA > > dy=dy_pondA > > r.mask raster=dem_pondA > > r.sim.water --overwrite -t elevation=dem_pondB dx=dx_pondB > > dy=dy_pondB rain_value=40 infil_value=15 man=manning > > flow_control=flow_control_pondB hmax=1 > > depth=water_depth_pondB_40x30mm discharge=discharge_pondB_40x30mm > > niterations=30 output_step=5 random_seed=42 nprocs=8 > > r.sim.water --overwrite -t elevation=dem_pondA dx=dx_pondA > > dy=dy_pondA rain_value=40 infil_value=15 man=manning > > flow_control=flow_control_pondA hmax=1 > > depth=water_depth_pondA_40x30mm discharge=discharge_pondA_40x30mm > > niterations=30 output_step=5 random_seed=42 nprocs=8 > The results are: > - water_depth approximately 0.38 meters for pondB (about 49m³) , 0.61 > meters for pondA (about 32m³) > - discharge of the watershed: pondB 48m³, pondA 51m³ > But I am not sure that the spread of water in the slope, and > especially in the ditches, is correct in this way, with hmax=1. > > Openfluid I find difficult to install, also for small watersheds with > the design of ditches, possibly not topologically connected. > > Could this route, with hmax=depth of the pond, be correct? > > Thanks > -- > -- > Perito agrario Enrico Gabrielli > progetto F.A.R.M. www.farm-agroecologia.it > Tessera n. 633 Collegio Periti agrari prov. Di Modena > Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ > https://www.inaturalist.org/observations/bonushenricus > > > Il giorno ven, 04/08/2023 alle 08.26 +0200, bonushenricus ha scritto: > > Thanks Micha > > What a mistake with Manning's coefficient! I took off a zero! > > For infil: the soil is sandy. The 24.1 mm/h is taken from the soil > > map with published regional data. There are two reference sites in > > the area of soil delineation: 48% sand and 22% clay: 7.7 mm/h; 52% >
Re: [GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?
Hello I made two better digital elevation models for my tests, here https://cubeatic.com/index.php/s/dYzjRdLGD7wksQt attached. There are two designs, each with a pond about 1 metre deep, the same position on the slope, and two ditches reaching the pond. One design has a pond with a surface area of 63m², and the other has a surface area of 131m², with a depth of about 1 metre, with a volume of 52m³ and 118m³, respectively. I expect that having the same slope and ditches upstream, the two ponds will be filled with a similar volume of water. Seen infil_rast for make waterproof the ponds doesn't run, I tried using flow_control, and it work. And I tried with hmax=1 Here the "script" (after import geotiff attached) > r.lake --overwrite elevation=dem_pondB water_level=480.7 lake=pondB > coordinates=687064.2576117209,4910526.453118301 > #results 118m³ 131m² > r.lake --overwrite elevation=dem_pondA water_level=480.9 lake=pondA > coordinates=687064.2576117209,4910526.453118301 > #results 52m³ 63m² > r.mapcalc expression="flow_control_pondA = if(pondA,0)" --overwrite > r.mapcalc expression="flow_control_pondB = if(pondB,0)" --overwrite > r.slope.aspect --overwrite elevation=dem_pondB dx=dx_pondB > dy=dy_pondB > r.slope.aspect --overwrite elevation=dem_pondA dx=dx_pondA > dy=dy_pondA > r.mask raster=dem_pondA > r.sim.water --overwrite -t elevation=dem_pondB dx=dx_pondB > dy=dy_pondB rain_value=40 infil_value=15 man=manning > flow_control=flow_control_pondB hmax=1 > depth=water_depth_pondB_40x30mm discharge=discharge_pondB_40x30mm > niterations=30 output_step=5 random_seed=42 nprocs=8 > r.sim.water --overwrite -t elevation=dem_pondA dx=dx_pondA > dy=dy_pondA rain_value=40 infil_value=15 man=manning > flow_control=flow_control_pondA hmax=1 > depth=water_depth_pondA_40x30mm discharge=discharge_pondA_40x30mm > niterations=30 output_step=5 random_seed=42 nprocs=8 The results are: - water_depth approximately 0.38 meters for pondB (about 49m³) , 0.61 meters for pondA (about 32m³) - discharge of the watershed: pondB 48m³, pondA 51m³ But I am not sure that the spread of water in the slope, and especially in the ditches, is correct in this way, with hmax=1. Openfluid I find difficult to install, also for small watersheds with the design of ditches, possibly not topologically connected. Could this route, with hmax=depth of the pond, be correct? Thanks -- -- Perito agrario Enrico Gabrielli progetto F.A.R.M. www.farm-agroecologia.it Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://www.inaturalist.org/observations/bonushenricus Il giorno ven, 04/08/2023 alle 08.26 +0200, bonushenricus ha scritto: > Thanks Micha > What a mistake with Manning's coefficient! I took off a zero! > For infil: the soil is sandy. The 24.1 mm/h is taken from the soil > map with published regional data. There are two reference sites in > the area of soil delineation: 48% sand and 22% clay: 7.7 mm/h; 52% > sand, 14% clay: 24.1 mm/h. If I can, I will go and measure on the > ground. But for now, maybe 15 might be good. > The result, however, still doesn't convince me. > If I try the simulation on "invaso6", with the same parameters as > "invaso2", it ends after 10 minutes with a result of 30 cm. > > Il giorno mer, 02/08/2023 alle 00.45 +0300, Micha Silver ha scritto: > > Hello Enrico: > > > > Anna knows this subject better than I do, but I noticed a few > > problems with your command, so here are some comments that might > > help to get a better result. > > > > First, your man_value is way too high. You probably want something > > like 0.03 > > Second, you are using the '-t' flag but no `output_step`, If you > > add output_step of a few minutes, then you should get multiple > > output rasters at each time step. > > Third, you have 40 mm/hr rain_rate and 24.1 mm/hr infiltration > > rate. Is that correct? That means that 60% of the rain is > > infiltrating throughout the 30 minute storm. This might happen in > > very dry and sandy soil. Is that your situation? > > > > Here's what I tried (changing the above 3 parameters): > > > > r.external ./reservoir_farm_granello/dem_invaso2.tif output=dem_2 > > g.region -ap rast=dem_2 > > r.slope.aspect elevation=dem_2 dx=dx_2 dy=dy_2 > > r.sim.water -t elevation=dem_2 dx=dx_2 dy=dy_2 rain_value=40 > > infil_value=15 man_value=0.0368 depth=water_depth_invaso2_40x30mm > > discharge=discharge_invaso2_40x30mm niterations=30 output_step=5 > > random_seed=42 nprocs=8 --overwrite > > > > This resulted in 5 depth (and 5 discharge) rasters. For example: > > > > r.univar water_depth_invaso2_40x30mm.05 > > 1
Re: [GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?
Thanks Micha What a mistake with Manning's coefficient! I took off a zero! For infil: the soil is sandy. The 24.1 mm/h is taken from the soil map with published regional data. There are two reference sites in the area of soil delineation: 48% sand and 22% clay: 7.7 mm/h; 52% sand, 14% clay: 24.1 mm/h. If I can, I will go and measure on the ground. But for now, maybe 15 might be good. The result, however, still doesn't convince me. If I try the simulation on "invaso6", with the same parameters as "invaso2", it ends after 10 minutes with a result of 30 cm. Il giorno mer, 02/08/2023 alle 00.45 +0300, Micha Silver ha scritto: > Hello Enrico: > > Anna knows this subject better than I do, but I noticed a few > problems with your command, so here are some comments that might help > to get a better result. > > First, your man_value is way too high. You probably want something > like 0.03 > Second, you are using the '-t' flag but no `output_step`, If you add > output_step of a few minutes, then you should get multiple output > rasters at each time step. > Third, you have 40 mm/hr rain_rate and 24.1 mm/hr infiltration rate. > Is that correct? That means that 60% of the rain is infiltrating > throughout the 30 minute storm. This might happen in very dry and > sandy soil. Is that your situation? > > Here's what I tried (changing the above 3 parameters): > > r.external ./reservoir_farm_granello/dem_invaso2.tif output=dem_2 > g.region -ap rast=dem_2 > r.slope.aspect elevation=dem_2 dx=dx_2 dy=dy_2 > r.sim.water -t elevation=dem_2 dx=dx_2 dy=dy_2 rain_value=40 > infil_value=15 man_value=0.0368 depth=water_depth_invaso2_40x30mm > discharge=discharge_invaso2_40x30mm niterations=30 output_step=5 > random_seed=42 nprocs=8 --overwrite > > This resulted in 5 depth (and 5 discharge) rasters. For example: > > r.univar water_depth_invaso2_40x30mm.05 > 100% > total null and non-null cells: 1197120 > total null cells: 667811 > > Of the non-null cells: > -- > n: 529309 > minimum: 4.25896e-05 > maximum: 0.313524 > range: 0.313481 > mean: 0.00323487 > mean of absolute values: 0.00323487 > standard deviation: 0.0125372 > variance: 0.000157182 > variation coefficient: 387.565 % > sum: 1712.24596255017 > micha@RMS:bonuschenricus$ r.univar water_depth_invaso2_40x30mm.25 > 100% > total null and non-null cells: 1197120 > total null cells: 667811 > > Of the non-null cells: > -- > n: 529309 > minimum: 4.25896e-05 > maximum: 0.406802 > range: 0.406759 > mean: 0.00358821 > mean of absolute values: 0.00358821 > standard deviation: 0.0176433 > variance: 0.000311286 > variation coefficient: 491.702 % > sum: 1899.27293131027 > > r.univar discharge_invaso2_40x30mm.05 > 100% > total null and non-null cells: 1197120 > total null cells: 667811 > > Of the non-null cells: > -- > n: 529309 > minimum: 0 > maximum: 0.595495 > range: 0.595495 > mean: 0.000783053 > mean of absolute values: 0.000783053 > standard deviation: 0.0121067 > variance: 0.000146571 > variation coefficient: 1546.08 % > sum: 414.477138618156 > micha@RMS:bonuschenricus$ r.univar discharge_invaso2_40x30mm.30 > 100% > total null and non-null cells: 1197120 > total null cells: 667811 > > Of the non-null cells: > -- > n: 529309 > minimum: 0 > maximum: 0.595495 > range: 0.595495 > mean: 0.000857986 > mean of absolute values: 0.000857986 > standard deviation: 0.0125651 > variance: 0.000157882 > variation coefficient: 1464.49 % > sum: 454.13982509354 > > > Attached is the final depth map (after 30 minutes). You might try a > longer run time (higher niternations) > One other note: Your region resolution is 0.2 meters (from the > original DEM) so each pixel is 0.04 sq meters. The sum of values of > all non-null cells in the final depth map is about 1900 (from the > r.univar result). So the total discharge should be about 76 m³. Does > that sound reasonable? > > HTH > Micha > > On 01/08/2023 21:35, bonushenricus wrote: > > > > > Thank you Anna. > > I will try to attach the two geotiffs in a compressed folder, with > > the simplest example of a single ditch, for both reservoirs. > > EPSG:32632. > > The ditch is not exactly the same for the two reservoirs, they > > change a little bit in the final part of the mouth of the > > reservoir, but it is very similar. > > Sorry I didn't use a sample vector of points, I did it later with > > temporal. > > > > > r.slope.aspect elevation=dem_invaso2 dx=dx_invaso2 dy=dy_i
Re: [GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?
Sorry I was too impetuous. I have to think about it more calmly. In fact, I am too ignorant on the subject. If it were the water blade, it wouldn't make sense for it to grow faster in case of the smaller reservoir. But I would expect, in my logic, that the water depth would again grow in the smaller reservoir. I will do more tests, try to understand. Or maybe the model is not adapted to the presence of small ponds. Consider that these are 30 and 70 m³ ponds, very small indeed. -- -- Perito agrario Enrico Gabrielli progetto F.A.R.M. www.farm-agroecologia.it Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://www.inaturalist.org/observations/bonushenricus Il giorno mar, 01/08/2023 alle 16.23 +0200, bonushenricus ha scritto: > Thank you, Anna. > r.sim.water finishes the simulation not at the end of the rainfall > event, in my case at 30 minutes, but at an earlier time. In my case, > in the smaller reservoir at 16 minutes, in the case of the more > extensive reservoir at 24 minutes. But the water keeps coming even > after that. I imagined that the calculation ends when it reaches the > steady state of the water blade. > But it's not so. Then I don't understand why it ends at 16 or 24 > minutes. Doesn't the water continue to arrive after that? Shouldn't > it increase? > I cannot understand it. In the reservoirs, the discharge is very low, > as I expect. But if the discharge does not increase and the > precipitation continues, I expect the water depth to rise again. > And it is not understandable that two reservoirs, one twice the > volume of the other, contain the same depth of 30 cm at the end of > the rainfall. > To understand how this works, I would apply waterproofing to the > reservoirs. The ksat, or infil_value, is the only variable that can > explain this: the larger reservoir loses more water. > If both reservoirs were waterproof, I would have removed this > variable. Unfortunately r.sim.water infil=raster where I have marked > value 0 in the reservoirs does not work. There is perhaps a bug that > I have reported. So I haven't had a chance to test this. > I don't know how to do it; I can't trust the 30 cm as a value to > calculate the water volume in the two reservoirs. I will have to use > another model. > I will try to use a distributed model. Since I have the data in > GRASS, I will try using the old geomhydas, hoping the modules will > work in GRASS8, and then use the Mhydas models in OpenFluid. I have > no other chance unless someone can help me find a solution. > -- > -- > Perito agrario Enrico Gabrielli > progetto F.A.R.M. www.farm-agroecologia.it > Tessera n. 633 Collegio Periti agrari prov. Di Modena > Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ > https://www.inaturalist.org/observations/bonushenricus > > Il giorno mar, 01/08/2023 alle 09.23 -0400, Anna Petrášová ha > scritto: > > > > > > On Mon, Jul 31, 2023 at 11:42 PM bonushenricus > > wrote: > > > Hi Anna > > > I too immediately thought it was enough to compute it for the > > > final step of the simulation, > > > but I noticed that the same slope, same ditches, same rainfall, > > > for two reservoirs at the same location, same length along a > > > contour, but different width and depth, at the final step of the > > > simulation the water depth was always 30 cm, I went to read the > > > article > > > Mitasova, Helena, Chris Thaxton, Jaroslav Hofierka, Richard > > > McLaughlin, Amber Moore, e Lubos Mitas. «Path Sampling Method for > > > Modeling Overland Water Flow, Sediment Transport, and Short Term > > > Terrain Evolution in Open Source GIS». In Developments in Water > > > Science, 55:1479–90. Elsevier, 2004. > > > https://doi.org/10.1016/S0167-5648(04)80159-X > > > where I read the Saint-Venant equation. I am an agricultural > > > technician and geographer unfortunately ignorant of hydrological > > > calculations and serious mathematics, and I understood, looking > > > at the equation, that the water depth is the depth of overland > > > flow = rainfall exces - water flow. > > > So the final 30 cm should not be understood as accumulated water, > > > but as the blade of water that was added at that precise moment. > > > Isn't my interpretation right? > > > > > > > > > No, it should be actual water depth. I didn't understand the > > discrepancy you are describing? > > > > > > -- ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?
Thank you, Anna. r.sim.water finishes the simulation not at the end of the rainfall event, in my case at 30 minutes, but at an earlier time. In my case, in the smaller reservoir at 16 minutes, in the case of the more extensive reservoir at 24 minutes. But the water keeps coming even after that. I imagined that the calculation ends when it reaches the steady state of the water blade. But it's not so. Then I don't understand why it ends at 16 or 24 minutes. Doesn't the water continue to arrive after that? Shouldn't it increase? I cannot understand it. In the reservoirs, the discharge is very low, as I expect. But if the discharge does not increase and the precipitation continues, I expect the water depth to rise again. And it is not understandable that two reservoirs, one twice the volume of the other, contain the same depth of 30 cm at the end of the rainfall. To understand how this works, I would apply waterproofing to the reservoirs. The ksat, or infil_value, is the only variable that can explain this: the larger reservoir loses more water. If both reservoirs were waterproof, I would have removed this variable. Unfortunately r.sim.water infil=raster where I have marked value 0 in the reservoirs does not work. There is perhaps a bug that I have reported. So I haven't had a chance to test this. I don't know how to do it; I can't trust the 30 cm as a value to calculate the water volume in the two reservoirs. I will have to use another model. I will try to use a distributed model. Since I have the data in GRASS, I will try using the old geomhydas, hoping the modules will work in GRASS8, and then use the Mhydas models in OpenFluid. I have no other chance unless someone can help me find a solution. -- -- Perito agrario Enrico Gabrielli progetto F.A.R.M. www.farm-agroecologia.it Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://www.inaturalist.org/observations/bonushenricus Il giorno mar, 01/08/2023 alle 09.23 -0400, Anna Petrášová ha scritto: > > > On Mon, Jul 31, 2023 at 11:42 PM bonushenricus > wrote: > > Hi Anna > > I too immediately thought it was enough to compute it for the final > > step of the simulation, > > but I noticed that the same slope, same ditches, same rainfall, for > > two reservoirs at the same location, same length along a contour, > > but different width and depth, at the final step of the simulation > > the water depth was always 30 cm, I went to read the article > > Mitasova, Helena, Chris Thaxton, Jaroslav Hofierka, Richard > > McLaughlin, Amber Moore, e Lubos Mitas. «Path Sampling Method for > > Modeling Overland Water Flow, Sediment Transport, and Short Term > > Terrain Evolution in Open Source GIS». In Developments in Water > > Science, 55:1479–90. Elsevier, 2004. > > https://doi.org/10.1016/S0167-5648(04)80159-X > > where I read the Saint-Venant equation. I am an agricultural > > technician and geographer unfortunately ignorant of hydrological > > calculations and serious mathematics, and I understood, looking at > > the equation, that the water depth is the depth of overland flow = > > rainfall exces - water flow. > > So the final 30 cm should not be understood as accumulated water, > > but as the blade of water that was added at that precise moment. > > Isn't my interpretation right? > > > > > No, it should be actual water depth. I didn't understand the > discrepancy you are describing? > > > > -- > > -- > > Perito agrario Enrico Gabrielli > > progetto F.A.R.M. www.farm-agroecologia.it > > Tessera n. 633 Collegio Periti agrari prov. Di Modena > > Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ > > https://www.inaturalist.org/observations/bonushenricus > > > > > > Il giorno lun, 31/07/2023 alle 14.34 -0400, Anna Petrášová ha > > scritto: > > > > > > > > > On Sun, Jul 30, 2023 at 6:01 AM bonushenricus > > > wrote: > > > > Hi > > > > From r.sim.water, how can I calculate the volume of water > > > > stored in > > > > small water storages placed along a relief and connected to > > > > ditches? > > > > In this article https://doi.org/10.1016/j.agwat.2023.108398 > > > > these > > > > Italian researchers with r.sim.water manage did this > > > > calculation, but I > > > > do not understand how. With a calculation at different times on > > > > discharge at the entrance to the water storage? > > > > I tried to contact them, but they did not reply. > > > > Thanks! > > > > > > > > > > > > > Hi, > > > > > > volume would be simple depth times cell size squared for a > > > certain selected area. I would compute it for the final step of > > > the simulation, I am not sure what is the purpose of summing > > > it for different time steps. Perhaps you could clarify a little > > > bit? > > > > > > Anna > > > > > > > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?
Hi Anna I too immediately thought it was enough to compute it for the final step of the simulation, but I noticed that the same slope, same ditches, same rainfall, for two reservoirs at the same location, same length along a contour, but different width and depth, at the final step of the simulation the water depth was always 30 cm, I went to read the article Mitasova, Helena, Chris Thaxton, Jaroslav Hofierka, Richard McLaughlin, Amber Moore, e Lubos Mitas. «Path Sampling Method for Modeling Overland Water Flow, Sediment Transport, and Short Term Terrain Evolution in Open Source GIS». In Developments in Water Science, 55:1479–90. Elsevier, 2004. https://doi.org/10.1016/S0167-5648(04)80159-X where I read the Saint-Venant equation. I am an agricultural technician and geographer unfortunately ignorant of hydrological calculations and serious mathematics, and I understood, looking at the equation, that the water depth is the depth of overland flow = rainfall exces - water flow. So the final 30 cm should not be understood as accumulated water, but as the blade of water that was added at that precise moment. Isn't my interpretation right? -- -- Perito agrario Enrico Gabrielli progetto F.A.R.M. www.farm-agroecologia.it Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://www.inaturalist.org/observations/bonushenricus Il giorno lun, 31/07/2023 alle 14.34 -0400, Anna Petrášová ha scritto: > > > On Sun, Jul 30, 2023 at 6:01 AM bonushenricus > wrote: > > Hi > > From r.sim.water, how can I calculate the volume of water stored in > > small water storages placed along a relief and connected to > > ditches? > > In this article https://doi.org/10.1016/j.agwat.2023.108398 these > > Italian researchers with r.sim.water manage did this calculation, > > but I > > do not understand how. With a calculation at different times on > > discharge at the entrance to the water storage? > > I tried to contact them, but they did not reply. > > Thanks! > > > > > Hi, > > volume would be simple depth times cell size squared for a certain > selected area. I would compute it for the final step of the > simulation, I am not sure what is the purpose of summing it for > different time steps. Perhaps you could clarify a little bit? > > Anna > > > -- ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?
Sorry in fact temporal_plot_tool when I export to csv there is an interpolation the sum result is invaso2 2 meters invaso5 2.2 meters How I can calculate without temporal_plot_tool? Il giorno dom, 30/07/2023 alle 19.01 +0200, bonushenricus ha scritto: > Hi and good sunday > I attach the result of two small pond of this simulation: > the invaso2 is less a half surface area than the invaso5 > They are in the same position in the watershed > I simulated a precipitation of 40 mm/hr x 30 minutes (!) > I aggregated with t.rast.aggregate method=sum granularity=30 > (relative > time, timestamps of the r.sim.water -t are relative minutes) > the result at 30 minutes are > in invaso2 average of 2.91m > in invaso5 average of 1.97m > I expected the inverse, > so t.rast.aggregate method=sum with depth is not correct. > Thanks for some help > > Il giorno dom, 30/07/2023 alle 12.01 +0200, bonushenricus ha scritto: > > Hi > > From r.sim.water, how can I calculate the volume of water stored in > > small water storages placed along a relief and connected to > > ditches? > > In this article https://doi.org/10.1016/j.agwat.2023.108398 these > > Italian researchers with r.sim.water manage did this calculation, > > but > > I > > do not understand how. With a calculation at different times on > > discharge at the entrance to the water storage? > > I tried to contact them, but they did not reply. > > Thanks! > > -- ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?
Hi and good sunday I attach the result of two small pond of this simulation: the invaso2 is less a half surface area than the invaso5 They are in the same position in the watershed I simulated a precipitation of 40 mm/hr x 30 minutes (!) I aggregated with t.rast.aggregate method=sum granularity=30 (relative time, timestamps of the r.sim.water -t are relative minutes) the result at 30 minutes are in invaso2 average of 2.91m in invaso5 average of 1.97m I expected the inverse, so t.rast.aggregate method=sum with depth is not correct. Thanks for some help Il giorno dom, 30/07/2023 alle 12.01 +0200, bonushenricus ha scritto: > Hi > From r.sim.water, how can I calculate the volume of water stored in > small water storages placed along a relief and connected to ditches? > In this article https://doi.org/10.1016/j.agwat.2023.108398 these > Italian researchers with r.sim.water manage did this calculation, but > I > do not understand how. With a calculation at different times on > discharge at the entrance to the water storage? > I tried to contact them, but they did not reply. > Thanks! > -- ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?
Hi >From r.sim.water, how can I calculate the volume of water stored in small water storages placed along a relief and connected to ditches? In this article https://doi.org/10.1016/j.agwat.2023.108398 these Italian researchers with r.sim.water manage did this calculation, but I do not understand how. With a calculation at different times on discharge at the entrance to the water storage? I tried to contact them, but they did not reply. Thanks! -- -- Perito agrario Enrico Gabrielli progetto F.A.R.M. www.farm-agroecologia.it Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://www.inaturalist.org/observations/bonushenricus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] agricultural small water reservoir
Thanks Rich I work for small farms. For their needs and for simplified permit management, I design irrigation ponds of less than 5,000 m³. Perhaps Bentley's product or HydroCAD might be suitable, but they are not available in Linux. SWAT has just been upgraded to SWAT+, and works in QGIS. But from the bibliography I found it seems complicated to use for this kind of small ponds. But maybe I am wrong. I asked the mail-list of SWAT+ users what they thought. -- -- Perito agrario Enrico Gabrielli progetto F.A.R.M. www.farm-agroecologia.it Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://www.inaturalist.org/observations/bonushenricus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] agricultural small water reservoir
Tanks Rich Excellent advice! I could do both for example, check with three events, a moderate rain of 5 mm/h x 4 hours, a heavy rain of 15 mm/h for 1 hour, and an extreme event of 50 mm/h for 15 minutes. And for each event, give a frequency index. There are all about small slope sides. Do you have any articles or searchable projects on the internet to recommend the US method? In addition, I need to learn how to do earthmoving calculations and then use 3drasters, so if you have any advice on how to do that, I welcome it. -- -- Perito agrario Enrico Gabrielli progetto F.A.R.M. www.farm-agroecologia.it Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://www.inaturalist.org/observations/bonushenricus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] agricultural small water reservoir
Hi This is a question on the approach to take in order to achieve a consultancy objective. For two farms I have to give some input on the possible design of a small water reservoir for agricultural use. I have this rainfall data: the number of days per month of moderate rainfall (4-6 mm/hr) of at least 4 hours. So, without taking into account extreme events, which are more interesting for erosion, I was thinking of doing a r.sim.water calculation for each month of the water depth in the reservoirs, and at the same time an evaporation calculation, to build up a yearly report of the potential changes in the amount of water available. Has anyone ever used GRASS for this type of work? Perhaps for dams? -- -- Perito agrario Enrico Gabrielli progetto F.A.R.M. www.farm-agroecologia.it Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://www.inaturalist.org/observations/bonushenricus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.to.rast -d segmentation fault Re: Surfaces with faults
And at the end I found the solutions: after a v.to.rast at the desired resolution I can choose the line width with r.buffer and at the end I can use v.surf.rst, with raster line mask > v.surf.rst --overwrite input=fosso_punti zcolumn=z elevation=fosso_dem_rst mask=line3d_rast smooth_column=vdop segmax=60 dmin=0.2 dmax=5 !!! Il giorno mar, 25/07/2023 alle 06.17 +0200, bonushenricus ha scritto: > Hello > the problem isn't in my ASCII file or in v.in.lines > but a bug in v.to.rast, with the -d parameter. > I used gdb > > Thread 1 "v.to.rast" received signal SIGSEGV, Segmentation fault. > > (gdb) bt > > #0 0x in ?? () > > #1 0x77ef7091 in G_plot_point () > from /usr/local/grass83/lib/libgrass_gis.8.3.so > > #2 0x8d46 in do_lines () > > #3 0xabc6 in vect_to_rast () > > #4 0x7ad6 in main () > > (gdb) > > > > Il giorno lun, 24/07/2023 alle 17.59 +0200, bonushenricus ha scritto: > > Hello > > I've just tried with the solution of this thread > > https://www.mail-archive.com/grass-user@lists.osgeo.org/msg40640.html > > so > > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea / > > > separator=comma > > > g.region vector=fosso_linea res=0.2 > > > v.split input=fosso_linea output=fosso_linea_split length=0.2 > > > v.to.points -i input=fosso_linea_split output=fosso_punti > > > v.to.rast -d input=fosso_punti type=point output=fosso_dem use=z > > but the result is > > > Command ended with non-zero return code -11 (0 sec) > > > > I believe there was something wrong in v.in.lines or in my ASCII > > file: > > the vector line hasn't attribute > > > > Il giorno lun, 24/07/2023 alle 16.44 +0200, bonushenricus ha > > scritto: > > > Hello > > > I would like to use the procedure described in "Open Source GIS: > > > A > > > GRASS GIS Approach" second edition page 191 "7.3.5 Surfaces with > > > faults". > > > I have a survey of points. Some points are two ditches. I have > > > run > > > a > > > v.surf.rst with the survey points without the ditch. > > > Attached is the ascii file of the ditch points (EPSG:32632) > > > I have therefore operated as follows: > > > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea / > > > > separator=comma > > > > g.region vector=fosso_linea res=0.2 > > > > v.to.rast -d --overwrite input=fosso_linea type=line > > > > output=fosso > > > > / > > > > use=z > > > > v.surf.rst --overwrite segmax=60 npmin=100 dmin=1 dmax=6 / > > > > input=fosso_linea elevation=fosso_dem mask=fosso > > > the result is with no_data > > > > > > Some suggestions? > > > -- ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.to.rast -d segmentation fault Re: Surfaces with faults
Almost eureka spline with tension only for point of the ditch is possible with r.resample.rst > r.resamp.rst --overwrite input=fosso_punti_rast@granello ew_res=0.1 ns_res=0.1 elevation=fosso_dem_rst@granello overlap=2 tension=40. but the result in width of the line is too big and also the profile is with "terraces" Il giorno mar, 25/07/2023 alle 08.33 +0300, Maris Nartiss ha scritto: > Please provide your input data and computational region settings. I > was not able to reproduce the issue with my data. > > Māris. > > otrd., 2023. g. 25. jūl., plkst. 07:17 — lietotājs bonushenricus > () rakstīja: > > > > Hello > > the problem isn't in my ASCII file or in v.in.lines > > but a bug in v.to.rast, with the -d parameter. > > I used gdb > > > Thread 1 "v.to.rast" received signal SIGSEGV, Segmentation fault. > > > (gdb) bt > > > #0 0x in ?? () > > > #1 0x77ef7091 in G_plot_point () > > from /usr/local/grass83/lib/libgrass_gis.8.3.so > > > #2 0x8d46 in do_lines () > > > #3 0xabc6 in vect_to_rast () > > > #4 0x7ad6 in main () > > > (gdb) > > > > > > > > Il giorno lun, 24/07/2023 alle 17.59 +0200, bonushenricus ha > > scritto: > > > Hello > > > I've just tried with the solution of this thread > > > https://www.mail-archive.com/grass-user@lists.osgeo.org/msg40640.html > > > so > > > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea / > > > > separator=comma > > > > g.region vector=fosso_linea res=0.2 > > > > v.split input=fosso_linea output=fosso_linea_split length=0.2 > > > > v.to.points -i input=fosso_linea_split output=fosso_punti > > > > v.to.rast -d input=fosso_punti type=point output=fosso_dem > > > > use=z > > > but the result is > > > > Command ended with non-zero return code -11 (0 sec) > > > > > > I believe there was something wrong in v.in.lines or in my ASCII > > > file: > > > the vector line hasn't attribute > > > > > > Il giorno lun, 24/07/2023 alle 16.44 +0200, bonushenricus ha > > > scritto: > > > > Hello > > > > I would like to use the procedure described in "Open Source > > > > GIS: A > > > > GRASS GIS Approach" second edition page 191 "7.3.5 Surfaces > > > > with > > > > faults". > > > > I have a survey of points. Some points are two ditches. I have > > > > run > > > > a > > > > v.surf.rst with the survey points without the ditch. > > > > Attached is the ascii file of the ditch points (EPSG:32632) > > > > I have therefore operated as follows: > > > > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea > > > > > / > > > > > separator=comma > > > > > g.region vector=fosso_linea res=0.2 > > > > > v.to.rast -d --overwrite input=fosso_linea type=line > > > > > output=fosso > > > > > / > > > > > use=z > > > > > v.surf.rst --overwrite segmax=60 npmin=100 dmin=1 dmax=6 / > > > > > input=fosso_linea elevation=fosso_dem mask=fosso > > > > the result is with no_data > > > > > > > > Some suggestions? > > > > -- > > ___ > > 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] v.to.rast -d segmentation fault Re: Surfaces with faults
Thank you. the CRS is EPSG:32632 fosso.dat I attached > g.region vector=fosso_linea res=0.2 > v.split input=fosso_linea output=fosso_linea_split length=0.1 > v.to.points -i input=fosso_linea_split output=fosso_punti > v.to.rast -d input=fosso_punti type=point output=fosso_dem use=z Il giorno mar, 25/07/2023 alle 08.33 +0300, Maris Nartiss ha scritto: > Please provide your input data and computational region settings. I > was not able to reproduce the issue with my data. > > Māris. > > otrd., 2023. g. 25. jūl., plkst. 07:17 — lietotājs bonushenricus > () rakstīja: > > > > Hello > > the problem isn't in my ASCII file or in v.in.lines > > but a bug in v.to.rast, with the -d parameter. > > I used gdb > > > Thread 1 "v.to.rast" received signal SIGSEGV, Segmentation fault. > > > (gdb) bt > > > #0 0x in ?? () > > > #1 0x77ef7091 in G_plot_point () > > from /usr/local/grass83/lib/libgrass_gis.8.3.so > > > #2 0x8d46 in do_lines () > > > #3 0xabc6 in vect_to_rast () > > > #4 0x7ad6 in main () > > > (gdb) > > > > > > > > Il giorno lun, 24/07/2023 alle 17.59 +0200, bonushenricus ha > > scritto: > > > Hello > > > I've just tried with the solution of this thread > > > https://www.mail-archive.com/grass-user@lists.osgeo.org/msg40640.html > > > so > > > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea / > > > > separator=comma > > > > g.region vector=fosso_linea res=0.2 > > > > v.split input=fosso_linea output=fosso_linea_split length=0.2 > > > > v.to.points -i input=fosso_linea_split output=fosso_punti > > > > v.to.rast -d input=fosso_punti type=point output=fosso_dem > > > > use=z > > > but the result is > > > > Command ended with non-zero return code -11 (0 sec) > > > > > > I believe there was something wrong in v.in.lines or in my ASCII > > > file: > > > the vector line hasn't attribute > > > > > > Il giorno lun, 24/07/2023 alle 16.44 +0200, bonushenricus ha > > > scritto: > > > > Hello > > > > I would like to use the procedure described in "Open Source > > > > GIS: A > > > > GRASS GIS Approach" second edition page 191 "7.3.5 Surfaces > > > > with > > > > faults". > > > > I have a survey of points. Some points are two ditches. I have > > > > run > > > > a > > > > v.surf.rst with the survey points without the ditch. > > > > Attached is the ascii file of the ditch points (EPSG:32632) > > > > I have therefore operated as follows: > > > > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea > > > > > / > > > > > separator=comma > > > > > g.region vector=fosso_linea res=0.2 > > > > > v.to.rast -d --overwrite input=fosso_linea type=line > > > > > output=fosso > > > > > / > > > > > use=z > > > > > v.surf.rst --overwrite segmax=60 npmin=100 dmin=1 dmax=6 / > > > > > input=fosso_linea elevation=fosso_dem mask=fosso > > > > the result is with no_data > > > > > > > > Some suggestions? > > > > -- > > ___ > > grass-user mailing list > > grass-user@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/grass-user 687244.011,4910560.273,482.096 687240.364,4910558.058,482.109 687236.976,4910556.868,482.224 687233.285,4910555.428,482.328 687229.403,4910553.534,482.447 687224.965,4910551.415,482.629 687220.509,4910549.32,482.71 687216.282,4910546.997,482.89 687211.919,4910544.472,483.09 687208.558,4910542.642,483.261 687204.914,4910540.584,483.411 687204.912,4910540.58,483.32 687204.91,4910540.585,483.318 687200.661,4910538.442,483.673 687196.32,4910536.328,483.925 687191.518,4910534.29,484.293 687186.415,4910532.11,484.606 687181.112,4910530.163,484.737 687175.282,4910528.125,484.931 687169.458,4910526.233,485.236 687165.078,4910524.769,485.454 687160.04,4910522.885,485.697 687155.365,4910521.006,485.94 687151.164,4910519.457,486.282 687146.398,4910517.688,486.647 687141.874,4910515.805,487 687136.644,4910513.793,487.386 687132.068,4910512.125,487.659 687127.667,4910510.478,487.808 687122.314,4910508.022,487.879 687118.571,4910505.605,488.063 687114.031,4910501.636,488.301 687110.273,4910498.216,488.499 687108.325,4910496.676,488.602 687104.514,4910493.377,488.952 687101.82,4910491.029,489.219 687098.956,4910488.78,489.501 687096.126,4910486.848,489.734 687093.251,4910484.774,489.993 687088.748,4910482.092,490.242 687084.967,4910480.104,490.434 687080.853,4910478.109,490.631 687079.416,4910477.4,490.858 NaN,NaN,NaN 687034.891,4910501.481,486.212 687036.539,4910499.803,486.445 687038.564,4910497.364,486.72 687041.869,4910494.061,487.317 687046.279,4910490.702,487.837 687051.119,4910486.971,488.42 687056.483,4910483.767,488.936 687062.8,4910480.263,489.641 687068.777,4910477.408,490.42 687075.301,4910474.554,491.299 687082.093,4910471.638,492.264 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.to.rast -d segmentation fault Re: Surfaces with faults
Hello the problem isn't in my ASCII file or in v.in.lines but a bug in v.to.rast, with the -d parameter. I used gdb > Thread 1 "v.to.rast" received signal SIGSEGV, Segmentation fault. > (gdb) bt > #0 0x in ?? () > #1 0x77ef7091 in G_plot_point () from /usr/local/grass83/lib/libgrass_gis.8.3.so > #2 0x8d46 in do_lines () > #3 0xabc6 in vect_to_rast () > #4 0x7ad6 in main () > (gdb) Il giorno lun, 24/07/2023 alle 17.59 +0200, bonushenricus ha scritto: > Hello > I've just tried with the solution of this thread > https://www.mail-archive.com/grass-user@lists.osgeo.org/msg40640.html > so > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea / > > separator=comma > > g.region vector=fosso_linea res=0.2 > > v.split input=fosso_linea output=fosso_linea_split length=0.2 > > v.to.points -i input=fosso_linea_split output=fosso_punti > > v.to.rast -d input=fosso_punti type=point output=fosso_dem use=z > but the result is > > Command ended with non-zero return code -11 (0 sec) > > I believe there was something wrong in v.in.lines or in my ASCII > file: > the vector line hasn't attribute > > Il giorno lun, 24/07/2023 alle 16.44 +0200, bonushenricus ha scritto: > > Hello > > I would like to use the procedure described in "Open Source GIS: A > > GRASS GIS Approach" second edition page 191 "7.3.5 Surfaces with > > faults". > > I have a survey of points. Some points are two ditches. I have run > > a > > v.surf.rst with the survey points without the ditch. > > Attached is the ascii file of the ditch points (EPSG:32632) > > I have therefore operated as follows: > > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea / > > > separator=comma > > > g.region vector=fosso_linea res=0.2 > > > v.to.rast -d --overwrite input=fosso_linea type=line output=fosso > > > / > > > use=z > > > v.surf.rst --overwrite segmax=60 npmin=100 dmin=1 dmax=6 / > > > input=fosso_linea elevation=fosso_dem mask=fosso > > the result is with no_data > > > > Some suggestions? > > -- ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Surfaces with faults
Ok v.to.points creates 2 layer. The good layer is the 2. So with v.to.rast -d input=fosso_punti type=point layer=2 output=fosso_dem use=z is correct. I prefered the way with v.surf.rst from my original survey points, but the way with v.to.points can help me. Il giorno lun, 24/07/2023 alle 17.59 +0200, bonushenricus ha scritto: > Hello > I've just tried with the solution of this thread > https://www.mail-archive.com/grass-user@lists.osgeo.org/msg40640.html > so > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea / > > separator=comma > > g.region vector=fosso_linea res=0.2 > > v.split input=fosso_linea output=fosso_linea_split length=0.2 > > v.to.points -i input=fosso_linea_split output=fosso_punti > > v.to.rast -d input=fosso_punti type=point output=fosso_dem use=z > but the result is > > Command ended with non-zero return code -11 (0 sec) > > I believe there was something wrong in v.in.lines or in my ASCII > file: > the vector line hasn't attribute > > Il giorno lun, 24/07/2023 alle 16.44 +0200, bonushenricus ha scritto: > > Hello > > I would like to use the procedure described in "Open Source GIS: A > > GRASS GIS Approach" second edition page 191 "7.3.5 Surfaces with > > faults". > > I have a survey of points. Some points are two ditches. I have run > > a > > v.surf.rst with the survey points without the ditch. > > Attached is the ascii file of the ditch points (EPSG:32632) > > I have therefore operated as follows: > > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea / > > > separator=comma > > > g.region vector=fosso_linea res=0.2 > > > v.to.rast -d --overwrite input=fosso_linea type=line output=fosso > > > / > > > use=z > > > v.surf.rst --overwrite segmax=60 npmin=100 dmin=1 dmax=6 / > > > input=fosso_linea elevation=fosso_dem mask=fosso > > the result is with no_data > > > > Some suggestions? > > -- ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Surfaces with faults
Hello I've just tried with the solution of this thread https://www.mail-archive.com/grass-user@lists.osgeo.org/msg40640.html so > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea / > separator=comma > g.region vector=fosso_linea res=0.2 > v.split input=fosso_linea output=fosso_linea_split length=0.2 > v.to.points -i input=fosso_linea_split output=fosso_punti > v.to.rast -d input=fosso_punti type=point output=fosso_dem use=z but the result is > Command ended with non-zero return code -11 (0 sec) I believe there was something wrong in v.in.lines or in my ASCII file: the vector line hasn't attribute Il giorno lun, 24/07/2023 alle 16.44 +0200, bonushenricus ha scritto: > Hello > I would like to use the procedure described in "Open Source GIS: A > GRASS GIS Approach" second edition page 191 "7.3.5 Surfaces with > faults". > I have a survey of points. Some points are two ditches. I have run a > v.surf.rst with the survey points without the ditch. > Attached is the ascii file of the ditch points (EPSG:32632) > I have therefore operated as follows: > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea / > > separator=comma > > g.region vector=fosso_linea res=0.2 > > v.to.rast -d --overwrite input=fosso_linea type=line output=fosso / > > use=z > > v.surf.rst --overwrite segmax=60 npmin=100 dmin=1 dmax=6 / > > input=fosso_linea elevation=fosso_dem mask=fosso > the result is with no_data > > Some suggestions? > -- ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Surfaces with faults
Hello I would like to use the procedure described in "Open Source GIS: A GRASS GIS Approach" second edition page 191 "7.3.5 Surfaces with faults". I have a survey of points. Some points are two ditches. I have run a v.surf.rst with the survey points without the ditch. Attached is the ascii file of the ditch points (EPSG:32632) I have therefore operated as follows: > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea / > separator=comma > g.region vector=fosso_linea res=0.2 > v.to.rast -d --overwrite input=fosso_linea type=line output=fosso / > use=z > v.surf.rst --overwrite segmax=60 npmin=100 dmin=1 dmax=6 / > input=fosso_linea elevation=fosso_dem mask=fosso the result is with no_data Some suggestions? -- -- Perito agrario Enrico Gabrielli progetto F.A.R.M. www.farm-agroecologia.it Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://www.inaturalist.org/observations/bonushenricus 687244.011,4910560.273,482.096 687240.364,4910558.058,482.109 687236.976,4910556.868,482.224 687233.285,4910555.428,482.328 687229.403,4910553.534,482.447 687224.965,4910551.415,482.629 687220.509,4910549.32,482.71 687216.282,4910546.997,482.89 687211.919,4910544.472,483.09 687208.558,4910542.642,483.261 687204.914,4910540.584,483.411 687204.912,4910540.58,483.32 687204.91,4910540.585,483.318 687200.661,4910538.442,483.673 687196.32,4910536.328,483.925 687191.518,4910534.29,484.293 687186.415,4910532.11,484.606 687181.112,4910530.163,484.737 687175.282,4910528.125,484.931 687169.458,4910526.233,485.236 687165.078,4910524.769,485.454 687160.04,4910522.885,485.697 687155.365,4910521.006,485.94 687151.164,4910519.457,486.282 687146.398,4910517.688,486.647 687141.874,4910515.805,487 687136.644,4910513.793,487.386 687132.068,4910512.125,487.659 687127.667,4910510.478,487.808 687122.314,4910508.022,487.879 687118.571,4910505.605,488.063 687114.031,4910501.636,488.301 687110.273,4910498.216,488.499 687108.325,4910496.676,488.602 687104.514,4910493.377,488.952 687101.82,4910491.029,489.219 687098.956,4910488.78,489.501 687096.126,4910486.848,489.734 687093.251,4910484.774,489.993 687088.748,4910482.092,490.242 687084.967,4910480.104,490.434 687080.853,4910478.109,490.631 687079.416,4910477.4,490.858 NaN,NaN,NaN 687034.891,4910501.481,486.212 687036.539,4910499.803,486.445 687038.564,4910497.364,486.72 687041.869,4910494.061,487.317 687046.279,4910490.702,487.837 687051.119,4910486.971,488.42 687056.483,4910483.767,488.936 687062.8,4910480.263,489.641 687068.777,4910477.408,490.42 687075.301,4910474.554,491.299 687082.093,4910471.638,492.264 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass82 with_opencl in Debian 12
Ok I found the page for the installation of the pdal from the source https://pdal.io/en/2.4.3/development/compilation/unix.html and after the compilation of GRASS with CFLAGS=-O2 ./configure was done without problem!! I have now GRASS83 with opengl: the rendering is perfect now! Il giorno mar, 27/06/2023 alle 08.41 +0300, Maris Nartiss ha scritto: > There are two options for PDAL – either disable completely (no import > tools for LAS files then) or provide paths for include and lib > directories. See ./configure --help for correct syntax of all > parameters. I have no idea if one can mix conda and native libs in a > single program. > > Good luck, > Māris. > > otrd., 2023. g. 27. jūn., plkst. 08:21 — lietotājs bonushenricus > () rakstīja: > > > > Hi and thanks > > Yes QGIS runs the 3D rendering very well > > For GRASS-GIS with the most simple > > > CFLAGS=-O2 ./configure > > i have at the end a problem in DEBIAN 12 because the pdal library > > doesn't exist in the stable repository > > so the configuration done: > > > Package pdal was not found in the pkg-config search path. > > > Perhaps you should add the directory containing `pdal.pc' > > > to the PKG_CONFIG_PATH environment variable > > > Package 'pdal', required by 'virtual:world', not found > > > Package pdal was not found in the pkg-config search path. > > > Perhaps you should add the directory containing `pdal.pc' > > > to the PKG_CONFIG_PATH environment variable > > > Package 'pdal', required by 'virtual:world', not found > > > configure: error: *** Unable to locate suitable (>=1.7.1) PDAL > > > library > > The formal installation (from the website of PDAL) with conda > > doesn't > > change anything. > > > > Bye > > > > > > Il giorno lun, 26/06/2023 alle 21.29 +0200, Richard Duivenvoorde ha > > scritto: > > > Wel there IS an openCL too :-) In QGIS: > > > > > > https://www.itopen.it/opencl-acceleration-now-available-in-qgis/ > > > > > > 'naming is important' :-) > > > > > > Regards, > > > > > > Richard Duivenvoorde > > > > > > On 6/26/23 16:04, Markus Neteler wrote: > > > > Hi Enrico, > > > > > > > > On Mon, Jun 26, 2023 at 3:59 PM bonushenricus > > > > wrote: > > > > > > > > > > Hello everyone > > > > > I installed Debian 12. > > > > > I found grass-gis 8.2.1 > > > > > But it's not configured to work in opencl, and 3d rendering > > > > > is > > > > > very > > > > > slow. > > > > > > > > It is actually "openGL" to be installed, see > > > > > > > > https://github.com/OSGeo/grass/blob/main/REQUIREMENTS.md#optional-packages > > > > > > > > HTH, > > > > Markus > > > > > > > > > > > > > > > ___ > > 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] grass82 with_opencl in Debian 12
Hi and thanks Yes QGIS runs the 3D rendering very well For GRASS-GIS with the most simple > CFLAGS=-O2 ./configure i have at the end a problem in DEBIAN 12 because the pdal library doesn't exist in the stable repository so the configuration done: > Package pdal was not found in the pkg-config search path. > Perhaps you should add the directory containing `pdal.pc' > to the PKG_CONFIG_PATH environment variable > Package 'pdal', required by 'virtual:world', not found > Package pdal was not found in the pkg-config search path. > Perhaps you should add the directory containing `pdal.pc' > to the PKG_CONFIG_PATH environment variable > Package 'pdal', required by 'virtual:world', not found > configure: error: *** Unable to locate suitable (>=1.7.1) PDAL > library The formal installation (from the website of PDAL) with conda doesn't change anything. Bye Il giorno lun, 26/06/2023 alle 21.29 +0200, Richard Duivenvoorde ha scritto: > Wel there IS an openCL too :-) In QGIS: > > https://www.itopen.it/opencl-acceleration-now-available-in-qgis/ > > 'naming is important' :-) > > Regards, > > Richard Duivenvoorde > > On 6/26/23 16:04, Markus Neteler wrote: > > Hi Enrico, > > > > On Mon, Jun 26, 2023 at 3:59 PM bonushenricus > > wrote: > > > > > > Hello everyone > > > I installed Debian 12. > > > I found grass-gis 8.2.1 > > > But it's not configured to work in opencl, and 3d rendering is > > > very > > > slow. > > > > It is actually "openGL" to be installed, see > > > > https://github.com/OSGeo/grass/blob/main/REQUIREMENTS.md#optional-packages > > > > HTH, > > Markus > > > > > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] grass82 with_opencl in Debian 12
Hello everyone I installed Debian 12. I found grass-gis 8.2.1 But it's not configured to work in opencl, and 3d rendering is very slow. I tried to install it from sources, but I find several errors. Has anyone tried and knows how to give the right configuration with with_opencl in Debian? Thank you Enrico Gabrielli ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] "ERROR: Row cache is too small" r.li.cwed
Hello (again!) What does it mean "ERROR: Row cache is too small"? Is the exit from this command (the file raster, setup of r.li and weight in attachments of this email) Thanks Enrico Gabrielli agricultural technician Italy 1,2,0.3 1,3,0.3 1,4,0.9 1,5,0 1,6,0 2,3,0.1 2,4,0.5 2,5,0 2,6,0 3,4,0.1 3,5,0 3,6,0 4,5,0 4,6,0 5,6,0 SAMPLINGFRAME 0|0|1|1 SAMPLEAREA -1|-1|0.011764705882352941|0.00816326530612245 MOVINGWINDOW ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] actinia from R?
Hello after "r.li" and "r.le" I have another question: I am testing the landscape analysis functions for a work on the simulation of the dispersion of a parasitoid insect launched in an agroecosystem. For the simulation I use R, and I will make a shiny app. If "r.le" or "r.li" will suit me with respect to R packages to make the suitability map, I will have to do these analyzes locally and transfer the raster file to the shiny app for the following algorithm. But maybe there could be another possibility: the use of curls from R towards "actinia" ?? !! Has anyone from R ever tried to use "actinia"? Provided you can use it: I still don't understand how you can have an account. But maybe I should ask Mundialis Thanks! Enrico Gabrielli agricultural technician Italy ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.le.pixel addons not found
Hello and happy holidays! (I'm in quarantine for having a lunch where a person found out the next day they were COVID positive and so I'm spending the holidays studying and working!) GRASS 7.8.5 under Debian 11 points to a wrong URL 'https://github.com/OSGeo/grass- addons / trunk / grass7 / raster / r.le.pixel ' the correct url is without "trunk" and with "/ tree / master" P.S.: I know that "r.le" has been replaced by "r.li" but I wanted to see how it worked, I understand that such a thing "r.le.pixel map = ... string = w att = b4 t1 = m7 te2 = t5" is not possible with "r.li", where the closest form could be "r.li.cwed" (where, however, I don't understand what "path =" refers to, but now I try to study a lot: in the meantime I have several days , hoping that how he seems to continue to feel good!) -- Enrico Gabrielli ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.carve default value (design keyline simulation of water drainage)
Hello. I found this old discussion very interesting http://osgeo-org.1560.x6.nabble.com/Re-GRASSLIST-7895-Re-Hutchinson-s-Adaptive-Alogrithm-for-sound-DEMs-tt4030188.html#none and I realized that it is quite complex. Looking in various modules I realized that maybe I could use r.watershed, and maybe I could use a raster a flow model based in vect line and still use bocking input with tree Well I'm undecided I have a lot of work to do now, and within a week I wanted to submit a report to the farm (the consultancy is funded by the rural development plan of my region, and I could look great!) winter, when I have more time to devote to it. Thanks a lot anyway! -- Perito agrario Enrico Gabrielli Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://it.linkedin.com/pub/enrico-gabrielli/9a/186/159 https://enricogabrielli76.wordpress.com/ https://www.inaturalist.org/observations/bonushenricus skype: enricogabrielli (enricogabrielli76.per...@gmail.com) Il giorno sab, 24/07/2021 alle 22.31 +0200, Enrico Gabrielli bonushenricus ha scritto: > Hello. On a small agricultural test field of about 1.5 Ha, on which I > made the DEM with a survey in the field, I am trying some simulation > of > rainwater drainage, with a comparison of the current situation, a > situation of passages of the tractor with carriages according to > straight lines, and a situation of passages according to a keyline > design, curved. > To modify the dem to keep up with the tractor tracks, I am using the > r.carve module: I use a width of 0.4 meters and a depth of 0.07 > (resolution of the DEM and of the region of 0.1). > In the situation of straight carriageways, r.carve cuts ditches about > 3 > m deep (either using -n or not). > Strange because in the situation of curved lines in keyline > everything > was fine. > I don't understand how the module thinks, and what the default is. > Thank you > > Enrico bonushenricus tecnico agricolo (Italia) > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.carve default value (design keyline simulation of water drainage)
Hello. On a small agricultural test field of about 1.5 Ha, on which I made the DEM with a survey in the field, I am trying some simulation of rainwater drainage, with a comparison of the current situation, a situation of passages of the tractor with carriages according to straight lines, and a situation of passages according to a keyline design, curved. To modify the dem to keep up with the tractor tracks, I am using the r.carve module: I use a width of 0.4 meters and a depth of 0.07 (resolution of the DEM and of the region of 0.1). In the situation of straight carriageways, r.carve cuts ditches about 3 m deep (either using -n or not). Strange because in the situation of curved lines in keyline everything was fine. I don't understand how the module thinks, and what the default is. Thank you Enrico bonushenricus tecnico agricolo (Italia) ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.mapcalc
Hi How are you? After solving thanks to Stefan and his r.slope.direction how to calculate the slope along the keyline, now I have to solve how to create parallels to the keyline. Nothing easier: see parallel! But I have to create many. In the graphical modeler I can't learn how to use the loop. Damn if I'm ignorant. But maybe v.mapcalc would also be very handy. But it doesn't work for me. After installing ply it doesn't work anyway. > Traceback (most recent call last): > File "/usr/lib/grass76/scripts/v.mapcalc", line 429, in > > sys.exit(main()) > File "/usr/lib/grass76/scripts/v.mapcalc", line 415, in > main > p.parse(expression) > File "/usr/lib/grass76/scripts/v.mapcalc", line 191, in > parse > self.parser.parse(expression) > File "/usr/lib/python2.7/dist-packages/ply/yacc.py", line > 333, in parse > return self.parseopt_notrack(input, lexer, debug, > tracking, tokenfunc) > File "/usr/lib/python2.7/dist-packages/ply/yacc.py", line > 1063, in parseopt_notrack > lookahead = get_token() # Get the next token > File "/usr/lib/python2.7/dist-packages/ply/lex.py", line > 393, in token > newtok = self.lexerrorf(tok) > File "/usr/lib/grass76/scripts/v.mapcalc", line 146, in > t_error > (t.lineno, t.value)) > SyntaxError: syntax error on line 1 near > ''buff_l(keyline@PERMANENT,5)'' I used all possible quotes in the expression, but the result is always the same I don't want to use qgis (where there would be offset) because r.slope.direction is in grass and it is very convenient, and also all the rasters I use have them in grass. I would like to learn how to do everything in GRASS. Well, who knows if I'll succeed. As soon as I have some pennies I pay a friend of mine who is a python developer: maybe it's better. Thanks -- Perito agrario Enrico Gabrielli Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://it.linkedin.com/pub/enrico-gabrielli/9a/186/159 https://enricogabrielli76.wordpress.com/ https://www.inaturalist.org/observations/bonushenricus skype: enricogabrielli (enricogabrielli76.per...@gmail.com) ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] KEYLINE; installing new module add-on (of 7.8) in GRASS 7.6
Sorry Stefan
I'm a real fool
In the north-south direction the values are the same
while when the direction is different, oblique, the right is yours,
because the mapcalc formula is based only on the resolution of the
raster, not on the actual distance !!
Thank you very much for the work: very useful
Il giorno mar, 09/03/2021 alle 16.23 +0100, Enrico Gabrielli
bonushenricus ha scritto:
> Thanks Stefanobviously this is how it works. I was lost in a drop of
> water.But I don't understand how the module works:below the
> comparison of the results
> betweenr.mapcalc="slope_dir= abs(atan(tan(slope) * cos(aspect -
> direction)))
> isr.slope.direction with step 1
> i tried to read python but i don't understand exactly what it does,
> and also what 45degree means
> Il giorno mar, 09/03/2021 alle 13.35 +, Stefan Blumentrath ha
> scritto:
> > Hi again,
> >
> > Yes, this seems to be a Python2/3 issue. Good suggestions from
> > Vero.
> > Enrico, can also try to replace python3 with just python in the
> > shebang (first line in the script)?
> >
> > Cheers
> > Stefan
> >
> > From: Veronica Andreo
> >
> >
> > Sent: mandag 8. mars 2021 12:38
> >
> > To: Enrico Gabrielli bonushenricus
> >
> > Cc: Stefan Blumentrath ;
> > grass-user@lists.osgeo.org
> >
> > Subject: Re: [GRASS-user] KEYLINE; installing new module add-on (of
> > 7.8) in GRASS 7.6
> >
> >
> >
> > Hi Enrico,
> >
> >
> >
> >
> >
> >
> > GRASS 7.6 is the last using python 2, and in 7.8 we moved to python
> > 3, though still supporting python 2. Could that be a problem?
> >
> >
> >
> >
> >
> >
> > What about compiling GRASS 7.8+ if not in the Debian stable repos?
> >
> >
> >
> > https://grasswiki.osgeo.org/wiki/Compile_and_Install#Debian
> >
> >
> >
> >
> >
> > my 0.2 cents
> >
> >
> > Vero
> >
> >
> >
> >
> >
> > El lun, 8 mar 2021 a las 11:37, Enrico Gabrielli bonushenricus (<
> > bonushenricu...@gmail.com>) escribió:
> >
> > > Thanks
> > >
> > > some problems:
> > >
> > > > File "/home/bonushenricus/.grass7/addons/scripts/r.slope.d
> > >
> > > > irection.py", line 291, in
> > >
> > > > options, flags = gscript.parser()
> > >
> > > > File "/usr/lib/grass76/etc/python/grass/script/core.py",
> > >
> > > > line 800, in parser
> > >
> > > > return _parse_opts(lines[1:])
> > >
> > > > File "/usr/lib/grass76/etc/python/grass/script/core.py",
> > >
> > > > line 751, in _parse_opts
> > >
> > > > os.environ[var] = val
> > >
> > > > File "/usr/lib/python3.7/os.py", line 682, in __setitem__
> > >
> > > > key = self.encodekey(key)
> > >
> > > > File "/usr/lib/python3.7/os.py", line 753, in encode
> > >
> > > > raise TypeError("str expected, not %s" %
> > >
> > > > type(value).__name__)
> > >
> > > > TypeError: str expected, not bytes
> > >
> > > It seems that the files are all there, but perhaps they must be
> > >
> > > updated. That's pity. Alternatively I will use MAPCALC with
> > >
> > > ABS (ATAN (TAN (slope) * COS (aspect - raster_direction)))
> > >
> > > but unfortunately with an extra passage and without the
> > > possibility of
> > >
> > > defining calculation steps.
> > >
> > >
> > >
> > >
> > >
> > > Il giorno lun, 08/03/2021 alle 09.04 +, Stefan Blumentrath ha
> > >
> > > scritto:
> > >
> > > > Hm, maybe some fixes for g.extension should be backported to
> > > 7.6...
> > >
> > > >
> > >
> > > > Anyway, as a workaround, you can just save the python script
> > > from (as
> > >
> > > > r.slope.direction
> > >
> > > >
> > > https://raw.githubusercontent.com/OSGeo/grass-addons/master/grass7/raster/r.slope.direction/r.slope.direction.py
> > >
> > > > ) to:
> > >
> > > > ~/.grass7/addons/scripts/
> > >
> > > >
> > >
> > > > Then make it executable:
> > &
Re: [GRASS-user] KEYLINE; installing new module add-on (of 7.8) in GRASS 7.6
Thanks Stefanobviously this is how it works. I was lost in a drop of
water.But I don't understand how the module works:below the comparison
of the results betweenr.mapcalc="slope_dir= abs(atan(tan(slope) *
cos(aspect - direction)))
isr.slope.direction with step 1
i tried to read python but i don't understand exactly what it does, and
also what 45degree means
Il giorno mar, 09/03/2021 alle 13.35 +, Stefan Blumentrath ha
scritto:
> Hi again,
>
> Yes, this seems to be a Python2/3 issue. Good suggestions from Vero.
> Enrico, can also try to replace python3 with just python in the
> shebang (first line in the script)?
>
> Cheers
> Stefan
>
> From: Veronica Andreo
>
>
> Sent: mandag 8. mars 2021 12:38
>
> To: Enrico Gabrielli bonushenricus
>
> Cc: Stefan Blumentrath ;
> grass-user@lists.osgeo.org
>
> Subject: Re: [GRASS-user] KEYLINE; installing new module add-on (of
> 7.8) in GRASS 7.6
>
>
>
> Hi Enrico,
>
>
>
>
>
>
> GRASS 7.6 is the last using python 2, and in 7.8 we moved to python
> 3, though still supporting python 2. Could that be a problem?
>
>
>
>
>
>
> What about compiling GRASS 7.8+ if not in the Debian stable repos?
>
>
>
> https://grasswiki.osgeo.org/wiki/Compile_and_Install#Debian
>
>
>
>
>
> my 0.2 cents
>
>
> Vero
>
>
>
>
>
> El lun, 8 mar 2021 a las 11:37, Enrico Gabrielli bonushenricus (<
> bonushenricu...@gmail.com>) escribió:
>
> > Thanks
> >
> > some problems:
> >
> > > File "/home/bonushenricus/.grass7/addons/scripts/r.slope.d
> >
> > > irection.py", line 291, in
> >
> > > options, flags = gscript.parser()
> >
> > > File "/usr/lib/grass76/etc/python/grass/script/core.py",
> >
> > > line 800, in parser
> >
> > > return _parse_opts(lines[1:])
> >
> > > File "/usr/lib/grass76/etc/python/grass/script/core.py",
> >
> > > line 751, in _parse_opts
> >
> > > os.environ[var] = val
> >
> > > File "/usr/lib/python3.7/os.py", line 682, in __setitem__
> >
> > > key = self.encodekey(key)
> >
> > > File "/usr/lib/python3.7/os.py", line 753, in encode
> >
> > > raise TypeError("str expected, not %s" %
> >
> > > type(value).__name__)
> >
> > > TypeError: str expected, not bytes
> >
> > It seems that the files are all there, but perhaps they must be
> >
> > updated. That's pity. Alternatively I will use MAPCALC with
> >
> > ABS (ATAN (TAN (slope) * COS (aspect - raster_direction)))
> >
> > but unfortunately with an extra passage and without the possibility
> > of
> >
> > defining calculation steps.
> >
> >
> >
> >
> >
> > Il giorno lun, 08/03/2021 alle 09.04 +, Stefan Blumentrath ha
> >
> > scritto:
> >
> > > Hm, maybe some fixes for g.extension should be backported to
> > 7.6...
> >
> > >
> >
> > > Anyway, as a workaround, you can just save the python script from
> > (as
> >
> > > r.slope.direction
> >
> > >
> > https://raw.githubusercontent.com/OSGeo/grass-addons/master/grass7/raster/r.slope.direction/r.slope.direction.py
> >
> > > ) to:
> >
> > > ~/.grass7/addons/scripts/
> >
> > >
> >
> > > Then make it executable:
> >
> > > chmod u+x ~/.grass7/addons/scripts/r.slope.direction
> >
> > >
> >
> > > And it should work...
> >
> > >
> >
> > > Cheers
> >
> > > Stefan
> >
> > >
> >
> > > -Original Message-
> >
> > > From: Enrico Gabrielli bonushenricus
> >
> >
> > > Sent: mandag 8. mars 2021 09:44
> >
> > > To: Stefan Blumentrath ;
> >
> >
> > > grass-user@lists.osgeo.org
> >
> > > Subject: Re: [GRASS-user] KEYLINE; installing new module add-on
> > (of
> >
> > > 7.8) in GRASS 7.6
> >
> > >
> >
> > > Hi Stefan
> >
> > > and thanks
> >
> > > Thanks to all and all developers! And here I have the answer
> > directly
> >
> > > from those who have developed R-Slope.Direction, no ??
> >
> > > Here's what happens:
> >
> > > > g.extension extension=r.slope.direction
>
Re: [GRASS-user] KEYLINE; installing new module add-on (of 7.8) in GRASS 7.6
Thanks
some problems:
> File "/home/bonushenricus/.grass7/addons/scripts/r.slope.d
> irection.py", line 291, in
> options, flags = gscript.parser()
> File "/usr/lib/grass76/etc/python/grass/script/core.py",
> line 800, in parser
> return _parse_opts(lines[1:])
> File "/usr/lib/grass76/etc/python/grass/script/core.py",
> line 751, in _parse_opts
> os.environ[var] = val
> File "/usr/lib/python3.7/os.py", line 682, in __setitem__
> key = self.encodekey(key)
> File "/usr/lib/python3.7/os.py", line 753, in encode
> raise TypeError("str expected, not %s" %
> type(value).__name__)
> TypeError: str expected, not bytes
It seems that the files are all there, but perhaps they must be
updated. That's pity. Alternatively I will use MAPCALC with
ABS (ATAN (TAN (slope) * COS (aspect - raster_direction)))
but unfortunately with an extra passage and without the possibility of
defining calculation steps.
Il giorno lun, 08/03/2021 alle 09.04 +, Stefan Blumentrath ha
scritto:
> Hm, maybe some fixes for g.extension should be backported to 7.6...
>
> Anyway, as a workaround, you can just save the python script from (as
> r.slope.direction
> https://raw.githubusercontent.com/OSGeo/grass-addons/master/grass7/raster/r.slope.direction/r.slope.direction.py
> ) to:
> ~/.grass7/addons/scripts/
>
> Then make it executable:
> chmod u+x ~/.grass7/addons/scripts/r.slope.direction
>
> And it should work...
>
> Cheers
> Stefan
>
> -Original Message-
> From: Enrico Gabrielli bonushenricus
> Sent: mandag 8. mars 2021 09:44
> To: Stefan Blumentrath ;
> grass-user@lists.osgeo.org
> Subject: Re: [GRASS-user] KEYLINE; installing new module add-on (of
> 7.8) in GRASS 7.6
>
> Hi Stefan
> and thanks
> Thanks to all and all developers! And here I have the answer directly
> from those who have developed R-Slope.Direction, no ??
> Here's what happens:
> > g.extension extension=r.slope.direction
> > operation=add
> > Fetching from GRASS GIS Addons repository (be
> > patient)...
> > ERROR: Extension not found
>
> Il giorno lun, 08/03/2021 alle 08.38 +, Stefan Blumentrath ha
> scritto:
> > Hi Enrico,
> >
> > GRASS 7.6 should not be a limiting factor. Did you try to install
> > the
> > addon through g.extension?
> >
> > g.extension extension=r.slope.direction operation=add
> >
> > If not, please try. If you did but get an error message, please
> > provide the error message you got...
> >
> > Cheers
> > Stefan
> >
> >
> > -Original Message-
> > From: grass-user On Behalf Of
> > Enrico Gabrielli bonushenricus
> > Sent: søndag 7. mars 2021 23:59
> > To: grass-ita...@listserv.unipr.it; grass-user@lists.osgeo.org
> > Subject: [GRASS-user] KEYLINE; installing new module add-on (of
> > 7.8)
> > in GRASS 7.6
> >
> > Hello everyone and everyone.
> > I write maybe once every one or two years!
> > I am a geographer and agricultural consultant.
> > I am using GRASS to design in KeyLine (you can easily find news
> > about
> > this ingenious technique, which is also the basis of permaculture,
> > on
> > the internet).
> > I found that in GRASS 7.8 there is a new add-on module called
> > r.slope.direction which would be very useful for keyline designs.
> > Unfortunately I use Debian stable, and therefore GRASS 7.6.
> > I have tried to use the r.slope.direction source script which I
> > find
> > here
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2FOSGeo%2Fgrass-
> > addons%2Ftree%2Fmaster%2Fgrass7%2Fraster%2Fr.sl
> > ope.directiondata=04%7C01%7C%7C6f03009d912c4bed9a9e08d8e20e5a2
> > 0%7
> > C6cef373021314901831055b3abf02c73%7C0%7C0%7C637507898555085492%7CUn
> > kno
> > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> > wiL
> > CJXVCI6Mn0%3D%7C1000sdata=QpindTE6R0zQP6ArlP9rc2d3nFOYLMHhwtDn
> > iM8
> > EksA%3Dreserved=0 but can't use it. If I install it following
> > the
> > instructions I find here
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgras
> > swiki.osgeo.org%2Fwiki%2FGRASS_and_Python%23Installationdata=0
> > 4%7
> > C01%7C%7C6f03009d912c4bed9a9e08d8e20e5a20%7C6cef373021314901831055b
> > 3ab
> > f02c73%7C0%7C0%7C637507898555085492%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> > iMC
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
> > ;sd
> > ata=1%2BzzVwsIW7mBcsBvuI%
Re: [GRASS-user] KEYLINE; installing new module add-on (of 7.8) in GRASS 7.6
Hi Stefan and thanks Thanks to all and all developers! And here I have the answer directly from those who have developed R-Slope.Direction, no ?? Here's what happens: > g.extension extension=r.slope.direction > operation=add > Fetching from GRASS GIS Addons repository (be > patient)... > ERROR: Extension not found Il giorno lun, 08/03/2021 alle 08.38 +, Stefan Blumentrath ha scritto: > Hi Enrico, > > GRASS 7.6 should not be a limiting factor. Did you try to install the > addon through g.extension? > > g.extension extension=r.slope.direction operation=add > > If not, please try. If you did but get an error message, please > provide the error message you got... > > Cheers > Stefan > > > -Original Message- > From: grass-user On Behalf Of > Enrico Gabrielli bonushenricus > Sent: søndag 7. mars 2021 23:59 > To: grass-ita...@listserv.unipr.it; grass-user@lists.osgeo.org > Subject: [GRASS-user] KEYLINE; installing new module add-on (of 7.8) > in GRASS 7.6 > > Hello everyone and everyone. > I write maybe once every one or two years! > I am a geographer and agricultural consultant. > I am using GRASS to design in KeyLine (you can easily find news about > this ingenious technique, which is also the basis of permaculture, on > the internet). > I found that in GRASS 7.8 there is a new add-on module called > r.slope.direction which would be very useful for keyline designs. > Unfortunately I use Debian stable, and therefore GRASS 7.6. > I have tried to use the r.slope.direction source script which I find > here > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass-addons%2Ftree%2Fmaster%2Fgrass7%2Fraster%2Fr.slope.directiondata=04%7C01%7C%7Cc948a6d62a5d41a9266008d8e1bcaf3d%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637507547808270723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2B57KfELJq8o574mNFA5bXr%2BzFktjBCzyEVUJVrGMaJw%3Dreserved=0 > but can't use it. If I install it following the instructions I find > here > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrasswiki.osgeo.org%2Fwiki%2FGRASS_and_Python%23Installationdata=04%7C01%7C%7Cc948a6d62a5d41a9266008d8e1bcaf3d%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637507547808270723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=mAiEmMf4GNB%2FBSjGuS4KOvzOAKnFbEK4iUdVZEZ%2FYUI%3Dreserved=0 > it gives me several errors. I created the directory in / usr / lib / > grass76 / scripts / > I can attach the result of the terminal. > But if you think that it is simply not easy to install in GRASS 7.6 > it will mean that I will be looking forward to Debian 11 (I never > install > testing) > -- > Perito agrario Enrico Gabrielli > Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca > agricoltura: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.zotero.org%2Fgroups%2Faplomb%2Fdata=04%7C01%7C%7Cc948a6d62a5d41a9266008d8e1bcaf3d%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637507547808270723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WdQo31pdh44v1QXjsg7Psde34m3QPzlIUYCOAuH8lHE%3Dreserved=0 > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fit.linkedin.com%2Fpub%2Fenrico-gabrielli%2F9a%2F186%2F159data=04%7C01%7C%7Cc948a6d62a5d41a9266008d8e1bcaf3d%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637507547808270723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3Ouk5FFFNCyHfmPw%2BF1V7jWltSf1RlWp%2FDcCczVgzqI%3Dreserved=0 > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fenricogabrielli76.wordpress.com%2Fdata=04%7C01%7C%7Cc948a6d62a5d41a9266008d8e1bcaf3d%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637507547808270723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=k2fBrPk1BqhAi50h5NeMQ%2FP2MCM2b3G3xkSYDZMaOjc%3Dreserved=0 > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inaturalist.org%2Fobservations%2Fbonushenricusdata=04%7C01%7C%7Cc948a6d62a5d41a9266008d8e1bcaf3d%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637507547808280712%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yBLov2z5rUOVuMG%2Fe%2FdlDOQ%2Fv6cqpKqUjoYv6f20BMM%3Dreserved=0 > skype: enricogabrielli (enricogabrielli76.per...@gmail.com) > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgrass-userdata=04%7C01%7C%7Cc948a6d62a
[GRASS-user] KEYLINE; installing new module add-on (of 7.8) in GRASS 7.6
Hello everyone and everyone. I write maybe once every one or two years! I am a geographer and agricultural consultant. I am using GRASS to design in KeyLine (you can easily find news about this ingenious technique, which is also the basis of permaculture, on the internet). I found that in GRASS 7.8 there is a new add-on module called r.slope.direction which would be very useful for keyline designs. Unfortunately I use Debian stable, and therefore GRASS 7.6. I have tried to use the r.slope.direction source script which I find here https://github.com/OSGeo/grass-addons/tree/master/grass7/raster/r.slope.direction but can't use it. If I install it following the instructions I find here https://grasswiki.osgeo.org/wiki/GRASS_and_Python#Installation it gives me several errors. I created the directory in / usr / lib / grass76 / scripts / I can attach the result of the terminal. But if you think that it is simply not easy to install in GRASS 7.6 it will mean that I will be looking forward to Debian 11 (I never install testing) -- Perito agrario Enrico Gabrielli Tessera n. 633 Collegio Periti agrari prov. Di Modena Biblioteca agricoltura: https://www.zotero.org/groups/aplomb/ https://it.linkedin.com/pub/enrico-gabrielli/9a/186/159 https://enricogabrielli76.wordpress.com/ https://www.inaturalist.org/observations/bonushenricus skype: enricogabrielli (enricogabrielli76.per...@gmail.com) ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
