TransitLM: A Large-Scale Dataset and Benchmark for Map-Free Transit Route Generation
Abstract: Public transit route planning traditionally depends on structured map infrastructure and complex routing engines, and no existing dataset supports training models to bypass this dependency. We present TransitLM, a large-scale dataset of over 13 million transit route planning records from four Chinese cities covering 120,845 stations and 13,666 lines, released as a continual pre-training corpus and benchmark data for three evaluation tasks with complementary metrics. Experiments show that an LLM trained on TransitLM produces structurally valid routes at high accuracy and implicitly grounds arbitrary GPS coordinates to appropriate stations without any explicit mapping. These results demonstrate that transit route planning can be learned entirely from data, enabling end-to-end, map-free route generation directly from origin-destination information. The dataset and benchmark are available at https://huggingface.co/datasets/GD-ML/TransitLM, with evaluation code at https://github.com/HotTricker/TransitLM.
Summary
- The paper demonstrates that LLMs can internalize transit network topology from log data, achieving near-perfect connectivity and route accuracy without relying on explicit maps.
- The study introduces a dual-stream approach with Continual Pre-Training and Supervised Fine-Tuning, which significantly enhances structural validity and performance across benchmark tasks.
- The work establishes that domain-specific pre-training on rich transit logs results in robust spatial grounding, effective preference-aware planning, and diverse multi-route generation.
TransitLM: A Large-Scale Dataset and Benchmark for Map-Free Transit Route Generation
Motivation and Problem Formulation
Conventional transit route planning relies on explicit map infrastructure and routing engines with detailed network topology. Despite the emergence of LLMs with strong reasoning capabilities, general-purpose LLMs have consistently failed to generate route plans with structural validity, suffering from hallucinated stations and disconnected paths when deprived of map-based grounding. The absence of comprehensive transit planning datasets with behavioral annotations has prevented end-to-end, map-free route generation. TransitLM addresses this gap by leveraging rich transit log data to establish whether LLMs can internalize network topology and spatial relationships directly from data, eliminating maps and routing engines.
Figure 1: Comparison of transit route planning paradigms—traditional map-based, general-purpose LLMs (with ungrounded outputs), and TransitLM (with implicit spatial grounding and structurally valid routes).
Dataset Construction
TransitLM aggregates over 13.9 million route planning sessions from Amap, spanning Beijing, Shanghai, Shenzhen, and Chengdu, with 120,845 stations and 13,666 transit lines. The dataset includes detailed session records: origin-destination GPS coordinates, station ID sequences, transfer points, line identifiers, segment-level timing, and route-type annotations. Each station is represented as a dedicated vocabulary token.
The dataset comprises two streams:
- Continual Pre-Training (CPT) Corpus: Textual records of real-world planning sessions and static descriptions enable next-token prediction to encode network structure and spatial relationships.
- Benchmark Supervised Fine-Tuning (SFT) Data: Standardized prompts and labels for three distinct evaluation tasks (Optimal Route Generation, Preference-Aware Planning, Multi-Route Generation) provide reproducible assessment of route accuracy, preference compliance, and output diversity.
Figure 2: TransitLM framework—data sources, benchmark tasks, evaluation metrics, and training protocol.
Benchmark Tasks and Evaluation Metrics
TransitLM defines three benchmark tasks:
- Optimal Route Generation (ORG): Produce the top-ranked route selected by a user, requiring full station and line sequences, numeric estimates, and first/last-mile access.
- Preference-Aware Planning (PRG): Route generation under explicit user preferences (bus-first, subway-first, fewer transfers, shortest time) with hard compliance constraints.
- Multi-Route Generation (DRG): Generate three diverse route alternatives, evaluated for structural diversity as well as correctness.
Evaluation metrics span four orthogonal dimensions: Connectivity (reachability among stations), Access Feasibility (geometric proximity and distance plausibility for first/last-mile segments), Route Overlap (IoU between predicted and ground-truth line/station sets), Numeric Field Accuracy (absolute/relative error and tolerance-based accuracy), and task-specific criteria (Preference Compliance and Route Diversity).
Model Training and Architecture
Qwen3-0.6B, Qwen3-1.7B, and Qwen3-4B serve as backbone models. Station IDs are registered as dedicated tokens, nullifying station hallucination via character-level composition and facilitating spatial/topological learning. Models are trained in two stages: CPT (domain-focused next-token prediction) and SFT (task-specific fine-tuning). A joint variant (Qwen3-4B-Joint) is fine-tuned across all three tasks to assess transferability and task-agnostic spatial knowledge.
Figure 3: CPT training loss curves for three backbone models; sustained loss reduction and clear capacity gap across model sizes.
Experimental Results
General-purpose LLMs (GPT-5.4, DeepSeek-V4, Gemini-3.1, Claude-Opus-4.6, Qwen3.6, Doubao-Seed) evaluated under lenient conditions (only boarding/alighting stations) achieve no more than 75.5% connectivity and 40.2% Route Exact Match, confirming the necessity of transit-specific pre-training for structural validity.
Domain-specific models exhibit high structural fidelity:
- Optimal Route Generation: Qwen3-4B achieves 97.0% connectivity, 98.5% station grounding, 71.0% Route Exact Match, 98.5% estimation accuracy, and 1.33% MAPE; 4B-Joint further improves to 97.9% connectivity and 73.7% Route Exact Match.
- Preference-Aware Planning: 4B-Joint attains 95.3% connectivity, 97.4% station grounding, 52.6% Route Exact Match, and 90.5% preference compliance.
- Multi-Route Generation: 4B-Joint receives 97.1% connectivity, 98.8% station grounding, 67.2% Route Exact Match, 98.1% estimation accuracy, and 0.547 route diversity.
Scalability experiments demonstrate monotonically increasing performance as CPT data volume increases. Even at 6.25% data volume, connectivity persists at 94.0% and Route Exact Match at 49.9%, indicating robust data efficiency.
Qualitative Examples
The model generates visually coherent and structurally valid routes under all benchmark tasks. Example outputs evidence preference compliance, output diversity, and spatial grounding—even with GPS-only input.
Figure 4: Geographic distribution of route planning origins; dataset samples closely align with urban demand patterns.
Figure 5: Optimal Route Generation from Qwen3-4B-Joint in Beijing; the model produces a two-segment subway route with accurate transfer, distance, fare, and spatially coherent station sequence.
Figure 6: Preference-Aware Planning with bus preference; model output switches to a bus-only route, demonstrating strict preference compliance.
Figure 7: Multi-Route Generation; three alternatives (subway, subway + cycling, bus) illustrate model capacity for diverse planning strategies.
Figure 8: GPS-only Optimal Route Generation; predicted route remains structurally and spatially consistent with textual-input results.
Robustness and Implicit Spatial Grounding
GPS-only input ablation reveals that general-purpose LLMs degrade to <1% Route Exact Match due to lack of spatial knowledge, with station grounding declining steeply. In contrast, domain-specific Qwen3 variants retain nearly all performance, with Qwen3-4B-Joint maintaining 98.0% connectivity and 72.9% Route Exact Match. This demonstrates implicit spatial grounding directly from CPT data, independent of textual context.
Implications and Future Directions
TransitLM empirically challenges the necessity of explicit map infrastructure in transit route planning. End-to-end, map-free route generation is validated at scale, with spatial and topological knowledge acquired solely from data. The incorporation of station IDs as vocabulary tokens successfully grounds structural outputs and prevents hallucination. Results substantiate that continual pre-training enables transferability across planning objectives and robust spatial grounding.
Pragmatically, TransitLM offers a scalable, self-contained paradigm for transit route planning, eliminating the need for external routing engines, API latency, and infrastructure dependencies. Theoretically, it establishes that LLMs, given sufficient appropriately structured domain logs, can internalize arbitrary network topologies and spatial representations. Future directions include extending geography coverage to nationwide or multi-lingual settings, compressing token vocabulary for scalability, and incorporating real-time dynamics for temporally adaptive planning.
Conclusion
TransitLM demonstrates that a LLM, trained or continually pre-trained on rich transit log data with explicit station ID grounding, achieves structurally valid, spatially coherent, preference-aware, and diverse route generation entirely without maps or routing engines. The findings refute the presumption that LLM route planning must rely on explicit spatial resources and confirm the sufficiency of domain data for end-to-end planning. The dataset and training framework highlight the potential for LLMs to serve as autonomous route planners, extendable to other structured spatial domains, and open significant avenues for further research involving generalization, real-time adaptation, and massive-scale deployment.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
This paper introduces TransitLM, a huge collection of real public transit plans (over 13 million) from four big Chinese cities. The authors use this data to train and test AI models that can plan bus and subway trips without using a traditional map or routing engine. In other words, the model learns to give you a step‑by‑step route (stations, transfers, times, and costs) just from where you start and where you want to go.
What questions are the researchers trying to answer?
- Can an AI learn to plan public transit routes just by studying lots of past trip plans, instead of relying on a digital map and a complex routing program?
- Can the AI understand real-world locations from GPS numbers (the latitude/longitude of your start and end points) and pick sensible nearby stations on its own?
- Can one AI handle different planning needs, like “fewest transfers” or “shortest time,” and even suggest several good alternatives?
How did they do it? (Methods in simple terms)
Think of teaching an AI to be a “transit expert” the way you’d learn a city:
- First, you read millions of travel diaries that show how people actually got from place A to place B (which stations they used, where they switched lines, how long it took, etc.).
- Then, you take some practice tests that ask you to plan routes under different rules.
More concretely:
- They collected 13+ million route-planning logs from Amap (a navigation app) in Beijing, Shanghai, Shenzhen, and Chengdu. Each log includes GPS start/end points, the exact sequence of station IDs, transfers, lines, time, distance, fare, and which route a user chose.
- They trained a LLM—a kind of AI that’s very good at reading and writing—to “speak transit.” This happened in two phases: 1) Continual pre-training: The model reads the massive route texts so it can absorb the network’s structure and habits (like learning the “grammar” of transit). 2) Supervised fine-tuning: The model practices on specific tasks with correct answers so it learns to follow instructions and output routes in a precise format.
- They added all 120,845 station IDs to the model’s vocabulary so each station is treated as a unique word. This helps prevent the AI from inventing fake stations.
- They built three tests (benchmarks) to check the model:
- Optimal Route Generation: Make the single best route.
- Preference-Aware Planning: Make the best route that matches a specific wish (like subway-first, bus-first, fewest transfers, or shortest time).
- Multi-Route Generation: Propose three diverse, good routes at once.
- They measured results with practical checks, such as:
- Connectivity: Does the route properly connect from station to station?
- Station Grounding: Are the first/last stations close enough to the GPS start/end points?
- Overlap/Exact Match: How closely does the predicted route match the real “best” route?
- Numbers accuracy: How close are time, distance, and fare estimates?
Key terms in plain language:
- LLM: An AI trained to understand and generate text, like a very advanced autocomplete.
- Map-free: The AI doesn’t look up a map or run a traditional routing algorithm; it plans routes by recalling patterns learned from data.
- GPS coordinates: Latitude and longitude—like a street address for computers.
- Pre-training and fine-tuning: First learn general knowledge (pre-training), then practice a specific job (fine-tuning).
What did they find, and why does it matter?
- The AI can plan correct, map-free routes: The best version produced connected, sensible routes about 97% of the time and exactly matched the full ground-truth route up to 71% of the time in the main task. It also predicted numbers like travel time with very low error.
- It learned “spatial grounding”: Given only GPS start and end points (no place names), the model still picked appropriate nearby stations and kept performance high. In contrast, general-purpose AIs (like popular chatbots) mostly failed without text clues, showing that TransitLM’s specialized training taught the model real spatial understanding.
- One model can handle different goals: A single jointly trained model did as well as or better than separate models trained for each task, meaning the knowledge it learned was general and reusable.
- More data makes it better: With more training logs, the model’s routes got closer to the real ones, and its time/distance estimates improved. Even with a small slice of the data, the model already planned routes quite well.
Why this matters:
- It shows that accurate public transit planning can be learned directly from data, which could simplify future transit apps and research tools. Instead of maintaining big map systems and complex routing engines, some planning can be done by an AI that has “read” lots of real plans.
What’s the bigger impact?
- For cities and apps: This approach could make building or improving transit planners easier, especially in places where map data is incomplete or hard to maintain.
- For users: It could provide fast, flexible route suggestions, tailored to preferences like speed or fewer transfers, and even multiple good alternatives.
- For research: TransitLM is a public dataset and benchmark, encouraging other teams to test and improve map-free planning. Future steps include expanding to more cities and adding real-time factors like delays and congestion.
Overall, TransitLM suggests a new way to plan public transit: learn directly from how people actually travel, then generate routes end-to-end—no traditional map engine required.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a consolidated list of limitations, unanswered questions, and unexplored areas that future research can address.
- Geographic scope is limited to four Chinese cities from a single platform; generalization to other countries, languages, transit schemas, and data providers remains untested.
- Temporal coverage is a single day of logs; the model’s robustness to seasonality, peak/off-peak patterns, holidays, events, strikes, and long-term network changes is unknown.
- The dataset “captures only static route structures”; real-time schedules, headways, transfer waiting times, disruptions, crowding, and congestion are not modeled or evaluated.
- Zero-shot transfer to entirely unseen cities/networks is not evaluated; a rigorous holdout-city protocol is needed to test generalization without any city-specific CPT/SFT.
- Station-ID vocabulary expansion (120,845 dedicated tokens) may not scale to national/global coverage; handling out-of-vocabulary new stations and network updates is left open.
- Robustness to GPS noise and geocoding errors is not assessed; the model should be tested under perturbed coordinates, address parsing ambiguity, and varying coordinate formats/projections.
- First/last-mile feasibility thresholds (3 km walking, 5 km cycling, 10 km taxi) are heuristic and unusually large; sensitivity analyses and city-specific calibration to realistic user tolerances are needed.
- Evaluation relies on the platform engine’s candidate set and rankings as “ground truth,” which may encode engine-specific biases; independent validation (multi-engine, human expert review) is lacking.
- “Optimality” is defined by engine ranking and user click order; there is no explicit, transparent multi-criteria utility function or Pareto optimal frontier to benchmark against.
- Multi-route “diversity” is measured by line-set dissimilarity only; coverage of the Pareto set (time, fare, transfers, walking) and user-centric diversity metrics are not considered.
- Numeric field accuracy (EA, MAPE) is computed only for exact-match routes; calibration on structurally valid but non-exact predictions remains unquantified.
- Preference handling is limited to four categories (subway-first, bus-first, fewer transfers, shortest time); additional preferences (cost minimization, walking aversion, accessibility, reliability, crowding, comfort) are not supported or evaluated.
- Robustness of preference parsing to paraphrases, negations, compound/multi-objective preferences, and multilingual queries is not examined.
- Fairness and bias are unstudied: performance by neighborhood, trip length bins, modal mix, socioeconomic proxies, and accessibility needs (e.g., wheelchair users) is unknown.
- Privacy guarantees are described only at a high level; formal privacy risk assessments (e.g., k-anonymity, differential privacy) and potential re-identification threats are not quantified.
- The “diversity filtering” that retains up to five routes per session is not detailed; its effect on label coverage, training signal, and evaluation bias is unknown.
- Placing the user-clicked route first in CPT may bias learning toward clicks; the impact on exploring diverse alternatives and multi-route generation quality is not analyzed.
- Model family is limited to vanilla Transformers (Qwen3-base); comparisons with graph-aware/geospatial encoders, coordinate embeddings, or structure-aware objectives are not explored.
- Connectivity guarantees are not enforced at decoding; constrained decoding or soft verification during generation (without full map reliance) could reduce invalid outputs and is not investigated.
- Scaling laws beyond 4B are not characterized; inference latency, memory, and cost vs. performance trade-offs for deployment at city scale are not measured.
- Hybrid methods (map-free core with optional tool/API augmentation for schedule queries or disruptions) are not evaluated; conditions under which tools improve or harm performance remain open.
- Continual learning under network evolution (new lines, station closures, timetable changes) is not addressed; mechanisms to update vocabularies and avoid catastrophic forgetting are needed.
- Stress testing on edge cases (very long trips, last-train constraints, night service, limited-service lines, rare stations) is missing.
- Real-world validation (A/B testing or user studies) comparing generated routes to production engine outcomes and traveler satisfaction is absent.
- The error anatomy of general-purpose LLMs is not dissected beyond aggregate metrics; targeted analyses (hallucinations, transfer errors, station grounding failures) and improved prompting strategies are needed.
- Reproducibility details are unclear for external users: whether full station coordinates/connectivity are released, and to what extent evaluation can be replicated without proprietary assets.
- Cross-city transfer effects (negative/positive) are mentioned only in appendix; a main-text quantification of single-city vs. multi-city training impacts is missing.
- Safety checks for recommending impractical/unsafe paths (e.g., non-operational stations, unsafe walking segments) are not incorporated or evaluated.
- Sustainability-aware planning (fare/emissions trade-offs, energy use) is not modeled; adding environmental objectives and metrics is an open direction.
- Cross-lingual generalization is untested; the corpus is in Chinese, and performance on English/bilingual prompts and station/name variants is unknown.
Practical Applications
Below are practical, real-world applications that follow from TransitLM’s findings, methods, and innovations. Each item notes concrete use cases, target sectors, prospective tools/workflows/products, and the key assumptions or dependencies that affect feasibility.
Immediate Applications
These can be deployed now in settings similar to the paper (e.g., the four covered cities) or with minimal adaptation.
- Map-free transit routing microservice — transportation, software
- Use cases: Power route planning in apps for Beijing/Shanghai/Shenzhen/Chengdu without invoking a traditional routing engine or map graph; serve as a lightweight backend for startups or municipal apps.
- Tools/products/workflows: “TransitLM Router” API that accepts city + GPS OD and returns JSON routes with station IDs, times, fares, and access segments; server-side inference using the 1.7B–4B models; token registry for station IDs.
- Assumptions/dependencies: Model currently trained on four cities; deployment elsewhere needs data adaptation; no real-time schedules incorporated—pair with basic schedule service or add a verifier.
- Preference-aware trip assistants and chatbots — transportation, customer service, accessibility
- Use cases: In-app or kiosk chatbots that understand requests like “fewest transfers,” “subway-first,” or “fastest,” and return valid routes; call-center automation for public transit agencies.
- Tools/products/workflows: “Preference Planner” NLU front-end + TransitLM backend; voice assistant or IVR integration; JSON-to-card UI renderer.
- Assumptions/dependencies: Performance validated for four preference types; ensure guardrails to prevent occasional hallucinations; language/locale adaptation for broader rollout.
- Multi-route suggestion UI components — transportation, UX
- Use cases: Present three diverse alternatives (e.g., bus-first, subway-first, mixed) to users to improve choice and resilience during minor disruptions.
- Tools/products/workflows: “Multi-Route Card” component fed by TransitLM’s multi-route JSON; diversity metric in QA to maintain variety without sacrificing feasibility.
- Assumptions/dependencies: Label ambiguity implies more than one valid answer; integrate simple post-checks for connectivity and station proximity.
- Offline/edge transit advisor with small models — mobile, embedded/edge computing, privacy
- Use cases: On-device route generation for commuters with spotty connectivity or strict privacy needs; kiosk or in-vehicle systems with limited compute.
- Tools/products/workflows: Quantized 0.6B–1.7B checkpoints running on modern smartphones or edge boxes; local station-ID token map; minimal UI rendering.
- Assumptions/dependencies: City-specific checkpoints; storage for station metadata; periodic updates when networks change.
- Fallback planner when map APIs fail — reliability engineering, DevOps
- Use cases: Graceful degradation when third-party map services throttle, change pricing, or suffer outages; provide continuity for core route queries.
- Tools/products/workflows: Circuit breaker that switches from map engine to TransitLM inference; health checks and canary testing; logging and rollback.
- Assumptions/dependencies: Requires a fast connectivity validator to catch rare invalid routes before display.
- Mobility-as-a-Service (MaaS) first/last-mile integration — transportation, ride-hailing, micromobility
- Use cases: Suggest walking/cycling/taxi segments to connect to transit within learned distance thresholds; improve door-to-door planning UX.
- Tools/products/workflows: “Access Segment Composer” that fuses TransitLM outputs with partner APIs (bike-share availability, taxi ETA); unified fare/time display.
- Assumptions/dependencies: Paper uses static thresholds/estimates; real-time availability/ETA should be layered on; local policy constraints may differ.
- QA/Evaluation harness for routing engines — software testing, quality assurance
- Use cases: Use TransitBench metrics (connectivity, station grounding, IoU overlaps, numeric accuracy) to regression-test incumbent routing engines and LLM planners.
- Tools/products/workflows: “TransitBench Eval Kit” CI job; batch tests on curated OD sets; dashboards for REM, MAPE, and diversity.
- Assumptions/dependencies: Needs station geocodes for grounding checks; adapt thresholds to city norms if different from the paper.
- Academic benchmark for planning and spatiotemporal reasoning — academia, education
- Use cases: Course assignments and research on data-driven routing, implicit spatial grounding, and multi-criteria planning; compare LLMs vs graph-based methods.
- Tools/products/workflows: Public dataset on Hugging Face; open-source evaluation code; baseline checkpoints for reproducibility.
- Assumptions/dependencies: Chinese-language data and city coverage; researchers may need to translate/adapt for other locales.
- Accessibility-oriented routing (fewer transfers, simpler paths) — accessibility, public sector
- Use cases: Provide routes with fewer transfers or longer walking segments to accommodate mobility-impaired users; generate step-by-step narratives from station sequences.
- Tools/products/workflows: “Accessible Route Mode” that prioritizes constraints; TTS pipeline for voice guidance using station IDs.
- Assumptions/dependencies: Accessibility needs vary by city; may require custom preference prompts and constraints beyond the four categories in the paper.
- Developer SDK for station-sequence JSON rendering — software, UI/UX
- Use cases: Rapidly embed structured route cards/timelines into apps and kiosks; unify display across web and mobile.
- Tools/products/workflows: JSON schema adapters; React/Vue components for station timelines, transfer markers, and fare/time badges.
- Assumptions/dependencies: Requires up-to-date station metadata (names, icons) to map IDs to human-readable labels.
Long-Term Applications
These require further data, scaling, or development (e.g., coverage beyond the four cities, real-time dynamics, or new training paradigms).
- Global/cross-city generalization pipeline — transportation, software
- Use cases: Train city-agnostic or multi-city models that generalize to new geographies; bootstrap for cities with sparse logs.
- Tools/products/workflows: “City Adaptation Toolkit” with continual pre-training on local logs/GTFS-derived corpora, automatic station-ID tokenization; few-shot SFT per city.
- Assumptions/dependencies: Requires data-sharing agreements with agencies/operators; standardized station ID schemas; localization and multilingual support.
- Real-time and disruption-aware routing — transportation operations, smart cities
- Use cases: Incorporate delays, closures, and crowding into map-free planning; provide resilient alternatives during incidents or events.
- Tools/products/workflows: Stream processor feeding real-time signals into prompts or adapters; verifier/ranker that re-scores LLM routes with live data.
- Assumptions/dependencies: The paper uses static logs; real-time integration needs new data pipelines, calibration, and rigorous safety checks.
- Counterfactual planning for policy and network design — public policy, urban planning
- Use cases: Simulate effects of adding/removing lines or stations on route availability and transfer burden; evaluate policies like fare changes or priority corridors.
- Tools/products/workflows: “TransitLM-Sim” that swaps station/line tokens to reflect proposed networks; batch route generation over OD demand matrices; KPIs for transfers and travel time.
- Assumptions/dependencies: Requires synthetic or reconstructed network variants; behavior learned from historical logs may not reflect future elasticities without re-training.
- Privacy-preserving, federated training across agencies — data governance, public sector IT
- Use cases: Train/refresh models across multiple cities without centralizing sensitive logs.
- Tools/products/workflows: Federated continual pre-training with secure aggregation; differential privacy budgets; cross-agency token registries.
- Assumptions/dependencies: Organizational buy-in; harmonized privacy policies; compute at edge nodes.
- Map-light deployments in emerging markets — international development, NGOs
- Use cases: Deliver usable routing in cities lacking mature map infrastructure; reduce reliance on proprietary map APIs.
- Tools/products/workflows: “Mapless Routing SDK” bundled with minimal station/line metadata; offline-capable inference; low-bandwidth UI.
- Assumptions/dependencies: Must obtain at least basic station geocodes and IDs; quality depends on the volume and coverage of available logs.
- Continual learning for evolving networks — MLOps, transportation operations
- Use cases: Rapidly adapt models to new stations/lines, temporary closures, or timetable shifts.
- Tools/products/workflows: Weekly CPT/SFT refresh pipelines; station-ID token registry with versioning; change detection and A/B testing.
- Assumptions/dependencies: Requires stable data engineering and monitoring; guard against catastrophic forgetting and distribution drift.
- Safety-verified route generation — safety engineering, compliance
- Use cases: Combine generative routes with formal verifiers that enforce connectivity, access thresholds, and policy rules before display.
- Tools/products/workflows: Post-generation graph checker (lightweight), constraint solvers, or hybrid rankers; signed “verified” flags in JSON.
- Assumptions/dependencies: Needs basic topological data for verification even if primary planning is map-free; define city-specific constraints.
- Multimodal MaaS pricing and bundling — mobility platforms, finance
- Use cases: Offer transparent fare/time trade-offs across taxi, micromobility, and transit segments; create bundles or passes based on likely routes.
- Tools/products/workflows: Tariff engine plugged into TransitLM outputs; A/B testing on conversion and satisfaction.
- Assumptions/dependencies: Real-time fare and availability data; regulatory compliance for pricing and bundling.
- Assistive technologies for special populations — healthcare, social services
- Use cases: Patient navigation to clinics with reduced-transfer routes; caregiver-friendly itineraries for elderly users.
- Tools/products/workflows: Integration into hospital/clinic apps; accessibility profiles mapping to planning preferences; appointment-aware scheduling.
- Assumptions/dependencies: Data-sharing agreements; local customization; clinical safety/usability reviews.
- Research on spatial reasoning and grounding — academia, AI safety
- Use cases: Extend the demonstrated GPS-to-station grounding into broader geospatial tasks (e.g., POI matching, micro-navigation) and evaluate failure modes.
- Tools/products/workflows: New benchmarks mixing coordinates and sparse text; probing tasks for grounding robustness; interpretability studies.
- Assumptions/dependencies: Additional datasets with varied geographies and annotation types; compute resources for larger-scale studies.
- Synthetic data generation to reduce log dependence — software, data engineering
- Use cases: Augment or pretrain in cities with limited logs by generating high-quality synthetic planning sessions from GTFS/OSM and simple behavioral models.
- Tools/products/workflows: “Synthetic Planner” that emits station sequences and preferences; curriculum mixing synthetic and real logs.
- Assumptions/dependencies: Synthetic behavior may mismatch real choices; needs careful calibration and subsequent fine-tuning on real data.
Notes on general feasibility:
- The strongest near-term fit is within the four cities used for training; transferring to new cities requires local data or synthetic augmentation.
- Real-time reliability, safety, and compliance need hybrid designs (LLM generation + verifier/ranker + minimal topological data).
- Station-ID tokenization is a central enabler; stable, city-wide station registries are necessary.
- Language/localization and privacy constraints must be addressed for international deployments.
Glossary
- Access Feasibility: An evaluation dimension that validates the feasibility of first/last-mile segments connecting a trip’s endpoints to the transit network. "Access Feasibility. Validates the first/last-mile segments connecting the origin/destination to the transit network."
- A: A heuristic shortest-path search algorithm used on graphs; here referenced in both classic routing and LLM-assisted variants. "LLM-A \cite{meng2024llmastar} incorporates LLM-generated heuristics into A* search but still requires the graph as input."
- Connection Scan Algorithm (CSA): A timetable-based public transit routing algorithm that scans connections to find optimal journeys. "Connection Scan Algorithm \cite{dibbelt2018csa},"
- Continual Pre-Training (CPT): Additional pre-training of a LLM on domain-specific corpora to specialize it before fine-tuning. "In the continual pre-training (CPT) stage \cite{gururangan2020dont},"
- Distance Plausibility (DP): A metric that checks whether predicted first/last-mile distances are physically reasonable. "Distance Plausibility (DP) verifies that the predicted access distance is physically plausible."
- Domain-adaptive continual pre-training: A technique where LMs are further pre-trained on in-domain data to improve performance on domain tasks. "Domain-adaptive continual pre-training \cite{gururangan2020dont} has proven effective for specializing LLMs to new domains."
- Estimation Accuracy (EA): A metric assessing whether numeric outputs (e.g., distance, time, fare) fall within specified tolerance thresholds. "Estimation Accuracy (EA) measures the pass rate under a dual-tolerance criterion,"
- First/last-mile: Non-transit or access legs (e.g., walk, bike, taxi) that connect the traveler to and from the transit network. "first/last-mile access details"
- General Transit Feed Specification (GTFS): A common data format for public transportation schedules and associated geographic information. "GTFS \cite{wong2013leveraging}"
- GPS-only ablation: An experiment setup where textual cues are removed and only coordinates are provided to test spatial grounding. "GPS-only ablation."
- Implicit spatial grounding: The model’s learned ability to map raw coordinates to appropriate stations without explicit mapping. "Implicit spatial grounding emerges from data."
- Intersection-over-Union (IoU): A set-overlap metric used here to measure structural agreement between predicted and reference routes. "Quantifies the structural match between predicted and ground-truth routes using Intersection-over-Union (IoU)."
- Line Overlap (LO): IoU computed over the set of lines (including access legs) used by the route. "Line Overlap (LO) computes IoU over the full line set including first/last-mile access segments;"
- Map-free route generation: Producing complete transit routes directly from inputs without relying on map infrastructure or routing engines. "End-to-end map-free route generation is feasible."
- Multi-Route Generation: A benchmark task requiring generation of three diverse, valid transit routes for the same input. "Multi-Route Generation."
- Optimal Route Generation: A benchmark task where the model outputs one optimal route as structured JSON given OD and a query. "Optimal Route Generation."
- Origin–Destination (OD): The pair of trip endpoints used as inputs for planning. "Given the same OD input and a natural-language query, the model generates three diverse transit routes in a single JSON response."
- Pareto-optimal extension: An algorithmic enhancement that optimizes multiple criteria such that no criterion can be improved without worsening another. "and its Pareto-optimal extension \cite{delling2019fast},"
- Preference-Aware Planning: A benchmark task where the model must honor a specified user preference (e.g., subway-first) while planning. "Preference-Aware Planning."
- Preference Compliance (PC): A metric that checks whether the generated route satisfies the stated user preference via hard rules. "Preference-Aware Planning additionally uses Preference Compliance (PC), which checks whether the predicted route satisfies the stated preference via hard rules."
- RAPTOR: A round-based public transit routing algorithm designed for efficient journey planning on large networks. "RAPTOR \cite{delling2015round} and its Pareto-optimal extension \cite{delling2019fast},"
- Route Diversity (RD): A metric measuring how different multiple generated routes are from each other. "Multi-Route Generation uses Route Diversity (RD), measuring the average pairwise line-set dissimilarity among the three generated routes;"
- Route Exact Match (REM): A strict metric indicating complete structural match (lines and stations) with the ground-truth route. "Route Exact Match (REM) reports the fraction of samples achieving both LO\,=\,1 and SSO\,=\,1."
- Station Grounding (SG): A metric verifying that predicted boarding/alighting stations are within threshold distances of the OD points. "Station Grounding (SG) checks whether the predicted boarding/alighting station is within a mode-specific distance threshold"
- Station Sequence Overlap (SSO): IoU computed over the sets of station IDs in predicted vs. reference routes. "Station Sequence Overlap (SSO) computes IoU over station ID sets;"
- Supervised Fine-Tuning (SFT): Task-specific training of a pre-trained model using labeled examples. "In the subsequent supervised fine-tuning (SFT) stage \cite{ouyang2022training,wei2022finetuned},"
- Tool-calling agents: LLM agents that invoke external tools or APIs during planning or reasoning. "through tool-calling agents \cite{schick2023toolformer}"
- Transfer markers: Explicit indicators in a station sequence denoting transfer points between lines. "station-ID sequence with transfer markers,"
- Transfer Patterns: A precomputation-based approach that accelerates public transit routing by cataloging optimal transfers. "Transfer Patterns \cite{bast2010transfer},"
Collections
Sign up for free to add this paper to one or more collections.
