Thanks everybody!<br><br>It turns out my road network *was* faulty in the first place - the point features were well placed, but the roads were interrupted by bad intersections, as shown by v.digit (which btw, seems to be using much more memory in the latest cvs snapshot than in debian unstable version 

6.2 - ~700MB where previously it didn&#39;t even have to swap) I fixed this using v.clean&#39;s snap on just the road network which  apparently hadn&#39;t worked previously because I&#39;d forgotten to specify a threshold, and the default wasn&#39;t sufficient. Snapping the lines meant that some of the previously ok features were now off the line, which is where the connect came in.

The <a href="http://v.net">v.net</a> connect tool in the latest CVS snapshot worked like a charm (though the provided cvs debian package was too old - you weren&#39;t kidding that it was a new feature :-P), and the worked example was a perfect guide too.

I then went back and tried to follow the rest of the connecting instructions in the tutorial (p89), but it didn&#39;t quite work as well as the new tool. Looks like I started using GRASS at just the right time for my problems... I still managed to get a few shortest paths working where previously I was getting nothing - the main problem definitely was with the dataset.

<br><br>Thanks for the links to other datasets. In this particular case though, I wanted to clean up the one I had, because it&#39;s a university-provided dataset of the local region. They may come in handy later though :-)

<br><br><br>Thanks again!<br><br>Joseph<br><br><br><br><div><span class="gmail_quote">On 8/3/07, <b class="gmail_sendername">Joseph Guillaume</b> &lt;<a href="mailto:josephguillaume@gmail.com">josephguillaume@gmail.com</a>

&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,

<br>

<br>I&#39;m trying to run a travelling salesman analysis between point features 

on a road map, but it tells me that two nodes are unreachable from one 

another, which is a fatal error.

<br>

<br>I&#39;ve successfully done this exact analysis using ARC/View, but I&#39;m trying to find an 

OSS alternative that works on Debian - and it seems GRASS is the only 

software currently able to do network analyses.

<br>

<br>I patched together two ESRI shapefile datasets, following the Grass 6.0 

v1.2 tutorial.

<br>I tried linking the attributes to the original datasets and tried 

without linking.

I tried putting the new points on both the same layer and a new layer.

<br>I tried running every single v.clean function on both the original and 

patched datasets.

I am certain that all the points are actually on the network.

<br>I&#39;ve searched all mailing lists, reference materials, and bugtracker, 

but didn&#39;t find anything explicitly related to unreachable nodes.

<br>

<br>Assuming the error message does mean that the map I am using has 

segments disconnected from the rest of the network, the questions are:

<br>

* How do I detect them and remove them?

<br>The node numbers given don&#39;t match the cat attribute, so I assumed they 

referred to the id attribute. The two nodes referred to by id are 

however connected to each other (directly) and to the main part of the 

network. I suspect the node numbers therefore don&#39;t correspond to any 

attribute as such, but are rather internal. In that case, how do I 

identify the actual nodes/segments responsible?

<br>

* Shouldn&#39;t the algorithm be tolerant of such errors anyway?

<br>I checked, and none of the relevant nodes are actually within segments I 

can see are disconnected, so the analysis results should be the same if 

the algorithm ignored the error... Is this perhaps because of the 

heuristics used to solve this NP-hard problem? Does anyone know what 

ArcView does differently?

<br>

<br>

<br>

Any ideas?

<br>

<br>Cheers,

<br><span class="sg">

<br>Joseph Guillaume

<br>

</span></blockquote></div><br>