Cities need mobility data to manage their streets. The influx of scooters and dockless bikes in American cities has resulted in large amounts of data flowing from companies to cities. This data has cities asking new kinds of questions and we need transparent tools to empower that inquiry.
SharedStreets Mobility Metrics is open source software that turns the large datasets many cities receive about scooters into a set of open metrics that answer common questions like, ‘how many scooters were available in my city at 8am?’, ‘how long is the average scooter trip’ and many more!
We don’t get in between cities and their data. Mobility Metrics is a locally-hosted application that runs entirely on city infrastructure.
In keeping with SharedStreets’ values, it is open source, fully customizable, and helps limit privacy risks by working with data in aggregate. Data is linked and aggregated to the street using the SharedStreets Referencing system, making it interoperable with other street-linked data sets and easy to export to your preferred workflow.
Data for dockless mobility devices (e.g. bikes and scooters) is often available in a standardized format called MDS. The raw MDS feeds contain a vast amount of data and has to be extensively translated, processed and analyzed to answer common questions cities are asking about scooters on their streets. The mobility metrics software takes this raw data and translates it into answers to common questions cities are asking.
We hope the mobility metrics software can contribute to creating a standard, transparent set of metrics that evolve with standards and cities, and create an open process for evaluation.
We have been talking to some cities about the metrics they use to evaluate micromobility. This is our first draft. Ideas and contributions for existing and future metrics are welcome and encouraged (submit them here & label them ‘metrics’). We will be regularly checking feedback and updating metrics.
Currently, the Mobility Metrics tool generates a set of overall metrics that focus on daily activity for dockless vehicles across the city, as well as a set of map-based metrics that produce geographic data and can answer more detailed questions about particular streets, zones, neighborhoods and time periods when a minimum trip threshold is met.
Available as daily summaries:
Available for specific time intervals:
All changes to metrics will be reflected in the Github readme linked here.
Mobility Metrics currently aggregates information based on time of day or geographic areas, provided the minimum trip threshold is met. The aggregation of individual trips or points to a minimum trip threshold in a given area ensures that data is not unnecessarily stripped of information when the density meets or exceeds the minimum threshold.
Time of day aggregation: Specific time aggregations can be specified, for units ranging from a day to a 15-minute window
Geographic areas: Two options for geographic aggregation are currently available. Different options and combinations are available depending on the metric.
Street segment-based aggregation: Data about transportation is usually most useful when it is linked to the street. We use the SharedStreets referencing system to link point data and line data to street segments. Aggregating to street segments using SharedStreets references results in data that is portable can be re-linked to other street related datasets, like parking. Aggregation to the street also allows you to keep the fidelity of data, where the minimum threshold is met, to see things like how many vehicles are traveling on specific street segments.
Area-based aggregation: Right now, this returns metrics that have been aggregated to hexagonal shapes, using a standard format called H3. This allows users to easily see patterns across the city, and enables GIS users to re-aggregate the data into larger areas like neighborhoods and zones. The default “zoom” level for the H3 bins is level 9, but the city can customize this and set it to the granularity they prefer.
SharedStreets regards individual trip data as highly sensitive information that should be protected in order to safeguard riders’ privacy. Mobility Metrics uses the aggregation techniques discussed above and a minimum trip threshold to avoid showing individual trip data. The tool performs all metric calculations in-memory, and raw data is not archived locally.
The software also has a programmed minimum trip threshold. The minimum trip threshold exists to help mitigate privacy risks by aggregating individual trip data. The default threshold is three unique trip pairs. If a zone or street does not have sufficient trip activity in the desired time period in order to meet this threshold, then the data for that area will not be shown.
However, this software is designed as a framework for implementing and understanding data aggregation methods. While the specific thresholds are configurable, we strongly encourage users to work with data in aggregate. We’re building these tools to help explore the tradeoff between aggregation and temporal/spatial resolution. Finer resolution requires that more trips be aggregated. This is important not only for privacy, aggregation is needed to extract useful information from sparse data.
All source code is free to use and completely open, with no strings attached. Full documentation is available on Github, and cities can follow these instructions if you are comfortable deploying and securing a production service. If not, get in touch with us! We’re happy to help walk through security and deployment, as well as workflows for integrating the outputs into GIS systems used by planners.
We are very excited to receive feedback on the Mobility Metrics tool and the metrics it calculates. Submit an issue on Github or reach out if you have questions or comments to share with us!