Discrepancies in travel time with Public Transit Data Model- service area and closest facility analysis

Question

Hello everyone,

I wanted to express my gratitude to all the members of this community and to the ESRI team for providing invaluable step-by-step tutorials on utilizing the Network Analyst Extension.

After some experimentation and following the tutorial provided here, along with the written documentation, I have successfully created a public transit model for Washington, D.C. using WMTA GTFS data. However, I've encountered a discrepancy when comparing the results from the service areas analysis and closest facility analysis with those obtained from Google Maps.

Specifically, I've observed that the transit estimates from my model tend to be significantly higher than those from Google Maps for some areas. For instance, a census tract centroid location indicates a 52-minute transit time via my public transit model, while Google Maps suggests a transit time of 25 minutes to a closer facility and different location. While some other census tract locations have the correct closest facilities and similar transit travel times.

Upon examining the data provided by Google Maps, I noticed that in this example the quickest route involved a 0.3-mile walk followed by an 11-minute metro ride, concluding with another 0.3-mile walk. As far as I understand, the public transit model accounts for walk time at a speed of 83.3 meters per minute, which is included in the total time reachable within the service area and factored into the total time when using the closest facility tool.

However, I am puzzled as to what other factors might be contributing to such different travel time results. For context, my Transit Network dataset indicates no issues with dirty areas. The inputs include both rail and bus GTFS data, and the census tracts I'm using as incidents are population-weighted centroids. Additionally, I've purchased the Street Maps premium custom roads product and specified the restricted pedestrian areas when running the 'connect public transit data model to streets' tool.

If anyone has insights into what could be causing this discrepancy in several of the travel time estimates, I would greatly appreciate your input.

Thank you.

Melinda Morang · Answer

Send me an e-mail at mmorang - at - esri - dot - com, and I can provide you with a link to a secure file transfer tool (or you can use your own and share it with me at that address).

Please include the network dataset and also some information about the specific area where you're seeing the problem and the date/time you're using for the analysis.

JFontenot · Answer

Hi Melinda,

Thank you so much for your response, the detail provided, and the transit tutorials you previously released.

I did check WMATA GTFS data again, they initially didn’t include the caledar.txt file, but newer releases as of March 2024 have both the calendar_Dates.txt and calendar.txt. I was also surprised and happy to see this updated! However, I have attempted to run both options (generic weekday and specific date/time) and encounter the same error, located to one particular region of DC

To the second point you provided, I’ve noticed the route and service areas where I am seeing this error do appear unreasonably long even with the potential of a missed bus or connection. I would love to share my data with you, if possible. What is the best way to provide you with the data on a secure platform?

I will do some additional digging to see if there is also a difference in the pedestrian pathways between the Streetmap Premium Custom Roads and those on Google Maps.

I truly appreciate your help!

Jazmin

Melinda Morang · Answer

Hi.  Thanks for your question.

I don't know the details behind exactly what Google Maps does, but I can at least try to explain what Esri's tools are doing and some areas where they might be different.

First, it's been a while since I've looked at WMATA's GTFS data, but I recall that in the past it didn't include a calendar.txt file and used a calendar_dates.txt file for everything.  This means it is not possible to do an analysis for a generic Wednesday.  Instead, you have to pick a specific Wednesday when setting your analysis settings.  Please be sure you've checked for this scenario.  If you're running your analysis for a generic Wednesday or a specific date that is outside the date range the input GTFS data is valid for, the transit may not be getting used at all, and this would account for the discrepancy.  Basically all routes are walking only.

Also, if the routes or Service Areas appear unreasonable, it's possible something isn't configured right in your network dataset.  If this is the case, we can try to debug this, or if you care share your data, I can take a look.  We want to rule out any network configuration problems before examining any differences in results between Esri and Google.

One difference between Esri's transit solves and Google Maps is that Esri's solvers use the exact time of day configured by the analyst as the starting or ending time.  It's hypersensitive to this start time, and the result might be different if you choose a start time a minute or two off.  I don't really know what Google does, but since they are designed more for passenger-facing routing apps, I think they're employing some sort of fuzzy start time logic to find the best or most sensible route.  If leaving one minute earlier allows you to arrive at your destination 20 minutes earlier (because you don't miss a useful bus), I think Google will find that, but Esri's solvers don't have this functionality.  The downloadable Transit Network Analysis Tools may help you to account for this in an analysis.

The difference in street data is also a consideration, although the Streetmap Premium Custom Roads data should be of a high quality and include various pedestrian pathways and useful attributes.  Google may have slightly different information about pedestrian paths, although probably not substantial differences that would account for huge discrepancies in travel time.

Hope this helps a little.