<div dir="ltr"><div><div><div>Hi Mark,<br><br></div>I tried using v.clean with break, rmdup and snap. However, when I try to run v.net.components I get an error saying that<br><br>v.net.components input=rede_brk_rmdup_snap@PERMANENT node_layer=1 output=component_brk_rmdup_snap method=weak<br>Building graph...<br>Registering arcs...<br>Flattening the graph...<br>Graph was built<br>ERROR: Cannot insert new record: insert into component_brk_rmdup_snap values (3689, 1)<br><br></div><div></div>I'm using Grass v7RC1 on Windows and v.net.components work if I use only the snap tool in my roads network<br><br></div>Cheers<br>Daniel<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 7:40 PM, Mark Wynter <span dir="ltr"><<a href="mailto:mark@dimensionaledge.com" target="_blank">mark@dimensionaledge.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Daniel<br>
When you ran v.clean, did you v.clean tool=break,rmdupl ?<br>
<br>
I suspect you still may encounter a problem with road T junctions if the vectors don't cross or intersect.  Take this simple example of 2 roads - NS, and EW.  Each line has only 2 nodes - at the line’s  start and end points.<br>
|—<br>
The problem is when the horizontal line “undershoots” the vertical line.  The break command will have no effect, and snapping won’t make any difference because there is no midpoint node to which the horizontal line can attach itself to.<br>
<br>
I’d be interested to hear how others have dealt with what is essentially a “data preparation” issue in GRASS?<br>
<br>
[The solution I ended up implementing used a PostGIS SQL custom function to “break” overshoots and undershoots, with rules for correct treatment of bridges and tunnels. The function is fast, and can be run in parallel when working with continental-sized road networks.<br>
After PostGIS, I import the “broken-up” network into GRASS and use v.clean to snap the nodes, but NOT break the lines - as my PostGIS function has already dealt with this.<br>
The GRASS procedure involves running the v.clean in 5 steps, to avoid inadvertently snapping a tunnel node to say a bridge node, just because they are spatially close.<br>
1) v.clean tool=snap # no bridges, no tunnels<br>
2) v.clean tool=snap # bridges only<br>
3) v.clean tool=snap # tunnels only<br>
4) v.patch (steps 1-3)<br>
5) v.clean tool=snap # on the patched layer, with a much smaller tolerance to that used in steps 1-3 to again avoid say tunnel nodes inadvertently snapping to bridge nodes.<br>
We’re then good to go with <a href="http://v.net" target="_blank">v.net</a> analysis.]<br>
<br>
This may sound like a complicated process, but when using imperfect data to model complex road networks in dense urban areas, its important to get the vector topology as close as possible to the real world.  I’ve found this process generates a highly representative, routable vector topology from imperfect OSM data.<br>
<br>
Your situation might be much simpler, which is not to say you won’t encounter anomalies like you’ve already identified.<br>
<br>
Mark<br>
<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 15 Jan 2015 15:22:27 -0200<br>
From: Daniel Victoria <<a href="mailto:daniel.victoria@gmail.com">daniel.victoria@gmail.com</a>><br>
To: grass <<a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>><br>
Subject: [GRASS-user] Checking and fixing roads for network analysis<br>
Message-ID:<br>
        <<a href="mailto:CA%2BirsJjeKZQ9EqQ7igZcgL92k7uMfdKUJv6A-KVbtP7wn-XqYQ@mail.gmail.com">CA+irsJjeKZQ9EqQ7igZcgL92k7uMfdKUJv6A-KVbtP7wn-XqYQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi List,<br>
<br>
I'll need to perform some network analysis and right now I'm trying to see<br>
if my roads map is all good. I know that there are some clearly isolated<br>
areas on my roads network but I'd like to identify and fix the less obvious<br>
ones.<br>
<br>
Here is what I did:<br>
1) Import road lines (v.in.ogr)<br>
2) Clean the topology with snap tool, thresh=0.0001 (it's a latlong<br>
location)<br>
2) Create network (<a href="http://v.net" target="_blank">v.net</a> using the nodes option --not sure if that was the<br>
correct option)<br>
3) Ran v.net.components to find the weakly connected components, not<br>
setting any cost columns<br>
4) Color roads lines according to the component number<br>
<br>
By doing that I could spot the lines that were clearly disconnected<br>
(net_components_unlink.png).<br>
But I also found some lines that where disconnected even thou there are<br>
nodes (red squares) linking them (apparently) -<br>
net_components_pseudo_link.png<br>
<br>
Should I increase my snapping threshold?<br>
How can I see if my nodes are endnodes or located between two lines?<br>
<br>
Thanks<br>
Daniel<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/grass-user/attachments/20150115/0dd532a1/attachment.html" target="_blank">http://lists.osgeo.org/pipermail/grass-user/attachments/20150115/0dd532a1/attachment.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: net_components_unlink.png<br>
Type: image/png<br>
Size: 25250 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.osgeo.org/pipermail/grass-user/attachments/20150115/0dd532a1/attachment.png" target="_blank">http://lists.osgeo.org/pipermail/grass-user/attachments/20150115/0dd532a1/attachment.png</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: net_components_pseudo_link.png<br>
Type: image/png<br>
Size: 15279 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.osgeo.org/pipermail/grass-user/attachments/20150115/0dd532a1/attachment-0001.png" target="_blank">http://lists.osgeo.org/pipermail/grass-user/attachments/20150115/0dd532a1/attachment-0001.png</a>><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="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
<br>
End of grass-user Digest, Vol 105, Issue 25<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="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
</blockquote></div><br></div>