Network Analyst With Centroid Connectors

5219
8
Jump to solution
04-15-2016 08:32 AM
Highlighted
New Contributor III

Good morning and happy Friday,

I have a fairly straight forward routing problem that I cannot seem to solve with the various Network Analyst tools available to me. We have categorized our street network according to the level of traffic stress one experiences while biking (colored lines in the image below). The goal of this analysis is to calculate the network distance between the top trip producing census blocks (green points in the image below) and top trip attracting census blocks (red point in the image below). This would be done twice, once for all levels of traffic stress and once for only minimal levels of traffic stress so a comparison can be made.

In order to "connect" the census block centroids to the network, I created connectors (the gray lines emanating from the points) and integrated them into our network. The number of connectors was based on how many network segment midpoints fell along the border of the census block. I have weighted these connectors with 0 cost which was a decision made by our research team. The problem I am having, is that the route algorithm obviously searches for the route that costs the least (black line below) causing the route to traverse multiple centroid connectors and avoiding the network all together. I have introduced turn restrictions (see the red lines adjacent to the origin of the trip below) that restricts movement through two connectors. This appears to work, but would mean I would have to build turn lines for each pair of connectors in my network!

Does anyone know of an alternative solution to this problem? If there was a way to tell Network Analyst to never pass through a centroid or to only traverse one connector for any given route solution. I cannot think of a way to do this. Any ideas? Thank you in advance.

Russ

RouteExample.png

1 Solution

Accepted Solutions
Highlighted
New Contributor III

Thanks Melinda. You certainly got my creative juices flowing with suggestion 3. This is what I tried so far to no avail. As you suggested, I wrote a script evaluator (see below) for my cost attribute under the default tab for turns. My logic behind the syntax is that if a route is attempting to traverse from one segment that is classified as a connector to another segment that is classified as a connector, the movement is restricted. I added a descriptor attribute to my network entitled "Connector" which is coded as 1 if it is a centroid connector. After implementing this logic, the route still traverses multiple connectors and avoids the network. Any thoughts?

restricted = False

a = Turn.Angle

If a >= 0 Then

    If fromEdge.AttributeValueByName( "Connector" )= 1 And toEdge.AttributeValueByName("Connector") = 1 Then

        restricted = True

    End If

End If

Value = restricted.

View solution in original post

Reply
0 Kudos
8 Replies
Highlighted
Esri Regular Contributor

Hi Russ.  I understand the problem, and it's a tricky one. I have a couple of ideas, none of which are ideal.

Idea 1: Use Point Barriers

You could make your census block centroids into point barriers to prevent travel across your virtual lines with 0 cost.  However, the problem is dealing with your origin and destination centroids.  If they were to locate directly on top of the point barrier at the same location, then they would not be reachable at all.  If the origin or destination located on one of your virtual connector lines slightly offset from the point barrier, then it would only be able to use that single exit from the centroid to connect to the road network, so that doesn't work either.  However, you might be able to make this work if you calculate routes one at a time and simply remove the point barriers at the origin and destination location for that route and leave the others.  This could be automated, but if you're doing every block to every other block, the calculation might take a really long time compared to just running a single OD Cost Matrix analysis.

Idea 2: Don't use centroids

The cleanest solution might be to simply not use the centroids but to instead use the intersections with the surrounding streets as your origins and destinations.  By giving your centroid connectors 0 cost, you're effectively doing this anyway.  The disadvantage here is that you will have a bunch of origins and a bunch of destinations associated with each centroid, and you would end up with a bunch of routes instead of just one.  But, if you tracked the census block IDs, with a little post-processing, you could just delete all but the fastest route between unique pairs of blocks.

Idea 3: Use a Script Evaluator for default turn behavior

I haven't experimented with this idea, but you might be able to come up with a solution that works using a Script Evaluator for the default turn values on your cost attribute.  For the cost attribute you're using for your analysis, you can open up the Evaluators dialog from the network dataset properties.  On the Default Values tab, there's a place where you can set the default behavior for all turns (transitions from one edge to another).  Here, you could use a script evaluator to allow all turns except for transitions from one virtual edge to another. Learn more about script evaluators here: Types of evaluators used by a network—Help | ArcGIS for Desktop

As I said, this is a tough problem.  I hope this gives you a few ideas.  If you come up with a good solution, please post it here so others can see!

Highlighted
MVP Esteemed Contributor

My vote goes to Melindas  #2 suggestion; can't you simply adjust the distance the ntwork uses to establish whether or not a point is 'part' of the network?

Reply
0 Kudos
Highlighted
New Contributor III

Thanks Melinda. You certainly got my creative juices flowing with suggestion 3. This is what I tried so far to no avail. As you suggested, I wrote a script evaluator (see below) for my cost attribute under the default tab for turns. My logic behind the syntax is that if a route is attempting to traverse from one segment that is classified as a connector to another segment that is classified as a connector, the movement is restricted. I added a descriptor attribute to my network entitled "Connector" which is coded as 1 if it is a centroid connector. After implementing this logic, the route still traverses multiple connectors and avoids the network. Any thoughts?

restricted = False

a = Turn.Angle

If a >= 0 Then

    If fromEdge.AttributeValueByName( "Connector" )= 1 And toEdge.AttributeValueByName("Connector") = 1 Then

        restricted = True

    End If

End If

Value = restricted.

View solution in original post

Reply
0 Kudos
Highlighted
New Contributor III

This worked!!!! I just needed to switch my connector decriptor type from Boolean to integer!!! Thanks again!

Reply
0 Kudos
Highlighted
Esri Regular Contributor

Great!  I'm so glad you found a solution.  The disadvantage of script evaluators is that they increase solve time because they have be calculated at solve time (as opposed to being baked into the network so the values can just be looked up).  But if speed isn't your main concern, this should hopefully work fine for you.

Highlighted
New Contributor III

Hi Melinda,

So I have run into a problem with the Script Evaluator for default turn behavior. We are using the same connector strategy for a bike to school analysis. I have made sure that all of the connectors (black lines in the below images) are snapped to the schools. I noticed that the solution (pink line) often time does not use the connector that is closest to the origin (image one). Network analyst seems to arbitrarily assign the the location of the school, in this example, to the western connector. All of the route solutions pass through that one connector. This is not always consistent, however, with other networks I have built for testing using the same source dataset. Another network had all of the solutions passing through the eastern connector.  When I remove the Script Evaluator for default turn behavior, however, the correct solution is generated (image two). Any ideas??

DetourAnalysisWithTurnScript.jpg

          Image 1: Solution with script evaluator.

DetourAnalysisWithoutTurnScript.jpg

         Image 2: Solution without script evaluator.

Reply
0 Kudos
Highlighted
Esri Regular Contributor

I see what's happening here.  When you run a Network Analysis, your input points have to "locate" on the network, meaning they snap to the closest network edge and the snapped location is considered to be the start or end point of the analysis.

In your image 1, the origin is snapping to the western connector.  Since you have a script evaluator preventing turns from one connector to another, it can't travel from its start location at the end of the western connector to the eastern connector the way you want, so it's forced to used the western connector.  In image 2, it happily travels from the western connector to the eastern connector because there's nothing to prevent it.

This problem can be worked around.  You can tell your stops (origins and destinations) not to "locate" on edges but to instead locate on junctions.  If it's located on the junction between the connector lines, I think it should be able to travel down any of them.

To set this up, open your NA layer properties, and go to the Network Locations tab.  You should see a box that looks something like the image below.  Uncheck the boxes for your streets or connectors, and check on the Shape box for junctions.

Reply
0 Kudos
Highlighted
New Contributor III

Thanks Melinda. That worked beautifully. You have been a tremendous help.

Reply
0 Kudos