Michel,<div><br></div><div>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.</div>
<div><br></div><div>To handle the problem with multiple streams, maybe do some filtering based on stream order?</div><div><br></div><div>Tom<br><br>On Tuesday, February 18, 2014, Michel Wortmann <<a href="mailto:wortmann@pik-potsdam.de">wortmann@pik-potsdam.de</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Thank you for your answers Helmut, Rich
and Tom,<br>
<br>
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.<br>
<br>
Rich: I didnt want to dig that deep into the other code, but yes,
that is definitely an advantage of open source software.<br>
<br>
Helmut: the R.basin is what I was looking at but for multiple
subbasins you will end up looping over them.<br>
<br>
Cheers,<br>
Michel<br>
<br>
On 02/17/2014 08:20 PM, Thomas Adams wrote:<br>
</div>
<blockquote type="cite">
<div>Michel,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Tom</div>
<br>
On Monday, February 17, 2014, Rich Shepard <<a href="javascript:_e(%7B%7D,'cvml','rshepard@appl-ecosys.com');" target="_blank">rshepard@appl-ecosys.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 17 Feb 2014, Michel Wortmann wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
this is what I meant by looping over each subbasin, but that
is exactly<br>
what I would like to avoid as it would take a lot of time for
1000+<br>
subbasins and I dont really need all the other analysis.<br>
</blockquote>
<br>
Michel,<br>
<br>
If you look at the code for that module you'll see that you
cannot get<br>
directly to the end without calculating all the intermediate
values; one<br>
attribute builds on those calculated before it. As long as the
intermediates<br>
are being calculated there's no reason to not put their results
in the<br>
overall table.<br>
<br>
If you want only main channel length for 1000+ subbasins you
might figure<br>
out a way to calculate that directly and modify the code (with a
different<br>
module name, of course) to do that. This is one of the
advantages of open<br>
source software licensed under the GPL.<br>
<br>
Rich<br>
<br>
-- <br>
Richard B. Shepard, Ph.D. | Have knowledge, will
travel.<br>
Applied Ecosystem Services, Inc. |<br>
<<a href="http://www.appl-ecosys.com" target="_blank">http://www.appl-ecosys.com</a>> Voice:
503-667-4517 Fax: 503-667-8863<br>
<br>
_______________________________________________<br>
grass-user mailing list<br>
<a>grass-user@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
</blockquote>
<br>
<br>
-- <br>
Thomas E Adams, III
<div>718 McBurney Drive</div>
<div>Lebanon, OH 45036</div>
<div><br>
</div>
<div>1 (513) 739-9512 (cell)</div>
<div><br>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
grass-user mailing list
<a href="javascript:_e(%7B%7D,'cvml','grass-user@lists.osgeo.org');" target="_blank">grass-user@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a></pre>
</blockquote>
<br>
</div>
</blockquote></div><br><br>-- <br>Thomas E Adams, III<div>718 McBurney Drive</div><div>Lebanon, OH 45036</div><div><br></div><div>1 (513) 739-9512 (cell)</div><div><br></div><br>