Hydrological grass question: main channel length for each subbasin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Hydrological grass question: main channel length for each subbasin

Michel Wortmann
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
Reply | Threaded
Open this post in threaded view
|

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

Thomas Adams-2
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Helmut Kudrnovsky
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
Reply | Threaded
Open this post in threaded view
|

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

Michel Wortmann
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Rich Shepard
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.   |
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

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

Thomas Adams-2
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.   |
<http://www.appl-ecosys.com>     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
Reply | Threaded
Open this post in threaded view
|

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

Michel Wortmann
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.   |
<http://www.appl-ecosys.com>     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
Reply | Threaded
Open this post in threaded view
|

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

Thomas Adams-2
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?

Tom

On 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;rshepard@appl-ecosys.com&#39;);" target="_blank">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.   |
<http://www.appl-ecosys.com>     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
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;grass-user@lists.osgeo.org&#39;);" target="_blank">grass-user@...
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