[GRASS-user] v.net vector orientation when creating a stream network with gauges

Sat Apr 9 03:32:23 PDT 2016

Hi Markus,
I was able to get back to this issue and tried what you had suggested with creating the new layer 3 and re-categorizing the stream after v.net op=connect ... but to no avail. I even tried setting the forward and backward costs of the little vectors added by v.net to a positive value (1) and that only worked if there were no nodes in the network between the points... 
Some of the issues are that v.net.allpairs requires the points and arcs all be on the same layer (which I tried) but that didn't work.
I tried v.net.distance and there is no way to tell it to use the layer 3 instead of layer 1 for the stream network ...
The only thing that sort of worked was v.net.path but only if there were no stream branches between the pair of points. The downstream cost worked for point pairs without branches between them fine and reversing the order did not yield a "cost" which is also correct as the upstream cost is -1... but again, this only works if there are no branches in between. 
Thinking the points in the original stream vector (layer 2 it seems) might be causing the problem (r.stream.extract creates points and lines for the stream), I used v.extract and took only the lines from the original stream vector and tried recreating the network from that. Same problem - the distances can't be calculated. The error I kept getting using v.net.path was: "point with category 22501 is unreachable from point with category 22416" (point categories varied with what pairs I used for the test)

I've created an mapset containing the stream vector and the raster it was derived from and also have the shell script I'm programming all this in, and an ascii file of point locations all in a zip file if you would like to try and see it yourself... I've been using GRASS 6.4.4 with the MSYS window (on a Windows7 64-bit PC) and cut/paste the commands into the window to run this step-by-step.  Would you like me to send you the data? (please!) The shell script has all the commands I tried and a lot of notes on what I've come across and had to work around.

Thanks for caring!
:)
Chris

Chris Bartolomei P.E.
Engineer/Scientist
ENSCO, Inc.
bartolomei.chris at ensco.com
________________________________________
From: Markus Metz [markus.metz.giswork at gmail.com]
Sent: Tuesday, March 22, 2016 1:41 PM
To: Bartolomei.Chris
Cc: grass-user
Subject: Re: [GRASS-user] v.net vector orientation when creating a stream network with gauges

On Tue, Mar 22, 2016 at 8:33 PM, Bartolomei.Chris
<Bartolomei.Chris at ensco.com> wrote:
> Hi Markus,
> Thank you for the feedback.  I had indeed used r.stream.extract after I sent the original post and yes, it does set the direction wonderfully.  I had (have) problems when adding the stream gauge point map into the network (v.net op=connect) ... the small vectors added had one direction (from the point to the stream) so traveling between points would always have an "upstream" leg ... if you use a cost of -1 for upstream travel (or the reverse) you will never get a route between points.  In an effort to get around this, Micha was kind enough to suggest using v.distance (upload=to_x,to_y) to create new points on the line vector and via export to ASCII file and re-import then add these new points to the network (v.net op=connect). The v.net worked but I am still having problems calculating the cost between points - I suspect there is a minuscule line vector between the point and stream line that has direction to it similar to the previous attempt. I ran out of time on the project and had to revert back to a simplistic non-directional network and using r.watershed - r.thin - r.to.vect and the v.net with original point locations then v.net.allpairs. I'll have to figure out how to go through the results in a script to get just the distances between gauges in the same stream flow.
> Any ideas on how to get bi-direction on the connector vectors generated in v.net (op=connect)  would be great.  Wait! Hey, now that I think about it, those connectors are very small... If I set the upstream and downstream cost of vectors under the threshold limit used in v.net to the same (non '-1') cost then the route should be able to be calculated... what do you think?

You need to snap gauges to the river network with v.net -s option=connect.

This can break any stream segment into two new parts, both will have
the same category like the original stream segment. But you need
unique categories, created with:

v.category option=add layer=3 type=line in=??? out=???

Now add an attribute table to layer 3
v.db.addtable layer=3 columns="ft_cost double,tf_cost double" map=???

upload lengths to attribute table
v.to.db layer=3 type=line option=length columns=ft_cost map=???

close backwards direction
v.db.update column=tf_cost value=-1 map=???

Now you can use v.net.allpairs or any other v.net.* module that
considers different forward and backward costs.

Markus M

> :)
> Chris
>
> Chris Bartolomei P.E.
> Engineer/Scientist
> ENSCO, Inc.
> bartolomei.chris at ensco.com
> ________________________________________
> From: Markus Metz [markus.metz.giswork at gmail.com]
> Sent: Tuesday, March 22, 2016 12:03 PM
> To: Bartolomei.Chris
> Cc: grass-user
> Subject: Re: [GRASS-user] v.net vector orientation when creating a stream network with gauges
>
> On Wed, Mar 9, 2016 at 8:28 PM, Bartolomei.Chris
> <Bartolomei.Chris at ensco.com> wrote:
>> Good afternoon,
>> I was hoping someone could provide some insight as to how v.net works.  I have a set of (438) watershed boundaries and their DEMs from which I have created the stream vectors from the DEM rasters (r.watershed, r.thin, r.to.vect, v.clean, etc.)
>
> If you use r.stream.extract instead of r.watershed + r.thin +
> r.to.vect + v.clean + etc, you get line directions pointing downstream
> without any further processing/editing.
>
> Please note that r.stream.extract also writes points at stream
> sources, confluences, and outlets. If you are only interested in
> vector stream segments, you can extract them with
>
> v.extract type=line layer=1
>
> HTH,
>
> Markus M
>
>> I also have the set of USGS stream gauges as points from which I extract the gauges within each watershed as a separate map. I am able to use v.net op=connect to create a network with the stream vectors and watershed gauge points no problem and v.path successfully creates paths from one gauge to the next IF the forward and backward costs are the same (cost is length).
>> What I am trying to do is measure the distance between a pair of gauges that are in the same flow path. I am automating this so there is no user input as to which pair to select, therefore I would like to use v.net.allpairs and then analyze the resulting table and select only those which have a route.
>> If I set the fwd cost to length and the backwards cost to -1 to shut off going upstream after traversing downstream, then the paths fail – which in many cases is good, but the paths between gauges that are clearly up/downstream from each other (along the same flow path) fail as well. If I reverse the forward and backward cost columns the path calculations still fail.
>> My thoughts are that the stream vectors do not have the correct forward and/or backward orientation (they are probably mixed) in the network. Is there a way to see or set the orientation of the stream vectors? Does anyone have experience with this?
>> When I created the stream vectors, I didn’t include the 3D data, if it were included in the stream vector would the forward/backward orientation then go from higher elevation to lower?
>>
>> I’ve looked at (https://urldefense.proofpoint.com/v2/url?u=https-3A__grasswiki.osgeo.org_wiki_Vector-5Fextract-5Fupstream-5Fnetwork&d=CwIFaQ&c=DsZY2bea7iNIzyp-7sZ0t0F2UfNQZUfZhEPCv_2wBI0&r=O31ltou6ygJL2Y01kQyNJJD2kiILIsbyz2V0Hn4lFUY&m=1-Bq36PO0aj3hbwFOZByHU2xrelvj7pZujqnHEw3z2k&s=OC4w9JIGf5ncldjugNKCNhNN_TqudY11r4e7xIPJric&e= ) and I seem to lose a lot of (stream) lines when the network is created this way which I feel may be related to the vector orientations as well.
>>
>> Any assistance would be greatly appreciated!
>> 
>> Chris
>>
>>
>>
>> Chris Bartolomei P.E.
>> Engineer/Scientist
>> ENSCO, Inc.
>
>> bartolomei.chris at ensco.com
>>
>> The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited.
>>
>> The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws.
>> _______________________________________________
>> grass-user mailing list
>> grass-user at lists.osgeo.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org_mailman_listinfo_grass-2Duser&d=CwIFaQ&c=DsZY2bea7iNIzyp-7sZ0t0F2UfNQZUfZhEPCv_2wBI0&r=O31ltou6ygJL2Y01kQyNJJD2kiILIsbyz2V0Hn4lFUY&m=1-Bq36PO0aj3hbwFOZByHU2xrelvj7pZujqnHEw3z2k&s=lhNCR5GWM3EnE50dLwXnNW5e_WC39gDvYQZx6h-5Xgc&e=