I have successfully created and run analysis on a transit network data set that is created from GTFS files from 4 regional transit agencies and includes walk access to stations. I would like add in drive access for stations that include a park and ride facility. My organization has street map premium, I am using ArcGIS Pro 2.8.1.
I haven't found any useful tutorials, youtube vides, or threads on this forum specifically for this task. Does anyone know if this is possible? Or perhaps my better option would be to run separate OD matrices for walk and drive and then combine the output data to select shorter times for specific OD pairs?
Any ideas would be appreciated.
Hello. Yes, this is possible with careful set-up and a few considerations.
First, if you want to combine StreetMap Premium with the public transit data model tables and feature classes, you need to have an editable version of StreetMap Premium. You cannot edit or add stuff to a licensed, non-editable StreetMap Premium dataset. Talk to your Esri representative to find out about the editable version.
The other thing you need to think about is how you want to model travel on either end of the transit trip. The traveler will drive to the park-and-ride, leave their car, travel on the bus/train, and then...walk the remaining distance to their destination? Or hitch a ride in an Uber?
You can configure the travel time (or impedance, more generally) calculation in a network however you want to. So, you could configure the network to calculate travel time along streets based the length of the street and a walk speed. Thus, the time to travel along some specific block might be, say, 1 minute. You could also configure a different calculation to model the time to drive along those same streets based on the length of the street and the speed limit (or, to be more complicated and accurate, based on typical speeds from historical traffic data). With this configuration, the travel time along the same street from earlier might be, say, 20 seconds.
The way the public transit impedance attribute is configured (assuming you followed the tutorial and used our template) is that it uses the transit schedules to calculate travel time on the transit lines, and it uses a walk speed to calculate the travel time on the streets. This allows you to model WALK - RIDE - WALK with no problem.
You could combine our sample transit dataset with one of StreetMap Premium's driving impedance calculations to model DRIVE - RIDE - DRIVE by calculating drive time along the streets instead of walk time. However, the problem here is that if the traveler has left their car and the park-and-ride, they no longer have it when they get off the bus/train, so they can't drive at that point. The Network Analyst solvers don't have the ability to set any type of flag indicating whether the traveler currently does or doesn't have their car, so it is not possible, within the same solve operation, to do DRIVE - RIDE - WALK.
The only way to do this is, as you suggest, separate it into to solve operations. First, calculate the drive time to the park-and-ride. Then, calculate the transit/walk travel time from the park-and-ride to the final destination, and then sum the two for the total travel time. For good measure, you might want to calculate the transit/walk travel time from the original destination to the final destinations directly (bypassing park-and-ride entirely) and the drive-only journey going straight to the destination (bypassing transit entirely).
Does this help? If you DO want to combine your StreetMap Premium data with the transit data model and need some specific help on configuring the attributes, please post again. Actually, I would like to develop an automated procedure to help with that, but I have not done so yet. Learning more about your use case might help me move forward on that project.
PS. Are you with RTA in Chicago and taking on some of the work that Will Gillespie used to do? He did a whole bunch of analysis combining driving to park-and-rides with transit journeys, so you might check with him.
Hello! This is super helpful and has given me some places to start. I sense that I will be coming back for more help but let me digest what's here first. Happy to discuss further at some point.
I am indeed from RTA Chicago and I am attempting to recreate Will's previous work for updated an updated network and relating that to current population/job data and thinking about how to best model walk/drive access (i.e. Ubers on destination end) and doing so with current tools. Unfortunately for us, Will has moved on to a new role at a different organization.
Oh, one other consideration: The streets are also used to make transfers between transit lines. If you've got it set up so the travel time along streets is configured for driving, then you'll end up the the transfer times being calculated as if for driving. That's almost certainly incorrect. I think splitting up the analysis into parts is probably the way to go, and I think that's what Will was doing.
That makes sense, might even produce some weird drive transfers that would be prohibitively far away for walk travel.
One follow-up question: is there any way to produce the OD output that breaks up the travel/time segments further? Most importantly the concept of initial wait time. For example: I set start time parameter at 8am, traveler walks 3 mins from home to nearest bus stop but if the first bus doesn't depart until 8:15 the total travel time includes the 12 min wait. Instead, traveler waits at home 12 min, departs at 8:12 for the 3 min walk to the stop and bus departs immediately. Initial wait is broken out in the output along with walk time, in vehicle time, transfer time, etc.
I've seen other tools produce the output this way. It resolves the issue of needing to average start times throughout a peak hour window (which is what Will did and requires a lot of extra processing.)
With OD Cost Matrix, you can't do that at all because OD Cost Matrix does not preserve and report the "traversal result", the detailed path taken through the network. This makes OD Cost Matrix faster, but it does mean you can't get the full path if you need it. To do that, you would have to use the Closest Facility or Route solver instead.
Assuming you're doing an OD Cost Matrix or Route analysis, you can retrieve the traversal result using the Copy Traversed Source Features tool. This breaks it down into every network edge, junction, and turn that were traversed, and it tells you the travel time for that segment and the cumulative travel time along the route up through that segment. You could post-process this result to determine how much of the time is spent walking/driving (by summing the components on street segments) and how much is spent waiting/riding (by summing the transit line component) and how much is spent boarding/exiting (by summing the stop-street connector component). Unfortunately, wait time and ride time are combined in the transit lines. This is because of the way the Public Transit evaluator works, and although internally the evaluator knows how much time was waiting and how much time was walking and exactly which transit trip was used, the evaluator has no way to pass this information back out into the traversal result. It's a limitation of the internal architecture of Network Analyst.
It sounds like what you would like to model is the best-case scenario where the traveler knows the transit schedule and leaves home at whatever time minimizes their travel time, subject to some desired arrival time. Is that right? Unfortunately there's no easy out-of-the-box way to do this without just choosing the optimal start time in advance, or solving across a time window and picking the best one of the lot after looking at all the results.
Duly noted on the limits of OD Cost Matrix - I had come to that conclusion but good to know I wasn't missing an easy way to fix.
To your last paragraph - correct, best path and customer optimizes leave time. Running at multiple start times and averaging across a peak hour seems to be the best workaround.