Data sources

The model is organized around types of evidence, not New York-specific products. A different city can replace each source with a local equivalent as long as it supplies the same identifiers, geography, and behavioral meaning. The links below show the New York datasets used by this deployment. Links for API-backed sources point to human-facing catalog or program pages, where the download and API options are documented, rather than to raw API requests.

flowchart TD
  transit[Transit supply and operations] --> service[Service and physical travel times]
  geography[Population and geography] --> demand[Person-trip demand]
  activity[Jobs, land use, schools, and travel survey] --> demand
  streets[Pedestrian network] --> access[Station access and egress]
  service --> outputs[J and Compare]
  demand --> outputs
  access --> outputs
  basemap[Basemap tiles] -. presentation only .-> website[Website]
  outputs --> website

This page catalogs inputs to the published model and map. Intermediate artifacts such as routed travel times, destination probabilities, and station demand are derived products, not additional sources. Candidate lines and infrastructure edits are user-authored scenarios. A disconnected live-feed diagnostic also exists in the repository, but live data are not an input to the published model.

Transit supply and observations

Generic input	What the model needs	What it supports	New York example
Static transit schedule	Stops, routes, trips, ordered stop times, transfers, route colors, and stable stop identifiers	Scheduled line patterns, platform coordinates, transfer walks, and display metadata	MTA developer resources, under Static GTFS data
Historical vehicle or stop-event archive	Dated trip identifiers and ordered observed arrival/departure events at stops	Observed segment running times, wait distributions, reroutes, and evidence for the physical graph	Subway Data NYC — explore the data
Station and interchange reference	A stable station-complex identifier, member platform/stop identifiers, names, and coordinates	Joins schedule stops, observed ridership, pedestrian access, and UI stations into one station-complex system	MTA Subway Stations and Complexes
Observed station origin–destination demand	Origin complex, destination complex, time bucket, date/day type, and estimated trip volume	The baseline station OD matrix, calibration of modeled subway trips, and demand-weighted evaluation	MTA estimates for 2021, 2022, 2023, 2024, and 2025
Service-corridor geometry	A route or service identifier and its named corridor geometry	Corridor identity where multiple services share infrastructure; this is used by track-capacity accounting	MTA Subway Service Lines

The static schedule describes intended service, while the event archive describes what actually ran. They are not interchangeable. In particular, observed events supply travel-time and wait evidence; the current static feed supplies canonical stop patterns and transfer definitions.

Population and statistical geography

Generic input	What the model needs	What it supports	New York example
Small-area boundary geometry	Polygon geometry and stable geographic identifiers for a consistent census vintage	The tract spine, spatial joins, map geometry, and origins/destinations for demand	2020 TIGER/Line shapefiles
Complete population and housing counts	Resident population, housing units, occupancy, and the same geographic identifiers	Population totals and the base from which household and trip production are estimated	2020 Census P.L. 94-171 data
Small-area socioeconomic estimates	Household, income, vehicle-availability, age, and related estimates with margins of error	Socioeconomic trip-production features and the no-vehicle share used by mode choice	American Community Survey data
Home-to-work flows	Home geography, work geography, primary-job count, and worker/job categories	Work destinations and workplace attraction totals; these are job flows, not transit trips	LEHD Origin-Destination Employment Statistics

The New York build holds census geographic identifiers as strings and uses a consistent 2020 geography for these joins. Another deployment need not use census tracts, but it does need a stable small-area unit shared by population, activity, access, and demand.

Urban activity and destinations

Generic input	What the model needs	What it supports	New York example
Parcel or land-use inventory	Parcel identifier, land-use category, units, and residential/non-residential floor area	Tract-level residential, commercial, institutional, industrial, and other destination activity	MapPLUTO
Building footprints	Building geometry plus parcel/building identifiers where available	Allocation of parcel activity to buildings and preservation of unmatched building activity	NYC Building Footprints
School locations	Stable school identifier, coordinates, and school type or grade span	Candidate school destinations	NYC public-school locations
School enrollment or capacity	School identifier, year, enrollment, and capacity	Relative attraction weights among school destinations	Enrollment, Capacity and Utilization Reports

Land use and buildings are physical activity indicators, not observed trips. They help allocate destination attraction after trip totals have been estimated. Schools are kept separately because school trips have a specialized destination set rather than the general land-use attraction model.

Travel behavior

Generic input	What the model needs	What it supports	New York example
Household travel survey	Linked household, person, diary-day, trip, and survey-zone records; expansion weights; trip purpose, time, mode, origin/destination, and distance	Trip-production rates by purpose and period, intracity distance priors, and descriptive mode-choice inputs	NYC DOT Citywide Mobility Survey, which links the public tables and documentation

The survey estimates person-trip behavior. It does not replace observed station OD ridership: the survey builds the citywide trip market, while the transit OD source calibrates the share and station pairs observed on the transit system.

Pedestrian access

Generic input	What the model needs	What it supports	New York example
Routable pedestrian street graph	Walkable nodes and directed edges with lengths, including bridges and other real network connections	Walk times from neighborhood sample points to station candidates and from stations to destinations	OpenStreetMap; data are queried through the Overpass ecosystem by OSMnx

Straight-line distance is not enough for station access: barriers, crossings, bridges, and the street layout determine which stations are plausible. The current model routes on the pedestrian graph, then retains the nearest five station complexes inside its access fringe.

Presentation-only map data

Generic input	Role	New York example
Reference basemap	Provides labels, streets, water, and geographic context behind the modeled layers; it never enters J, demand, routing, or Compare	CARTO basemaps, built from sources including OpenStreetMap

Map tiles are fetched by the browser and are deliberately outside the analytical pipeline. Hiding the basemap or changing its visual theme cannot change any model result.

Local modeling inputs

Two inputs are maintained with the model rather than downloaded from an external catalog:

• Physical-topology overrides describe connections that station-to-station observations and a service schedule cannot represent unambiguously, such as explicit track sharing or junctions.
• Candidate service plans contain ordered stops and period-specific frequencies for the service being evaluated.

These are transparent modeling assumptions, not measurements. They should be reviewed separately from source freshness and licensing when adapting the project to another city.

Snapshot and provenance policy

Downloaded sources first land as immutable bronze snapshots. Where the provider permits it, the pipeline records the source URL, retrieval time, byte size, and checksum before building any model artifact. This matters because several catalog pages expose live datasets: rerunning an API query later may otherwise return a different revision under the same dataset identifier.

For a reproducible deployment, record at least:

1. the provider and human-facing dataset page;
2. the dataset identifier, release or observation dates, and geographic vintage;
3. the exact request or downloaded file in machine-readable provenance;
4. the retrieval timestamp and checksum; and
5. the license or attribution requirements.

The documentation links above are for discovery and interpretation. The pinned bronze provenance, not the current contents of a live catalog page, defines the exact data used by a particular build.