Calculate Transit Service Frequency stuck at "Solving Service Area analysis"

[pearlescent]

Hi all.

As part of my final student project I'm making a coverage map of Vancouver's transit system (SkyTrain and buses included) through the Calculate Transit Service Frequency tool.

This tool requires a Network Dataset that I've carefully assembled from Vancouver's GTFS data (available here -- it's also in immaculate condition), using a premade template (with some minor modifications like a new travel mode for walking) that I got from the ArcGIS tutorial.

So far, every Network Analyst tool I've tested (e.g., service area, OD cost matrix) has worked great on this ND, including the aforementioned Calculate Transit Service Frequency tool using the settings transit stops, transit lines, and points of interest.

It's only when I try to use the "Areas" analysis type (to generate the aforementioned coverage map) that the tool just hangs. It gets stuck at "Solving Service Area Analysis" despite minimizing duration, units of travel time, and maximizing cell size (i.e., making it run as fast as possible).

While I have thought of some ways to circumvent using the "Areas" analysis type (e.g., doing a kernel density analysis with the resulting features from the "transit stops" analysis), I'd really like to generate this coverage map. If anyone has any pointers I'd love to hear it.

This is particularly confusing since I can individually run multiple service area analyses separately, so I see no reason why the Calculate Transit Service Frequency tool can't do the same.

N of transit stops = 8832

Streets layer source: OSM

P.S., I have looked up this issue everywhere and it seems I'm the only person so far to have had this tool hang on me like this! I've left it running for 48 hours on a lab computer only to come back to the tool still in process.

[MelindaMorang]

Hello, @pearlescent .  Happy to help with this.

First off, I think the problem might be that you should NOT be using your transit-enabled network dataset as the network for this tool.  Calculate Transit Service Frequency needs to calculate the walk time/distance from transit stops.  It should NOT model travel BY public transit.

The Points of Interest mode is a bit more intuitive than the Areas mode, so let me use that as an example.  Behind the scenes, the tool calculates an OD Cost Matrix to calculate the walk time or distance from each point of interest to all transit stops within the cutoff.  Once those stops have been identified, it calculates the frequency of service available at those stops and combines them into one set of statistics for each point of interest.

So, you don't want to model travel by public transit.  You just want to find the transit stops that are within walking distance of the points of interest.

The Areas mode uses a Service Area to calculate the area within a short walk time or distance of all the stops in the system and then combines the resulting polygons into a big raster-like thing.  If you used your public transit travel time mode here, you're probably getting much larger polygons, and it's struggling to perform the calculations.

I'm not really sure what's going on under the hood that's causing the slowdown or hang, but the first thing you need to do is to use an appropriate network dataset and travel mode that models walking time or distance only, not public transit travel time.  Try that, and if you still have problems, we can move on to some further debugging.

[pearlescent]

Hi @MelindaMorang! Thank you so much for the prompt response!

Should I create an entirely new network dataset, or is a new travel mode in the same network dataset acceptable?

I caught the warning about public transit travel time mode, and created some new restrictions alongside a new travel mode that should only use WalkTime as impedance and restricts access to StopConnectors and LineVariantElements. I've attached some screenshots of this new travel mode and the corresponding new restriction.

This is what I've been using with my calculations so far. Do let me know if I require another Network Dataset and I'll see to making that work!New restrictor - HumanNotOnTransitNew travel mode - Walking

[pearlescent]

A bit more troubleshooting and I realized that I must have used incorrect settings when creating the travel mode (which I must have fixed somehow before taking those screenshots (?)), because now the tool is successfully getting past the "Solving Service Area Analysis..." step.

A huge thank you for all your help thus far (especially with pointing out the travel mode issue). One step closer to getting all of this done!

However, I'm now receiving Error 000918: Cannot retrieve feature class extent, which fails the FeatureToRaster (Converting Service Area polygons into cells...) step. I'm not certain what I can do to fix this issue as I don't have access to the inputs (as they are automatically ran by the script). Any additional insights you have would be much appreciated.

[MelindaMorang]

Hmm, using the transit-enabled network for walking only with restrictions like you're using or other ways to prevent using the transit lines is generally okay.  For a route or OD cost matrix, it would work fine and produce the right results.  However, for Service Area specifically, I think polygons it will generate will be kind of nonsensical.

The Service Area solver runs an algorithm to generate the polygon geometry, and this algorithm has a lot of rules around when to cover or not cover edges in the network.  Let's say you have an ordinary city block, and all streets surrounding that block were reachable within the travel time limit.  Then the entire area of that city block will be covered by the polygon.  Let's say only three of the four sides were reachable.  The polygon generation algorithm does some math and covers only part of the interior of that block.  Let's say all four sides were reachable, but a small dead end going into the center of that block is NOT reachable or is restricted.  More math happens, and the polygon geometry will have a hole in it to account for the unreachable street.

The problem is if you have a bunch of transit lines criss-crossing your network that are restricted or effectively unreachable in the analysis, the Service Area polygon generation algorithm will go to heroic lengths to avoid covering them, sometimes producing really weird and complicated geometries that really aren't what you want.

For your case, I think it would be better to create a separate network.  You can make a copy of your current network and remove the LineVariantElements, StopConnectors, Stops, and StopsOnStreets (and then delete the feature classes and all the associated transit tables).  Or you could start over from scratch with your OSM streets.

Here is a tutorial about how to create a network dataset (non-transit): https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/how-to-create-a-usable-network-datas...