Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#2298 closed defect (invalid)

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

Reported by: hcho Owned by: grass-dev@…
Priority: major Milestone: 7.2.0
Component: Raster Version: svn-trunk
Keywords: r.stream.order Cc:
CPU: x86-64 Platform: Linux

Description

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?

Attachments (3)

r.stream.order_streams.png (4.2 KB) - added by hcho 5 years ago.
r.stream.order input streams raster
r.stream.order_hack.png (4.1 KB) - added by hcho 5 years ago.
r.stream.order output hack raster
r_stream_order_explained.png (6.7 KB) - added by hcho 5 years ago.
r.stream.order hack explained why it's happening.

Download all attachments as: .zip

Change History (13)

Changed 5 years ago by hcho

Attachment: r.stream.order_streams.png added

r.stream.order input streams raster

Changed 5 years ago by hcho

Attachment: r.stream.order_hack.png added

r.stream.order output hack raster

comment:1 in reply to:  description Changed 5 years ago by 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.

comment:2 Changed 5 years ago 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.

comment:3 in reply to:  2 Changed 5 years ago by 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.

comment:4 Changed 5 years ago 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...?

comment:5 in reply to:  4 ; Changed 5 years ago 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.

comment:6 in reply to:  4 Changed 5 years ago 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...?

see:

-a

Use flow accumulation to trace horton and hack models

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

comment:7 in reply to:  5 Changed 5 years ago by 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.

comment:8 Changed 5 years ago 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.
  1. 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.

Changed 5 years ago by hcho

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

comment:9 Changed 5 years ago by hcho

Resolution: invalid
Status: newclosed

comment:10 Changed 4 years ago by neteler

Milestone: 7.1.07.2.0

Milestone renamed

Note: See TracTickets for help on using tickets.