The SharedStreets Mobility Metrics tool aggregates spatial data about micromobility to both the streets where activity occurs and into zones (these are hexagons called “h3 bins”). The tool makes it simple for cities to convert data about scooters and bikes in MDS into useable metrics and bring that information back into a city’s GIS or database system, where endless customization and analysis can easily take place.
This post shows how to export metrics data into GIS and create custom geographic boundaries, like city council districts or equity zones, to visualize scooter metrics. Specifically, we will demonstrate how to calculate availability by city council district using Detroit as an example.
If you don’t have the Mobility Metrics web interface running, you will find instructions here.
First, we use the Mobility Metrics web interface to select a provider and a day. We’re interested in morning scooter availability so we set the time to 7–8am and navigate to the availability metric (this can be set to any time aggregation). Then we export the zone (hexagon) data as a JSON.
Next, we add the JSON into a desktop GIS application, like ArcGIS or QGIS. In QGIS, you can simply drag-and-drop the JSON into your map. In ArcGIS, you may need to convert it to a feature class first (you can do this using Geoprocessing → Conversion Tools → JSON → JSON to Feature Class).
In GIS, the data looks like this:
For binned, hexagon output, the attribute table contains a bin reference for the data and the relevant metric (in this case, the 7–8am availability). This is shown in the image above.
Once the data layer is loaded into GIS, we re-project it into an appropriate, projected coordinate system (not WGS 84) with the units in meters (not degrees). We ensure that the GIS project itself is set to that same coordinate system. In this case, we’re using UTM NAD83, zone 17 north.
The areas of interest for this example are the Detroit city council districts. We will use the hexes we just downloaded to generate the scooter availability for each city council district from 7–8am.
To do this, we first load the city council districts into GIS and ensure that they are in the same projected coordinate system as the hexes and the GIS project itself. This ensures consistency during geoprocessing calculations.
The city council districts look like this:
Some of the hexes overlap between multiple city council districts, like so: To account for the imperfect fit, we use proportional weighting to scale the scooter availability based on the area that falls within each district.
In the attribute table for the hexes, we add a new column (orig_area) and calculate it to be the area of the original hex. The attribute table now looks like this:
Next, we perform an Intersection between the two layers. This will create a new layer that splits the hexes that overlap between multiple city council districts.
In the resulting layer, we add a new field to the attribute table (prop_value) where we will calculate the proportional value of each hex. This is formatted as a decimal number. The formula to calculate prop_value is is the new area of the “hex”, divided by its original area, multiplied by the number of available scooters.
The attribute table will now contain the proportionally-weighted scooter availability for each hex and hex fragment:
Finally, we sum the proportionally-weighted availability within each city council district.
In ArcGIS, this can be done using a spatial join. The target layer is the city council districts and the join layer is the intersected hexes. Under Field Map of Join Features, right-click prop_value and set the Merge Rule to be Sum. The match option is Intersects.
The process is similar in QGIS, using a spatial join that sums the proportional value of all hexes in each city council. However, in QGIS 3.x, the right tool is difficult to find. It is located under Processing → Toolbox → Vector general → Join attributes by location (summary).
Once we’ve completed the spatial join, the attribute table for the city council districts will have a field for the sum of the scooter availability from 7–8am in each district:
This process could be repeated to add additional daily stats to the city council districts layer. To avoid performing these operations each time, the process can be automated (using Python, the Model Builder in ArcGIS, or the Graphical Modeler in QGIS).
Through this process, Mobility Metrics allows cities to calculate aggregated metrics and perform their own custom analysis — enabling them to monitor scooter availability over time and consider how this relates to their equity goals. This is one example of how SharedStreets works to remove technical barriers and interoperability issues that can otherwise prevent cities from accessing and using essential transportation data.
You can find more information on the mobility metrics tool here.