[GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance

[Mira Kattwinkel]

Hi,


On 24/09/16 22:56, Markus Metz wrote:
> On Thu, Sep 22, 2016 at 4:17 PM, Mira Kattwinkel
> <kattwinkel-mira at uni-landau.de> wrote:
>> Dear Markus, dear List
>>
>> It is much better now but still not exactly the same. Close to the outlet,
>> the difference in distance to the outlet is about 30 cm (Fig_1b) and in the
>> middle of the network it's about 80 cm (Fig_2b). The upDist raster produced
>> with r.stream.distance gives the exact length I would expect (for Fig_1b: 6
>> * sqrt(2 * 25.0235 ^2) = 212.33) while r.stream.order still results in
>> slightly to high values. .
>>
>> That's good enough for the task I am working on but I wonder why this is the
>> case.
> r.stream.order used single precision floating point values for easting
> and northing while r.stream.distance uses double precision. This can
> make a difference when calculating distances. I changed r.stream.order
> with r69566 to also use double precision for distance calculations.
> Can you please test after reinstalling r.stream.order? Thanks!
Yes, now the distances are exactly the same everywhere in the network.
Thank you!
Mira

>
>> Btw, I checked and my dem really has a cell size of 25.0235. I do not know
>> why this is the case.
> Such odd numbers typically occur when raster data are reprojected with
> default settings and can cause various problems (calculating extents,
> distance calculations, exact export to other data formats etc). The
> default settings for reprojection, e.g with r.proj -g or gdalwarp,
> will produce some output (in the past I have received DEMs with
> strange reprojection settings from someone else in your group), but it
> is worth to fine-tune the output grid geometry (extents and
> resolution) and select an appropriate resampling method which in turn
> depends on the kind of input data and the desired output resolution.
>
> Markus M
>
>> Cheers,
>>
>> Mira
>>
>>
>> On 21/09/16 14:33, Markus Metz wrote:
>>
>> On Wed, Sep 21, 2016 at 1:26 PM, Mira Kattwinkel
>> <kattwinkel-mira at uni-landau.de> wrote:
>>
>> Thanks a lot!
>>
>> I saw that you uploaded a revision. Can you please give me a hint how I
>> upgrade to the revised version of r.stream.order? I am running Linux Mint
>> 17.3 and Windows 7.
>>
>> I have fixed another bug in r.stream.order (r69543): the stream
>> segment lengths are now identical to the lengths of the vector lines
>> and the out_dist value of r.stream.order matches now the output of
>> r.stream.distance. BTW, any reason why the resolution is 25.023 and
>> not exactly 25?
>>
>> Markus M
>>
>> I found that there are nightly pre-built Addon executables for Windows, so I
>> will try that tomorrow. What about Linux? Is it sufficient to just reinstall
>> the addon?
>>
>>
>> All the best,
>>
>> Mira
>>
>>
>>
>> Am 21.09.2016 um 11:08 schrieb Markus Metz:
>>
>> On Tue, Sep 20, 2016 at 10:53 AM, Mira Kattwinkel
>> <kattwinkel-mira at uni-landau.de> wrote:
>>
>> Dear List
>>
>> r.stream.order gives, among other output, the distance of current the
>> stream
>> init from the outlet of the catchment ('out_dist'). So for the most
>> downstream segment this is identical to the length of the segment.
>> r.stream.distance calculates the distance to the outlet and results in a
>> raster file. Both are based on a stream raster and a direction raster.
>>
>> When I compare the results, they are slightly different, although based
>> on
>> the same input files (see the attached Fig1). The raster value is 212.33
>> at
>> the junction, while the out_dist of the line is 237.69. The difference is
>> one cellsize (25.023 in may example), probably due to the horizontal bit
>> of
>> the line at the end (upper right of the figure).
>>
>> Yes, this horizontal bit of the line is a bug in r.stream.order, the
>> stream vector is leaving the current region or going into a NULL cell.
>> All other r.stream.* modules place the outlet on a valid cell. Fixed
>> in r69542.
>>
>> However, this difference is
>> not fixed. In the middle of the network (Fig2) it is larger (81028.9 -
>> 81002.89 = 27).
>>
>> What is the difference in the middle of the network now with r69542?
>>
>> Markus M
>>
>> What is the reason for this difference? Is this a bug or a wanted
>> behaviour?
>>
>> I want to extract the position of points on the network (i.e. upstream of
>> a
>> junction on the lines). To this end, I planned to use the upstream
>> distance
>> of the points and the out_dist of the segments (length(segment) -
>> (out_dist(segment) - upDist(point)) = position(point)).
>> Has anybody another idea how to accomplish this?
>>
>> Thanks a lot,
>> Mira
>>