Trouble carrying out closest facility analysis in ArcMap

[CharlotteJ]

I’m trying to carry out closest facility analysis in Arcmap 10.2.2 on the network analysis layer created from the OS integrated transport and urban path networks. But when I click "solve" in the network analyst bar, to generate the routes between the incidents (postcode centroids) and facilities (green space access points), its failing to calculate routes for all my incidents.

An error window comes up once the analysis in complete listing hundreds of the incidents which it says are on traversable positions of the network e.g. "Location BS138RG in incidents is on a non-traversable network element position".

It repeats this message for 1715 of my incidents, then the list goes on to list 2716 postcodes which it says no facilities can be found for, I assume because of the incidents being on non-traversable parts of the network. All my access points and postcodes were originally located fine when I loaded their locations, shown from the image below. And routes have been calculated fine for about 85% of the incidents, but I can't work out why it's not working for them all, many of the facilities and locations now showing up as errors on the map.

I didn't set any restrictions in the analysis settings of the network analysis layer, so assumed this would mean that all parts of the network should be traversable. However, because I set drive time as the impedance, perhaps the problem's that in the speed profile for this impedance, the speeds are set to 0 mph along networks which aren't accessible by cars e.g. paths, bridleways. In which case, perhaps there's no way around some of the incidents being on non traversable parts of the network when calculating drive times, since cars are never going to be able to drive along these types of networks! Or perhaps the problem's that most of my facilities and incidents aren't actually situated on the network. But I thought selecting to "snap to position along network" when loading the locations of each of them, would prevent this being a problem.

I'm very confused as to what the problem might be so any help would be hugely appreciated!

[DanPatterson_Retired]

First, try using something other than time, since the 0 speed limit is definitely going to be a problem (alternately, you will have to edit that field to provide an appropriate speed limit)

Second, did you check to see whether the locations were indeed snapped to the network?  If they aren't, then you will have to increase the tolerance for a location being considered on the network.

[CharlotteJ]

Thank you, I'll try creating a restriction attribute for all the non-car-traversable networks so that they can then just be set as restrictions and excluded from the analysis. I'd set the tolerance to 50km which I'm pretty sure should have been high enough and I think that all the locations were snapped to the network fine as they were all originally located ok, so I don't think that this was the problem. Thank you for your help though

[ChrisDonohue__GISP]

Some bits and pieces that may help:

The Tool help offers the following:

Input/Output fields of incidents - Status field

Element not traversable (3)—The network element that the network location is on is not traversable. This can occur when the network element is restricted by a restriction attribute.

ArcGIS Help (10.2, 10.2.1, and 10.2.2)

Here's the Restrictions available:

ArcGIS Help (10.2, 10.2.1, and 10.2.2)

This restriction looks like it would be best for the non-vehicular portions:

Prohibit network elements

The most common use of a restriction is to prohibit traversal. For example, one-way streets can be modeled with a restriction attribute so they can only be traversed from one end to another, but not in the reverse direction. Similarly, a restriction attribute on walkways can completely prohibit traversal so that the network elements identified as walkways are excluded from any route that is generated for a motorized vehicle.

Chris Donohue, GISP

[CharlotteJ]

Thank you, I've already had a look at these pages but I'll give them another look

[ChrisDonohue__GISP]

I'll addMelinda Morang (ESRI Network Analyst Expert) here on the off chance the automated forwarding of Network Analyst questions didn't trigger.  She is very helpful in figuring out Network Analyst issues.

Chris Donohue, GISP

[MelindaMorang]

(Thanks, Chris.)

Hi Charlotte J.  The previous answers have summarized the likely problem.  For some reason, your points are being located on network edges that are non-traversable.  Edges are non-traversable either because they are restricted because of a restriction, a barrier, or a negative impedance value (which the solver interprets as inaccessible).

Normally, the first thing I would suggest you do is to check on the "Exclude restricted portions of the network" button in the NA layer properties "Network locations" page before you load locations.  This way, if an edge is restricted, the point won't get located there but will instead get located on the next-closest non-restricted edge.  This works great for restrictions and for existing barriers.  I'm not sure how you've constructed your 0mph edges, so I'm not sure if Add Locations will be able to determine that these edges are restricted or if it doesn't become apparent until solve time.  At any rate, this is the first thing I would try.

To make your network a little more robust, I would create a restriction attribute that you can assign to all the non-car-traversable edges (like your bridlepaths) rather than using 0mph speed profiles.  That seems like a kind of odd way to do it when restriction attributes are specifically designed to do exactly this.

Note for everyone: "Snap to network" does not impact whether or not points get "located" on the network".  No matter how you set this, the points are always "located" on a particular network edge (or junction), and that network location will be used as the starting point for the analysis.  "Snap to network" just moves the visible location of the facility/stop/incident to the network location.  Otherwise, it will show up in the original location of the input, even though it's the network location that's being used in the analysis.  To summarize: "Snap to network" will not change anything in the way your analysis runs and will not fix any of the problems Charlotte J is experiencing here.

[CharlotteJ]

Hi,

Thank you so much for you help. I've tried loading the locations after checking the "Exclude restricted portions of the network" button and it seems to be calculating routes for a lot more of my incidents now which is really good. Routes still aren't being created for 1073 of them though, an error message now showing up to list all those which no facilities have been found for e.g. "Warning: No facilities found for BS206GU in Incidents." So I'm still unsure why routes aren't being created for them all. I've checked that all my layers have the same projections as I've heard that this can prevent the analysis working properly, but they all do seem to be the same so this can't be the issue. But I don't think that the problem is that my incidents are on non traversable portions of the network anymore, as this message is no longer displayed in the error box.

And creating a restriction attribute for the non-car-traversable edges sounds like a good idea so I'll try doing this. When going through the OS Mastermap Integrated Transport Network Data Preparation wizard to prepare my raw ITN data, I left the speed profiles as they were, so in the "drive" profile speeds were already set by default to 0 kmph (sorry I made a mistake before in saying mph) for paths networks such as the bridleways and footpaths. I then assumed that by setting the impedance to "drive" in the analysis settings of the closest facility analysis layer that these are the speeds which would be set each type of road.

But if it's better to set networks which are non traversable as restrictions, as I'm also hoping to calculate walking speeds, should I then also set create restriction attributes for certain roads, since as these would be non traversable for pedestrians, I wouldn't want them to be included in this analysis.

Thanks.