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 total
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 elevation
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 :
> On Mon, Dec 31,
On Mon, Dec 31, 2012 at 4:41 PM, Markus Metz
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
>
> http://grass.osgeo.org/grass65/manuals/r.drain.html
Just F
On Mon, Dec 31, 2012 at 3:52 PM, Milton Cezar Ribeiro
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 r.cost man page I can'
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 s
On Mon, Dec 31, 2012 at 3:05 PM, Milton Cezar Ribeiro
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 release branch (includin
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 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,
>>
>> Mar
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 :
>>> On Sun, Dec 30, 2012 at 8:59 PM, Milton Cezar Ribeiro
>>> wrote:
Hi Rashad
>
On Sun, Dec 30, 2012 at 11:44 PM, Milton Cezar Ribeiro
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 vector_points=map_target_pt --o
r
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 eve
On Sun, Dec 30, 2012 at 8:59 PM, Milton Cezar Ribeiro
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 you used? I found
r.drain
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 :
> Hi Milton,
>
> I think this fix will solve the problem[0]. For eleva
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 :
> On Wed, Dec 26, 2012 at 10:01 PM, Milton Cezar Ribe
On Wed, Dec 26, 2012 at 10:01 PM, Milton Cezar Ribeiro
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 source and target I will
On Wed, Dec 26, 2012 at 10:01 PM, Milton Cezar Ribeiro
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 source and target I will
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 le
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
On Sun, Dec 23, 2012 at 7:07 PM, Milton Cezar Ribeiro
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 position, and target
> point
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 Cezar
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
On Fri, Nov 2, 2012 at 11:13 AM, laurent celati
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 projection of the DEM file
> and
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 r.dr
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
recu
Hi Paolo,
try to use r.fill.dir on the elevation map with ~3 - 4 runs before you
use r.drain.
Best regards
Soeren
2011/3/24 Paolo Cavallini :
> 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
>
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.
--
http
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 eq
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
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
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
>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
>bu
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.
33 matches
Mail list logo
