# Hydrological grass question: main channel length for each subbasin

8 messages
Open this post in threaded view
|

## Hydrological grass question: main channel length for each subbasin

 Hi list, I'm looking for a way to calculate the main channel length and width for a large number of subbasins within a river basin. I understand that the r.stream.* addon / R.basin gives me the main channel length along with a tone of other statistics but only for one catchment. Of course, I could loop over all my subbasins and calculate the statistics one by one, but I fear that will be time consuming and I dont actually need all the other analysis. I have got an efficient way to calculate the mainstream for each subbasin as a vector, but I'm struggling to get from there to the distance of the longest segment in each subbasin. Maybe someone has an idea to complete this idea of a work flow: raster=mainstreams (thinned raster with unique categories for each subbasin) r.to.vect to vectorise, this unfortunately gives me line segments crossing over subbasin boundaries somehow make stream segments from each subbasin v.to.db to measure the distance of each line segment choose the longest distance for each subbasin Any suggestions/help would be much appreciated. Regards, Michel _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user
Open this post in threaded view
|

## Re: Hydrological grass question: main channel length for each subbasin

 Michel,If you do what you suggest, but first apply a MASK using each subbasin; so, when you calculate the statistics, they will be for one subbasin at a time; with a very simple script you could loop through each subbasin. I hope this helps.Cheers!TomOn Sun, Feb 16, 2014 at 11:07 AM, Michel Wortmann wrote: Hi list, I'm looking for a way to calculate the main channel length and width for a large number of subbasins within a river basin. I understand that the r.stream.* addon / R.basin gives me the main channel length along with a tone of other statistics but only for one catchment. Of course, I could loop over all my subbasins and calculate the statistics one by one, but I fear that will be time consuming and I dont actually need all the other analysis. I have got an efficient way to calculate the mainstream for each subbasin as a vector, but I'm struggling to get from there to the distance of the longest segment in each subbasin. Maybe someone has an idea to complete this idea of a work flow: raster=mainstreams (thinned raster with unique categories for each subbasin) r.to.vect to vectorise, this unfortunately gives me line segments crossing over subbasin boundaries somehow make stream segments from each subbasin v.to.db to measure the distance of each line segment choose the longest distance for each subbasin Any suggestions/help would be much appreciated. Regards, Michel _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user
Open this post in threaded view
|

## Re: Hydrological grass question: main channel length for each subbasin

 In reply to this post by Michel Wortmann >Of course, I could >loop over all my subbasins and calculate the statistics one by one, but >I fear that will be time consuming and I dont actually need all the >other analysis. have a look at http://grasswiki.osgeo.org/wiki/R.basin for multiple basins' analysis best regards Helmut
Open this post in threaded view
|

## Re: Hydrological grass question: main channel length for each subbasin

 In reply to this post by Thomas Adams-2 Thanks Tom, this is what I meant by looping over each subbasin, but that is exactly what I would like to avoid as it would take a lot of time for 1000+ subbasins and I dont really need all the other analysis. Cheers, Michel On 02/16/2014 05:58 PM, Thomas Adams wrote: Michel, If you do what you suggest, but first apply a MASK using each subbasin; so, when you calculate the statistics, they will be for one subbasin at a time; with a very simple script you could loop through each subbasin. I hope this helps. Cheers! Tom On Sun, Feb 16, 2014 at 11:07 AM, Michel Wortmann wrote: Hi list, I'm looking for a way to calculate the main channel length and width for a large number of subbasins within a river basin. I understand that the r.stream.* addon / R.basin gives me the main channel length along with a tone of other statistics but only for one catchment. Of course, I could loop over all my subbasins and calculate the statistics one by one, but I fear that will be time consuming and I dont actually need all the other analysis. I have got an efficient way to calculate the mainstream for each subbasin as a vector, but I'm struggling to get from there to the distance of the longest segment in each subbasin. Maybe someone has an idea to complete this idea of a work flow: raster=mainstreams (thinned raster with unique categories for each subbasin) r.to.vect to vectorise, this unfortunately gives me line segments crossing over subbasin boundaries somehow make stream segments from each subbasin v.to.db to measure the distance of each line segment choose the longest distance for each subbasin Any suggestions/help would be much appreciated. Regards, Michel _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user
Open this post in threaded view
|

## Re: Hydrological grass question: main channel length for each subbasin

 On Mon, 17 Feb 2014, Michel Wortmann wrote: > this is what I meant by looping over each subbasin, but that is exactly > what I would like to avoid as it would take a lot of time for 1000+ > subbasins and I dont really need all the other analysis. Michel,    If you look at the code for that module you'll see that you cannot get directly to the end without calculating all the intermediate values; one attribute builds on those calculated before it. As long as the intermediates are being calculated there's no reason to not put their results in the overall table.    If you want only main channel length for 1000+ subbasins you might figure out a way to calculate that directly and modify the code (with a different module name, of course) to do that. This is one of the advantages of open source software licensed under the GPL. Rich -- Richard B. Shepard, Ph.D.          |      Have knowledge, will travel. Applied Ecosystem Services, Inc.   |     Voice: 503-667-4517      Fax: 503-667-8863 _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user
Open this post in threaded view
|

## Re: Hydrological grass question: main channel length for each subbasin

 Michel,If it were me, I'd go ahead and take the hit with the brute force method. However, I was involved with a project in calculating basin average precipitation in real-time, over many basins (~700) for many time periods, several times per day. Each second was critical; what we did was to convert the real values to ints as cat values and associate them to basin IDs; then convert back to reals -- this was very fast (I can provide shell scripting). I understand this is not want you want, but you may be able to do something analogously, by converting the stream main channel pixels to the same cat value and count them (as they are associated with each basin), then multiply by the pixel resolution -- if you follow what I'm suggesting... Doing what we did, did not involve any looping -- which would have been disasterously slow for our application. TomOn Monday, February 17, 2014, Rich Shepard <[hidden email]> wrote: On Mon, 17 Feb 2014, Michel Wortmann wrote: this is what I meant by looping over each subbasin, but that is exactly what I would like to avoid as it would take a lot of time for 1000+ subbasins and I dont really need all the other analysis. Michel,   If you look at the code for that module you'll see that you cannot get directly to the end without calculating all the intermediate values; one attribute builds on those calculated before it. As long as the intermediates are being calculated there's no reason to not put their results in the overall table.   If you want only main channel length for 1000+ subbasins you might figure out a way to calculate that directly and modify the code (with a different module name, of course) to do that. This is one of the advantages of open source software licensed under the GPL. Rich -- Richard B. Shepard, Ph.D.          |      Have knowledge, will travel. Applied Ecosystem Services, Inc.   |     Voice: 503-667-4517      Fax: 503-667-8863 _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user -- Thomas E Adams, III718 McBurney DriveLebanon, OH 450361 (513) 739-9512 (cell) _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user
 Thank you for your answers Helmut, Rich and Tom, Tom: this is indeed a smart way of doing it and I have associated each main channel pixel to a subbasin ID, but counting the cells and multiplying that by the resolution seems a bit simplistic or would you disagree with that? I have now done this with consideration for those cells draining diagonally (using the drainage). Still leaves some subbasins that for some reasons have more than one inlet and thus several branches which then overestimates the length. Rich: I didnt want to dig that deep into the other code, but yes, that is definitely an advantage of open source software. Helmut: the R.basin is what I was looking at but for multiple subbasins you will end up looping over them. Cheers, Michel On 02/17/2014 08:20 PM, Thomas Adams wrote: Michel, If it were me, I'd go ahead and take the hit with the brute force method. However, I was involved with a project in calculating basin average precipitation in real-time, over many basins (~700) for many time periods, several times per day. Each second was critical; what we did was to convert the real values to ints as cat values and associate them to basin IDs; then convert back to reals -- this was very fast (I can provide shell scripting). I understand this is not want you want, but you may be able to do something analogously, by converting the stream main channel pixels to the same cat value and count them (as they are associated with each basin), then multiply by the pixel resolution -- if you follow what I'm suggesting... Doing what we did, did not involve any looping -- which would have been disasterously slow for our application. Tom On Monday, February 17, 2014, Rich Shepard <[hidden email]> wrote: On Mon, 17 Feb 2014, Michel Wortmann wrote: this is what I meant by looping over each subbasin, but that is exactly what I would like to avoid as it would take a lot of time for 1000+ subbasins and I dont really need all the other analysis. Michel,   If you look at the code for that module you'll see that you cannot get directly to the end without calculating all the intermediate values; one attribute builds on those calculated before it. As long as the intermediates are being calculated there's no reason to not put their results in the overall table.   If you want only main channel length for 1000+ subbasins you might figure out a way to calculate that directly and modify the code (with a different module name, of course) to do that. This is one of the advantages of open source software licensed under the GPL. Rich -- Richard B. Shepard, Ph.D.          |      Have knowledge, will travel. Applied Ecosystem Services, Inc.   |     Voice: 503-667-4517      Fax: 503-667-8863 _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user -- Thomas E Adams, III 718 McBurney Drive Lebanon, OH 45036 1 (513) 739-9512 (cell) ```_______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user``` _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user
 Michel,I was thinking there may be a problem with multiple streams in a single basin, so that's not a surprise. Depending on your application, if your location has a fine enough raster resolution, I would think counting pixels and multiplying by the resolution would be an adequate approximation. To handle the problem with multiple streams, maybe do some filtering based on stream order?TomOn Tuesday, February 18, 2014, Michel Wortmann <[hidden email]> wrote: Thank you for your answers Helmut, Rich and Tom, Tom: this is indeed a smart way of doing it and I have associated each main channel pixel to a subbasin ID, but counting the cells and multiplying that by the resolution seems a bit simplistic or would you disagree with that? I have now done this with consideration for those cells draining diagonally (using the drainage). Still leaves some subbasins that for some reasons have more than one inlet and thus several branches which then overestimates the length. Rich: I didnt want to dig that deep into the other code, but yes, that is definitely an advantage of open source software. Helmut: the R.basin is what I was looking at but for multiple subbasins you will end up looping over them. Cheers, Michel On 02/17/2014 08:20 PM, Thomas Adams wrote: Michel, If it were me, I'd go ahead and take the hit with the brute force method. However, I was involved with a project in calculating basin average precipitation in real-time, over many basins (~700) for many time periods, several times per day. Each second was critical; what we did was to convert the real values to ints as cat values and associate them to basin IDs; then convert back to reals -- this was very fast (I can provide shell scripting). I understand this is not want you want, but you may be able to do something analogously, by converting the stream main channel pixels to the same cat value and count them (as they are associated with each basin), then multiply by the pixel resolution -- if you follow what I'm suggesting... Doing what we did, did not involve any looping -- which would have been disasterously slow for our application. Tom On Monday, February 17, 2014, Rich Shepard <rshepard@...> wrote: On Mon, 17 Feb 2014, Michel Wortmann wrote: this is what I meant by looping over each subbasin, but that is exactly what I would like to avoid as it would take a lot of time for 1000+ subbasins and I dont really need all the other analysis. Michel,   If you look at the code for that module you'll see that you cannot get directly to the end without calculating all the intermediate values; one attribute builds on those calculated before it. As long as the intermediates are being calculated there's no reason to not put their results in the overall table.   If you want only main channel length for 1000+ subbasins you might figure out a way to calculate that directly and modify the code (with a different module name, of course) to do that. This is one of the advantages of open source software licensed under the GPL. Rich -- Richard B. Shepard, Ph.D.          |      Have knowledge, will travel. Applied Ecosystem Services, Inc.   |     Voice: 503-667-4517      Fax: 503-667-8863 _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user -- Thomas E Adams, III 718 McBurney Drive Lebanon, OH 45036 1 (513) 739-9512 (cell) ```_______________________________________________ grass-user mailing list grass-user@... http://lists.osgeo.org/mailman/listinfo/grass-user``` -- Thomas E Adams, III718 McBurney DriveLebanon, OH 450361 (513) 739-9512 (cell) _______________________________________________ grass-user mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-user