Why is Miles shorter than using time as impedance when the miles would give the shorter time route

[EmmaButzler]

I am trying to figure out network analyst function. I was given a dataset with the Feilds TF_Minutes and FT_minutes that were calculated by taking the distance (in miles) and the MPH to find the time it takes to traverse that network. My problem arises when i make the impedance Minutes Versus Miles. I get very different answers. I checked on google maps and it follows the route where miles is the impedance. 

I changed the attributes so the cost of turns are calculated however that did not change my route. Can anyone help with this issue?

[DavidPike]

From your pictures it looks like the lowest distance (miles) route is taking a road which isn't on the map at that scale and probably a back-road/lower speed limit.  Have you looked at the speed limits of the road sections to compare?

The fastest 'time' route looks to be going into a population centre.  I'd reckon ArcGIS probably isn't factoring traffic factors and is just going off the maximum speed limit if Google Maps is suggesting differently.

[RachelApplebaum]

Hi Emma,

I want to make sure I'm understanding the problem, though, so I'm going to recap what I think you're asking about:
You have your own network dataset that was given to you by someone else. It has 3 cost attributes: Minutes, TravelTime, and Miles. Presumably Miles is based on the shape length (though with no pictures of that cost attribute setup, I can't be sure), Minutes is based on a field that was calculated by some equation with distance (unknown if shape length or something else) and the speed limit, and TravelTime is not mentioned (or unknown; usually when I see TravelTime it uses traffic info [that's how SMP and ArcGIS Online do it] but I doubt you have historical traffic info with this network).
When you solve using the Miles cost as the impedance, the route makes sense and fairly closely matches what Google Maps gives you for shortest time route. But when you solve with Minutes as the impedance, the route is a lot longer and doesn't look correct.

My first thought upon seeing the pictures is that there is a problem with the calculation of the costs somewhere in the data. I'd look at the FT_ and TF_Minutes field values on the centerlines and check that they make sense. Pick a few random streets and divide the shape length by the speed limit (make sure you keep the unit conversion correct) and see if those numbers match what's in the FT_ and TF_Minutes fields. For a more circumspect review, pick streets that are on and around the path that's return when solving with Miles as the impedance. Do the Minutes values for those streets make sense? My guess is that somewhere, maybe on a few streets or maybe everywhere, the Minutes values aren't correct; they are too large, and that's what's making the route solver take a longer path when solving using Minutes.

I'd also double check how the Miles attribute is set up. If it's not using the Shape field directly, double check the numbers and make sure that it was calculated correctly.

To inspect the network attributes directly, you can use the Explore Network tool https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/explore-network.htm . Or look directly at the attributes on the street centerlines. Whichever works best for you.

Regards,

Rachel

[EmmaButzler]

Hi Rachel,

Thanks for the response. 

I tried some of your tips. I created a field script that takes the Shape Length and the MPH to calculate the time it takes to travel the segments. I also created a Hierarchy of roads so interstates and larger roads have preference before local roads. I then included the time it takes to make a turn. I still am getting a route that is not the time optimized route.  

My thought is that the intersection of the highways with other roads is causing the route to look funky. I don't have elevation included in my network dataset therefore any intersection of roads even if there is a under passing I am assuming is getting treated as an intersection that you have to stop at.

[EmmaButzler]

I do think it is the group connectivity however I am unsure how many  groups to make and how they should be grouped.