Hi all,
I am using r.drain with an elevation raster as input. I filled the elevation
raster using r.fill.dir. When I run r.drain, it only creates a short path
segment before finishing the analysis, even though it hasn't come close to
the region border. There should not be any sinks in my
Thanks to Markus and Ivan for the help-- I'll answer this on the forum in
case others have the same problem in the future.
For the record, I am using GRASS 6.4.4 on Mac OS 10.9.5.
The problem was that though I ran r.fill.dir once, there were still sinks
in my DEM. After running r.fill.dir 5
On Sun, Dec 30, 2012 at 11:44 PM, Milton Cezar Ribeiro
miltinho.astrona...@gmail.com wrote:
Hi Markus
I am using this commands.
r.cost -k input=friction_landuse_roads output=cost_map
start_points=map_source_pt stop_points=map_target_pt --o
r.drain input=cost_map output=drain_map
Markus Metz wrote:
I am going to backport r.cost/r.walk/r.drain from 6.5 to 6.4.
Done in r54470-1.
Happy new year,
Markus M
best wishes
miltinho
2012/12/30, Markus Metz markus.metz.gisw...@gmail.com:
On Sun, Dec 30, 2012 at 8:59 PM, Milton Cezar Ribeiro
Hi Markus
Thanks for all your help.
Please, which svn command I need to run to get the daily trunk subversion?
best
miltinho
2012/12/31, Markus Metz markus.metz.gisw...@gmail.com:
Markus Metz wrote:
I am going to backport r.cost/r.walk/r.drain from 6.5 to 6.4.
Done in r54470-1.
Happy
On Mon, Dec 31, 2012 at 3:05 PM, Milton Cezar Ribeiro
miltinho.astrona...@gmail.com wrote:
Hi Markus
Thanks for all your help.
Please, which svn command I need to run to get the daily trunk subversion?
See here:
http://trac.osgeo.org/grass/wiki/Release/6.4.3RC2-News
-- SVN Checkout latest 6.4
Hi all,
thanks again for the help with this.
I tried several versions of 6.4X (6.42 weekly snapshot, 6.43.. ) and
6.5 but in none of them, when I try to see the parameters for create
output direction on r.cost man page I can't see how can I generate
direction for input on r.drain.
Including the
On Mon, Dec 31, 2012 at 3:52 PM, Milton Cezar Ribeiro
miltinho.astrona...@gmail.com wrote:
Hi all,
thanks again for the help with this.
I tried several versions of 6.4X (6.42 weekly snapshot, 6.43.. ) and
6.5 but in none of them, when I try to see the parameters for create
output direction
On Mon, Dec 31, 2012 at 4:41 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
see
http://grass.osgeo.org/grass65/manuals/r.cost.html
http://grass.osgeo.org/grass65/manuals/r.walk.html
For r.drain, the option to use directions as input is indir, see
Hi there
Everything worked fine.
Congrats for all your great job on GRASS-GIS solution, and again many
thanks for the effert on deal with this in the transition 2012/2013
(yes! 2013 in Australia and other places around world!).
best wishes
miltinho
2012/12/31, Markus Neteler nete...@osgeo.org:
Hi Rashad
I tested with the trunk svn, but apparently it still not worked to me.
Are you able to test with my datased?
https://www.yousendit.com/download/UW16RE9zTkxlM1JBSXNUQw
Thanks!
miltinho
2012/12/27, Mohammed Rashad mohammedrasha...@gmail.com:
Hi Milton,
I think this fix will solve
On Sun, Dec 30, 2012 at 8:59 PM, Milton Cezar Ribeiro
miltinho.astrona...@gmail.com wrote:
Hi Rashad
I tested with the trunk svn, but apparently it still not worked to me.
Are you able to test with my datased?
https://www.yousendit.com/download/UW16RE9zTkxlM1JBSXNUQw
What are the commands
Hi Markus
I am using this commands.
r.cost -k input=friction_landuse_roads output=cost_map
start_points=map_source_pt stop_points=map_target_pt --o
r.drain input=cost_map output=drain_map vector_points=map_target_pt --o
I have not a direction map, and as for other source-target-friction
maps
On Wed, Dec 26, 2012 at 10:01 PM, Milton Cezar Ribeiro
miltinho.astrona...@gmail.com wrote:
Hi Mohamed and Markus
Mohamed, thanks for your reply, I will wait for a solution within GRASS :-)
Markus, thanks for your reply,. Sorry but I disagree a tiny bit,
because is expected that between a
On Wed, Dec 26, 2012 at 10:01 PM, Milton Cezar Ribeiro
miltinho.astrona...@gmail.com wrote:
Hi Mohamed and Markus
Mohamed, thanks for your reply, I will wait for a solution within GRASS :-)
Markus, thanks for your reply,. Sorry but I disagree a tiny bit,
because is expected that between a
Hi Markus
You are right. Thanks for your comments. In fact I don´t thougth on
null cell between Source and Target, and agree that extent influences
one archive or not a real least cost path solution.
Cheers
miltinho
2012/12/27, Markus Metz markus.metz.gisw...@gmail.com:
On Wed, Dec 26, 2012
Hi Mohamed and Markus
Mohamed, thanks for your reply, I will wait for a solution within GRASS :-)
Markus, thanks for your reply,. Sorry but I disagree a tiny bit,
because is expected that between a source and target I will find a
solution with the Least Cost path. Do you think that is there any
Hi Milton,
I think this fix will solve the problem[0]. For elevation data there might
be cases where no path exists ie, only single pixel is the selected path. I
had tested it by myself and it worked.
Please apply the patch and let me know.
If any problem comes in compilation or doing r.drain
Dear all,
I am running a least cost path analysis combining r.cost and r.drain.
But on some cases, when the least cost path between source and target
reach the border of my map, r.drain stop on that position, and target
point isn´t reached. Running on other softwares the algorithms the
source and
Hi Milton,
I think there is a bug in r.drain direction map calculation. see this
thread[0]
It may take a day or two to get fixed. I will send you a patch as I cant
commit ;)
[0] http://lists.osgeo.org/pipermail/grass-user/2012-December/066546.html
On Sun, Dec 23, 2012 at 11:37 PM, Milton
On Sun, Dec 23, 2012 at 7:07 PM, Milton Cezar Ribeiro
miltinho.astrona...@gmail.com wrote:
Dear all,
I am running a least cost path analysis combining r.cost and r.drain.
But on some cases, when the least cost path between source and target
reach the border of my map, r.drain stop on that
On Fri, Nov 2, 2012 at 11:13 AM, laurent celati
lcel...@latitude-geosystems.com wrote:
Hello,
I have an error message when i run rdrain. For information i use Grass
tools via qgis. I imported a DEM file (32 bit reel/ PCIDSK format .pix
/Pixel size x y : 15m) in my Grassdata set. The
Hello,
I have an error message when i run rdrain. For information i use Grass
tools via qgis. I imported a DEM file (32 bit reel/ PCIDSK format .pix
/Pixel size x y : 15m) in my Grassdata set. The projection of the DEM file
and of the Grass project(location) is UTM 32N Wgs84.
When i run
Hi all.
I'm testing r.drain, but I cannot get reasonable results over a dtm: the
line produced is always much too short, stopping where it seems it
should proceed. I exaggerated elevation (*10), as suggested by the
manpage, but results were only slightly better.
Any suggestion?
Thanks.
--
Il giorno gio, 24/03/2011 alle 12.47 +0100, Soeren Gebbert ha scritto:
Hi Paolo,
try to use r.fill.dir on the elevation map with ~3 - 4 runs before you
use r.drain.
Thanks Soeren, that improved the results considerably.
It would be good to have an option to set the level of filling (by
Hi,
Is it possible to substitute a 'direction' raster generated from a
module other than r.cost, when using the 'indir' option for r.drain?
This is for GRASS65.
Specifically, I would like to compute a least-cost path based on a
friction surface AND direction map. Is this possible?
Thanks,
Dylan
Stefano:
On the other hand I can't understand why in the man page the section
entitled BUG says: r.drain currently finds only the lowest point
(the cell having the smallest category value) in the input file
that can be reached through directly adjacent cells that are less
than or equal in
Hello everybody,
I'm a bit confused about r.drain (I'm working with Debian's backport version
6.2.1). I have noticed that if you give as input in the coordinate
parameter a point that stands on the region's edge, r.drain won't move
from there: it would output a map with that same single point. Is
Stefano Negri wrote:
I'm a bit confused about r.drain (I'm working with Debian's backport
version 6.2.1). I have noticed that if you give as input in the
coordinate parameter a point that stands on the region's edge,
r.drain won't move from there: it would output a map with that
same single
Thanks for your answers Eric and Hamish.
I had already made sure with d.rast.num and I have double checked now on a
toy map (a slope on a 100x100 grid): even if there are lower value cells
beside a border cell, it won't move from there.
Stefano.
2008/2/15, Hamish [EMAIL PROTECTED]:
Stefano
I'm a bit confused about r.drain (I'm working with Debian's backport version
6.2.1). I have noticed that if you give as input in the coordinate
parameter a point that stands on the region's edge, r.drain won't move
from there: it would output a map with that same single point. Is this a
bug?
On
Hi,
You are right - r.drain will NOT give sane results at region boundary.
Here is snippet from filldir.c:107:
/* determine the flow direction in each cell. On outer rows and columns
* the flow direction is always directly out of the map */
It's a questionable what action r.drain should take if
32 matches
Mail list logo
