AnsweredAssumed Answered

Service Area analysis - holes in service areas

Question asked by shaunrconway on Jan 21, 2015
Latest reply on Jan 21, 2015 by shaunrconway

Like • Show 0 Likes0
Comment • 11

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

No one else has this question

Outcomes

11 Replies

jborgion Jan 21, 2015 7:32 AM
Mark Correct
Correct Answer
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.
1 person found this helpful
Like • Show 1 Like1
Actions
- shaunrconway @ jborgion on Jan 21, 2015 7:48 AM
  Mark Correct
  Correct Answer
  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.
  Like • Show 0 Likes0
  Actions
  - jborgion @ shaunrconway on Jan 21, 2015 8:06 AM
    Mark Correct
    Correct Answer
    ...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'.
    1 person found this helpful
    Like • Show 1 Like1
    Actions
    - shaunrconway @ jborgion on Jan 21, 2015 8:53 AM
      Mark Correct
      Correct Answer
      Exactly the discussion the we had in our office. Worst case scenario would be filling in the holes ourselves. Thanks again Joe.
      Like • Show 0 Likes0
      Actions
cdspatial Jan 21, 2015 7:45 AM
Mark Correct
Correct Answer
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
1 person found this helpful
Like • Show 0 Likes0
Actions
- shaunrconway @ cdspatial on Jan 21, 2015 7:55 AM
  Mark Correct
  Correct Answer
  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
  Like • Show 0 Likes0
  Actions
  - cdspatial @ shaunrconway on Jan 21, 2015 8:13 AM
    Mark Correct
    Correct Answer
    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
    1 person found this helpful
    Like • Show 1 Like1
    Actions
  - cdspatial @ shaunrconway on Jan 21, 2015 11:02 AM
    Mark Correct
    Correct Answer
    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
    1 person found this helpful
    Like • Show 1 Like1
    Actions
MMorang-esristaff Jan 21, 2015 8:58 AM
Mark Correct
Correct Answer
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.
2 people found this helpful
Like • Show 1 Like1
Actions
- shaunrconway @ MMorang-esristaff on Jan 21, 2015 9:12 AM
  Mark Correct
  Correct Answer
  Thanks for the reply Melinda.
  
  The screenshots I provided show a successfully solved routing problem to the segments in question. There doesn't appear to be any issue with their accessibility (restrictions). I also ran the analysis with line generation and the suspect segments were correctly categorized within the appropriate impedance accumulation ranges which indicates the impedance values are correct. I ran statistics on the impedance fields and their aren't any outliers.
  
  It doesn't appear to be an issue with the geometry. I would suspect if the entirety of a road segment is non-traversable, than the resulting hole would encase the entire segment. In our situation, the holes are appearing only at the ends of segments, leaving the majority of the segment within a solved polygon.
  
  Thanks again for the response,
  Shaun
  Like • Show 0 Likes0
  Actions
shaunrconway Jan 21, 2015 1:16 PM
Mark Correct
Correct Answer
Hey Everyone,

Just wanted to provide an update and let you know we have identified the issue. It is very specific to our data and is not, as I wrongly expected, an issue with the Network Analyst tools. Our street centerline data includes "paper" streets. These centerlines represent the remaining right of way at the end of a street segment or the entirety of a right of way that was dedicated but never built. They are essentially a means of inventorying undeveloped right of way. They are a requirement of our asset management system as they are used to track right of way work orders (all city right of way must be maintained to certain standards within developed areas for safety/insurance/sightliness reasons ). Naturally, these segments are not traversable, and are therefor resulting in holes in the analysis.

Unfortunately our asset management system requires a one-to-one relationship with a feature class so there is no way to have paper streets as a separate feature class at this time. What we'll have to do is export the FDS to a FGDB, delete the paper streets and update the network accordingly whenever we need to run this specific type of analysis.

I really appreciate everyone's feedback and pointing me in the right direction! Wouldn't have figured it out otherwise.

Thanks again,
Shaun
Like • Show 0 Likes0
Actions

GeoNet

The Esri Community

Service Area analysis - holes in service areas

Outcomes

Related Content

Recommended Content