On Tue, Mar 22, 2016 at 8:33 PM, Bartolomei.Chris <[email protected]> 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. > [email protected] > ________________________________________ > From: Markus Metz [[email protected]] > 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 > <[email protected]> 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. > >> [email protected] >> >> 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 >> [email protected] >> 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= _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
