Spatial unit: H3 Resolution 8
We use H3 resolution 8 hexagons (average area about ) to create a stable, comparable grid across Manhattan. H3 provides consistent adjacency, clean aggregation, and native compatibility with modern GIS pipelines.
All use cases
Use case
Bike-Share Equity & Mobility Need (Manhattan Demo) - Powered by EtherData's Canonical US Census at H3 Resolution 8
Etherdata.ai makes spatial data trustworthy and usable for every team. We publish open, rigorous, deeply usable datasets that make decision-making fairer and faster.
This page is the first of our free starter queries, built on a free New York sample of our flagship product: the Canonical, Complete US Census Dataset at H3 Resolution 8.
This demo answers a practical question cities, operators, and planners ask constantly: Where is bike-share service aligned with resident mobility needs - and where is it not?
Focus
Equity-first bike-share planning
Geography
Manhattan, New York (H3 R8)
Spatial unit
Canonical H3 grid with census + trips
Output
Need, service, and service gap scores
Why Census is the Backbone (and trips alone are not enough)
Bike trips are an outcome. They reflect where stations exist, where commuters and tourists concentrate, weather, pricing, and operational decisions. If you only map trips, you mostly map the operator's supply footprint and the city's activity hotspots - not resident mobility need.
Census transforms bike-share analysis from "what happened" to "what should happen" by providing:
- Denominators (population, households, workers) to convert counts into comparable rates
- Structural constraints (car ownership, renter share, rent burden) that shape real transportation choices
- Commuting context (public transit share, walk share, work-from-home) to separate commuter/tourist effects from resident mobility
Planning lens
Where delivered service lags neighborhood reality.
Quantify whether observed bike service is under-delivering relative to the people and constraints in each neighborhood cell.
Datasets and spatial framework
Geographic scope: Manhattan (New York County)
We retrieve Manhattan's county geometry, polyfill it into H3 R8 cells, then use membership joins so every metric aligns to the same spatial support. This avoids centroid-in-polygon errors and keeps all joins deterministic and reproducible.
Data sources (BigQuery)
- Citi Bike trips: start station point events aggregated into H3 R8
- Citi Bike stations: supply proxy (stations + dock capacity) aggregated into H3 R8
- Etherdata canonical census (H3 R8): demographic, housing, and commuting variables keyed to the same H3 cells
Methodology (How census converts raw trips into decision signals)
1
Define the analysis grid (H3 R8 Manhattan)
- Load Manhattan polygon
- Polyfill to H3 R8
- Use that H3 list as the authoritative domain for joins
2
Aggregate trips into the grid (observed usage)
Trips are aggregated by the H3 cell of the start station. We compute counts and behavioral slices (subscriber share, weekend share, average duration) to separate commuting-like usage from leisure-like usage.
3
Aggregate station supply into the grid (service capacity)
Stations and dock capacity are aggregated into H3 cells. This is a service proxy: it is not perfect, but it captures where supply exists and its potential throughput.
4
Roll up census into the grid (structural demand)
This is the core value proposition: Etherdata's canonical census layer provides consistent, H3-keyed demographic and mobility variables. We roll them safely (sums for counts, weighted rollups for income/rent) to ensure one row per H3 cell.
5
Create indices that support planning decisions
Mobility Need Index (census-driven)
A composite indicator designed to approximate structural need for shared mobility using census variables:
- no_car_rate (higher values mean more reliance on non-car modes)
- public_transit_share (higher values mean stronger transit-oriented mobility and more first/last-mile relevance for bikes)
- renter_share and rent_burden (higher values mean tighter budgets and higher sensitivity to mobility cost)
- wfh_share (lower values mean more commute pressure)
Key point: this index is intentionally independent of bike usage. It is a census-only "need surface."
Service Index Core (service supply + utilization)
A composite "delivered service" indicator using:
- docks (supply)
- trips_per_dock (utilization)
Service Gap Score (the planning output)
- Positive: under-served (need exceeds service)
- ~0: balanced
- Negative: well-served or over-served relative to resident need (often tourism/CBD effects)
- NULL: non-comparable cell (typically too few households/workers, parks, water edges)
Results & Interpretation (What each chart means)
Mobility Need Index
This map answers: Where do resident and commuter demographics imply high dependence on shared mobility? It is a census-driven layer and should not be interpreted as bike demand.
Need vs Service
This scatter tests whether the system is allocating service where need is highest.
Mobility Need vs Observed Bike Usage
This chart asks: Does observed usage increase with structural mobility need?
Service Gap Score
This is the planning output: a spatially explicit measure of mismatch between census-defined need and delivered bike service.
What we can conclude (and what we cannot)
Conclusions we can support
- Census materially changes the story. Trips show operations; census shows structural exposure and constraints.
- Need is stable and portable. The need surface is not the same as downtown intensity, which is why it generalizes.
- Service alignment is measurable. Need vs service dispersion indicates where equity and infrastructure questions should be investigated.
- Gap mapping is actionable. Service gap highlights priority cells for expansion, pricing programs, or safety/connectivity improvements.
What we cannot conclude from these data alone
- We cannot claim causality (need causes rides) without controls (bike lanes, safety, land use, tourism, pricing, events).
- We cannot measure latent demand directly; we infer it from mismatch between census need and observed service.
- Negative gap values are not bad-they often reflect non-residential demand.
Why Etherdata's canonical census at H3 R8 is the enabler
This demo is intentionally simple from a modeling standpoint because the product being demonstrated is the data layer: a canonical, complete census surface at H3 R8.
Why it matters
- Deterministic joins (same H3 key across all datasets)
- Consistent denominators to convert counts into comparable rates
- Auditability (every metric traces to a known census field)
- Portability (the same query pattern generalizes across cities and states)
In practice, this means a data scientist or analyst can move from raw events to equity-aware service planning in minutes, without rebuilding geography pipelines or fighting inconsistent tract joins.
Overall Summary
If you only look at trips, Manhattan mostly looks like midtown and downtown win. With Etherdata's canonical H3 census layer, you can ask a more rigorous question: Is the system delivering mobility utility where resident constraints and exposures imply higher need?
This demo shows how the census layer turns operational bike data into a planning instrument:
- A stable need surface (census-driven)
- A measurable service surface (supply + utilization)
- A single actionable output: service gap score
That is the core of trustworthy spatial decision-making: measurable, auditable, and portable.