Service Area analysis - holes in service areas

[ShaunConway]

Hello,

I am attempting to perform a Service Area analysis and am getting unexpected results. I am running the analysis using the detailed polygon generation. My issue is that there are a significant number of holes being generated in the service area results. To test these anomolies, I've run a simple routing problem to verify whether or not these "holes" are routable. In each instance, the routing problem is solved without issue. In the screenshot below, you can see the hole in the service area analysis. The turquoise line is the result of a routing problem. It solved correctly and the cumulative time indicates the entire hole in the service are polygon should be green (<5min drive time.)

I'm sure there is a setting that I am missing, but I've tried everything I can think of. I'd prefer to not user the generalized polygon generation setting, as the results negated a few pockets of "hard to reach" streets.

Any thoughts would be greatly appreciated.

Shaun

ArcGIS Desktop 10.2.2

Windows 7 64bit

Enterprise Geodatabase - SQL Server 2008 R2

[JoeBorgione]

I don't have an answer except to say that those holes in polygons have always appeared with network analyst; they've never been explained to me.

It looks like you are using NA to develop response zones for fire/ems, which is what I've used it for as well.  As long as your network has connectivity to to the islands, and the drive times are not exceeded [by too much] I wouldn't sweat it.There may be the off chance that the last segment traversed does in fact exceed the conditions, for example you have the speed limit erroneously set at 0 instead of 25; check those sorts of things out to be sure.

[ShaunConway]

Thanks Joe. I ran the Service Area analysis with line generation as well. All of the streets that are near these holes are routed and included in the appropriate drive time ranges.

You were correct about the response zones. Were running the analysis to supplement the initial discussions response zone remediation. Unfortunately, these holes are a distraction to those discussions.

If I can't resolve it, I can always just use the lines.

Appreciate the input.

[JoeBorgione]

...Unfortunately, these holes are a distraction to those discussions....

Yep, I get that.  Been there, and got the tee shirt....  The only thing I can suggest (and I've done this) is manually modify the polygons so the islands disappear before you present your findings to the 'experts'.

[ShaunConway]

Exactly the discussion the we had in our office. Worst case scenario would be filling in the holes ourselves. Thanks again Joe.

[ChrisDonohue__GISP]

I have run into weirdness like this in the past when deriving Service Areas with Network Analyst.  Sometimes it seems to have a mind of its own and produces strange results.

Just to be on the safe side, though, if you haven't done it already I would run topology on your data to ensure it all is connected correctly.  Sometimes it seems like having just one disconnect in an otherwise connected dataset causes the strange results.

For example, a break in connectivity in your lower image at or near the junction of Peachtree and Meadowbrook might yield the result you have.  Keep in mind that often the lines/edges will look connected when inspected visually, but topologically be off by a very small amount, rendering them unconnected from Network Analysts' perspective.

Another solution that sometimes works is to replace the linework in the area where it is weird.  Draw in new and delete the old, attribute as necessary, then run topology to ensure connectedness.  Then run it with Network Analyst.  I don't know why this resolves it in some cases, but it can sometimes fix the issue.

Chris Donohue, GISP

[ShaunConway]

Chris,

I appreciate the input. The topology is clean in all of these instances. Unfortunately replacing the geometry isn't a great option for us. We're tied into an asset management system and our E911 system and replacing the geometry will have to be a last resort. If we don't have any success elsewhere, it might just be what we have to do.

Thanks for the help,

Shaun

[ChrisDonohue__GISP]

I know what you mean about not being able to replace the data.  I recently started working for a mid-sized city and have found that some of the data sets I need to work with are not as clean or complete as needed for what is expected.  But those datasets are owned in SDE by other departments, so I can't change them directly.  And those departments are shorthanded and have other priorities than fixing their data.  So I'm having to do workarounds to address or bypass issues their data has so I can then do the analysis' my department needs done.  Frustrating.....

Chris Donohue, GISP

[ChrisDonohue__GISP]

Another troubleshooting idea/process:

Copy the data from your assets management to a File Geodatabase.  If it is too massive, just grab the road data near your problem areas.  Then try Network Analysis on that data.  When your issue reccurs (likely), try some of the solutions people have posted here.  The goal here is to determine the specific issue, knowing that it may not immediately be correctable in your "real" data.  Having a dataset that you can play with and modify will go a long way in terms of finding the issue.

Chris Donohue, GISP

[MelindaMorang]

Hi everyone.

When using detailed polygons in Service Area, holes are normal and expected.  Detailed polygons provide the most accurate representation of the area that can be reached within your time or distance limit.  It is quite possible that there might be pockets of unreachable areas completely surrounded by reachable areas.  For instance, it could take quite a bit of time for your fire truck to wind its way through a bunch of curvy subdivision roads to the end of a cul-de-sac, so the cul-de-sac might not be reachable even if the surrounding roads are, leaving a hole in the middle.  You might also have a stretch of road with a restriction on it, and Service Area polygons will not be drawn around it if the road is restricted in the analysis.  Finally, there might simply be a large area with no roads, such as a river or lake or forest.

That said, the holes you're getting might be a symptom of a problem with your network dataset (and the screenshots make me think this is indeed the case).  In addition to the topology issues mentioned above, there are a few reasons why some

- Your road has a one-way problem where both directions of travel are restricted (a 0-way road).

- The impedance is calculated incorrectly for the road, giving it an extremely high value that makes it effectively unreachable.

- Your road has a restriction placed on it incorrectly.  For instance, there might be a height restriction with an unreasonable height limit.

- The roads intersecting this one connect to it at vertices, but you're using an End Point connectivity model, so the roads don't actually connect.

Some debugging tips:

- Run the service area again with all the same settings, but check on line generation.  Are the Service Area lines covering the roads where the polygon holes are?  If not, then that looks like a symptom of a network connectivity problem.

- Create a Route analysis layer and drop two points on either side of that one troublesome road segment.  Can you calculate a Route and force it to cross that road segment, or does it loop around the block instead in order to get to the other side?

- Use the Network Identify tool (on the Network Analyst toolbar) to click on the problem road.  A pop-up window will appear, and it will show you a list of all the junctions and edges that are connected to that road.  You can click on the items in this list, and it will highlight them on the map.  If the road isn't connected to the surrounding roads the way you expected, then you have a network connectivity problem that needs to be solved.