Re: [GRASS-user] r.flow: define contributing area

[Johannes Radinger]

Rich,

Maybe have a look at r.lake: 
https://grass.osgeo.org/grass70/manuals/r.lake.html. This module fills the area 
upstream a dam or a blocked stream.

Cheers,
Johannes



 Original message From: Thomas Adams 
 Date:04/10/2016  04:32  (GMT+01:00) 
To: Rich Shepard  Cc: 
grass-user@lists.osgeo.org Subject: Re: [GRASS-user] r.flow: define 
contributing area 
Rich,

The only way to -correctly- do this is with hydrodynamic modeling, such as with 
HEC-RAS. It can be very crudely approximated with r.damflood 
(https://grass.osgeo.org/grass70/manuals/addons/r.damflood.html).

Tom

On Mon, Oct 3, 2016 at 7:39 PM, Rich Shepard  wrote:
  Reading the r.flow manual page suggests that the use of the '-u'
(upstream) option allows determination of flowlines and lengths that can be
used to delineate the area that would drain to a specific point. Is this
correct?

  To determine the area flooded if an outlet is plugged would require the
inverse of r.drain. That module calculates the area flooded with surface
water originating from a specific point; e.g., a hole in a dike or dam. The
closest I've seen to do the opposite seems to be r.flow. The quantity of
surface water and the rate of accumulation and infiltration into the vadoz
zone are not of interest, only the area flooded is needed.

  The modules listed under the Natural Hazards application page all appear
to delineate the area flooded from a point source. Can any of these be used
backwards to delineate the area flooded if an outlet is blocked?

  I'd appreciate pointers and suggestions based on cumulative experience
here for appropriate module(s).

TIA,

Rich
___
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

Re: [GRASS-user] r.flow: define contributing area

[Thomas Adams]

Rich,

The only way to -correctly- do this is with hydrodynamic modeling, such as
with HEC-RAS. It can be very crudely approximated with r.damflood (
https://grass.osgeo.org/grass70/manuals/addons/r.damflood.html).

Tom

On Mon, Oct 3, 2016 at 7:39 PM, Rich Shepard 
wrote:

>   Reading the r.flow manual page suggests that the use of the '-u'
> (upstream) option allows determination of flowlines and lengths that can be
> used to delineate the area that would drain to a specific point. Is this
> correct?
>
>   To determine the area flooded if an outlet is plugged would require the
> inverse of r.drain. That module calculates the area flooded with surface
> water originating from a specific point; e.g., a hole in a dike or dam. The
> closest I've seen to do the opposite seems to be r.flow. The quantity of
> surface water and the rate of accumulation and infiltration into the vadoz
> zone are not of interest, only the area flooded is needed.
>
>   The modules listed under the Natural Hazards application page all appear
> to delineate the area flooded from a point source. Can any of these be used
> backwards to delineate the area flooded if an outlet is blocked?
>
>   I'd appreciate pointers and suggestions based on cumulative experience
> here for appropriate module(s).
>
> TIA,
>
> Rich
> ___
> 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

Re: [GRASS-user] map display query and layers

[Dave Roberts]

Dear Maciek,

Thanks you sincerely for an updated PKGBUILD.  If I delete the 
includes for liblas and python-termcolor it builds successfully. 
Whether or not my previous reassignment of /usr/bin/python (see response 
to Markus) had any effect or whether your PKGBUILD finessed that I don't 
know.  Like the AUR PKGBUILD your PKGBUILD generated an extraordinary 
number of warnings about


 dlsym(acl_get_file): /usr/lib/libfakeroot/libfakeroot.so: undefined 
symbol: acl_get_file


As I expected

pacman -U grass7-7.0.5-1-x86_64.pkg.tar.xz

complained about conflicts with the existing GRASS7; when I approved an 
overwrite it installed fine.


   At any rate, since I did not edit what.c to apply Moritz's patch 
none of this affects my issues with map display query or d.what.vect. 
I'll get back to that in a subsequent post.


Thanks, Dave


On 10/03/16 15:46, Maciej Sieczka wrote:

W dniu 03.10.2016 o 23:18, Markus Neteler pisze:

On Mon, Oct 3, 2016 at 7:12 PM, Dave Roberts 
wrote:

Hi Markus,

Given your kind offer I elected to try and compile GRASS again. This
time I was successful (after a few false starts).  The primary
problem was
python confusion, where arch linux assumes python3 as the default,
and I had
not done the symbolic links  correctly to redicrect to python2.
After that

./configure \
   --without-freetype \
   --with-postgress \
   --with-readline

worked successfully.  I'm now testing GRASS-7.0.5.


Hi Dave,

My PKGBUILD may help:
https://gitlab.com/tutturu/grass7_pkgbuild/blob/master/PKGBUILD.
Advertised on https://grass.osgeo.org/download/software/linux/.

Maciek



--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.flow: define contributing area

[Rich Shepard]

  Reading the r.flow manual page suggests that the use of the '-u'
(upstream) option allows determination of flowlines and lengths that can be
used to delineate the area that would drain to a specific point. Is this
correct?

  To determine the area flooded if an outlet is plugged would require the
inverse of r.drain. That module calculates the area flooded with surface
water originating from a specific point; e.g., a hole in a dike or dam. The
closest I've seen to do the opposite seems to be r.flow. The quantity of
surface water and the rate of accumulation and infiltration into the vadoz
zone are not of interest, only the area flooded is needed.

  The modules listed under the Natural Hazards application page all appear
to delineate the area flooded from a point source. Can any of these be used
backwards to delineate the area flooded if an outlet is blocked?

  I'd appreciate pointers and suggestions based on cumulative experience
here for appropriate module(s).

TIA,

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

Re: [GRASS-user] map display query and layers

[Dave Roberts]

Markus, The material at the wiki (url below) did not work for me, but it 
DID provide the clues I needed to get things to work.  I can't speak for 
other Arch linux users, but I don't have sudo configured and just su to 
root when necessary.  So, the posted script failed when I didn't have 
permission to sudo ln -s.  In addition, since I don't sudo, I don't 
quite understand the path being constructed.  $HOME for someone using 
sudo is presumably their home directory (not root), and creating 
$HOME/usr/bin seems like an odd idea to me.  so,


su
ln -s /usr/bin/python2.7 /usr/bin/python
ln -s /usr/bin/python2.7-config /usr/bin/python-config
exit

worked.  That means that from now on python2 is the default, as opposed 
to python3, but I'm fine with that.  Then, I don't have all the 
libraries required by the config command (notably liblas, maybe more), 
so the config command needed to be edited for me, and there were several 
libraries I didn't include in addition to freetype.  Others may have 
different needs and experiences.


Again, I didn't sudo, but

make
su
make install
exit

worked of course.  Finally, I now have /usr/bin/grass70 as GRASS-7.0.4
and /usr/local/bin/grass70 as GRASS-7.0.5.  /usr/bin precedes 
/us/local/bin so I am at present entering /usr/local/bin/grass70 to 
start GRASS-7.0.5.  I think


mv /usr/bih/grass70 /usr/bin/grass704
mv /usr/local/bin/grass70 /usr/bin/grass705

might be my solution to have both available.

Thanks, Dave

P.S. the subject on this rthread should probably have been switched to 
Arch linux GRASS build, but I left it alone to allow tracking


On 10/03/16 15:18, Markus Neteler wrote:

On Mon, Oct 3, 2016 at 7:12 PM, Dave Roberts  wrote:

Hi Markus,

Given your kind offer I elected to try and compile GRASS again. This
time I was successful (after a few false starts).  The primary problem was
python confusion, where arch linux assumes python3 as the default, and I had
not done the symbolic links  correctly to redicrect to python2.  After that

./configure \
   --without-freetype \
   --with-postgress \
   --with-readline

worked successfully.  I'm now testing GRASS-7.0.5.


Glad you solved it! Please verify if all here is ok:

https://grasswiki.osgeo.org/wiki/Compile_and_Install#Arch_Linux

Best,
Markus



--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] map display query and layers

[Maciej Sieczka]

W dniu 03.10.2016 o 23:18, Markus Neteler pisze:

On Mon, Oct 3, 2016 at 7:12 PM, Dave Roberts  wrote:

Hi Markus,

Given your kind offer I elected to try and compile GRASS again. This
time I was successful (after a few false starts).  The primary problem was
python confusion, where arch linux assumes python3 as the default, and I had
not done the symbolic links  correctly to redicrect to python2.  After that

./configure \
   --without-freetype \
   --with-postgress \
   --with-readline

worked successfully.  I'm now testing GRASS-7.0.5.


Hi Dave,

My PKGBUILD may help:
https://gitlab.com/tutturu/grass7_pkgbuild/blob/master/PKGBUILD.
Advertised on https://grass.osgeo.org/download/software/linux/.

Maciek

--
Maciej Sieczka
http://www.sieczka.org

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

Re: [GRASS-user] map display query and layers

[Markus Neteler]

On Mon, Oct 3, 2016 at 7:12 PM, Dave Roberts  wrote:
> Hi Markus,
>
> Given your kind offer I elected to try and compile GRASS again. This
> time I was successful (after a few false starts).  The primary problem was
> python confusion, where arch linux assumes python3 as the default, and I had
> not done the symbolic links  correctly to redicrect to python2.  After that
>
> ./configure \
>--without-freetype \
>--with-postgress \
>--with-readline
>
> worked successfully.  I'm now testing GRASS-7.0.5.

Glad you solved it! Please verify if all here is ok:

https://grasswiki.osgeo.org/wiki/Compile_and_Install#Arch_Linux

Best,
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Helmut Kudrnovsky]

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=1 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
  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.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Helmut Kudrnovsky]

>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.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Rich Shepard]

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

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

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

[Markus Neteler]

Rich,

On Mon, Oct 3, 2016 at 5:57 PM, Rich Shepard  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
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Rich Shepard]

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 ...
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  (may take some time)...
Reading raster map ...
 100%
Reading raster map ...
 100%
Finding nodes...
Calculate downstream parameters...
 100%
Writing raster map ...
 100%
All in RAM calculation - method ...
Reading raster map ...
 100%
Reading raster map ...
 100%
Finding nodes...
Calculate upstream parameters...
 100%
Writing raster map ...
 100%
 100%
Invalid map 
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
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Rich Shepard]

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


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

Re: [GRASS-user] 'Maximum vector line maps loaded'

[Vaclav Petras]

On Mon, Oct 3, 2016 at 8:23 AM, Alec Ventura 
wrote:

> I can provide my workdata for anyone one grass develop team for v.path
> validation, you just have to ask =)



Please, send the data to me together with what are the expected results
(like number of points, z min, z max).
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Rich Shepard]

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

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

Re: [GRASS-user] 'Maximum vector line maps loaded'

[Alec Ventura]

So, here are my experiences with v.path thought the weekend:

I have installed grass 7.3 and used v.path with Z flag. I have notice that 
almost all of my boreholes (I am working with 3d boreholes) was correctly 
placed, but a few (around 10 of 110) wasn't. First I think about wrong field 
data.

But then I tried to merge then in another way:

I have generated 1 shape file for each borehole using v.out.ogr and merge then 
using Qgis. It worked beautifuly. So I am writing this because it may have an 
error on v.path or maybe an error on my thinking line. Either way I present a 
workaround for anyone there that may interest.

I can provide my workdata for anyone one grass develop team for v.path 
validation, you just have to ask =)

best regards for you all,

Alec Ventura.



De: grass-user  em nome de Rich Shepard 

Enviado: sexta-feira, 30 de setembro de 2016 09:59
Para: grass-user@lists.osgeo.org
Assunto: Re: [GRASS-user] 'Maximum vector line maps loaded'

On Fri, 30 Sep 2016, Alec Ventura wrote:

> Yeah, I notice that changes on v.patch, but I kind aprehensive to download
> 7.2 version because the download link was with a line through it, like it
> was deprecated or something =P.
>
> I will try 7.3 that is in development.

Alec,

   I have no problems running 7.0. 7.2, or 7.3 checked out from the
subversion repositories. They download, build, and run just fine.

   Use 7.3.svn unless something doesn't work, then repeat with 7.2.svn.

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
grass-user Info Page - 
lists.osgeo.org
lists.osgeo.org
GRASS GIS user list: The principal user mailing list, for discussion about 
problems and solutions using GRASS. Note: The maximum length of a message body 
is 350kb.


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

Re: [GRASS-user] Update categories/attribute table after v.clean with option break

[Markus Neteler]

Hi,

I have attempted to make it a FAQ page:

https://grasswiki.osgeo.org/wiki/Vector_break_line_intersections

Please feel free to edit and improve this Wiki page.

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

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

[Markus Neteler]

On Mon, Oct 3, 2016 at 10:07 AM, Laurent C.  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
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Laurent C.]

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"  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.80940854S: 174426.61003591   Res: 1.00019858
>E: 2296197.40538338W: 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
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[Helmut Kudrnovsky]

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.80940854S: 174426.61003591   Res: 1.00019858
> E: 2296197.40538338W: 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.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] map display query and layers

[Helmut Kudrnovsky]

Moritz Lennert wrote
> On 02/10/16 10:53, Helmut Kudrnovsky wrote:
>> it seems that d.what.vect [1] reports always all data of all layers.
>>
>> the same with v.what although the queried layer is specified.
>>
>> so maybe a bug/enhancement ticket is needed.
>>
> 
> https://trac.osgeo.org/grass/ticket/3172
> 
> I've attached a patch to v.what. Please test if this solves your problem.
> 
> Moritz
> 
> ___
> grass-user mailing list

> grass-user@.osgeo

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

tested r69647

nice addition.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5288990.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