r.stream.order hack= generates order 1 single pixels

[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?

[hcho]

r.stream.order input streams raster

[hcho]

r.stream.order output hack raster

[hellik]

Replying to 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?

thanks.

[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.

[hellik]

Replying to 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.*.

any helpful additions for the manual are welcome!

thanks.

[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...?

[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.

[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...?

see:

-a

Use flow accumulation to trace horton and hack models

did you use this flag when accumulation map is used as input?

[hellik]

Replying to 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.

[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.

[hcho]

r.stream.order hack explained why it's happening.

[neteler]

Milestone renamed