RE: [GRASS-user] r.drain documentation - updated
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 value to the cell reached immediately prior to it; therefore, it will not necessarily reach the lowest point in the input file. It currently finds pits in the data, rather than the lowest point present.. Why would a local search be a bug in this case? I think it should be like that by design... Hamish: It is like that by design so really a feature not a bug. The man page should mention you could fill pits first with a module like r.fill.dir or r.terraflow if you want that. (the first is listed in the see also section but not explained AFAICS) I've moved this section from 'Bugs' to 'Notes' to reflect the fact that it is a feature of the module. There was already mention of using r.fill.dir and r.basins.fill for filling local pits, and I've included a mention of r.terraflow in the 'Notes' section and under 'See Also'. I added a section in 'Notes' warning the user about running r.drain on region boundary points, including the part Maris mentioned from the source code in his post. For now the warning is under 'Notes', as I didn't really think is was a bug per se, more of a limitation of the module. I added a hint about using g.region to tweak the region to allow r.drain to find an outlet away from the region boundary. ~ Eric. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.drain documentation
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 this a bug? 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 value to the cell reached immediately prior to it; therefore, it will not necessarily reach the lowest point in the input file. It currently finds pits in the data, rather than the lowest point present.. Why would a local search be a bug in this case? I think it should be like that by design... I'm not too sure my understanding is correct. What do you think? Thanks a lot in advance, Stefano. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.drain documentation
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 point. Is this a bug? feature. 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 value to the cell reached immediately prior to it; therefore, it will not necessarily reach the lowest point in the input file. It currently finds pits in the data, rather than the lowest point present.. Why would a local search be a bug in this case? I think it should be like that by design... It is like that by design so really a feature not a bug. The man page should mention you could fill pits first with a module like r.fill.dir or r.terraflow if you want that. (the first is listed in the see also section but not explained AFAICS) I'm not too sure my understanding is correct. What do you think? You are right I think. My understanding is that it works by starting at the given point and looking for the most downhill cell around it. Then it moves to that cell and looks for the most downhill cell around that. And so on until it can go no further. If your starting cell is only surrounded by cells of higher value (you start in a pit) then it won't move. By being on the edge of the region you have cut down on the numbers of cells around your starting point so there is less chances for finding an outlet point. Zoom right in on the DEM and explore with d.rast.num to confirm. Hamish Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.drain documentation
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 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 point. Is this a bug? feature. 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 value to the cell reached immediately prior to it; therefore, it will not necessarily reach the lowest point in the input file. It currently finds pits in the data, rather than the lowest point present.. Why would a local search be a bug in this case? I think it should be like that by design... It is like that by design so really a feature not a bug. The man page should mention you could fill pits first with a module like r.fill.dir or r.terraflow if you want that. (the first is listed in the see also section but not explained AFAICS) I'm not too sure my understanding is correct. What do you think? You are right I think. My understanding is that it works by starting at the given point and looking for the most downhill cell around it. Then it moves to that cell and looks for the most downhill cell around that. And so on until it can go no further. If your starting cell is only surrounded by cells of higher value (you start in a pit) then it won't move. By being on the edge of the region you have cut down on the numbers of cells around your starting point so there is less chances for finding an outlet point. Zoom right in on the DEM and explore with d.rast.num to confirm. Hamish Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] r.drain documentation
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 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 value to the cell reached immediately prior to it; therefore, it will not necessarily reach the lowest point in the input file. It currently finds pits in the data, rather than the lowest point present.. Why would a local search be a bug in this case? I think it should be like that by design... I'm not too sure my understanding is correct. What do you think? Thanks a lot in advance, Stefano. My short answer is I don't know; but I can try to have a look at the module and try to figure out what is happening...I've never used it before, so it will take some trial-and-error to figure. Alternatively, if anyone listening is familiar with r.drain and can previde some hints, I'll certainly update the manpage. ~ Eric. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.drain documentation
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 draining process reaches map/region edge and there are reasonable arguments that support current behaviour. Definitely it must be reflected in documentation and probably there could be printed some warning if draining process fails over the edge :) Maris. 2008/2/16, stefano negri [EMAIL PROTECTED]: 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. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
