[GRASS-user] r.water.outlet: no map displayed

   For some reason r.water.outlet now produces an empty map. It did before I
re-projected source maps to ensure they all have the proper values in the
target location.

   Attached is an image of the input drainage map and the coordinate feature
(the lower dot).

   This is how r.info describes the output (watershed) map:

Type of Map: raster Number of Categories: 0 |
    Data Type: CELL
    Rows: 1004
    Columns: 577
    Total Cells: 579308

    Projection: NAD83(HARN) / Oregon North
    N: 175430.80940854 S: 174426.61003591 Res: 1.00019858
    E: 2296197.40538338 W: 2295620.05945154 Res: 1.00059954
    Range of data: min = 1 max = 1

Data Description: |
    generated by r.water.outlet

    Comments:
    r.water.outlet --overwrite input="drainage" output="watershed" coord\
      inates=2295821.27858,175258.094514

   I'm not seeing what I've done differently so that there's no visible
display of map "watershed."

TIA,

Rich

(attachments)

drainage-outlet-coord.png

Rich Shepard wrote

For some reason r.water.outlet now produces an empty map. It did before I
re-projected source maps to ensure they all have the proper values in the
target location.

   Attached is an image of the input drainage map and the coordinate
feature
(the lower dot).

   This is how r.info describes the output (watershed) map:

Type of Map: raster Number of Categories: 0 |
    Data Type: CELL
    Rows: 1004
    Columns: 577
    Total Cells: 579308

    Projection: NAD83(HARN) / Oregon North
    N: 175430.80940854 S: 174426.61003591 Res: 1.00019858
    E: 2296197.40538338 W: 2295620.05945154 Res: 1.00059954
    Range of data: min = 1 max = 1

Data Description: |
    generated by r.water.outlet

    Comments:
    r.water.outlet --overwrite input="drainage" output="watershed" coord\
      inates=2295821.27858,175258.094514

   I'm not seeing what I've done differently so that there's no visible
display of map "watershed."

TIA,

Rich
_______________________________________________
grass-user mailing list

grass-user@.osgeo

http://lists.osgeo.org/mailman/listinfo/grass-user

drainage-outlet-coord.png (140K)
<http://osgeo-org.1560.x6.nabble.com/attachment/5288967/0/drainage-outlet-coord.png>

=> Range of data: min = 1 max = 1

it seems the raster isn't empty.

tested here the NC sample from the manual:
https://grass.osgeo.org/grass73/manuals/r.water.outlet.html

works nicly.

please test the sample from the manual with the NC sample data set [1], then
follow the example workflow with your data and report the results and the
used commands (g.region, r.watershed, r.water.outlet).

[1] https://grass.osgeo.org/download/sample-data/

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/r-water-outlet-no-map-displayed-tp5288967p5288992.html
Sent from the Grass - Users mailing list archive at Nabble.com.

Hello Rich,

When using r.water.outlet you need to be careful setting the outlet on the exact flow line. Using the flow accumulation map is useful for that task. If the outlet point is just one cell on the side, the generated watershed could be tiny.
Hope this helps.

Laurent

···

El oct. 2, 2016 6:17 PM, “Rich Shepard” <rshepard@appl-ecosys.com> escribió:

For some reason r.water.outlet now produces an empty map. It did before I
re-projected source maps to ensure they all have the proper values in the
target location.

Attached is an image of the input drainage map and the coordinate feature
(the lower dot).

This is how r.info describes the output (watershed) map:

Type of Map: raster Number of Categories: 0 |
Data Type: CELL
Rows: 1004
Columns: 577
Total Cells: 579308

Projection: NAD83(HARN) / Oregon North
N: 175430.80940854 S: 174426.61003591 Res: 1.00019858
E: 2296197.40538338 W: 2295620.05945154 Res: 1.00059954
Range of data: min = 1 max = 1

Data Description: |
generated by r.water.outlet

Comments:
r.water.outlet --overwrite input=“drainage” output=“watershed” coord
inates=2295821.27858,175258.094514

I’m not seeing what I’ve done differently so that there’s no visible
display of map “watershed.”

TIA,

Rich


grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

On Mon, Oct 3, 2016 at 10:07 AM, Laurent C. <lrntct@gmail.com> wrote:

Hello Rich,

When using r.water.outlet you need to be careful setting the outlet on the
exact flow line. Using the flow accumulation map is useful for that task. If
the outlet point is just one cell on the side, the generated watershed could
be tiny.

The r.lfp addon is perhaps also interesting here:

https://grass.osgeo.org/grass70/manuals/addons/r.lfp.html

Markus

On Mon, 3 Oct 2016, Laurent C. wrote:

When using r.water.outlet you need to be careful setting the outlet on the
exact flow line. Using the flow accumulation map is useful for that task.
If the outlet point is just one cell on the side, the generated watershed
could be tiny. Hope this helps.

Laurent,

   I'm working with the raster map (drainage) produced by r.watershed. The
outlet is a point whose coordinates I get from the info icon on the map
display window using that point.

   Prior to this attempt this same work flow produced a map of the area
draining to that point. It occurred to me that I might have used r.mask on
the watershed map prior to displaying it, but I don't understand why this
should matter. The only difference, as far as I know, is that I re-projected
all maps (vector and raster) from the original international feet location
to the new meters location.

   I'll test per Helmut's suggestion using the NC data and post results later
today.

Thanks,

Rich

On Mon, 3 Oct 2016, Helmut Kudrnovsky wrote:

please test the sample from the manual with the NC sample data set [1],
then follow the example workflow with your data and report the results and
the used commands (g.region, r.watershed, r.water.outlet).

Helmut,

   Yes, that works here, too. Of course, my data also worked until yesterday
afternoon and why it now fails is what I need to discover.

   In the NC data set from mapset user1 I selected 'elevation' as input to
r.watershed and 'drainage' as output. For r.water.outlet the input was
'drainage,' the output 'watershed,' and the coordinates a point I selected
that looked like a basin outlet. When I displayed 'watershed' a small yellow
area appeared.

   This is how it used to work here, too.

   Here's the region and commands used on my data:

From project location:

g.region -p

projection: 99 (NAD83(HARN) / Oregon North)
zone: 0
datum: nad83harn
ellipsoid: grs80
north: 175430.80940854
south: 174426.61003591
west: 2295620.05945154
east: 2296197.40538338
nsres: 1.00019858
ewres: 1.00059954
rows: 1004
cols: 577
cells: 579308

g.list type=rast

bare_earth

r.watershed elev=bare_earth drain=drainage --overwrite

r.water.outlet in=drainage out=watershed coord=2295821.27858,175258.094514 -- overwrite

   But, now when I use the GUI icon to display 'watershed' nothing appears.

   Using d.mon start=wx0; d.rast map=watershed also displayed nothing.

   Something changed. How do I trace the reason to the source?

Thanks,

Rich

On Mon, 3 Oct 2016, Markus Neteler wrote:

The r.lfp addon is perhaps also interesting here:
https://grass.osgeo.org/grass70/manuals/addons/r.lfp.html

Markus,

   Installed r.stream.distance, then r.lfp. Results:

r.lfp in=drainage out=lfp coord=2295821.27858,175258.094514

Scanning input for column types...
Number of columns: 2
Number of rows: 1
Importing points...
  100%
Building topology for vector map <r_lfp_525_outlet@analyses>...
Registering primitives...
One primitive registered
One vertex registered
Building areas...
  100%
0 areas built
0 isles built
Attaching islands...
Attaching centroids...
  100%
Number of nodes: 0
Number of primitives: 1
Number of points: 1
Number of lines: 0
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
Reading features...
  100%
Writing raster map...
  100%
v.to.rast complete.
Calculating segments in direction <DOWNSTREAM> (may take some time)...
Reading raster map <r_lfp_525_outlet>...
  100%
Reading raster map <drainage>...
  100%
Finding nodes...
Calculate downstream parameters...
  100%
Writing raster map <r_lfp_525_flds>...
  100%
All in RAM calculation - method <UPSTREAM>...
Reading raster map <r_lfp_525_outlet>...
  100%
Reading raster map <drainage>...
  100%
Finding nodes...
Calculate upstream parameters...
  100%
Writing raster map <r_lfp_525_flus>...
  100%
Invalid map <nan>
Parse error
ERROR: parse error
ERROR: Cannot create longest flow path raster map

   Perhaps this is a clue about what changed from Saturday to Sunday? I
suppose that I can (again) completely re-project from the feet location to
the meters location, but that takes many hours for the basic LiDAR DEMs
(bare earth and highest hit).

Rich

Rich,

On Mon, Oct 3, 2016 at 5:57 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
...

From project location:

g.region -p

projection: 99 (NAD83(HARN) / Oregon North)
zone: 0
datum: nad83harn
ellipsoid: grs80
north: 175430.80940854
south: 174426.61003591
west: 2295620.05945154
east: 2296197.40538338
nsres: 1.00019858
ewres: 1.00059954

^-- you have no-square pixels, is that on purpose? Of course that's
supported but just to reduce the amount of error if undesired.

Markus

On Mon, 3 Oct 2016, Markus Neteler wrote:

nsres: 1.00019858
ewres: 1.00059954

^-- you have no-square pixels, is that on purpose? Of course that's
supported but just to reduce the amount of error if undesired.

Markus,

   Nope. That's the result of re-projecting from
NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl (EPSG 2992) to
NAD83(HARN) / Oregon North (EPSG 2838). I saw the discrepancy but assumed
GRASS knew what it was doing.

   I can see how that could cause the problem.

Thanks,

Rich

rows: 1004
cols: 577

as the DEM raster you're using isn't that large, may you share the data
(offline)?

e.g. by a compressed geotiff, by e.g. using

r.out.gdal -f input=yourelevation output=outraster.tif format=GTiff
createopt=COMPRESS=LZW,PREDICTOR=2

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/r-water-outlet-no-map-displayed-tp5288967p5289094.html
Sent from the Grass - Users mailing list archive at Nabble.com.

Rich Shepard wrote

On Mon, 3 Oct 2016, Markus Neteler wrote:

nsres: 1.00019858
ewres: 1.00059954

^-- you have no-square pixels, is that on purpose? Of course that's
supported but just to reduce the amount of error if undesired.

Markus,

   Nope. That's the result of re-projecting from
NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl (EPSG 2992) to
NAD83(HARN) / Oregon North (EPSG 2838). I saw the discrepancy but assumed
GRASS knew what it was doing.

   I can see how that could cause the problem.

I've got the data offline, and tested locally

findings with the coordinates taken from the thread:

r.watershed elevation=outraster@data drainage=draindir
r.water.outlet input=draindir@data output=basin
coordinates=2295821.27858,175258.094514

to see the r.water.outlet results, just do

r.to.vect input=basin output=vbasin

the result is just 1 pixel, as already earlier mentioned in the thread,
because the coordinates=2295821.27858,175258.094514 aren't a outlet point.

easy to check by e.g.

r.stream.extract elevation=outraster@data accumulation=accum@data
threshold=10 d8cut=1000000000000 stream_raster=runiqe stream_vector=vunique

then v.in.ascii 2295821.27858,175258.094514, and overlay the extracted
streams and the v.in.ascii-vector

randomly tested

r.water.outlet --verbose input=draindir@data output=basin2
2295824.16407,175258.754074 (which is on the stream network by
r.stream.extract); see screenshot check.png
<http://osgeo-org.1560.x6.nabble.com/file/n5289100/check.png&gt; ru

the solution may be, find a outlet point which is on the stream network
which is appropriate for your analysis and then run r.water.outlet.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/r-water-outlet-no-map-displayed-tp5288967p5289100.html
Sent from the Grass - Users mailing list archive at Nabble.com.