<div dir="ltr"><div><div><br><br>On Fri, Jun 9, 2017 at 3:36 PM, Mira Kattwinkel <<a href="mailto:kattwinkel-mira@uni-landau.de">kattwinkel-mira@uni-landau.de</a>> wrote:<br>><br>> Dear list members,<br>><br>> has nobody any idea what's going on (see below)?<br>><br>> When using forward and backward costs or only backward costs in v.net.iso the backward end (i.e. upstream) always gets too short / too few segments.<br><br></div>I have an idea what could cause these differences, but I need some time for testing. More soon.<br><br></div>Markus M<br><div><div><br>><br>> Can anybody please point me into the right direction.<br>><br>> All the best, Mira<br>><br>><br>> Subject:      wrong result in v.net.iso for backward direction<br>> Date:    Thu, 8 Jun 2017 10:46:42 +0200<br>> From:      Mira Kattwinkel <<a href="mailto:kattwinkel-mira@uni-landau.de">kattwinkel-mira@uni-landau.de</a>><br>> To:        grass-user <<a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>><br>><br>> Dear list members<br>><br>> I am using v.net.iso to split a stream network at a certain distance<br>> from sampling points.<br>><br>> First, I create a network from vector lines (streams) and vector points<br>> (sampling sites) using <a href="http://v.net">v.net</a>. The lines feature have a 'cat' column,<br>> 'length', 'backward_cost' and 'forward_cost'. I would use -1 for forward<br>> costs because I am only interested in the upstream part, and length for<br>> backward costs in v.net.iso:<br>><br>> v.net.iso input=test_edges arc_layer=2 node_layer=3<br>> output=test_edges_bw_2000  center_cats=55  arc_column=forw_cost<br>> arc_backward_column=backw_cost costs=2000<br>><br>> However, the backward part of the resulting lines with cat 1 is always<br>> too short. Likewise, if I give just 1 for the backward costs and set the<br>> costs to 5, it gets 4 segments with cat 1. Working in both directions at<br>> the same time gives correct values for the forward end, but too short<br>> for the backward end. I then realised that the numbers would be correct<br>> if the first part of the forward end was added to the backward part (see<br>> attached example). The forward part all the costs (lengths) sum up<br>> correctly to 2000 (1443.19 + 556.81). For the backward part it would be<br>> 45.72 + 511.09 = 556.81. However, if the first segment of the forward<br>> part is added, it gives the correct cost sum (45.72 + 511.09 + 1443.19 =<br>> 2000).<br>><br>> Do I use the function in the wrong way or is this a bug?<br>><br>> Thanks a lot,<br>> Mira<br>><br>> URL: <<a href="http://lists.osgeo.org/pipermail/grass-user/attachments/20170608/97469a58/attachment.png">http://lists.osgeo.org/pipermail/grass-user/attachments/20170608/97469a58/attachment.png</a>><br>><br>> URL: <<a href="http://lists.osgeo.org/pipermail/grass-user/attachments/20170608/97469a58/attachment-0001.png">http://lists.osgeo.org/pipermail/grass-user/attachments/20170608/97469a58/attachment-0001.png</a>><br>><br>> PS<br>><br>> I just realized that it works correctly for length in both direction if <br>> the parameters arc_column and arc_backward_column are not given. <br>> However, for me this is inefficient because I only need the backward end.<br>><br>><br>><br>> _______________________________________________<br>> grass-user mailing list<br>> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br><br></div></div></div>