State Of The Map U.S. 2016/Hands-On Day/Road Speed Isochrones
During the West Africa ebola epidemic, there was a need to identify locations that were furthest away from current ebola clinics, to plan where to site new clinics. For that, we needed to collect road speed data (smartphone app for truck drivers!), aggregate it and compute speeds, match GPS traces to OSM road ways, add tags in OSM, then use that data in Open Source Routing Machine (OSRM) isochrone map generator. The epidemic ended before this work was completed. But we know we're going to need this in the future, so let's have it ready in advance!
Folks doing GIS support for the West Africa ebola response were asked if there was a way to find locations that were poorly served by current ebola clinics, to assist in siting new clinics. We found that Open Source Routing Machine, http://project-osrm.org/, has an isochrone tool, https://github.com/mapbox/osrm-isochrone, but it doesn't use speed data from OSM. We looked at what data we had -- mainly, road type, condition, and surface tags in OSM -- and found no good way to estimate travel speed from that. What we needed was a good way to get *average* speed...
Someone had a bright idea: Coca-Cola is very popular in West Africa, and Coca-Cola delivery drivers go everywhere. So...we could provide inexpensive Android phones to drivers, running an app that would collect time-stamped GPS information.
Then, we'd analyze that data to extract travel speed, aggregate across multiple trips on the same roads, and associate the tracks with the matching road ways in OSM. We have a new (agreed on!!!) OSM tag for average speed. The measured speeds would be attached to the roads -- this might require mapper assistance or verification, as ways would need to be split into sections with the same speed.
We'd update the OSRM isochrone tool to be able to use the new average speed information, and use that to compute isochrone polygons and make isochrone maps.
We had a tentative agreement from Coca-Cola, and a UN agency that could supply phones, but...the epidemic was subsiding (amen!!!) and clinics were being closed. Nevertheless, we believe these tools and workflow will be useful in future emergency response and even everyday use, so we'd like to get this project started.
Here are the pieces we need to develop:
Road speed phone app
This would be an Android app. (Sorry, IPhone fans -- we need something that runs on cheap phones and where the app can be installed without control by Apple.)
- Record GPS locations with timestamps.
- Have easy-to-use controls so the driver can start and stop the data collection.
- As a fallback, detect when the driver has stopped other than briefly, i.e. be able to distinguish stopping at a light versus stopping for lunch.
- Upload the data.
- Compute speed from the individual timestamped GPS traces.
- Match traces on the same road.
- Aggregate speeds across traces. (This and the next could be assisted by matching with OSM ways first).
- Identify segments that are sufficiently uniform in speed to be tagged with the same speed.
Add data to OSM
- Match the aggregated traces to OSM road ways. (Mapbox folks say there may be a tool for associating GPS traces with OSM roads.)
- Split the ways into sections with a uniform speed.
- Add average speed tags to the ways.
Add support for average speed in the OSRM isochrone tool
- Find out what the OSRM isochrone tool currently uses for edge weights in its shortest-paths implementation.
- Add support for using OSM average speed tag data.
- Deal with lack of tags on some roads.
- Coordinate with Mapbox on this.
Workflow and infrastructure
How would the process of data gathering and analysis be automated? What would be needed for a server?
Visualization and user tools
Think about how this would be used. Given the West Africa ebola scenario, what tools would response planners need? What about "everyday" uses, like collecting road speed data for commute times?
Contact and interest
Interested? Add your wiki user and talk page and comments here.