Update to GeoAI Skills

{
  "name": "network-accessibility-analysis",
  "description": "Always invoke for access to facilities or opportunities by walking, driving, cycling, or public transport, even for a conceptual question with no routing terms or data yet. Covers hospital and service access, transit/GTFS, routes, isochrones, OD matrices, closest facility, 2SFCA, walkability, coverage, and equity. Invoke when Euclidean buffers proxy for network access. Use movement-trajectory for observed tracks and MCDA for suitability without network costs.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 237
    },
    {
      "relative_path": "references/authoritative-sources.md",
      "size_in_bytes": 755
    }
  ],
  "skill_md_contents": "---\nname: network-accessibility-analysis\ndescription: >-\n  Always invoke for access to facilities or opportunities by walking,\n  driving, cycling, or public transport, even for a conceptual question with\n  no routing terms or data yet. Covers hospital and service access,\n  transit/GTFS, routes, isochrones, OD matrices, closest facility, 2SFCA,\n  walkability, coverage, and equity. Invoke when Euclidean buffers proxy for\n  network access. Use movement-trajectory for observed tracks and MCDA for\n  suitability without network costs.\nlicense: MIT\nmetadata:\n  author: Muhammed Enes Duran\n---\n\n# Network & Accessibility Analysis\n\nPurpose: replace as-the-crow-flies guesswork with network-true travel\ncosts, at the right scale and with honest assumptions about speeds and\nmodes. First decision on every task: Euclidean distance is only acceptable\nas a declared approximation — flag it whenever you see it standing in for\naccess.\n\n## Tool selection by scale\n\n| Scale | Tool |\n|---|---|\n| Neighborhood-city, research flexibility | **OSMnx + NetworkX** |\n| City-region, many-to-many OD (>10⁴×10⁴) | **r5py** (multimodal + transit w/ GTFS) or **pandana** (contraction-hierarchy speed) |\n| Production routing service | Valhalla / OSRM / OpenRouteService API |\n| Proprietary stacks | ArcGIS Network Analyst (script it headlessly) |\n\nNetworkX chokes on metro-scale many-to-many — don't loop `shortest_path`\nover thousands of origins; switch tools instead.\n\n## Graph construction (OSMnx)\n\n```python\nimport osmnx as ox\n\nG = ox.graph_from_place(\"City, Country\", network_type=\"drive\")  # walk/bike/all\nG = ox.add_edge_speeds(G)          # imputes from highway tags where maxspeed missing\nG = ox.add_edge_travel_times(G)    # edge attr: travel_time (s)\nG = ox.project_graph(G)            # metric CRS before any distance work\n```\n\n- **network_type matters**: pedestrian analysis on a `drive` graph misses\n  paths, stairs, plazas; driving on `all` uses footpaths. Match mode.\n- Imputed speeds are averages by road class — a systematic bias, not\n  noise. State it; calibrate against known trips when stakes are high.\n- Keep the strongly connected component for routing\n  (`ox.truncate.largest_component(G, strongly=True)`); orphan islands\n  cause spurious infinities.\n- **Snapping**: origins/destinations map to nearest nodes/edges\n  (`ox.distance.nearest_nodes`). Report the snap-distance distribution;\n  a facility snapped 2 km away (riverside, gated area) silently corrupts\n  results.\n\n## Core products\n\n- **Isochrones / service areas**: ego-graph by travel_time cutoff → alpha\n  shape or buffered edge union around reached edges. Node-based convex\n  hulls overstate coverage across rivers/highways — prefer edge-based\n  polygons. Always label the assumptions: mode, speed model, cutoff.\n- **OD matrix**: many-to-many travel costs; the substrate for\n  accessibility and location-allocation. For big matrices use\n  pandana/r5py; store as Parquet with origin/destination IDs.\n- **Closest facility**: k-nearest by network cost (not Euclidean); report\n  both the assigned facility and the cost.\n- **Centrality**: betweenness on travel_time (sampled `k` for big\n  graphs — exact is O(nm)); edge betweenness ≈ through-traffic potential.\n  Interpret as network structure, not observed traffic.\n\n## Accessibility metrics — pick deliberately\n\n| Metric | Question it answers | Weakness |\n|---|---|---|\n| Cumulative opportunities (# jobs/POIs within T min) | Simple, communicable | Cliff at T; all-or-nothing |\n| Gravity-based (distance-decayed sum) | Smooth access | Decay parameter must be justified |\n| **2SFCA / E2SFCA** | Supply-demand ratio access (health care standard) | Catchment size choice drives results |\n| Closest-facility time | Worst-case need | Ignores capacity/congestion |\n\nFor equity analyses, join metrics to population/demographic polygons\n(area-weighted or dasymetric — see `geo-data-engineering`) and report\ndistributions per group, not just city means. Route statistical testing of\ndisparities to `spatial-statistics`.\n\n## Location-allocation\n\nOptimal siting (p-median, max-coverage) on the OD matrix: formulate with\nPuLP/OR-Tools; inputs are the OD matrix + demand weights + candidate\nsites. State the objective explicitly — minimize mean travel time\n(p-median) vs maximize covered demand within T (max-coverage) give\ndifferent answers, and stakeholders rarely know which they asked for.\nFeed results back to `mcda-suitability-analysis` when siting mixes network\naccess with other criteria.\n\n## Transit (GTFS)\n\nUse r5py with OSM + GTFS feeds; results are departure-time sensitive —\ncompute over a time window (e.g., 07:00-09:00 percentiles), never a single\ndeparture. Validate the feed (calendar coverage on your analysis date!) —\nan expired GTFS calendar yields walking-only times that look plausible.\n\n## Verification protocol\n\n1. Spot-check 3 routes against an external router (Google/OSRM) — within\n   ~20% or explain why.\n2. Map unreachable/infinite-cost pairs — usually snapping or connectivity\n   artifacts, not real inaccessibility.\n3. Isochrone eyeball: does it respect rivers, highways, one-ways?\n\n## Pitfalls checklist\n\n- Euclidean buffers presented as \"service areas\".\n- Wrong network_type for the mode.\n- Convex-hull isochrones bridging barriers.\n- Snap distances unchecked.\n- One departure time for transit accessibility.\n- Betweenness sold as traffic volume.\n- OD matrix in degrees-CRS travel \"distances\".\n\n## Execution contract\n\n- **Workflow:** define mode, time, impedance, origins, destinations, and equity question; build and validate the network; snap inputs; compute routes or matrices; summarize access; verify.\n- **Decision rules:** use network costs for constrained travel, movement analytics for observed tracks, and MCDA only when accessibility becomes one criterion in a broader preference model.\n- **Verification protocol:** audit connectivity and snapping, spot-check routes, map unreachable pairs, test departure-time or impedance sensitivity, and reconcile OD dimensions and units.\n- **Failure modes:** withhold access claims for disconnected graphs, wrong mode or turn rules, expired GTFS service, excessive snapping, Euclidean substitution, or unstable departure-time results.\n- **Deliverables:** network provenance, assumptions and cost function, routes or OD matrix, isochrones or access metrics, unreachable-case report, validation evidence, and equity caveats.\n- **Source freshness:** consult [the authoritative source registry](references/authoritative-sources.md) before using network, GTFS, or routing APIs and archive source dates.\n"
}