[GRASS-user] r.stream.basins vector outlets help (Jens Hegg)

[Jens Hegg]

Ok,  I figured out how to make it work for the vector file. I was including both the flow direction and the stream network along with the vector file. It turns out that only the direction and vector outlets files are needed and then it runs perfectly. The manual examples really should be updated to include a vector points example.

I do still have one problem that someone might be able to help with. Many of the points I use for outlets are just downstream of one another so it creates watersheds that are just small slivers between points. Is it possible for it to create overlapping watersheds as you move down the stream, or do I need to go back and do this manually?

Jens



On Feb 9, 2015, at 6:08 PM, grass-user-request at lists.osgeo.org wrote:

> Send grass-user mailing list submissions to
> 	grass-user at lists.osgeo.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.osgeo.org/mailman/listinfo/grass-user
> or, via email, send a message with subject or body 'help' to
> 	grass-user-request at lists.osgeo.org
> 
> You can reach the person managing the list at
> 	grass-user-owner at lists.osgeo.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grass-user digest..."
> 
> 
> Today's Topics:
> 
>   1. Import/Export of ESRI Arc ascii grids (Thomas Adams)
>   2. GRASS GIS 7.0.0 RC2 released (Markus Neteler)
>   3. Re: Import/Export of ESRI Arc ascii grids (Markus Neteler)
>   4. Re: Import/Export of ESRI Arc ascii grids
>      (C?sar Augusto Ram?rez Franco)
>   5. Re: v.generalize: does it take forever? (F?bio Dias)
>   6. r.stream.basins vector outlets help (Jens Hegg)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 9 Feb 2015 13:12:45 -0700
> From: Thomas Adams <tea3rd at gmail.com>
> To: "grass-user at lists.osgeo.org" <grass-user at lists.osgeo.org>
> Subject: [GRASS-user] Import/Export of ESRI Arc ascii grids
> Message-ID:
> 	<CAGxgkWjdCo1pJNT1PAfSarUCfm5foaudLiLXcLGZC2UteNV39g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> All,
> 
> I'm probably missing the obvious, but has support for import/export of ESRI
> Arc ascii grids been dropped in GRASS 7.x? I can not find r.in.arc and
> r.out.arc in either the documentation or in GRASS itself. If it has been
> dropped, why? I know I can use GRASS 6.4.x?
> 
> Tom
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20150209/38dbcb14/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 9 Feb 2015 21:18:21 +0100
> From: Markus Neteler <neteler at osgeo.org>
> To: GRASS developers list <grass-dev at lists.osgeo.org>,	GRASS user list
> 	<grass-user at lists.osgeo.org>
> Cc: OSGeo-discuss <discuss at lists.osgeo.org>,	GRASS-announce list
> 	<grass-announce at lists.osgeo.org>
> Subject: [GRASS-user] GRASS GIS 7.0.0 RC2 released
> Message-ID:
> 	<CALFmHhtmwEEXCLkLeJkjJKX6JciC1Q0dwApkDqUkvaFjaeUK7Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> We are pleased to announce the second release candidate of the
> upcoming stable GRASS GIS 7.0.0 version.
> Between 7.0.0RC1 and the current 7.0.0RC2 about 100 updates have been applied.
> 
> 
> MOST IMPORTANT CHANGES in RC2:
> 
> * Updated Welcome and splash screens
> * 3D raster: terminology cleanup (raster3D -> 3D raster) in commands and manual
> * g.proj: generate PROJ_EPSG file (contains EPSG code) when location is given
> * r.cost, r.walk: change percent_memory to memory (in MB)
> * v.extract: index added
> * v.in.ogr: do not use old projection for area calculations in new projection
> * v.generalize: self-intersection fix
> * v.patch, v.reclass, v.overlay, v.vect.stats: accommodate SQLite
> * vector lib: numerical stability fixes for centroid calculation
> * vector lib: more robust topology engine
> * some simple mononchrome color tables added
> * wxGUI/nviz: 3D rendering fixes
> * several translations updated
> 
> Related updates in QGIS:
> * Further updates in QGIS Processing - GRASS GIS 7 interface submitted to QGIS
> 
> Related updates in OSGeo-Live:
> * GRASS GIS 7.0.0 RC2 planned to be shipped with the new OSGeo-Live 8.5
> 
> See also our detailed announcement:
> http://trac.osgeo.org/grass/wiki/Release/7.0.0RC-News
> http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures
> 
> DOWNLOAD
> 
> Binaries:
> http://grass.osgeo.org/download/software/#g70rcx
> 
> Source code:
> http://grass.osgeo.org/grass70/source/grass-7.0.0RC2.tar.gz
> http://grass.osgeo.org/grass70/source/grass-7.0.0RC2.md5sum
> 
> Changelog:
> http://grass.osgeo.org/grass70/source/ChangeLog_7.0.0RC2.gz
> 
> Please test on "any" platform which is supported (GNU/Linux,
> MS-Windows, Mac OSX, *BSD, ...).
> 
> The GRASS Development Team
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 9 Feb 2015 21:26:01 +0100
> From: Markus Neteler <neteler at osgeo.org>
> To: Thomas Adams <tea3rd at gmail.com>
> Cc: "grass-user at lists.osgeo.org" <grass-user at lists.osgeo.org>
> Subject: Re: [GRASS-user] Import/Export of ESRI Arc ascii grids
> Message-ID:
> 	<CALFmHhsHKRZQ9ORmDqNEp1SWFK1VC3bWUHgyr58yfs7DKeZu=w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On Mon, Feb 9, 2015 at 9:12 PM, Thomas Adams <tea3rd at gmail.com> wrote:
>> All,
>> 
>> I'm probably missing the obvious, but has support for import/export of ESRI
>> Arc ascii grids been dropped in GRASS 7.x?
> 
> Of course not :)
> 
>> I can not find r.in.arc and
>> r.out.arc in either the documentation or in GRASS itself. If it has been
>> dropped, why?
> 
> Because r.in.gdal and r.out,gdal do the job nicely.
> 
> For an overview of changes, see
> http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Replacedandremovedmodules
> 
> Markus
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 9 Feb 2015 16:22:59 -0500
> From: C?sar Augusto Ram?rez Franco <caesarivs at gmail.com>
> To: Thomas Adams <tea3rd at gmail.com>
> Cc: "grass-user at lists.osgeo.org" <grass-user at lists.osgeo.org>
> Subject: Re: [GRASS-user] Import/Export of ESRI Arc ascii grids
> Message-ID: <25DEB00C-3AF2-4FEF-8BB3-CF50BA7F829C at gmail.com>
> Content-Type: text/plain;	charset=utf-8
> 
> I think that functionality has been merged into r.in.gdal
> 
> Have you tried it?
> 
> C?sar
> 
>> El 9/02/2015, a las 3:12 p.m., Thomas Adams <tea3rd at gmail.com> escribi?:
>> 
>> All,
>> 
>> I'm probably missing the obvious, but has support for import/export of ESRI Arc ascii grids been dropped in GRASS 7.x? I can not find r.in.arc and r.out.arc in either the documentation or in GRASS itself. If it has been dropped, why? I know I can use GRASS 6.4.x?
>> 
>> Tom
>> _______________________________________________
>> grass-user mailing list
>> grass-user at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 9 Feb 2015 19:52:41 -0200
> From: F?bio Dias <fabio.dias at gmail.com>
> To: Markus Metz <markus.metz.giswork at gmail.com>
> Cc: GRASS user list <grass-user at lists.osgeo.org>
> Subject: Re: [GRASS-user] v.generalize: does it take forever?
> Message-ID:
> 	<CAFSZSaJF4Gb9uNwiyqnX5fH=GAcK_ie=0BsHOOGcCcxEDWNFfQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> I switched to postgis for data storage and the v.generalize time went
> down to 130ish minutes, all processes working in parallel.
> 
> I'm happy now :) thanks you guys very much.
> -=--=-=-
> F?bio Augusto Salve Dias
> ICMC - USP
> http://sites.google.com/site/fabiodias/
> 
> 
> On Tue, Jan 27, 2015 at 8:50 PM, F?bio Dias <fabio.dias at gmail.com> wrote:
>> Hi,
>> 
>> I've kept an iotop, cumulative, running while the generalization run.
>> No disk IO involved, just a couple of postgre stats. I believe the OS
>> is keeping everything in RAM cache. I don't believe the disk is a
>> bottleneck either, it is a 10 disk raid of 15k rpm disks, it's really
>> fast.
>> 
>> I interrupted the processing, moved everything into postgres and
>> started over. I'm still loading the shapefiles (that I'm doing one at
>> a time), I'll start the 15 processes as soon as it is loaded. As soon
>> as that stabilizes, I'll report back.
>> 
>> 
>> On a related note, wouldn't it be interesting to always try to
>> simplify a line? As I understood the code, if the simplification fails
>> for any reason, the original line is used. Might be interesting to
>> have an option that makes the algorithm retry that line, with half the
>> threshold, for instance. It's kind of weird for me to see one side of
>> something really simplified while the other side really complicated :)
>> 
>> F
>> -=--=-=-
>> F?bio Augusto Salve Dias
>> ICMC - USP
>> http://sites.google.com/site/fabiodias/
>> 
>> 
>> On Tue, Jan 27, 2015 at 7:56 PM, Markus Metz
>> <markus.metz.giswork at gmail.com> wrote:
>>> On Mon, Jan 26, 2015 at 3:54 PM, F?bio Dias <fabio.dias at gmail.com> wrote:
>>>> Hi,
>>>> 
>>>> The machine has 128Gb of ram. Doesn't matter what I do, I can't make a
>>>> dent on it. Even with everything cached in ram (shp files, database,
>>>> the whole lot), there is still free memory.
>>> 
>>> OK, it's not RAM.
>>> 
>>>> 
>>>> I'm asking about the database because the behavior I'm seeing on 'top'
>>>> looks like the one you get when mutexes are involved. The processes
>>>> don't go all to 100% processing at same time (and the machine has 64
>>>> processors, so no dent there either), except for the v.in.ogr.
>>> 
>>> The v.generailze processes should be at 100% while generalizing,
>>> unless the disk can not keep up with multiple simultaneous IO
>>> requests. The tables are copied only after the generalization finished
>>> (100% reached).
>>> 
>>>> What it
>>>> looks like is that something is locking each process and they are
>>>> taking turns. Considering how 'lite' the sqlite appears to be, and the
>>>> weird locking behavior that was mentioned in other threads (I'm not
>>>> getting the locked message here... I did, when I was running 2
>>>> parallel v.in.ogr), isn't it likely to be the culprit? Should I change
>>>> it to a more 'non-lite' system, like postgres for instance?
>>> 
>>> That could make sense when running multiple processes in parallel. An
>>> alternative would be to create a separate mapset for each process and
>>> at the end copy the results back to the main mapset.
>>> 
>>> Technically, it is not possible that the new v.generalize version in
>>> trunk (G71) is slower than the old version as in relbr70 because the
>>> new version updates only those parts of the topology that actually get
>>> changed. The old version also updates components that do not get
>>> changed, this is quite time-consuming.
>>> 
>>> I understand you like to go for the big nail immediately, but maybe it
>>> is worth testing first on a smaller sample?
>>> 
>>> Markus M
>>> 
>>>> 
>>>> F
>>>> -=--=-=-
>>>> F?bio Augusto Salve Dias
>>>> ICMC - USP
>>>> http://sites.google.com/site/fabiodias/
>>>> 
>>>> 
>>>> On Mon, Jan 26, 2015 at 7:22 AM, Markus Metz
>>>> <markus.metz.giswork at gmail.com> wrote:
>>>>> On Mon, Jan 26, 2015 at 9:30 AM, Markus Metz
>>>>> <markus.metz.giswork at gmail.com> wrote:
>>>>>> On Sun, Jan 25, 2015 at 6:11 PM, F?bio Dias <fabio.dias at gmail.com> wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Running r64249, with a couple of stuff in parallel using &. It seems
>>>>>>> to be considerably slower.
>>>>>> 
>>>>>> Very strange. Are you using trunk or GRASS 7.0?
>>>>> 
>>>>> Here, v.generalize on a TerraClass tile is down from 25 minutes to 13 seconds.
>>>>> 
>>>>>> 
>>>>>>> More than 100h, no 1% printed. To be fair,
>>>>>>> I'm not entirely sure I'll see it when it prints, 10 v.generalize
>>>>>>> running (5 for each year) + 1 v.in.ogr for 2012. That v.in.ogr is
>>>>>>> running for almost 100h too. I'm loading the shps directly, as advised
>>>>>>> way, way back in this thread.
>>>>>> 
>>>>>> What exactly do you mean with "loading shps directly"? For
>>>>>> v.generalize, you should import them with v.in.ogr.
>>>>>> 
>>>>>> What about memory consumption on your system? With 10 v.generalize + 1
>>>>>> v.in.ogr on such a big dataset, quite a lot of memory would be used.
>>>>>> 
>>>>>> Markus M
>>>>>> 
>>>>>>> 
>>>>>>> AFAIK, no disk is been used, the whole thing is cached (after more
>>>>>>> than 24h processing, cumulative iotop shows only a few mb
>>>>>>> written/read). I'm no longer using a ramdisk for the grassdata dir.
>>>>>>> 
>>>>>>> However, it appears to be considerably slower, probably because of the
>>>>>>> parallel running jobs.
>>>>>>> 
>>>>>>> My question then would be, considering the thread I saw about sqlite,
>>>>>>> should I be using something else as backend? When it starts to make
>>>>>>> sense to change it?
>>>>>>> 
>>>>>>> F
>>>>>>> 
>>>>>>> -=--=-=-
>>>>>>> F?bio Augusto Salve Dias
>>>>>>> ICMC - USP
>>>>>>> http://sites.google.com/site/fabiodias/
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Jan 14, 2015 at 1:06 PM, Markus Neteler <neteler at osgeo.org> wrote:
>>>>>>>> On Wed, Jan 14, 2015 at 3:54 PM, F?bio Dias <fabio.dias at gmail.com> wrote:
>>>>>>>> ...
>>>>>>>>> What would be the best way to do that in parallel? One mapset for each
>>>>>>>>> year? Can I run multiple v.generalizes on the same input with
>>>>>>>>> different outputs?
>>>>>>>> 
>>>>>>>> Yes sure.
>>>>>>>> 
>>>>>>>>> My first thought was to run completely separated grass processes for
>>>>>>>>> each simplification, but I didn't find a way to make it search
>>>>>>>>> something different than .grass / .grass70 for the configuration
>>>>>>>>> stuff....
>>>>>>>> 
>>>>>>>> Maybe take a look at this approach
>>>>>>>> http://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs#Grid_Engine
>>>>>>>> 
>>>>>>>> but even sending different v.generalize jobs to background (&) should
>>>>>>>> work if you have enough RAM.
>>>>>>>> 
>>>>>>>> markusN
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 9 Feb 2015 18:08:05 -0800
> From: Jens Hegg <jensenhegg at gmail.com>
> To: grass-user at lists.osgeo.org
> Subject: [GRASS-user] r.stream.basins vector outlets help
> Message-ID: <5C00976C-7B42-4AE9-AEC4-A5BD562847BF at gmail.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> I am trying to use r.stream.basins to delineate multiple watersheds upstream of water sampling points. From the manual page it appears that you can input a vector file with multiple stream outlet points under the command points= however I can't make that work. I get the error "ERROR: Only one outlet definition is allowed". 
> 
> The manual states that the "Every point shall have his own unique category." which I assume is the case for a vector file of points but perhaps I'm missing something. I have edited the points to make sure that each point overlays the stream on the stream direction map. My stream and direction maps are both output from r.watershed. 
> 
> Can anyone tell me what I'm doing wrong here? I'm using GRASS 7.0 on Mac OSX 10.7.5. 
> 
> Thanks, 
> 
> Jens Hegg
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20150209/bd723225/attachment.html>
> 
> ------------------------------
> 
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> End of grass-user Digest, Vol 106, Issue 18
> *******************************************