#2298: r.stream.order hack= generates order 1 single pixels
----------------------------+-----------------------------------------------
Reporter: hcho | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.1.0
Component: Raster | Version: svn-trunk
Keywords: r.stream.order | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
Running r.stream.order hack= assigns to single pixel tributaries order 1
instead of 2. I believe that any tributaries should get assigned order >=
2 and the main stream gets 1.
I'm attaching screenshots of a streams and output hack raster maps. In the
streams map, the blue and green streams merge and flow into the gray one.
The gray stream has a small one pixel tributary coming in (center lowest
pixel) and this pixel becomes an order 1 (yellow) in the hack output. I
think this pixel should become 2 (green) because it's a tributary to the
gray main stream. I have a lot these single pixel dangling tributaries and
simply selecting order 1 doesn't make a nice looking single polyline
representing the main stream.
Or maybe, I'm misunderstanding something in the Hack's order algorithm?
#2298: r.stream.order hack= generates order 1 single pixels
----------------------------+-----------------------------------------------
Reporter: hcho | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.1.0
Component: Raster | Version: svn-trunk
Keywords: r.stream.order | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
Comment(by hellik):
Replying to [ticket:2298 hcho]:
> Running r.stream.order hack= assigns to single pixel tributaries order 1
instead of 2. I believe that any tributaries should get assigned order >=
2 and the main stream gets 1.
>
> I'm attaching screenshots of a streams and output hack raster maps. In
the streams map, the blue and green streams merge and flow into the gray
one. The gray stream has a small one pixel tributary coming in (center
lowest pixel) and this pixel becomes an order 1 (yellow) in the hack
output. I think this pixel should become 2 (green) because it's a
tributary to the gray main stream. I have a lot these single pixel
dangling tributaries and simply selecting order 1 doesn't make a nice
looking single polyline representing the main stream.
>
> Or maybe, I'm misunderstanding something in the Hack's order algorithm?
please provide the command producing this result.
are you using the optional?
accumulation=name
Name of input accumulation raster map
if not, can you rerun r.stream.order with using accumulation raster map?
#2298: r.stream.order hack= generates order 1 single pixels
----------------------------+-----------------------------------------------
Reporter: hcho | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.1.0
Component: Raster | Version: svn-trunk
Keywords: r.stream.order | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
Comment(by hcho):
I used the following command:
{{{
r.stream.order stream_rast=streams direction=drain hack=streamshack
}}}
I didn't try it with the accumulation map, but it shouldn't make a
difference in theory, I think?
IMO, I got this problem because my streams raster has the single pixel
tributary and the module cannot handle it properly. If I try with the
accumulation map, it should work correctly because the accumulation map
covers the entire region. I'll try and let you know.
#2298: r.stream.order hack= generates order 1 single pixels
----------------------------+-----------------------------------------------
Reporter: hcho | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.1.0
Component: Raster | Version: svn-trunk
Keywords: r.stream.order | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
Comment(by hellik):
Replying to [comment:2 hcho]:
> I used the following command:
> {{{
> r.stream.order stream_rast=streams direction=drain hack=streamshack
> }}}
>
> I didn't try it with the accumulation map, but it shouldn't make a
difference in theory, I think?
in all my tests I've used r.stream.order with an accumulation map and the
results seemed to be ok.
>
> IMO, I got this problem because my streams raster has the single pixel
tributary and the module cannot handle it properly. If I try with the
accumulation map, it should work correctly because the accumulation map
covers the entire region. I'll try and let you know.
yes, please test with an accumulation map and report the results. the
region should be large enough to cover all accumulation.
maybe accumulation map should be marked as required for calculation for
the r.stream.*.
#2298: r.stream.order hack= generates order 1 single pixels
----------------------------+-----------------------------------------------
Reporter: hcho | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.1.0
Component: Raster | Version: svn-trunk
Keywords: r.stream.order | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
Comment(by hcho):
Unfortunately, accumulation map didn't help. I got the same result. Maybe,
flow direction map is still used for calculating orders? and accumulation
map is optional for doing something else...?
#2298: r.stream.order hack= generates order 1 single pixels
----------------------------+-----------------------------------------------
Reporter: hcho | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.1.0
Component: Raster | Version: svn-trunk
Keywords: r.stream.order | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
Comment(by hellik):
Replying to [hcho]:
> Unfortunately, accumulation map didn't help. I got the same result.
Maybe, flow direction map is still used for calculating orders? and
accumulation map is optional for doing something else...?
what about your region settings? the region and resolution should be
aligned to the DEM, e.g. g.region -a rast=yourDEM align=yourDEM.
#2298: r.stream.order hack= generates order 1 single pixels
----------------------------+-----------------------------------------------
Reporter: hcho | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.1.0
Component: Raster | Version: svn-trunk
Keywords: r.stream.order | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
Comment(by hellik):
Replying to [comment:4 hcho]:
> Unfortunately, accumulation map didn't help. I got the same result.
Maybe, flow direction map is still used for calculating orders? and
accumulation map is optional for doing something else...?
see:
-a
Use flow accumulation to trace horton and hack models
did you use this flag when accumulation map is used as input?
#2298: r.stream.order hack= generates order 1 single pixels
----------------------------+-----------------------------------------------
Reporter: hcho | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.1.0
Component: Raster | Version: svn-trunk
Keywords: r.stream.order | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
Comment(by hellik):
Replying to [comment:5 hellik]:
> Replying to [hcho]:
> > Unfortunately, accumulation map didn't help. I got the same result.
Maybe, flow direction map is still used for calculating orders? and
accumulation map is optional for doing something else...?
>
> what about your region settings? the region and resolution should be
> aligned to the DEM, e.g. g.region -a rast=yourDEM align=yourDEM.
tested here with different DEM (10x10m, 25x25m, 35x35m, 100x100m) and
different thresholds for river extraction, can't reproduce the report.
for the record, beside the region settings, the manual states:
{{{
The module can work only if direction map, stream_rast map and the
computational region have the same settings. It is also required that the
stream_rast map and the direction map come from the same source. For lots
of reason this limitation probably cannot be omitted. This means if
stream_rast map comes from r.stream.extract also the direction map from
r.stream.extract must be used. If stream network was generated with MFD
method also MFD direction map must be used.
}}}
regarding accumulation map:
{{{
Optional input flow accumulation map may be produced by r.watershed or
r.stream.extract. This map is an option only if Horton's or Hack's
ordering is performed. Normally both Horton and Hack ordering is
calculated on cumulative stream length which is calculated internally.
Flow accumulation can be used if user wants to calculate the main channel
as the stream with the highest value of aqccumulation.
}}}
#2298: r.stream.order hack= generates order 1 single pixels
----------------------------+-----------------------------------------------
Reporter: hcho | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.1.0
Component: Raster | Version: svn-trunk
Keywords: r.stream.order | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
Comment(by hcho):
I did more testing and found the reason why I got this issue. It was not a
bug of any modules, I would say. In my new screenshot attached, the green
line was created by r.stream.order stream_vector= and the black line and
purple pixels by r.stream.order hack= & r.to.vect.
As you can see, the green line flows downwards at the point where the
black and green lines don't agree, and goes right-up. This is the correct
flow line and was rasterized to the purple pixels "correctly". But the
problem is that by looking at the pixels only, we or r.to.vect cannot tell
if the flow should be drawn like the green line (with no single pixel
tributary) or black line (with a single pixel tributary), and r.to.vect
did the latter, causing single pixel tributaries here and there. Can we
say r.to.vect did something wrong? I wouldn't say so.
There are two solutions.
1. Use r.stream.order stream_vect=, but it requires an accumulation map
and vector clipping/merging if you're only interested in the main stream
in a study area. The main stream will be exact though.
2. Use r.stream.order hack= and r.to.vect, but build polylines using
v.build.polylines, clean up dangles with v.edit, and rebuild polylines.
The main stream will lose single pixel sharp turns and be a little bit
smoother than 1.