EtherDataEtherData
← Back to 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

The result is a planning-grade lens: we can quantify whether observed bike service is under-delivering relative to the people and constraints in each neighborhood cell.

Datasets and spatial framework

Spatial unit: H3 Resolution 8

We use H3 resolution 8 hexagons (average area about 0.737 km^2) to create a stable, comparable grid across Manhattan. H3 provides consistent adjacency, clean aggregation, and native compatibility with modern GIS pipelines.

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 -> more reliance on non-car modes)
  • public_transit_share (higher -> transit-oriented mobility; complements bikes as first/last-mile)
  • renter_share and rent_burden (higher -> tighter budgets and higher sensitivity to mobility cost)
  • wfh_share (lower -> 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)

service_gap_score = mobility_need_index - service_index_core

  • 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.

The value is operational:

  • 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.

References