<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 02/15/2012 03:33 PM, GRASS GIS wrote:
<blockquote
cite="mid:040.22954bf2f21865559e44da3c5f7e412e@osgeo.org"
type="cite">
<pre wrap="">#1577: r.stream.extract/r.stream.order - "calculated" mainchannel vs. "real"
mainchannel
-----------------------------+----------------------------------------------
Reporter: hellik | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: minor | Milestone: 6.4.2
Component: Raster | Version: svn-releasebranch64
Keywords: wingrass, addon | Platform: MSWindows Vista
Cpu: x86-32 |
-----------------------------+----------------------------------------------
hi,
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:
<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/grass/browser/grass">http://trac.osgeo.org/grass/browser/grass</a>-
addons/grass6/raster/r.basin/r.basin.py
the mainchannel of such a river basin is calculated by some calculation
steps of r.stream.extract [1]
and r.stream.order [2]
<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/grass/browser/grass">http://trac.osgeo.org/grass/browser/grass</a>-
addons/grass6/raster/r.basin/r.basin.py#L261
<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/grass/browser/grass">http://trac.osgeo.org/grass/browser/grass</a>-
addons/grass6/raster/r.basin/r.basin.py#L368
there seems to be sometimes a difference between the "calculated" and the
"real" (in the meaning of official hydrography,
science literature, etc.) mainchannel.
</pre>
</blockquote>
what does it means? Any reference? Main channel established in real
network or algorithms of modeling main channel?<br>
<blockquote
cite="mid:040.22954bf2f21865559e44da3c5f7e412e@osgeo.org"
type="cite">
<pre wrap="">
an example screenshot of river basin in the eastern part of the alps is
attached
</pre>
</blockquote>
where it is?<br>
<br>
Sorry. I cannot relate to this ticket, because, it is not clear what
kind of issue it reports.<br>
<br>
r.stream.order does not calculate "main channel". It is impossible,
bacuase main channel is marked according different criteria,
depending on national surveys. R.stream.order in Gravielius/Hack
hierarchy (Hack is used after jGrass, this name is not especially
correct) calculate stream of first order as longest channel or
optionally if you use SFD it can use alternatively channel draining
biggest basin area. That all. if it is main or not main channel it
is interpretation. Data generated by hydrological modeling are
deterministic realization of clear algorithms on the specific
dataset and does not reflect reality in 100%. <br>
<br>
Hope it helps<br>
<blockquote
cite="mid:040.22954bf2f21865559e44da3c5f7e412e@osgeo.org"
type="cite">
<pre wrap="">
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
[1] <a class="moz-txt-link-freetext" href="http://trac.osgeo.org/grass/browser/grass">http://trac.osgeo.org/grass/browser/grass</a>-
addons/grass6/raster/r.stream.extract
[2] <a class="moz-txt-link-freetext" href="http://trac.osgeo.org/grass/browser/grass">http://trac.osgeo.org/grass/browser/grass</a>-
addons/grass6/raster/r.stream.order
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
grass-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/grass-dev">http://lists.osgeo.org/mailman/listinfo/grass-dev</a></pre>
</blockquote>
<br>
</body>
</html>