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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
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
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
