[GRASS-user] Hydrological grass question: main channel length for each subbasin

[Thomas Adams]

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 <wortmann at pik-potsdam.de>
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 at appl-ecosys.com<javascript:_e(%7B%7D,'cvml','rshepard at appl-ecosys.com');>>
> 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
>> grass-user at lists.osgeo.org
>> 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 listgrass-user at lists.osgeo.org <javascript:_e(%7B%7D,'cvml','grass-user at lists.osgeo.org');>http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
>

-- 
Thomas E Adams, III
718 McBurney Drive
Lebanon, OH 45036

1 (513) 739-9512 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20140218/2ef6f855/attachment.html>