Re: [GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance
Hi, On 24/09/16 22:56, Markus Metz wrote: On Thu, Sep 22, 2016 at 4:17 PM, Mira Kattwinkel 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 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 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance
On Thu, Sep 22, 2016 at 4:17 PM, Mira Kattwinkel 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! > > 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 > 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 > 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 > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > -- > Dr. Mira Kattwinkel > Quantitative Landscape Ecology > Institute for Environmental Sciences > University of Koblenz-Landau > Fortstraße 7 > 76829 Landau > Germany > Fon: + 49 6341 280-31553 > > > -- > Dr. Mira Kattwinkel > Quantitative Landscape Ecology > Institute for Environmental Sciences > University of Koblenz-Landau > Fortstraße 7 > 76829 Landau > Germany > Phone: + 49 6341 280-31553 > Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance
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. Btw, I checked and my dem really has a cell size of 25.0235. I do not know why this is the case. Cheers, Mira On 21/09/16 14:33, Markus Metz wrote: On Wed, Sep 21, 2016 at 1:26 PM, Mira Kattwinkel 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 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Fon: + 49 6341 280-31553 -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Phone: + 49 6341 280-31553 Office: Building I, Room 2.02 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance
On Wed, Sep 21, 2016 at 1:26 PM, Mira Kattwinkel 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 >> 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 >>> >>> >>> ___ >>> grass-user mailing list >>> grass-user@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-user > > > -- > Dr. Mira Kattwinkel > Quantitative Landscape Ecology > Institute for Environmental Sciences > University of Koblenz-Landau > Fortstraße 7 > 76829 Landau > Germany > Fon: + 49 6341 280-31553 > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance
>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? Yes, for Linux it's enough to reinstall. For Windows you have to wait for the next daily build. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Different-distances-to-outlet-for-r-stream-order-and-r-stream-distance-tp5286849p5287085.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance
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 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 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Dr. Mira Kattwinkel Quantitative Landscape Ecology Institute for Environmental Sciences University of Koblenz-Landau Fortstraße 7 76829 Landau Germany Fon: + 49 6341 280-31553 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Different distances to outlet for r.stream.order and r.stream.distance
On Tue, Sep 20, 2016 at 10:53 AM, Mira Kattwinkel 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 > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user