Re: [GRASS-user] Filling sinks w/ minimum slope
On Mon, Jun 19, 2017 at 10:35 PM, Ken Mankoff wrote: > > > On 2017-06-19 at 18:20, Stefan Blumentrath wrote: > > To my knowledge r.watershed does not require to fill sinks in advance, > > because it has a minimal impact routing for handling (non-real) sinks. > > > > Do you have a particular reason for your wish to fill the DEM in > > advance? > > If I don't fill it, then my definition of non-real and the algorithms definition are different. I need all water to leave the domain, but there are internal sinks. You don't need to fill sinks with r.watershed, internal sinks are by default drained. You could also use r.hydrodem to remove internal sinks. > My solution is to fill them like this: > > # run the filling algorithm until there are no holes left > A=1 > while [[ $A -ne 0 ]]; do > r.fill.dir input=phi output=phi format=agnps direction=d areas=a --o --q > A=$(r.info a | egrep -o "max = .*" | cut -c7-20) > done > g.remove -f type=raster name=a,d > > Then use "phi" as the elevation input to r.watershed. Then all water leaves the domain, but there are flat areas. I would prefer if these were gently-sloped. A colleague does this in QGIS w/ SAGA and the minimum slope, but I am trying to make the work reproducible, and therefore prefer CLI GRASS to GUI QGIS. You can create flat areas (also with r.terraflow), then use the -b flag of r.watershed to create a gentle slope for flat areas. Markus M > > -k. > ___ > 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] Filling sinks w/ minimum slope
On 2017-06-19 at 18:20, Stefan Blumentrath wrote: > To my knowledge r.watershed does not require to fill sinks in advance, > because it has a minimal impact routing for handling (non-real) sinks. > > Do you have a particular reason for your wish to fill the DEM in > advance? If I don't fill it, then my definition of non-real and the algorithms definition are different. I need all water to leave the domain, but there are internal sinks. My solution is to fill them like this: # run the filling algorithm until there are no holes left A=1 while [[ $A -ne 0 ]]; do r.fill.dir input=phi output=phi format=agnps direction=d areas=a --o --q A=$(r.info a | egrep -o "max = .*" | cut -c7-20) done g.remove -f type=raster name=a,d Then use "phi" as the elevation input to r.watershed. Then all water leaves the domain, but there are flat areas. I would prefer if these were gently-sloped. A colleague does this in QGIS w/ SAGA and the minimum slope, but I am trying to make the work reproducible, and therefore prefer CLI GRASS to GUI QGIS. -k. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Filling sinks w/ minimum slope
Hi GRASS list, I'm interested in filling sinks in a DEM before using r.watershed. I currently use r.fill.dir. I've discovered that the SAGA fill command has an option to set a "Minimum slope gradient to preserve from cell to cell; with a value of zero sinks are filled up to the spill elevation (which results in flat areas)" (see http://www.saga-gis.org/saga_tool_doc/2.1.3/ta_preprocessor_4.html ). Does anyone know of an option for this in GRASS, or an addon that implements this feature? I've briefly looked at calling SAGA from GRASS and it seems non-trivial. I'd prefer to do this in GRASS if possible. Thanks, -k. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Single centroid/point for multiple polygons sharing the same category
On 19/06/17 13:02, Johannes Radinger wrote:
Hi GRASS users,
I am working on a polygon map of France that shows the single areas
belonging to a specific postal code. I want to extract for each area the
centroid (using v.extract), transform it to a point map (using v.type)
and finally add the X and Y coordinates to the attribute table for each
postal code region.
However, now I have the problem that some "postal code areas" have more
than one centroid, i.e. two or more closeby but not connected polygons
belong the same postal region and share a common category and entry in
the attribute table. So for these cases I get two or more points
(sharing the same cat) and of course I cannot calculate a single XY pair
for that postal code region.
Consequently, I need to find a method to get centroids of all the areas
sharing a common cat or I need to calculate the mean position of points
afterwards (using v.centerpoint). As far as I understood v.centerpoint
all points are used to calculate a mean point but not stratified for
points sharing the same cat!? FYI: I have around 2000 postal code areas
of which 200 consists of more than a single polygon.
Any suggestions?
Here are two examples using the urbanarea map of the NC dataset.
1) Use average centroid coordinates
v.category urbanarea op=add layer=2 out=myareas
v.db.addtable myareas layer=2 col="lay1cat integer, x double precision,
y double precision"
v.to.db myareas layer=2 op=query query_layer=1 query_col=cat col=lay1cat
v.to.db myareas layer=2 op=coor col=x,y
v.db.addcolumn myareas col="x double precision, y double precision"
db.execute sql="update myareas set x=(select avg(x) from myareas_2 where
lay1cat=myareas.cat group by lay1cat), y=(select avg(y) from myareas_2
where lay1cat=myareas.cat group by lay1cat)"
2) Use centroid coordinates of the largest polygon
v.category urbanarea op=add layer=2 out=myareas
v.db.addtable myareas layer=2 col="lay1cat integer, area double precision"
v.to.db myareas layer=2 op=query query_layer=1 query_col=cat col=lay1cat
v.to.db myareas layer=2 op=area col=area
v.extract myareas layer=2 cat=$(db.select -c sql="select cat from
myareas_2 group by lay1cat having area = max(area)" | awk '{printf"%s,",
$1}') out=my_unique_areas type=area
#change layers to get default layer 1 in final output (not really
necessary, but makes it nicer ot use afterwards)
v.category my_unique_areas op=chlayer layer=2,1 out=final_areas
v.db.connect -d final_areas layer=2
v.db.connect final_areas layer=1 table=final_areas
v.db.addcolumn final_areas col="x double precision, y double precision"
v.to.db final_areas op=coor col=x,y
v.db.join map=myareas layer=1 col=cat otable=final_areas ocol=lay1cat
subset_col=x,y
Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] wrong result in v.net.iso for backward direction
On Thu, Jun 8, 2017 at 10:46 AM, Mira Kattwinkel < kattwinkel-m...@uni-landau.de> wrote: > > Dear list members > > I am using v.net.iso to split a stream network at a certain distance from sampling points. > > First, I create a network from vector lines (streams) and vector points (sampling sites) using v.net. The lines feature have a 'cat' column, 'length', 'backward_cost' and 'forward_cost'. I would use -1 for forward costs because I am only interested in the upstream part, and length for backward costs in v.net.iso: > > v.net.iso input=test_edges arc_layer=2 node_layer=3 output=test_edges_bw_2000 center_cats=55 arc_column=forw_cost arc_backward_column=backw_cost costs=2000 > > However, the backward part of the resulting lines with cat 1 is always too short. Likewise, if I give just 1 for the backward costs and set the costs to 5, it gets 4 segments with cat 1. Working in both directions at the same time gives correct values for the forward end, but too short for the backward end. I then realised that the numbers would be correct if the first part of the forward end was added to the backward part (see attached example). The forward part all the costs (lengths) sum up correctly to 2000 (1443.19 + 556.81). For the backward part it would be 45.72 + 511.09 = 556.81. However, if the first segment of the forward part is added, it gives the correct cost sum (45.72 + 511.09 + 1443.19 = 2000). For the record in the ml, the problem was that several lines had the same category, thus uploaded lengths for each category were the sum of all lines with that category. The problem was solved by creating a new layer and adding unique categories for lines to that layer. This new layer was then used as arc_layer. Markus M > > Do I use the function in the wrong way or is this a bug? > > Thanks a lot, > Mira > > -- > Dr. Mira Kattwinkel > Quantitative Landscape Ecology > Institute for Environmental Sciences > University of Koblenz-Landau > Fortstraße 7 > 76829 Landau > Germany > Phone: + 49 6341 280-31553 > Office: Building I, Room 2.02 > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Projection errors with Aster GDEM and SHP Files
Hi Folks, I'm trying to combine a ASTER GDEM and some shape files from a different source in one mapset. I created a location using the aster_dem.tiff and another location using the .shp file. Now I want both maps in one mapset with a different projection. The import with r. / v.proj works without errors, but the displayed result is wrong. The either the raster or the vector map is getting shown in a wrong position. When I use QGis however and open the imported GDEM from the Grass Mapset together with the shp directly the vector maps are getting shown in the right position. Can someone tell me where I make my mistake. All projections are wgs84 based but not the same. Thanks in advanced Nils -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Projection-errors-with-Aster-GDEM-and-SHP-Files-tp5324655.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Single centroid/point for multiple polygons sharing the same category
Hi GRASS users, I am working on a polygon map of France that shows the single areas belonging to a specific postal code. I want to extract for each area the centroid (using v.extract), transform it to a point map (using v.type) and finally add the X and Y coordinates to the attribute table for each postal code region. However, now I have the problem that some "postal code areas" have more than one centroid, i.e. two or more closeby but not connected polygons belong the same postal region and share a common category and entry in the attribute table. So for these cases I get two or more points (sharing the same cat) and of course I cannot calculate a single XY pair for that postal code region. Consequently, I need to find a method to get centroids of all the areas sharing a common cat or I need to calculate the mean position of points afterwards (using v.centerpoint). As far as I understood v.centerpoint all points are used to calculate a mean point but not stratified for points sharing the same cat!? FYI: I have around 2000 postal code areas of which 200 consists of more than a single polygon. Any suggestions? /Johannes ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Suppress overwrite warnings in GRASS (using rgrass7)
James Duffy wrote > Hello, > > I'm executing loops where temporary files are overwritten on a regular > basis. Even with the 'quiet' flag, the "WARNING: Vector map > > already exists and will be overwritten" message > is produced. How can I turn this off? Either with a flag just for that > command, or across the whole session? > > Any help would be much appreciated. have a look into https://grass.osgeo.org/grass73/manuals/variables.html GRASS_VERBOSE [all modules] toggles verbosity level -1 - complete silence (also errors and warnings are discarded) 0 - only errors and warnings are printed 1 - progress and important messages are printed (percent complete) 2 - all module messages are printed 3 - additional verbose messages are printed This variable is automatically created by g.parser so that the --verbose or --quiet flags will be inherited by dependent modules as the script runs. HTH - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Suppress-overwrite-warnings-in-GRASS-using-rgrass7-tp5324630p5324641.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Suppress overwrite warnings in GRASS (using rgrass7)
Hello, I'm executing loops where temporary files are overwritten on a regular basis. Even with the 'quiet' flag, the "WARNING: Vector map already exists and will be overwritten" message is produced. How can I turn this off? Either with a flag just for that command, or across the whole session? Any help would be much appreciated. Kind regards James ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
