Crowd‑Map Road Quality With Your Phone: A Practical Guide to Safe, Useful Street Data

Why road quality from phones is useful now

Potholes cost drivers money and time. Rough pavement discourages cycling. City crews struggle to prioritize repairs. We already carry the tools to help. Modern phones can sense roughness, shocks, and local vibration while recording location with good accuracy. With a little care, you can turn normal trips into reliable road quality layers that public works teams and neighbors can use.

This guide shows you how to collect data safely, process it into meaningful scores, and publish simple maps. It avoids heavy math and focuses on practical choices that work in real conditions: different phones, mounts, speeds, and vehicle types. You can apply the same pipeline for cars, bikes, scooters, or buses with minor tweaks.

What your phone can measure on the road

Core sensors to use

Accelerometer (x, y, z): measures linear acceleration. It captures bumps, vibration, and braking.
Gyroscope (x, y, z): measures rotation. Useful to detect turns, tilts, and phone orientation changes.
GNSS (GPS/GLONASS/Galileo): provides location and speed. The fused location provider on phones smooths this.
Optional: Barometer (altitude change), magnetometer (heading), BLE beacons or OBD‑II (vehicle speed) where allowed and helpful.

These give you a time series: a stream of sensor vectors with timestamps. The goal is to extract road roughness and occasional events such as pothole hits from that stream while ignoring phone fiddling and stop‑and‑go traffic.

Limits and noise you must handle

Mount variability: A phone on a bike handlebar behaves differently than one in a car’s cup holder. Mounts add their own vibrations.
Orientation: The axes (x, y, z) change with phone tilt. You need an orientation‑invariant measure.
Speed effects: The same bump produces different signals at 10 km/h vs 60 km/h. You should normalize or stratify by speed.
Human actions: Picking up the phone, tapping the screen, or hitting the brakes create spikes that are not road defects.
GNSS drift: City canyons and trees degrade location. Map‑matching helps, but be conservative.

Design a signal pipeline that works outside the lab

Sampling, clocking, and chunking

Sampling rate: 50–100 Hz accelerometer is often enough. It captures the key band of road vibration without burning battery.
Time sync: Keep consistent timestamps. If you batch sensors for efficiency, ensure each sample has its original timestamp.
Chunking: Process data in 5–10 second windows for segment scores. For pothole events, use shorter windows (0.5–1.0 s) centered on spikes.

Orientation invariance and gravity removal

A simple way to avoid axis headaches is to compute the magnitude of the acceleration vector at each sample: |a| = sqrt(ax² + ay² + az²). This loses some directional detail but makes roughness comparable across mounts. Subtract gravity to isolate motion.

High‑pass approach: Apply a high‑pass filter (~0.5 Hz cutoff) to |a| to remove slow drift and gravity leakage.
Gravity vector approach: Use the phone’s sensor fusion (often exposed as “linear acceleration”) to get gravity‑compensated acceleration directly.

Feature extraction that survives real roads

Compute features on each window:

RMS acceleration: Overall roughness. Sensitive to vibration and repeated small bumps.
Spectral energy in 2–8 Hz: Often aligns with wheel and suspension response on rough pavement. Use a short FFT with a Hann window.
Jerk RMS (derivative of acceleration): Highlights sharp changes that correlate with pothole hits.
Peak count above adaptive threshold: Number of notable shocks per window.
Speed‑normalized metrics: Divide some features by speed or compute them within narrow speed bins.

Events vs segments

Event detection: A single strong impulse suggests a pothole or crack. Use jerk peaks plus a short refractory period to avoid double counting. Store time and location.
Segment scoring: For maintenance planning, continuous roughness scores are more useful. Aggregate features over 10–30 m segments or H3 hexes and compute a percentile score relative to local roads.

Map the signal to where it happened

Location smoothing and map‑matching

Raw GNSS jumps. Blend it with the phone’s fused location. For vehicles, avoid using vertical accuracy; it often drifts. After basic smoothing, map‑match the track to a road network to snap points to likely road centerlines.

Use open source tools like OSRM or Valhalla for map‑matching.
Keep the original coordinates, too. You’ll want to exclude points with poor accuracy or low match confidence.

Segments, tiles, and hexes

Instead of storing raw points, publish aggregated, anonymized segments:

By road segment ID: Attach scores to OSM way segments or your own split network.
By spatial index: Aggregate into a fixed grid like H3 (e.g., resolution 10–12 for street scale). This is simpler and privacy‑friendly.

For each unit, keep the median and IQR of roughness, count of samples, and a confidence score. You can also track day vs night or wet vs dry conditions if you add weather context later.

Avoid measuring the wrong things

Speed bumps and intentional traffic calming

Speed humps produce a large, symmetric signal and often come in series. Combine peak shape and spacing rules (e.g., similar bumps every 30–100 m) to flag them and exclude from “defects” metrics. You can still map them as traffic calming features if useful.

Cobblestones and rough‑by‑design surfaces

Old stone streets are noisy but not broken. Long, periodic vibration with a dominant frequency is your clue. Flag these segments as rough surface rather than poor condition.

Phone handling and stops

When the phone is in a pocket or you pick it up, the gyroscope shows distinct rotations. If speed is near zero, drop events entirely. If rotation spikes coincide with acceleration spikes, treat it as a handling artifact.

Vehicle differences

A stiff road bike amplifies small defects. A luxury SUV smooths them out. Keep a vehicle class attribute in the app so you can calibrate separately: car, bike, scooter, bus, truck. Do not mix them in the same model without normalization.

Build a minimal app without draining batteries

Android basics

Use SensorManager with GAME or UI delay, then resample to 50–100 Hz.
Use the FusedLocationProvider with balanced accuracy and a min interval (e.g., 1 s) while moving.
Run a foreground service only during trips. Offer a big, obvious stop button.
Batch raw samples in memory, compute features on device, and keep raw only for short windows for debugging.

iOS basics

Use CoreMotion for accelerometer and gyro, and CoreLocation for GPS.
Request background location updates sparingly and only when the user starts a trip.
Use significant motion to auto‑pause when the user stops for long periods.

Storage and sync

Store features and low‑rate summaries locally. Sync when on Wi‑Fi or with user consent on cellular.
Compress payloads and sign requests. If you publish data, strip user IDs and jitter start/end coordinates.

Privacy and safety by design

Data minimization

Do not collect contacts, photos, or mic. You don’t need them.
Collect only what you process: acceleration, rotation, speed, coarse location, and time.

Location safety

Drop first and last 200–500 m of each trip by default to protect home/work.
Quantize locations into tiles or hexes. Never publish raw traces without consent.
Require k‑anonymity before showing a segment: only display if at least k distinct trips contributed.

Identity control

Create a random, rotating user ID on device. Avoid hardware identifiers.
Use coarse time bins for public data (e.g., day vs night), not exact timestamps.

Optional differential privacy

For broad heatmaps, add small noise to scores before publishing. Keep raw, non‑public data private. This balances utility and protection in sensitive areas like hospitals or schools.

From data to a useful map

Scales and symbology that explain themselves

Use a three‑band color scheme: green (smooth), yellow (moderate), red (rough). Keep it color‑blind friendly.
Include a confidence overlay or transparent hatch patterns where sample counts are low.
Show speed bumps and cobblestone flags with distinct icons, not as roughness.

Confidence and data freshness

Report a segment’s sample count, distinct trips, median score, and last observed date. Add warnings like “insufficient samples” where appropriate. Users will trust a map that admits uncertainty.

APIs and tiles

Serve vector tiles (e.g., MVT) with per‑segment attributes: score, confidence, flags, updated_at.
Consider PMTiles for simple hosting. It packs tiles into a single file for cheap distribution.
Offer a lightweight JSON API for single‑segment queries for apps that need just a few streets.

Validating that your scores mean something

Ground truth runs

Drive or ride the same route with multiple mounts and devices. Check that rankings stay similar.
Log known defects (e.g., a large pothole at km 2.3). Confirm event detectors find them consistently.
Compare with independent measures: a cheap wheel‑mounted accelerometer on a bike, or OBD‑II speed for better normalization in cars.

Metrics for events and segments

Potholes: Precision and recall against hand‑labeled events.
Roughness: Correlation with expert rankings, or mean absolute error vs a calibrated instrument, if available.
Stability: Test–retest consistency within a day and across days.

Model maintenance

Keep your thresholds adaptive. Devices vary by sensor noise. Calibrate simple scaling constants per device model using a small set of shared tracks. Store device “gain” in your server profile and update as more data arrives.

Publishing and collaborating without friction

Share the right level of detail

For the public: aggregated tiles with privacy guards. No raw traces.
For city partners: access to higher‑resolution segments, under a data‑sharing agreement.
For researchers: de‑identified datasets with tiles and summary statistics.

Explain your method in plain language

Publish a short method page: what you collect, how you score, and how you protect privacy. Include contact info for removal requests. Clarity builds trust.

Legal and data licensing

Pick a license that fits your goal. For public good, consider ODbL or a Creative Commons license for derived tiles.
If you contribute to OpenStreetMap, add verifiable notes rather than bulk edits. Encourage local mappers to confirm.

Hardware and budget tips

Mounts and accessories

Rigid mount: A simple handlebar mount for bikes or a dashboard clamp for cars reduces handling artifacts.
Power: A short cable to keep the phone charged on long trips.
OBD‑II (optional): BLE dongle for accurate vehicle speed, if you need it and have owner consent.

Device selection

Any recent phone works. Prefer models with sensor fusion APIs for linear acceleration to simplify gravity removal.
For a dedicated rig, consider a mid‑range Android with good battery and a matte screen for visibility.

Common pitfalls and simple fixes

Orientation drift: Use magnitude features. If you need direction, rely on gravity‑compensated axes.
Low speed bias: Below ~5 km/h, roughness signals blur into handling. Drop or down‑weight those samples.
Wet vs dry roads: Rain changes vibration. Include a binary “wet” flag using recent weather; calibrate separately if you can.
Device heterogeneity: Keep per‑model calibration factors. Use medians and percentiles to reduce sensitivity to outliers.
Over‑eager thresholds: Start conservative. It’s better to miss a few minor defects than to flood the map with false positives.

A lightweight architecture you can deploy

On‑device

Sensor capture, feature computation, and basic filtering.
Trip lifecycle: start, pause, resume, stop; auto‑pause on long stops.
Privacy steps: drop first/last meters, random ID rotation.

Server

Ingest via a simple HTTPS endpoint. Validate signatures and rate‑limit.
Processing: Map‑match tracks, aggregate features into segments or H3, compute scores and confidence.
Storage: Keep raw trip summaries (not full traces) and aggregated tiles with metadata.
Publish: Serve vector tiles and a small API for lookups.

Ops and monitoring

Track data volumes, average samples per segment, and fraction of points with poor GPS accuracy.
Watch for drift: per‑device feature distributions that shift after OS updates or model changes.
Set up a privacy audit: periodic checks to ensure start/end trimming and ID rotation work as intended.

Extending the system over time

Weather and seasonality

Add weather context from a public API. Freeze‑thaw cycles create seasonal potholes. You can annotate segments by season to help planners schedule repairs.

Mode detection

Auto‑detect transport mode (bike vs car vs bus) from speed, acceleration variance, and gyroscope patterns. Store the predicted mode and let users correct it. This improves calibration with minimal user effort.

Community feedback

Let users tap to confirm obvious defects after a trip. A small number of human confirmations can raise model precision a lot. Keep it optional and low friction.

Accessibility and inclusivity

Rough sidewalks affect wheelchair users and strollers. With user consent and careful design, you can adapt the pipeline for sidewalk mapping using walking‑speed data and different thresholds. Always test with community partners before publishing sensitive layers.

Putting it all together

Start simple: one phone, a rigid mount, and a short neighborhood route. Build the pipeline end to end for that route. Check that the map mirrors what you feel. Share a small, private tile set with a few trusted testers. Once the feedback is positive, expand coverage and invite contributions.

The payoff: crews get a clear queue of streets that feel worst to most travelers, not just the loudest complaints. Cyclists find smoother detours. Delivery companies pick faster routes. And you did it with tools you already have—guided by a few principled choices about signals, maps, and privacy.

Summary:

Use accelerometer, gyroscope, and GNSS to capture road vibration and location.
Compute orientation‑invariant features like acceleration magnitude, jerk, and spectral energy.
Map‑match and aggregate into segments or hexes; publish median scores with confidence.
Filter out speed bumps, cobblestones, and phone handling to avoid false positives.
Build a battery‑friendly app with clear trip controls and strong privacy defaults.
Validate with repeat runs, multiple mounts, and clear metrics for events and segments.
Publish vector tiles with simple symbology and guardrails like k‑anonymity.
Plan for device diversity, weather effects, and community feedback.