Open alex-mucci opened 3 years ago
I have maps for Chicago car OTP travel times. Some centroids fall too far from a road segment which produces a missing value. Will either need to increase the threshold for searching for a road segment, or manually edit centroids to be closer to road segments. - Alex to do
To calculate congested travel times one time between each census tract pair in Chicago (not by tod) is over $5k. Could contact their sales department to see if a better deal is possible. - Greg to do? Sales contact form - https://cloud.google.com/contact/?pre_product=googleMapsPlatform Pricing - https://developers.google.com/maps/documentation/distance-matrix/usage-and-billing
Need to determine the cost for purchasing MA alone. - Greg to do?
Need to contact somebody at Uber. - Greg to do?
I feel like there were some Chicago folks that did something like this (for the Chi CMA?) that presented about it at the Carto Spatial Data Science conference in 20...18?
USDOT ITSJPO runs something called the Secure Data Commons and they might already have that data loaded into their system.
Waze also does data sharing, don’t know about research but they share for free with cities.
Also, maybe Streetlight data?
Tweet See new Tweets Conversation Greg Erhardt @GregErhardt · Dec 10 Transport friends: I'm looking for estimates of congested car travel times from every Census tract to every other Census tract in the US. Any recommendations on where to get this at a reasonable cost? #BigData #BigModels Matthew Wigginton Conway is on the job market @mattwigway · Dec 10 @owenam ? Andrew Owen @owenam Replying to @mattwigway and @GregErhardt Unfortunately the data we use for calculating this is under a license that prevents us from sharing the travel time results.
Cuebiq Mobility Flows? https://cuebiq.com/visitation-insights-mobility-flows/ Tracts could be computed from the raw data, but I'm not sure how reliable travel times would be. Worth a look though.
Fix OTP travel times and have Chicago RH travel times ready for estimation 12/21/20.
Compared the ridehailing travel times to OTP auto travel times. Surprisingly the ridehailing travel times are shorter than the OTP auto travel times, on average. The images below show the census tracts with the highest number of O/D pairs with OTP auto travel times above 60 minutes (the max ridehailing travel time). The area just north of Evergreen park jumps out with 6 zones adjacent to each other all having much higher OTP auto travel times than ridehailing travel times. Not sure what is going on here, but seems odd for them to be bunched together like that.
The highlighted census tracts are: 17031700401, 17031700402, 17031700100, 17031700200, 17031661000, 17031700501, 17031010300
Here is one of the zone pairs that has a much higher OTP auto travel time than ridehailing travel time. The average OTP auto travel time is 62 minutes and the average ridehailing travel time is 11 minutes. I used google maps as a third party validation of which travel time was feasible and found that the ridehailing travel time seems unreasonably low. Google maps estimates the same trip to take at least 30 minutes, even if it is taken at 4am with presumably no traffic. Google maps also estimates the trip to take nearly a hour during the AM peak, which matches up with the OTP auto travel time.
From another approach, the trip is 13.5 miles long. Completing the trip in 11 minutes would mean that the ride-hail vehicle averaged a speed of 74 mph. Side note, google maps estimates the trip to have zero miles along the interstate. The OTP auto travel time means that a vehicle has to average a speed of 13 mph, which is not unreasonable considering the route.
This leads me to thinking that the OTP auto travel times should be used instead of the observed travel times because of its estimates being closer to google maps estimates and its availability nationwide.
Google Maps Travel Time (AM Peak)
Google Maps Travel Time (Overnight)
Another example... this is when the difference between the two travel times is the greatest. The OTP auto travel time is 72 minutes and the ridehailing travel time is 12 minutes. The same thing happens here when the travel times are compared to google maps. The OTP auto travel time makes more sense.
The census tracts shown here are 17031010201 and 17031700302
Here is another example... this time the OTP auto travel time is lower than the ridehailing travel time. The auto travel time is 30 minutes and the ridehailing travel time is 46 minutes. Google maps estimates the travel time to be somewhere between 22 and 35 minutes at 4:30 in the morning, with presumably no traffic. Again, the OTP auto travel time matches better with what google maps estimates. Census tracts 17031980000 and 17031081201 are shown.
The ridehailing is much lower because of the zeros being added in for OD pairs without ridehailing trips. I will add in the zeros after aggregating and see how it changes things.
The transferable model will need to include a cost variable, most likely, travel time between zones. The Chicago data has the travel time of every trip, but there is not a clear way to get that data for MA. A few options were talked about after my proposal presentation.
Scale OTP free flow travel times 1a. Scale with the TTI congestion index that Dr. Chen emailed me 1b. Scale using the Chicago travel time data. Maybe a scalar by trip length bins or by tod
Use the Google maps congested travel time API
Purchase the data from a vendor (HERE, Inrix, etc.)
Reach out to see if Uber movement data is available in more cities