Skip to content
#edge computing Dataset Open access

High-resolution multi-modal accessibility metrics for Switzerland

Oct 2026 · Zenodo (CERN European Organization for Nuclear Research)
Urban Transport and Accessibility

Abstract

Per-cell accessibility metrics for Switzerland at approx. 100m resolution (H3 grid, resolution 10), computed in a time-based domain (gross travel time in seconds, including origin- and destination-side overheads), a utility-based domain (disutility from a fitted mode-choice discrete-choice model), and using straight-line distances (euclidean metres, mode-agnostic). All domains apply to all three metric families provided: cumulative opportunities, nearest-k, and exponential gravity. Produced using aperta via the aperta-atlas pipeline. Travel costs Accessibilities are reported based on Euclidean distance, travel time, and generalized travel costs (utility). Each cost type is affected by different aspects: Cost domain Spatial distribution Network topology Urban characteristics Personal preferences Distance (Euclidean) +++ o o o Time (gross, door-to-door) +++ +++ + o Utility (population-weighted) +++ +++ +++ o‡ ‡ Utility values are aggregated across a representative population's sociodemographic characteristics (age, sex, income bins, etc.). Vehicle ownership is modeled to be endogeneous (part of trip-based utility per mode). The accessibility pipeline supports deriving person-specific utilities, but only the population-aggregate values are shipped here. Modes and profiles All of the following modes and mode-specific profiles are included for time-based accessibility. Those marked with an "X" under "Utility" are also incldued as population-weighted utility-based accessibilities. Mode Profile ID Description Utility Walk rwalk Average pedestrian X Walk walk_prm Person with reduced mobility† Bike rbike Regular bicycle X Bike ebike25 E-bike, 25 km/h class (pedelec) Bike ebike45 E-bike, 45 km/h class (s-pedelec) Car car_night Late-evening / night traffic X Car car_base Baseline daytime hours X Car car_peak Peak traffic hours (Mon–Fri, 7:30–8:30 and 15:30–18:30) X Transit transit Swiss NPVM zone-to-zone times + per-cell transit access correction‡ X † Slower baseline than average pedestrian, higher slope penalty, max. 20% grade, and hard-exclusion of steps‡ More precise public transit accessibilities are planned for a future version of this dataset. Usage All accessibility CSVs are indexed by Uber H3 res-10 cell ID. If you're already working with H3 grids, join directly. Otherwise the bundled cells_aoi.gpkg provides one geometry per cell ID in EPSG:2056 (LV95) — use it as a join layer in QGIS (Properties → Joins) or as a merge target in Python (gpd.read_file('cells_aoi.gpkg').merge(csv, on='cell_id')). Calibration Route-cost weights, per-cell overheads, and utility coefficients are fitted against real ground truth, not chosen heuristically: Swiss travel-survey (National Household Travel Survey / MTMC and MOBIS) trips → per-edge weight calibration for walk, bike, and each car profile MTMC survey legs → biogeme MNL utility coefficients (including sociodemographic covariates) and per-cell overhead coefficients Traffic counter observations → validation of estimated car traffic flows that feed the peak/base/night car profiles Post-calibration, per-mode edge weights reach far superior correlation against observed/reported travel times all modes and trip-distance bands compared to using raw OSM data — see the companion transport-network dataset (section: "Calibration effectiveness") for more details. Coverage Accessibility values are computed per H3 res-10 cell (roughly hectare-scale) for all cells inside Switzerland that snap to every active transport network (walk, bike, car). Destinations include both cells and zones that successfully snap to the given mode, so accessibility from cells near the border correctly reflects cross-border trips into neighbouring countries. Networks and destinations extend across the Swiss border by mode-specific buffers (walk 5 km / bike 25 km / car 50 km). Destinations Per-cell accessibility is provided to: Group Columns Population population_total Employment employment_primary, employment_secondary, employment_tertiary, employment_total POI categories Errands: poi_errands_groceries, poi_errands_servicesHealthcare: poi_healthcareEducation: poi_education_preschool, poi_education_school, poi_education_higherLeisure: poi_leisure_gastronomy, poi_leisure_amenity, poi_leisure_hiking, poi_leisure_sportsTourism: poi_tourism Transit stops mobility_transit (all stops), mobility_transit_train (train stations) POI categories and transit stops are sourced from OpenStreetMap (2026 extract), grouped into the categories listed above (see aperta-atlas). Population and employment counts come from the publicly released hectare-cell versions of STATPOP (2021) and STATENT (2020) published by the Swiss Federal Statistical Office (BFS). Hectare totals are dasymetrically redistributed to individual OSM buildings and re-aggregated to the H3 hex cells. For cells and destinations outside the Swiss border (relevant for cross-border accessibility from cells near the frontier), per-building population and employment are extrapolated using the same dasymetric mapping coefficients fitted inside Switzerland. Cross-border accessibility therefore reflects realistic destination density even where no BFS-equivalent ground truth exists. Metric families and parameters Cumulative opportunities: e.g. "the number of destinations of a given type between 5 and 10 minutes away". For time-based costs, bin edges at 0, 5, 10, 15, 30, 60 minutes (five half-open bins per destination); for distance-based costs, bin edges at 0, 300, 1000, 3000, 10000, 30000 metres (five bins). Not currently implemented for utility-based costs. You can form combined bins by building a sum (e.g. 0–10 min = 0–5 min + 5–10 min). Nearest-k: e.g. "the average time it takes to get to the nearest 3 supermarkets". k ∈ {1, 3, 10, 30, 100}. Population and employment destinations are scaled by 1/100 before the k lookup, so k=1 for a population column means "time to reach the nearest 100 people" (and k=100 means the nearest 10,000). POI and transit-stop destinations use unit weights — k=1 is literally the nearest one. Note that a single transit stop can consist of multiple individual POIs; this is currently not addressed/consolidated. Implemented for distance-, time-, and utility-based costs. Exponential gravity: each destination is weighted using an exponential decay function based on how far away it is. Time-based (with half-decay times of 5, 10, 15, 20, 30 minutes, β = ln(2) / (m · 60)) and distance-based costs (half-decay distances of 300, 1000, 3000, 10000, 30000 metres; β = ln(2) / m), the reported value is the raw Hansen index Σ w_j · exp(-β · cost): larger = more accessible, 0 = no destinations reachable. For utility-based (with decay coefficients of 0.5, 0.8, 1.0, 1.5, and 2.0), the reported value is log(Σ w_j · exp(-β · D)); at β = 1 this equals the (mode-specific) weighted accessibility logsum in native utility units. Companion dataset — calibrated transport networks The prepared walk / bike / car networks (nodes, edges, and per-edge calibrated durations) used to compute these metrics are published as a separate record under the Open Database License (ODbL): 10.5281/zenodo.21410968. Methodology and reproduction Produced with the aperta accessibility library (path-first, cross-modal routing) via the aperta-atlas pipeline (Swiss instantiation, scenario switzerland-default). Both repositories document the full method and allow re-computation on updated inputs. Attribution Accessibility metrics are released under CC BY 4.0. The upstream OpenStreetMap network data is © OpenStreetMap contributors, available under the Open Database License; see https://www.openstreetmap.org/copyright.

View source

Similar papers

#computer vision Review Sep 2017

Agile Software Development Methods: Review and Analysis

This publication proposes a definition and a classification of agile software development approaches and analyses ten software development methods that can be characterized as being "agile" against the defined criterion.

P. Abrahamsson, O. Salo, Jussi Ronkainen et al. · 727 citations · ⚡54
#computer vision Jun 2008

The impact of agile practices on communication in software development

The study shows that agile practices improve both informal and formal communication, but indicates that, in larger development situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder the communication.

M. Pikkarainen, Jukka Haikara, O. Salo et al. · 401 citations · ⚡48
#machine learning Review Open access Oct 2014

Software development in startup companies: A systematic mapping study

The results indicate that software engineering work practices are chosen opportunistically, adapted and configured to provide value under the constrains imposed by the startup context.

Nicolò Paternoster, Carmine Giardino, M. Unterkalmsteiner et al. · 394 citations · ⚡54

Related blog posts

Microsoft Research Blog Oct 6, 2026

What AI gets wrong and what failure teaches us

Jennifer Neville did not want to go into computer science—but that’s exactly where she landed. Neville discusses the starts and stops that led to her professional sweet spot and her work identifying “surprising failures” making it hard for AI to handle complexity.  The post What AI gets wrong and what failure teaches us appeared first on Microsoft Research.

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.