nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OD Cost Matrix: Using separate road line and address point datasets

CathalDundon

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!

Find more posts tagged with

Accepted answers

All comments

MichaelRice

This issue can be due to several possible reasons:

Your origins (and/or destinations) are located on restricted elements. At the ArcGIS 10 release, we have provided functionality to avoid locating your points on restricted elements.
There is no valid path in your network dataset from some (or all) of your origins to some (or all) of your destinations. This can be due to disconnected parts of your network from using restriction attributes or from having bad topology in the network dataset.

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.

BruceBell

Hello I hope you may still be looking at this thread, but I am trying to do an even simpler analysis involving OD Cost Matrix over a road network. I have set the impedence parameters etc but the solver refuses to produce any results. I am sure that destinations and origins lie on the network (edited with snapping). Any ideas?

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

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

Cheers

CathalDundon

The straight lines mean that a path was found between those 2 points. They are not straight line distances. The actual distance is in the attribute table of the routes. If you want to see the routes taken on the map run a 'make closest facility layer' and specify the number of facilities as 40; otherwise it will only find the closest to each point.

luis_carlosmanrique_ruiz

hello: I'm new user in ArcGis, I have been working with another kind of softwares so I don't know so much about Arcgis and I have a question: I want to get an origin destination matrix using multiple records as origins (40) as destinations(2000), however using the network tool with Arcgis I get a matrix 40 * 2000 of course, but some lines are displayed on the map, I want to get the traveling road, so after getting the matrix I compare with another softwares and it seems not correct, is it correct?, the straight lines are not the straight distance, isn't?. Thank you very much, and I appreciate the comments.

MichaelRice

A line feature in ArcGIS is represented by a series of explicit point coordinates (known as vertices), in a specific order. This first vertex in this order defines the "from" end of the line, while the last vertex defines the "to" end of the line. To define elevation fields, you must specify a field value for each end of the line, respectively. Therefore, you need two fields: one to represent the elevation of the "from" end and one to represent the elevation of the "to" end. You can visualize this direction in ArcMap by specifying a symbology for your lines which has arrows that follow this "digitized direction".

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.

CathalDundon

I am still having issues with the elevation field. Routes are still taking inappropriate roads. I must be incorporating them in the wrong way. I don't understand the "From End" and "To End" fields. Do I need 2 fields for each line? I.e. what the elevation is at each end?
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.

MichaelRice

The article you suggested doesn't explain how to implement the elevation field.

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.

Is there a format the data must be in?

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.

...is the algorithm used by ArcMap Dijkstra's algorithm?

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/

CathalDundon

The article you suggested doesn't explain how to implement the elevation field. I have an elevation field in my data but when I am making a new network dataset it does not give it as an option in the drop down box for choosing an elevation field. Is there a format the data must be in? I have exact heights; should I change these to simple binary values since all I am interested in is avoiding turns?

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?

MichaelRice

...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.

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.

CathalDundon

Thank you for replying so quickly.
"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!

MichaelRice

...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 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.

CathalDundon

Just as an addition; I don't know if it's relevant but I have no problem finding service areas for each of my points, so there is clearly some interaction between the lines and points, which adds to my confusion.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.