Service Areas in Network Analyst

[AmandaGIN]

Using SMP the default is for the service areas to run on more major roads (use heichy) this means it uses the main roads to estimate the travel distance and infers points for the final shapes. This can cause it to over estimate the in-distance (in this case retailers) that really accessible because need to get to a local road.

Example school CDS_uniq = '01100170109835' says the retailer 91383666 is within a 1/2 mile but it is really 0.93 (as determined by cost matrix) (see retail dot in SW off a cul-de-sac)

Also noted in ESRI documentation: http://desktop.arcgis.com/en/arcmap/latest/extensions/network-analyst/service-area.htm Under Polygon Properties: One influential factor in determining the shape of the output polygon is whether Use Hierarchy is checked at solve time. Be aware that if hierarchy is used, the polygon may overlap some lower-order roads that can't truly be reached within the given distance, travel time, or other break impedance.

[AmandaGIN]

For at least retailers, we will need more accurate service areas (since they are used to calculate the demographics). @ychaiu to rerun the school service areas, then retailers (may need to be in batches since there are ~35k)

[ychaiu]

This is the service area for schools, run with no hierarchy, with detailed polygons

SMP_ServiceArea_Schools_HalfMile_NoHierarchy_Detailed_All.zip

[ychaiu]

Per discussion with Esri tech, I will start a new case to discuss the issue of overextended service areas

[ychaiu]

March 30 Email

Yessenia,

Thanks very much for the sample data for schools and the service areas you obtained from analysis. Since the route data and network dataset were from Streetmap Premium, those network settings were all pre-assigned and not changeable. I exported a subset of the Schools (in southern California, 3041 features in counties Los Angeles, Ventura, & Orange), and reprojected them to WGS84, the coordinate system of the SMP data, to ensure they were as compatible as possible with the route data.

I created a service area with the following parameters:

Network Locations: Location Type: Facilities, Name field = School Search Tolerance: 1800 meters, which I needed for having all the schools included Snap to: Closest - Routing_Streets: Shape Exclude (unchecked) No Line Generation Accumulation: Miles

Analysis Settings: Impedance: Miles Default Breaks: 0.5 Not using Time Direction: Away from facility U-Turns at Junctions: Allowed Hierarchy: no Ignore invalid locations: yes Restrictions: all unchecked

Polygon Generation: Generate Polygons: yes Polygon Type: Detailed Trim Polygons: 0.5 Miles No sources excluded Multiple Facilities: Overlapping Overlap type: Rings (doesn't matter with only one break level)

The service areas looked significantly better than the strange results that exceeded 0.5 miles in your sample. In some cases my output polygons matched yours, in other cases they were smaller or larger, but they were more "regular" in shape and didn't have the sharp corners from your sample. I'm posting those polygons to the FTP site.

In general, the irregular shapes of the service areas are due to having to travel along the streets to reach the half-mile distance, not traveling outward from the facility as the crow flies. The end points for the travel distance from each facility are connected together by the output polygon boundary for that facility, and are not going to have a regular-looking curved boundary as you might expect with the Buffer tool.

It's not clear to me (1) why the polygon boundaries are as rough as they are instead of being drawn with straight lines directly from one endpoint to another, although it's also evident that in some cases doing so would cross street segments that the algorithm appears to avoid. But the reason for all the bumps and jogs in those boundaries is not clear.

And (2), there are still some places where the boundaries seem excessively large, although in most cases it does not seem so pronounced as in the polygons you sent. I agree that some of the lines in the route data are ferry routes, but those are visible along with all the other street types, and would make it obvious that the polygon is following a route of the street layer. Some of the output polygons still have jutting corners for no apparent reason. The land boundaries are not an input to the network analysis, only streets, so the fact that some parts of the polygons are not overlapping land areas should not be significant.

I'll be consulting with colleagues to understand these results and will get back to you as soon as I have further information or questions. Thanks for your patience during this process.

[ychaiu]

April 2nd email

Yessenia,

1. In my sample, because I used the "trim" option for polygon generation (0.5 mi), the output polygons were extended to 0.5 mi outside the network lines corresponding to a given facility, which explains why some boundaries in your original service area followed the streets but mine extended away from the streets into areas where no roads existed. The trim will try to place boundaries where they don't intersect roads that are not included in the network. If possible, don't enable the Trim option. Trim should generally use small distances, such as some number of meters, not as large as half a mile.
2. The Detailed polygon algorithm can sometimes cause the extended angular boundaries of service areas that you reported. The General algorithm is newer and better in most cases, unless you anticipate "holes" in service areas for off-limits areas that should not be included within the polygon boundaries. If you switch to General, the large angular areas go away, but it won't be able to process holes.
3. I wasn't sure if you set any Restrictions at all under Analysis Settings, so I tried disabling all, but we recommend setting at least one restriction, such as Walking if this is to be a walking network. This will prevent walking routes from being considered along highways and other limited-access streets. A case where you could reasonably consider turning off all restrictions might be for a route for laying cable, for instance, where you're looking for a right-of-way and don't care about the type of street or direction of travel. When I tested with no restrictions and General polygons, the results were slightly larger polygons than with the Walking restriction, but pretty similar.

Would you test again using the General option for polygons, and let me know if there are further issues.

[AmandaGIN]

@ychaiu try running: No hierarchy and generalized polygons.

We'll look at the results and then see how those appear. We might need to take the No Hierarchy and Generalize and erase the No Hierarchy Detailed (if there are inner donuts to remove).

[ychaiu]

Documentation on network analyst issues and suggested solutions https://docs.google.com/document/d/1FmR47pi2Jvl0pc01PdeOTB2qZ2kiUAXSyxgPLgH9msY/edit