r.stream.extract/r.stream.order - "calculated" mainchannel vs. "real" mainchannel
tested with wingrass64svn, srtm v4.1 (lat/long, ETRS89-LAEA, UTM zone N33) and a river basin in the eastern part of the alps (if needed,a test-location is available).
there'a really nice grass-addon available (thanks to Margherita) which calculates some ecological relevant characteristics of river-basins:
there seems to be sometimes a difference between the "calculated" and the "real" (in the meaning of official hydrography, science literature, etc.) mainchannel.
an example screenshot of river basin in the eastern part of the alps is attached
may I cite Margherita:
1) stream extraction, by r.stream.extract. This step is dependent by the threshold. 2) stream ordering. The Hack order assigns the value 1 to the longest contributor, so that it actually individuates the main channel. This is done by r.stream.order. Successively, r.basin just does a series of monkey steps to turn the first hack order segment into vector and query the length. When Jarek wrote r.stream.order, i asked him to add Hack order just for that. When i was testing it, sometimes i raised with him the problem that you mention, and i don't remember if either he fixed it or wasn't able to reproduce the issue. Said that, i would suggest to raise the issue in dev-ML, so that either Markus Metz (from the r.stream.extract side) or Jarek (from the r.stream.order side) could answer and likely fix the problem. I would also suggest you to verify if the problem is due to a mistake in stream extraction, say the individuated mainchannel is actually longer than the other (natural) one (and this could be likely fixed by varying the threshold) or in hack ordering assignment, which is not able to individuate the longest segment. Only in this second case, a bug-fix by Jarek is needed.
any ideas how to get the calculated mainchannel matching the real mainchannel? I've tried a few different thresholds, but I've always get this "mismatch".
best regards Helmut