Mobility Research

Campus Mobility Study

Studying the composition and movement patterns of the UC Davis shared-mobility fleet — scooters, e-bikes, and campus transit

Data window: April 7–9, 2026 Platform: TowerWatch Scope: UC Davis Campus

Executive Summary

This study characterizes the UC Davis campus shared-mobility fleet — what it is made of, and how it moves through the day. By resolving persistent vehicle identities, we built a study registry of 538 vehicles and tracked their observed presence across campus, complemented by campus transit position data. The result is a longitudinal view of micromobility composition and movement patterns.

538
Vehicles in Registry
686
GBFS-Visible Fleet
13.3M
Presence Observations
91
H3 Cells (res 9)
474
Scooters (nbmax23)
64
E-bikes
Key takeaway: Resolving persistent vehicle identities lets us follow individual vehicles over time, turning a fleet that otherwise presents as anonymous per-poll snapshots into a longitudinal mobility dataset. Combined with spatial aggregation, this reveals where the fleet stages and how activity rises and falls across the hours of the day.

Why Longitudinal Tracking Is Hard

The General Bikeshare Feed Specification (GBFS) is the public, standardized feed for shared-mobility fleets. It is designed for availability snapshots, not for following individual vehicles over time. Each time a client polls the free_bike_status.json endpoint, vehicle IDs are rotated, so the same physical vehicle appears under a new identifier on every poll.

What GBFS provides per poll:

  • Temporary bike_id — rotated every poll cycle
  • GPS coordinates (current, but not linkable across polls)
  • Battery level (current, but not linkable)
  • Vehicle type (generic, e.g., "scooter")

On the UC Davis campus, GBFS shows roughly 686 vehicles on any given poll. Because identifiers rotate, a vehicle cannot be followed from one poll to the next using the public feed alone. To study movement patterns over hours and days, this study needed a stable, persistent identity for each vehicle.

The research question for the data-collection stage was therefore: how do we resolve a persistent identity for each vehicle so that observations can be linked into a longitudinal record?

Assembling the Study Dataset

Building the study registry from zero persistent identities to 538 catalogued vehicles unfolded over several phases, each refining the data-collection method and adding coverage.

Phase Method Vehicles Found Cumulative Time
1 GBFS observation 0 (rotating IDs) 0 Ongoing
2 QR code sampling 19 19 3 hours
3 Barcode lookup (broad range) 7 26 4 hours
4 IMEI lookup (TAC ranges) 3 29 2 hours
5 Serial-based resolution V1 +271 300 82 min
6 Serial V2–V4 (expanded ranges) +140 440 48 min
7 Multi-host collection +98 538 45 min

Data-Access Method — the /scan Endpoint

To resolve a persistent vehicle identity, the study used the /scan endpoint, which maps a physical vehicle identifier to its underlying vehicle record. Submitting a known identifier returns the stable vehicle record, which is what enables observations to be linked into a longitudinal series.

Why /scan is the useful data-access path:

  • Accepts 4 identifier types: barcode, IMEI, serial_number, sticker_id
  • Serial numbers are structured and sequential within manufacturing batches, which makes coverage tractable
  • Returns the persistent bird_id UUID — the stable identity key the study links on
  • Returns current GPS, battery, model, IMEI, fleet assignment
  • Resolving these identities is what let us assemble a longitudinal movement record

The serial number format follows a predictable hardware pattern:

// Serial number format "A1S0C2117C0378" │ │ │ │ │ │ │ │ │ └── unit (0378) — sequential within batch │ │ │ └───── separator (C) │ │ └────────── batch (2117) — manufacturing batch │ └───────────── variant (0C) — hardware variant └──────────────── maker (A1S) — manufacturer code

Request / Response:

POST /scan Authorization: Bearer [rider_jwt_token] Content-Type: application/json { "serial_number": "A1S0C2117C0378", "mode": "rider" }
// Response (sample) { "bird_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "code": "8KL9M2Z", "serial_number": "A1S0C2117C0378", "imei": "861234567890123", "model": "nbmax23", "vehicle_class": "scooter", "fleet_id": "davis-ca", "location": { "latitude": 38.5382, "longitude": -121.7617 }, "battery_level": 72, "locked": false, "born_at": "2024-03-15T08:22:00Z" }
How the study uses this: The bird_id returned here is the stable key. By resolving it once per vehicle and recording it in the study registry, subsequent observations can be attributed to the same physical vehicle — the prerequisite for the longitudinal movement analysis later in this report.

Data-Source Comparison

Different feeds expose different data, and they differ most in whether the vehicle identifier is persistent or rotating — the property that determines whether a feed can support longitudinal analysis.

The /nearby feed returns session-scoped identifiers (different IDs, codes, models, and battery ranges per session token), with only the position and approximate battery reflecting the underlying vehicle. GBFS feeds rotate all identifiers per poll. Neither lets you follow a specific vehicle over time.

The /scan path is the one that returns a persistent identity, which is why it anchors the study dataset.

Data Source Vehicle IDs GPS Battery Model IMEI Persistent?
/nearby Session-scoped Current Approx Session-scoped N/A No
GBFS feeds Rotated Current Current Generic N/A No
/scan Persistent Current Current Specific Specific Yes

Identifier Structure

Vehicle serial numbers follow a structured format that encodes manufacturing batch, hardware variant, and sequential unit number. Understanding this structure let the study cover the fleet efficiently and reason about its composition.

A1SMaker
0CVariant
2117Batch
CSep
0378Unit
Segment Values Found Meaning
Maker A1S, A1B, N4Z, A0S A1S = scooters, A1B = e-bikes, N4Z = alt scooters, A0S = nbs90l model
Variant 0A0F, 4A4F, 5B, WE, 01 Hardware revision / radio configuration
Batch 20402150+ Manufacturing batch (Davis fleet: 2047–2135)
Separator C Fixed delimiter
Unit 00010600 Sequential unit within batch (variable max)

Distribution of identified vehicles across manufacturing batches:

Collection Efficiency

Using the structured serial format was about 1,667× more efficient than a barcode-based approach, turning what would have been a multi-day collection into an 82-minute run.

~10 days
Barcode Lookup
9,000,000 candidates · 0.004% hit rate
~3 days
IMEI Lookup
1,400,000 candidates · 1.9% hit rate
82 min
Serial-Based Lookup
16,200 candidates · 10% hit rate
Why it works: Barcodes are random 7-digit codes (10M possible). IMEIs have a known TAC prefix but 7 random digits (10M per TAC). Serial numbers are structured: ~15 maker+variant combos × ~100 batches × ~600 units = ~900,000 total, and a real fleet clusters in a narrow batch range, reducing the effective candidate space to ~16,200.

Collection Throughput by Network

Sustained data-collection throughput varied by the network the request originated from. Mobile carrier networks supported the highest sustained throughput; datacenter networks the lowest. The study used this to schedule collection across the available hosts.

Network Type Sustained Throughput Stability Notes
Mobile Cellular ~50 req/s High Best throughput observed
University Ethernet ~10 req/s Moderate Steady, sustained
Residential ISP ~8 req/s Moderate Occasional slowdowns
Datacenter ~3 req/s Low Lowest sustained throughput
Takeaway: Throughput is network-dependent rather than account-dependent. Distributing collection across host networks let the study assemble the registry within the data window.

Data-Collection Architecture

Seven hosts across five network types ran in parallel, with results merged via shared storage and HTTP file servers into a single study registry.

Local Mac
UC Davis Ethernet
Primary coordinator
~10 req/s sustained
Old Mac
Mobile Cellular
Highest throughput
~50 req/s sustained
Windows VM
Residential Broadband
Steady contributor
~8 req/s
Codespace #1
Azure (West US 2)
Throttled but functional
~3 req/s
Codespace #2
Azure (West US 2)
Throttled but functional
~3 req/s
Deepnote
Cloud (GCP)
Supplementary
~5 req/s
Merge Controller
Local Mac
Dedup + reconcile
OneDrive / iCloud / HTTP sync
Sync pattern: Each host writes resolved vehicles to a local JSON file. Files sync via OneDrive, iCloud, and HTTP file servers (python3 -m http.server). The merge controller on the local Mac deduplicates by bird_id UUID and produces the canonical study registry.

Fleet Composition

The UC Davis campus shared-mobility fleet consists primarily of scooters (nbmax23 model) with a smaller contingent of e-bikes.

Scooters (nbmax23) 474
E-bikes (nba80) 64
Unidentified 148

Total GBFS-visible fleet: 686 vehicles

Fields Available Per Vehicle

Each resolved vehicle contributes the following fields to the study dataset. The persistent bird_id is the key that links repeated observations of the same vehicle into a time series.

Bird ID (UUID)
f47ac10b-58cc-4372-a567-0e02b2c3d479
Barcode
8KL9M2Z
Serial Number
A1S0C2117C0378
IMEI
861234567890123
Model
nbmax23
Fleet ID
davis-ca
GPS Position
38.5382, -121.7617
Battery Level
72%
Locked Status
false (available)
Vehicle Class
scooter
Born At
2024-03-15T08:22:00Z
Persistent Key
bird_id (stable across observations)
Analytical value: Because the bird_id is stable, repeated position observations of the same vehicle can be aggregated over time. The spatial analysis below uses this to measure where vehicles in the study set are present, by hour of day.

Spatial Movement Analysis

We aggregated the persistent, /scan-tracked observations spatially using the H3 hierarchical grid (resolution 9) over the data window of April 7–9, 2026 (~2 days). The result measures observed presence density — where vehicles in the study set are located, by hour of day. It is not trip origin–destination data: it reflects where vehicles dwell and stage, not where riders begin or end trips.

13,260,609
Persistent Observations
91
Distinct H3 Cells (res 9)
64,539
Unitrans Transit Positions

A live CARTO layer was produced from this aggregation — spin_density_hourly (H3 density × local hour-of-day) — served at /api/simcity/carto_layers/spin_density_hourly.geojson.

Activity by Hour of Day

Observed presence density summed across all cells, by local hour (0–23). Activity is broadly distributed across the day with peaks in the mid-afternoon and evening windows.

Busiest Staging Cells

The H3 cells with the highest observed presence, with distinct vehicles seen in each. These are the dominant staging and dwell locations in the study window.

H3 Cell (res 9) Observations Distinct Vehicles
892832b6097ffff485,2332,642
892832b65d7ffff471,9432,567
892832b659bffff420,7992,279
892832b655bffff412,3422,239
892832b6083ffff411,7502,228
892832b65c3ffff406,1182,207
Transit complement: Alongside the micromobility data, the study set includes 64,539 Unitrans transit vehicle position records (the campus bus fleet), providing a complementary view of campus movement to set against the scooter and e-bike presence density.

Registry vs. GBFS-Visible Fleet

Gold markers represent vehicles in the study registry (with a resolved persistent identity). Gray markers represent vehicles visible in GBFS but not yet linked to a persistent identity.

-- Identified -- Unidentified

Study Notes & Limitations

  1. Short observation window.
    The spatial analysis covers roughly two days (April 7–9, 2026). Hour-of-day patterns should be read as a snapshot of that window, not a long-run seasonal average. Weekday/weekend and term-calendar effects are not separated.
  2. Presence density, not trip origin–destination.
    The H3 aggregation measures where vehicles are observed to be present, by hour. It does not identify trip starts, trip ends, or routes. Busy cells indicate staging and dwell locations, not necessarily high ridership demand.
  3. Counts are observations, not unique trips.
    The 13,260,609 figure counts position observations across the window. A single stationary vehicle contributes many observations, so per-cell observation totals reflect dwell time as much as vehicle volume; the distinct-vehicle counts are reported alongside to disambiguate.
  4. Coverage is partial.
    The study registry holds 538 vehicles against a GBFS-visible fleet of roughly 686. Vehicles without a resolved persistent identity are not represented in the spatial analysis.