I am dealing with 3 very basic datasets. One is a road network where the only attribute available is length; given automatically when the Network Dataset is built. The second is an address database with XY coordinates (which I used to create a point shape file). The third is a shape file with one point to be used as a destination. I basically want to find the shortest paths between my address points and my destination but when I solve the OD Cost Matrix all I get are straight lines, which leads me to believe that the points and lines aren't talking to each other.

I have no hierarchy in my dataset but would like to include one (obviously to make the paths more efficient). I cannot find a way to add one as a column in the dataset. Is this even possible? My road network is not an american block system so it is far more complicated, so a hierarchy is basically essential to my analysis.

Any help on any matter I have mentioned would be greatly appreciated!

I have no hierarchy in my dataset but would like to include one (obviously to make the paths more efficient). I cannot find a way to add one as a column in the dataset. Is this even possible? My road network is not an american block system so it is far more complicated, so a hierarchy is basically essential to my analysis.

Any help on any matter I have mentioned would be greatly appreciated!

I am not sure what you mean by this. The OD solver will always produce straight lines. The lines are merely meant to indicate that a shortest path was found between the origin and destination pair connected by the line. You can look in the Lines attribute table to see the resulting shortest path cost (based on network distance and not straight-line distance) for each specific line's origin/destination pair.

If you wish to see the actual shortest path between each origin/destination pair, and not just the shortest path cost, then you can use the Closest Facility solver instead. Just load your origins as Incidents and your destinations as Facilities (make sure you specify 'Travel From: Incident to Facility' on your analysis settings for the Closest Facility layer; this can be done from the layer's property pages). You must also specify the number of Facilities to find for each Incident (the default is 1). However, since you will have only one Facility (i.e., destination) in your case, then the default should be okay. I am just letting you know in case you decide to add more Facilities later on.

As for your question about hierarchies, how many edges and junctions are in your dataset? If the dataset is small enough, you probably won't need hierarchies. Let me know, and we can proceed from there.

"I am not sure what you mean by this. The OD solver will always produce straight lines. The lines are merely meant to indicate that a shortest path was found between the origin and destination pair connected by the line."

I'm sorry, that was basically me not realizing that the costs were given in the attributes table. It was indeed the closest facility solver that I needed so thank you for clarifying that for me!

Now that I can see the shortest paths another problem has arisen; due to the fact that my road data is quite primitive, the shortest paths are often impossible. I.e. they take a left turn onto a bridge that is actually overhead. I know that I will need to include turning policies to prevent this but I am unsure how to do it. Do I add two fields to the attributes table of junctions for left and right turns with binary values for the permissions?

They also take residential roads with low speed limits, etc, which I realise has to do with a hierarchy. There are around 45,000 edges and around 41,000 junctions (it is the entire road network of a city) so I think I will definitely need a hierarchy. I realise that I have a lot of very monotonous work ahead of me!

If you wish to establish better connectivity for such overpass/underpass scenarios in your network dataset, you can use elevation fields instead of turn restrictions. Elevation fields are discussed in the online Desktop Help here: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//004700000009000000.htm

As for hierarchies, your network seems relatively small, so I do not know if you will truly need hierarchies for your purposes. Hierarchies are primarily used to speed up shortest path calculations on very large network datasets (e.g., the US road network with 50+ million edges). They are not intended to provide more "accurate" paths. In fact, using hierarchies can result in suboptimal paths, since they are based on a heuristic algorithm. In contrast, without using hierarchies, you are guaranteed to find the optimal path (although it may take longer to solve for very large networks).

Since your network dataset is so small, I would suggest assessing your current shortest path runtimes and solution quality first before worrying about trying to establish hierarchies. If you are doing exact shortest paths (i.e., no hierarchies) and your path is taking residential roads, it is because this is the true shortest path, based on the data you have provided. If you feel that this is incorrect, then you will need to somehow adjust the costs of your network to better reflect the paths you think the solver should find. The output paths will only be as good as the input data you provide.

Please let me know if you have any further questions.

I understand what you mean about the hierarchies. I think once I sort out the elevations there shouldn't be a problem. Just out of interest, is the algorithm used by ArcMap Dijkstra's algorithm?

Please see the Network Analyst tutorial. It walks through the creation of a network dataset which uses elevation fields. I showed you the earlier link mostly to give you a discussion of what the elevation fields are used for, since this is not really fully discussed in the tutorial. Now that you understand their purpose, perhaps the tutorials will be sufficient.

Yes, the elevation fields must store integer values. Since your data is exact height, it is probably some floating point representation, which is not allowed. You do not need exact heights. You really only need logical elevations (e.g., 0, 1, 2, etc.) to indicate that junctions at the same logical level connect.

It is a variant of Dijkstra's algorithm. Please see the following link for more details:

http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/Algorithms_used_by_Network_Analyst/004700000053000000/

I'm also not sure what the difference is between the "Any Vertex" and "End Point" connectivity policies.

I'm sorry but I have no idea where my discs are and I don't have the tutorials on my computer.

As for connectivity polices, please see the link I provided in my second response to this thread. This discusses connectivity concepts of the network dataset, including the "Any Vertex" and "Endpoint" policies.

Here is the an example of the error output message for one of my origins:

- Warning: No "Destinations" found for "COPACOL" in "Origins".

Cheers

There are other possible reasons, but these are generally the most likely cases, so let's start there first.

Where is your network dataset data coming from? I would first suggest turning off all of your restriction attributes and trying to re-solve the analysis to see if restrictions could be part of the problem. If this doesn't help, then it is likely a topology problem in your network data. Let me know, and we can proceed from there.