Data Gathering

How to combine telemetry with manual mapping into one dataset.

Overview

Anonymized telemetry from Bolt e-scooter rides is combined with manual mapping to produce a structured dataset for wheelchair accessibility. It captures accelerometer, GPS, and speed measurements across areas in Tallinn and is validated through ground-truth observations.

Objectives

Data collection set out to fill the gaps in wheelchair accessibility mapping by cross-referencing human input with sensor data from e-scooters, so the two could validate one another. The work focused on four main goals.

Collection Goals
Methodology: Compare human input with e-scooter sensor data
Prototype Map: Highlight accessible and non-accessible areas
Data Gaps: Identify for prioritization in future mapping efforts
Foundation: Make findings available open source to map developers

Telemetry Source

Anonymized e-scooter telemetry data is collected from Bolt e-scooter rides. Each ride generates a JSON file containing high-frequency sensor measurements, enabling detailed analysis of surface conditions for wheelchair accessibility mapping.

Ride Telemetry Sample
{"rideData": [  {    "timestamp": 1234567890000,    "accelerationCoord": { "x": 120, "y": -50, "z": 981 },    "gpsPos": { "lat": 59.4372, "lon": 24.7453 },    "currentSpeed": 278,    "gpsInfo": { "date": "2024-01-15", "time": "14:30:25" }  }]}
Key Parameters
SensorDetails
Accelerometer

Frequency: 30Hz (30 samples/sec)

Axes: X, Y, Z in milligravity (1/1000 G)

Primary metric: Z-axis standard deviation (surface roughness indicator)

GPS

Frequency: 1Hz (1 sample/sec)

Coordinates: WGS84 latitude/longitude

Accuracy: ±3–5 meters in urban environments

Speed

Unit: 1/10 km/h (raw telemetry)

Conversion: raw value ÷ 10 → km/h

Optimal range for wheelchair assessment: 2–6 km/h

Manual ValidationStructured on-the-ground mapping using StreetComplete app for surface types, ramps, curbs, etc. (for ground-truth and calibration)

Manual Collection

StreetComplete is a mobile app that enables volunteers to contribute structured data to OpenStreetMap in a simple and gamified manner. The app presents “Quests”, which are small, focused questions about streets and infrastructure. Each Quest corresponds to a specific OSM tag, ensuring that volunteers’ answers are standardized and directly usable in the map database.

StreetComplete Features
Key FeatureDescription
Focused AttributesEach Quest targets a single mapping attribute, such as surface type, ramp presence, or curb height
Consistent InputVolunteers select from predefined options, ensuring high-quality, uniform tagging
Automatic IntegrationAnswers are converted directly into OSM key=value pairs
Easy ContributionQuests are quick and intuitive, allowing volunteers to participate without deep OSM knowledge
Selected Quests
TopicQuestOSM Code
Sidewalk ExistenceIs there a sidewalk along this street?sidewalk=*
Sidewalk SurfaceWhat’s the surface here?surface=* (or sidewalk:surface=*)
Surface QualityWhat’s the surface quality here?smoothness=*
RampsDo these steps have a ramp? What kind?highway=steps
Street CurbsWhat’s the height of this curb?barrier=kerb, footway=sidewalk, footway=crossing
CrossingIs there a crossing here?footway=crossing
Crossing IslandDoes this crossing have an island?crossing:island=yes

Location

Before selecting specific areas for data collection, several criteria guided the choice of candidate cities and neighborhoods for mapping accessibility.

Candidate Cities
CityPopulationArea (km²)Characteristics
Oslo724K480 km²High accessibility awareness and strong pedestrian infrastructure
Stuttgart620K208 km²†

Dense urban layout with mixed sidewalks and streets

Good test for complex mapping

Berlin3.9M891.7 km²‡Large city with varied terrain and extensive wheelchair‑accessibility needs
Madrid3.3M604.3 km²Mediterranean streets with historical cobblestones and urban obstacles
Tallinn456K159 km²§

Mixed cobblestones and smooth urban zones

Bolt HQ city

E-scooters allowed on sidewalks at pedestrian speed

* Municipality-level population and area figures from public statistics, rounded; indicative for site selection
† Stuttgart’s inner‑city area estimate
‡ Berlin covers ~891.7 km² as municipality
§ Tallinn municipality area approximate

Ultimately, Tallinn was chosen because Estonian law permits e-scooters on sidewalks at pedestrian speed, and the city offered a controlled, representative environment for testing the methodology. Within Tallinn, certain areas were prioritized for logistical reasons.

Tallinn Areas
AreaDetails
KadriorgA historic and residential area known for its parks and the Kadriorg Palace
TelliskiviA creative district with a mix of industrial and modern architecture, popular among locals and tourists
KalamajaA bohemian neighborhood characterized by wooden houses and proximity to the sea
Balti JaamThe area around the main railway station, a hub for transportation and commerce
City CenterThe central business district largely including pedestrian zones

Data Collection

To ensure the accuracy and reliability of the data collected by e-scooters, the Wheels4Wheels team conducted a volunteer validation phase. Human contributors were enlisted to manually verify accessibility features in the city, providing a ground-truth reference against which sensor measurements could be compared. This made it possible to cross-check the automated readings and refine the mapping parameters before wider deployment.

Experiment Setup
ItemDetails
Participants10 volunteers participated in the experiment
Duration10 working days of data collection
MethodologyVolunteers used the StreetComplete app to manually map accessibility information, including surface type, ramps, presence of sidewalks, and obstacles
Cross-validationData collected by e-scooters (accelerometer, gyroscope, GPS, and cameras) was cross-referenced with the manual input to verify accuracy and ensure high-quality mapping

Data Extraction

The data extracted from e-scooter telemetry undergoes initial processing to isolate relevant measurements. This step ensures that only the information necessary for assessing surface quality, inclines, and accessibility features is retained, providing a clean and structured foundation for subsequent analysis.

Primary Metrics
MetricDescription
z_stdStandard deviation of Z-axis acceleration (mg units)
speed_kmhSpeed in kilometers per hour
CoordinatesGPS latitude/longitude pairs
TimestampUnix timestamp for synchronization

Raw metrics only become useful once they are condensed. Three derived quantities are computed from the stream and carried through the rest of the pipeline, each summarizing one aspect a routing engine ultimately cares about.

Telemetry Derivatives
Surface Roughness
Calculated from z_std over 1-second windows
Movement State
Stationary vs. moving on speed threshold
Data Quality
GPS accuracy, accelerometer stability

Time Series Visualization

The chart below mirrors the full-ride time series from the surface quality analysis. Flat segments with very low z_std correspond to idle periods (speed ≈ 0), while high spikes indicate rough surfaces under movement.

Loading chart data...