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; } } }

Creating Network Dataset for OD matrix

Seyed_AhadBeykaei

Hi,

I'm goint to find the nearest points from a shape file (nearest destination) to another shape file (points as buildings center) through the network analyst.
I tried several times to create the network dataset that all street be twoways without any other restriction.
But the problem is when I built the network from the street shape file or geodatabase, all streets treat as oneway. I went through the ESRI help manual in different way.
I could not figure out what is the problem .

If anyone can help me I really appreciate.

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

Seyed_AhadBeykaei

much appreciate.
This helped me alot.

MichaelRice

All edge directions are referenced relative to the digitized direction of the associated source feature. Therefore, you must be aware of this direction to properly set up direction-specific attributes in your network dataset.

When you specify an attribute value for your edges in your network dataset definition, you must specify an evaluator for both possible edge directions (i.e., one for "along-digitized" and one for "against-digitized"). To see this, create a new "Oneway" restriction attribute in your network dataset. From the Attributes tab on the property pages, click on the Evaluators button. In the resulting dialog, you will see two direction references for each of your polyline source feature classes: (1) From-To (this means "along" the digitized direction) and (2) To-From (this means "against" the digitized direction). Each one allows you to specify a unique evaluator for that specific direction.

The most common way to support oneway restrictions in your network dataset is to have two fields in your polyline source feature class(es). One that specifies whether the feature is restricted in the from-to/along direction and one that specifies whether it is restricted in the to-from/against direction. Once you have established the proper values for these fields, you can setup an evaluator for each direction of your polyline source feature class(es) that reads from the respective field in that direction. Please see the tutorial datasets for good examples of oneway restriction attributes and how these are normally setup.

Seyed_AhadBeykaei

Thanks for your comprehensive information.
I understand completely and you save my time. Thanks again.

I actually have another question. If I want to have directions in the network, which kind of coding I should have in the attribute table of shape file to link it to network dataset attribute.

For example, if we have a street that digitized from point A to B in the shape file. How we can code it in the attribute table that it is oneway from A to B or oneway from B to A useful in network dataset.
In general, do all the digitized polyline for oneway direction streets in the shape file should obey along-digitized direction, in other words, we should know their along-digitized direction?

Thanks

MichaelRice

I found oneway from Network Identify tool. When I click on every road, it highlights the road with an arrow which seems should be the directions.

The arrows drawn on the edges by the Network Identify tool do not represent oneway constraints. These arrows merely indicate the digitized direction of the edge's underlying source feature. More specifically, each edge in the network dataset is derived from a polyline source feature. Each polyline feature has a single digitized direction. For example, if you had drawn a polyline going from some point A to some other point B, then the network dataset would create a bidirected edge from A to B from this source feature. To determine the direction of traversal along this feature (since we could potentially travel in either direction along this edge), each edge direction is associated with the digitized direction of the feature. The direction (A,B) in this example would represent the "along-digitized" direction, whereas the opposite direction (B,A) would represent the "against-digitized" direction. The Network Identify arrows merely indicate the along-digitized direction, but this does not mean that the edge can only be traversed in this direction.

This also explains why you saw the following:

I found When I draw a line started from one point and ended from another ponit, the network dataset building obay this topological way as the direction of the street.

Again, however, note that the arrows you are seeing are not related to any directional constraints, they merely reference the source feature's digitized direction (i.e., you can still traverse the edges in both directions, assuming you have no restriction attributes turned on).

Write now there is not any warning, because during drawing new lines, I was care of the directions

This is because your latest edits properly established the connectivity you were missing in your previous state, not because you drew the features in a different direction. I just want to make sure you understand this distinction, because directional constraints in the analysis can only be enforced via restriction attributes.

Please let me know if there are any related questions.

Seyed_AhadBeykaei

Thanks for the fast replying.

I actually turned off all the restriction layers and also delete restrictions created automatically by the ArcGIS in attributes.
But when I create the network dataset, it seems all the roads are oneway.
I found oneway from Network Identify tool. When I click on every road, it highlights the road with an arrow which seems should be the directions.

I checked the connectivity issues. Some lines has problem that did not have connection by vertices that I corrected them. I deleted those lines and draw again manually. I found When I draw a line started from one point and ended from another ponit, the network dataset building obay this topological way as the direction of the street.

Write now there is not any warning, because during drawing new lines, I was care of the directions.

But I solve the network again with all the roads oneway.

Many Thanks.

MichaelRice

If you have turned off your restrictions on your analysis layer, then the street cannot still have a oneway limitation. This is because oneway constraints are only enforced via restrictions. So if you have turned them all off, the solver will treat every edge as bidirected and would find a path if one exists. Therefore, the problem would appear to be something completely different.

This sounds like it might actually be a connectivity issue. Please use the Network Identify tool to select the problematic network edges and then see which other edges/junctions are adjacent to these edges. You should be able to follow the adjacent elements using this tool to see if there is actually a connected path between your points of interest (note that this tool does not apply restrictions to determine adjacencies).

If you cannot find a connected path between them, then this is indeed a connectivity issue. If that is the case, then you should investigate your connectivity policy in the network dataset properties and also check to make sure that any features you expect to connect to each other actually share a common vertex at the intended connection point (it does not suffice for features merely to touch or cross; they must explicitly share a common vertex at their meeting point in order to establish connection).

Let me know what you find, and we can proceed from there.

Seyed_AhadBeykaei

Thanks for your information.

I actually did all the cases you mentioned, but it is still oneway for all my roads.
So, for example when I am going to find the nearest points from a layer to another point layer, some point has warning that can not find the route. Because the corresponding street for accessing the nearest points is oneway in reverse direction.

If it is possible you can see my data and why it is like that, I will send my data to you. More than week I am struggling with that and cannot find the problem.

Many Thanks.

MichaelRice

Streets will only be treated as oneway in your network dataset if you have created a restriction attribute which constrains them to be oneway. Please look at your analysis layer's property pages and see which restriction attributes you have turned on. Then, simply turn off any oneway restrictions or other restrictions which you did not explicitly mean to use.

Note that, when you are building your network dataset, the build process may automatically recognize certain fields in your source feature classes (e.g., a field named "Oneway") and create attributes based on these fields. This is only done for common attributes used in transportation analysis (such as oneway restrictions), and it may explain how you ended up with such restrictions in the first place. However, you can always simply remove them during the build process, if you like.

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

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