TransitLM: A Large-Scale Dataset and Benchmark for Map-Free Transit Route Generation

# TransitLM: A Large-Scale Dataset and Benchmark for Map-Free Transit Route Generation
Source: [https://arxiv.org/html/2605.22355](https://arxiv.org/html/2605.22355)
Hanyu Guo∗Jiedong Yang∗Chao Chen Longfei Xu Kaikui Liu Xiangxiang Chu AMAP, Alibaba Group Beijing, China \{guohanyu\.ghy,jiedong\.yjd,cc201598,longfei\.xl,damon\}@alibaba\-inc\.com cxxgtxy@gmail\.com

###### 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](https://huggingface.co/datasets/GD-ML/TransitLM), with evaluation code at[https://github\.com/HotTricker/TransitLM](https://github.com/HotTricker/TransitLM)\.

## 1Introduction

Public transit route planning underpins daily urban mobility, yet conventional systems rely heavily on structured map infrastructure and complex engineering pipelines for candidate retrieval and ranking over topological networks\. Notably, massive route planning logs continuously generated by transit platforms implicitly encode rich routing knowledge, including boarding stations, transfer points, and how travelers balance speed, convenience, and line preference\. This contrast motivates a natural question: can route planning be learned directly from such data, bypassing maps and routing engines entirely?

One might expect general\-purpose LLMs like GPT\-3\[[4](https://arxiv.org/html/2605.22355#bib.bib41)\], GPT\-4\[[1](https://arxiv.org/html/2605.22355#bib.bib1)\], and Qwen3\[[41](https://arxiv.org/html/2605.22355#bib.bib2)\]to address this question with their strong reasoning and broad world knowledge\. However, recent studies argue that autoregressive LLMs cannot reliably perform planning by themselves\[[34](https://arxiv.org/html/2605.22355#bib.bib37),[20](https://arxiv.org/html/2605.22355#bib.bib36)\]\. Although these models may recall frequently mentioned stations or popular routes, they consistently produce routes with hallucinated stations or broken connections\[[19](https://arxiv.org/html/2605.22355#bib.bib38)\], particularly for less prominent origin\-destination pairs\. This limitation stems from the absence of suitable training data\. Existing data sources each capture only partial aspects of the problem\. Vehicle trajectory datasets such as T\-Drive\[[42](https://arxiv.org/html/2605.22355#bib.bib3)\]and Porto Taxi\[[25](https://arxiv.org/html/2605.22355#bib.bib4)\]lack station structures\. Static network datasets including GTFS\[[38](https://arxiv.org/html/2605.22355#bib.bib5)\]and CPTOND\-2025\[[36](https://arxiv.org/html/2605.22355#bib.bib6)\]contain no user behavior or planning trajectories\. Consequently, no existing source provides the complete route structures and behavioral annotations needed for learning end\-to\-end transit planning\.

![Refer to caption](https://arxiv.org/html/2605.22355v1/x1.png)Figure 1:Three paradigms for transit route planning\.Top:Traditional map\-based pipeline\.Bottom\-left:General\-purpose LLMs lack structural grounding, producing hallucinated stations, disconnected routes, and invalid boarding/alighting points\.Bottom\-right:TransitLM generates structurally valid, continuous routes end\-to\-end via implicit spatial grounding, without map infrastructure\.As illustrated in Figure[1](https://arxiv.org/html/2605.22355#S1.F1), we introduce TransitLM to address this gap\. TransitLM is a large\-scale dataset of over 13 million route planning records from four Chinese cities: Beijing, Shanghai, Shenzhen, and Chengdu, covering 120,845 stations and 13,666 transit lines\. Each record captures a full planning session with GPS coordinates, station sequences, transfer points, line identifiers, segment\-level timing, and route\-type annotations\. We release two complementary resources\. The continual pre\-training corpus contains 13\.9 million textual route descriptions for next\-token prediction training, enabling models to internalize transit network topology and spatial relationships\. The benchmark\-specific SFT data provides standardized prompts and labels for three core tasks: optimal route generation, preference\-aware planning, and multi\-route generation, each evaluated by complementary metrics spanning connectivity, access feasibility, route overlap, and numeric field accuracy\.

To validate the dataset, we train an LLM through continual pre\-training followed by supervised fine\-tuning\. Our experiments reveal three key findings\.\(1\) End\-to\-end map\-free route generation is feasible\.The trained model produces structurally valid, connected routes at high accuracy, demonstrating that rich trajectory data alone can replace conventional map\-based routing engines\.\(2\) Implicit spatial grounding emerges from data\.Given only origin and destination GPS coordinates, the model learns to resolve arbitrary coordinates to appropriate boarding and alighting stations without any explicit coordinate\-to\-station mapping or geographic database, effectively internalizing the spatial topology of the transit network\.\(3\) A single model generalizes across planning objectives\.A jointly trained model matches or exceeds task\-specific counterparts on all three benchmarks without negative transfer, confirming that the transit knowledge encoded in the dataset is task\-agnostic and supports unified deployment across diverse planning scenarios\. Our contributions are as follows:

- •Dataset\.We present TransitLM, a large\-scale dataset of over 13 million transit route planning records spanning four Chinese cities, 120,845 stations, and 13,666 lines, released as a pre\-training corpus and benchmark data with standardized prompts and labels\.
- •Benchmark\.We define three evaluation tasks: optimal route generation, preference\-aware planning, and multi\-route generation\. Each task is evaluated by complementary metrics spanning connectivity, access feasibility, route overlap, and numeric field accuracy\.
- •Validation\.We validate the dataset by training an LLM that achieves accurate map\-free route generation, exhibits implicit spatial grounding from GPS coordinates to transit stations, and generalizes across diverse planning objectives with a single jointly trained model, confirming that the underlying transit knowledge is task\-agnostic\.

## 2Related Work

### 2\.1Transit Route Planning Methods

Classical transit routing operates over explicit graph representations\. Foundational algorithms such as Dijkstra\[[11](https://arxiv.org/html/2605.22355#bib.bib7)\]and A\*\[[17](https://arxiv.org/html/2605.22355#bib.bib8)\]have been extended by transit\-specific methods including RAPTOR\[[9](https://arxiv.org/html/2605.22355#bib.bib15)\]and its Pareto\-optimal extension\[[8](https://arxiv.org/html/2605.22355#bib.bib43)\], Connection Scan Algorithm\[[10](https://arxiv.org/html/2605.22355#bib.bib16)\], and Transfer Patterns\[[2](https://arxiv.org/html/2605.22355#bib.bib17)\], enabling efficient multi\-criteria journey planning on large\-scale networks\[[3](https://arxiv.org/html/2605.22355#bib.bib18)\]\. All these approaches inherently require structured map infrastructure and real\-time schedule data\. Recent work explores whether LLMs can reduce this dependence\. LLM\-A\*\[[24](https://arxiv.org/html/2605.22355#bib.bib19)\]incorporates LLM\-generated heuristics into A\* search but still requires the graph as input\. GridRoute\[[22](https://arxiv.org/html/2605.22355#bib.bib20)\]benchmarks LLM path reasoning in synthetic grid environments\. MapBench\[[40](https://arxiv.org/html/2605.22355#bib.bib22)\]and MapTrace\[[28](https://arxiv.org/html/2605.22355#bib.bib21)\]evaluate multimodal LLMs on pixel\-level map navigation\. ReasonMap\[[14](https://arxiv.org/html/2605.22355#bib.bib10)\]targets transit map reading but reveals substantial limitations in visual reasoning accuracy\. TraveLLM\[[12](https://arxiv.org/html/2605.22355#bib.bib9)\]applies LLMs to transit disruption scenarios while remaining dependent on external map data\. Across these efforts, no method has achieved end\-to\-end, map\-free transit route generation from origin\-destination information\.

### 2\.2Transit Data Sources

Existing transit\-related datasets each cover only partial aspects of the route planning problem\. Vehicle trajectory datasets such as T\-Drive\[[42](https://arxiv.org/html/2605.22355#bib.bib3)\], Porto Taxi\[[25](https://arxiv.org/html/2605.22355#bib.bib4)\], and GeoLife\[[44](https://arxiv.org/html/2605.22355#bib.bib13)\]record GPS traces of taxis or individuals\[[45](https://arxiv.org/html/2605.22355#bib.bib12)\]but lack station structures, transfer logic, and line identifiers inherent to public transit\. Static network datasets including GTFS\[[38](https://arxiv.org/html/2605.22355#bib.bib5)\], OpenStreetMap\[[16](https://arxiv.org/html/2605.22355#bib.bib14)\], and CPTOND\-2025\[[36](https://arxiv.org/html/2605.22355#bib.bib6)\]provide comprehensive topology and schedules across hundreds of cities but contain no user behavior or actual travel trajectories\. No existing dataset combines complete route structures with behavioral annotations for data\-driven transit route planning\.

### 2\.3Travel Planning and Routing Benchmarks

Recent benchmarks evaluate LLM agents on planning and navigation tasks, yet none targets end\-to\-end transit route generation\. TravelPlanner\[[39](https://arxiv.org/html/2605.22355#bib.bib23)\], NATURAL PLAN\[[43](https://arxiv.org/html/2605.22355#bib.bib24)\], TripCraft\[[5](https://arxiv.org/html/2605.22355#bib.bib25)\], ChinaTravel\[[31](https://arxiv.org/html/2605.22355#bib.bib26)\], TripTailor\[[35](https://arxiv.org/html/2605.22355#bib.bib27)\], TP\-RAG\[[26](https://arxiv.org/html/2605.22355#bib.bib28)\], TravelBench\[[6](https://arxiv.org/html/2605.22355#bib.bib31)\], and TRIP\-Bench\[[32](https://arxiv.org/html/2605.22355#bib.bib30)\]all focus on multi\-day itinerary scheduling through tool\-calling agents\[[30](https://arxiv.org/html/2605.22355#bib.bib42)\], evaluating high\-level constraint satisfaction rather than station\-level route accuracy\. Urban intelligence benchmarks such as CityBench\[[13](https://arxiv.org/html/2605.22355#bib.bib11)\]and USTBench\[[21](https://arxiv.org/html/2605.22355#bib.bib29)\]cover diverse urban tasks but exclude or marginalize transit routing\. MobilityBench\[[33](https://arxiv.org/html/2605.22355#bib.bib32)\]is the closest to our setting, but it evaluates agent ability to orchestrate map APIs rather than to generate routes directly\. No existing benchmark assesses whether an LLM can directly produce structurally valid transit routes with station\-level precision\.

## 3Dataset Construction

### 3\.1Data Collection

TransitLM is constructed from public transit route planning logs provided by Amap, a leading navigation platform in China\. We collect data from four major cities, Beijing, Shanghai, Shenzhen, and Chengdu, covering 120,845 stations and 13,666 bus and subway lines\. From a single day of navigation logs we extract over 12\.9 million planning sessions\. Since all candidate routes are generated by the platform’s production routing engine, they inherently satisfy connectivity and feasibility constraints, providing high\-quality training signal without manual verification\. Each session records origin and destination GPS coordinates, POI names, candidate routes with full station\-ID sequences and line identifiers where stations are represented by unique numeric IDs rather than natural\-language names, segment\-level travel distances and times, route\-type annotations, first/last\-mile access details, and user selection labels\. All records are fully de\-identified and privacy safeguards are detailed in Appendix[H](https://arxiv.org/html/2605.22355#A8)\.

![Refer to caption](https://arxiv.org/html/2605.22355v1/x2.png)Figure 2:Overview of TransitLM\.Left:Data sources from Amap comprising route plans, station information, station connectivity, and line information across four cities\.Center:TransitBench defines three evaluation tasks \(ORG, PRG, DRG\) with 10K test samples each, assessed by 10 metrics across five categories\.Right:TransitLM addresses the limitations of general LLMs through continual pre\-training on three knowledge sources and supervised fine\-tuning on three tasks, with vocabulary expansion and varied data settings\.
### 3\.2Data Schema

TransitLM releases two complementary data resources\.

Continual Pre\-Training \(CPT\) Corpus\.A textual corpus of 13\.9 million records, comprising 12\.9 million route planning sessions and 1\.0 million static descriptions of stations and lines\. Domain\-adaptive continual pre\-training\[[15](https://arxiv.org/html/2605.22355#bib.bib33)\]has proven effective for specializing language models to new domains\. Each session record encodes a planning query as natural language: a query header specifying city, origin–destination coordinates, and POI names, followed by candidate routes with per\-segment details\. The user\-selected route is placed first among the candidates, allowing the model to implicitly learn user preference patterns through next\-token prediction\. Static records describe individual lines and stations with attributes such as line length, stop sequences, operating hours, and connectivity\. Representative examples of these record types are provided in Appendix[B](https://arxiv.org/html/2605.22355#A2)\. This formulation enables the model to internalize transit network topology and spatial relationships\.

Benchmark Supervised Fine\-Tuning \(SFT\) Data\.Task\-specific data constructed for three benchmark tasks \(Section[4](https://arxiv.org/html/2605.22355#S4)\): optimal route generation, preference\-aware planning, and multi\-route generation\. Each task selects specific routes from the candidate set according to task\-defined criteria to construct structured labels\. Each task provides 30,000 training and 10,000 test examples with task\-specific filtering criteria\. All examples follow a standardized prompt–label format as illustrated in Appendix[C](https://arxiv.org/html/2605.22355#A3), enabling reproducible comparison across models and training configurations\.

### 3\.3Data Statistics and Analysis

The CPT corpus comprises 13\.9 million records from three complementary sources: 12,945,264 route planning sessions, 880,854 station descriptions, and 147,918 line descriptions\. Table[1](https://arxiv.org/html/2605.22355#S3.T1)summarizes key statistics across the four cities\. Each session contains on average 6\.32 candidate routes from the navigation engine; during CPT corpus construction, we retain at most five routes per session after diversity filtering\.

Route modality distribution\.We classify each candidate route into four categories based on its transit segments, excluding walking which serves only as a connection between segments\. Bus\-only routes account for 33\.0%, subway\-only for 19\.0%, and bus\+subway for 16\.8%\. Mixed routes, where at least one segment involves taxi or cycling as a first/last\-mile connection to a transit line, represent 30\.5%\. The remaining 0\.7% consist of non\-transit alternatives such as taxi\-only, or cycling\-only routes\. No single modality dominates the corpus, confirming balanced coverage across transit types\.

Route distance and travel time\.Route distances span from under 5 km to over 30 km\. Short\-range routes within 5 km account for 22\.8%, mid\-range routes of 5–20 km collectively represent 47\.4%, and long\-range routes beyond 20 km make up 29\.7%\. Travel times exhibit a comparable spread, with the majority falling between 15 and 90 minutes\. This breadth ensures that models trained on the corpus encounter the full continuum of urban commuting scenarios\.

Corpus sequence length\.CPT records average 2,377 Chinese characters in length, with 58\.4% falling in the 2,000–5,000 range\. Another 23\.6% lies between 1,000 and 2,000, while 2\.4% exceeds 5,000 characters, typically corresponding to long\-distance routes with many intermediate stops\. The corpus totals over 20 billion tokens, providing substantial training signal for continual pre\-training\[[18](https://arxiv.org/html/2605.22355#bib.bib40)\]\.

Table 1:CPT corpus statistics by city\. Stations and Lines denote the number of unique entities covered\. Routes/Sess\. is the average number of candidate routes per session\. Stops indicates the average station sequence length per route\. Transfers, Fare are per\-route averages\.

## 4Benchmark Tasks

End\-to\-end, map\-free transit route planning requires a model to produce a complete route from a user query and origin\-destination information alone, without relying on map infrastructure or routing engines\. A complete route encompasses transit lines and station\-ID sequences with transfer markers, from which the full trajectory can be reconstructed on a map, together with estimated distance, time, fare, and first/last\-mile access details connecting the origin and destination to the transit network\. To evaluate this capability under a standardized protocol, we design three benchmark tasks that collectively assess route accuracy, preference\-conditioned planning, and output diversity\.

### 4\.1Task Definitions

#### Optimal Route Generation\.

Given origin\-destination information and a natural\-language query, the model generates a single optimal transit route as structured JSON, including line sequence, station\-ID sequence with transfer markers, distance, time, fare, and first/last\-mile access details\. The ground\-truth label is the top\-ranked route that was also selected by the user\. The top\-ranked constraint ensures route quality as assessed by the platform’s routing engine, while the user\-selection constraint confirms real\-world preference\.

#### Preference\-Aware Planning\.

The input and output formats are identical to Optimal Route Generation, except that the query explicitly states a user preference\. We define four preference categories that reflect the most common real\-world planning needs:subway\-first,bus\-first,fewer transfers, andshortest time\. The model must parse the stated preference from the query and generate a route that satisfies the corresponding constraint while remaining optimal under that criterion\. Training data are constructed from sessions where the user explicitly set one of these preferences, and the ground\-truth label follows the same dual\-condition principle as Optimal Route Generation\.

#### Multi\-Route Generation\.

Given the same OD input and a natural\-language query, the model generates three diverse transit routes in a single JSON response\. Each route shares the schema of Optimal Route Generation, with an additionalroute\_tagindicating the route type, formed by a primary mode label and an optional secondary access label\. Ground\-truth triples are assembled from the session’s candidate pool by priority: \(1\) the user\-clicked route; \(2\) routes with distinct tags or non\-overlapping lines for diversity, selected in display order as ranked by the platform; and \(3\) top\-scored routes by an expert scoring function as fallback\.

Table 2:Comparison with general\-purpose LLMs onOptimal Route Generationover 1,000 test samples across four cities\. Column headers abbreviate full model names: GPT\-5\.4\-pro, DeepSeek\-V4\-Pro, Gemini\-3\.1\-Pro, Claude\-Opus\-4\.6, Qwen3\.6\-Plus, and Doubao\-Seed\-2\.0\-Pro\.↑\\uparrow/↓\\downarrowindicate higher/lower is better\.Bold: best;underline: second best\.

### 4\.2Evaluation Metrics

We evaluate predicted routes along four complementary dimensions, supplemented by task\-specific metrics\. Formal definitions are provided inAppendix[D](https://arxiv.org/html/2605.22355#A4)\.

#### Connectivity\.

Verifies that every consecutive station pair in the predicted sequence is reachable via a shared transit line or a valid transfer\. All subsequent metrics except task\-specific ones are computed only on connected samples\.

#### Access Feasibility\.

Validates the first/last\-mile segments connecting the origin/destination to the transit network\. It comprises two sub\-metrics:Station Grounding\(SG\) checks whether the predicted boarding/alighting station is within a mode\-specific distance threshold of the origin/destination, namely 3 km for walking, 5 km for cycling, and 10 km for taxi, reflecting implicit spatial grounding\[[23](https://arxiv.org/html/2605.22355#bib.bib39)\]learned from training data;Distance Plausibility\(DP\) verifies that the predicted access distance is physically plausible\.

#### Route Overlap\.

Quantifies the structural match between predicted and ground\-truth routes using Intersection\-over\-Union \(IoU\)\.Line Overlap\(LO\) computes IoU over the full line set including first/last\-mile access segments;Station Sequence Overlap\(SSO\) computes IoU over station ID sets;Route Exact Match\(REM\) reports the fraction of samples achieving both LO = 1 and SSO = 1\.

#### Numeric Field Accuracy\.

Measures how accurately the model predicts route\-level numeric attributes\. Letℱ=\{distance,time,fare\}\\mathcal\{F\}=\\\{\\text\{distance\},\\text\{time\},\\text\{fare\}\\\}denote the set of numeric fields\.Estimation Accuracy\(EA\) measures the pass rate under a dual\-tolerance criterion, andMean Absolute Percentage Error\(MAPE\) quantifies continuous error magnitude\. Both are restricted to samples achieving REM \(LO = 1 and SSO = 1\), ensuring that ground\-truth numeric fields serve as valid references\.

#### Task\-specific Metrics\.

Preference\-Aware Planning additionally usesPreference Compliance\(PC\), which checks whether the predicted route satisfies the stated preference via hard rules\. Multi\-Route Generation usesRoute Diversity\(RD\), measuring the average pairwise line\-set dissimilarity among the three generated routes; RD should be interpreted jointly with the four evaluation dimensions to balance diversity against route quality\.

## 5Experiments

### 5\.1Experimental Setup

We use Qwen3\-0\.6B\-Base, Qwen3\-1\.7B\-Base, and Qwen3\-4B\-Base\[[41](https://arxiv.org/html/2605.22355#bib.bib2)\]as backbones\. We extend the vocabulary by registering all 120,845 station IDs as dedicated tokens, so that each station is represented as a single token\. This prevents the model from hallucinating non\-existent stations through character\-level composition and enables it to learn station\-level spatial and topological relationships directly\. We do not explore larger models, as the 4B model already achieves strong performance across all tasks while larger variants would incur substantially higher training cost with diminishing returns\.

Each model is trained through a two\-stage pipeline\. In the continual pre\-training \(CPT\) stage\[[15](https://arxiv.org/html/2605.22355#bib.bib33)\], all sequences are packed to a fixed length and optimized with cosine learning rate scheduling\. In the subsequent supervised fine\-tuning \(SFT\) stage\[[27](https://arxiv.org/html/2605.22355#bib.bib34),[37](https://arxiv.org/html/2605.22355#bib.bib35)\], each model is fine\-tuned for one epoch on each benchmark task\. The SFT data are drawn from a separate time period with no overlap with the CPT corpus, preventing data leakage\. We additionally train a joint variant \(Qwen3\-4B\-Joint\) that fine\-tunes the 4B CPT checkpoint on the combined SFT data of all three tasks, evaluating whether the transit knowledge learned during pre\-training transfers across planning objectives, enabling unified deployment with a single model\. All training is conducted on Alibaba Cloud PPU accelerators\. Detailed hyperparameters are provided in Appendix[E](https://arxiv.org/html/2605.22355#A5)\.

### 5\.2Benchmark Results

#### Comparison with general\-purpose LLMs\.

A central question underlying this dataset is whether existing general\-purpose LLMs can perform transit route planning without domain\-specific training data\. We evaluate six state\-of\-the\-art models on Optimal Route Generation over 1,000 test samples across four cities, as shown in Table[2](https://arxiv.org/html/2605.22355#S4.T2)\. To provide a maximally favorable setting, we simplify the output requirement: each model predicts only the boarding and alighting stations per leg, whereas our domain\-specific models must generate the complete intermediate station sequence\. This design isolates the core challenge of transit network knowledge from sequence\-level generation difficulty, constituting a strictly more lenient evaluation\. Despite this advantage, all models struggle substantially\. The best performer, Gemini\-3\.1\-Pro, achieves only 75\.5% connectivity and 40\.2% Route Exact Match, confirming that general\-purpose LLMs lack the transit\-specific topological knowledge for structurally valid route generation\. The bottleneck lies in domain knowledge rather than model capacity or output complexity, underscoring the necessity of dedicated transit planning data\.

Table 3:Results onOptimal Route Generationwith 10,000 test samples across four cities\. Qwen3\-4B\-25 denotes CPT on 25% of session data\. Qwen3\-4B\-Joint is fine\-tuned on the combined SFT data of all three tasks\.↑\\uparrow/↓\\downarrowindicate higher/lower is better\.Bold: best;underline: second best\.Table 4:Results onPreference\-Aware Planningwith 10,000 test samples across four cities\. Qwen3\-4B\-25 denotes CPT on 25% of session data\. Qwen3\-4B\-Joint is fine\-tuned on the combined SFT data of all three tasks\. Label Preference Compliance is 96\.02%\.
#### Main results\.

Tables[3](https://arxiv.org/html/2605.22355#S5.T3)–[5](https://arxiv.org/html/2605.22355#S5.T5)report results on the three benchmark tasks\. The Qwen3\-4B model achieves≥\\geq93% connectivity,≥\\geq96% station grounding, and up to 71\.0% Route Exact Match, with estimation accuracy exceeding 92% and MAPE below 2\.1%\. These results collectively confirm that end\-to\-end map\-free route generation is feasible: the model not only produces connected routes but also grounds them to plausible stations, recovers correct complete routes at high rates, and accurately predicts numeric fields such as duration and walking distance\. The high station grounding further suggests that implicit spatial grounding begins to emerge from training data, though the current evaluation includes origin and destination names alongside GPS coordinates\. We provide stronger evidence for this capability in the GPS\-only ablation below, where removing all textual cues yields minimal performance degradation for our models while general\-purpose LLMs degrade substantially\.

Route Exact Match reaches 71\.0% on Optimal Route Generation, 50\.4% on Preference\-Aware Planning, and 64\.5% on Multi\-Route Generation\. The variation reflects task difficulty, as preference\-conditioned planning must satisfy additional hard constraints such as minimum transfers or shortest time, while multi\-route generation contends with higher label ambiguity due to multiple valid alternatives\. Performance scales monotonically with model capacity, with the 4B model gaining \+8\.9pp Route Exact Match over the 0\.6B on Optimal Route Generation\. Even our smallest 0\.6B model surpasses all six general\-purpose LLMs evaluated under more lenient conditions as shown in Table[2](https://arxiv.org/html/2605.22355#S4.T2), underscoring that domain\-specific data, rather than model scale, is the critical enabler\.

The joint variant 4B\-Joint further validates the generalizability of the learned transit knowledge\. Trained on the combined SFT data of all three tasks, it matches or exceeds the single\-task 4B counterpart on every metric across all benchmarks\. The gains are most pronounced on Preference\-Aware Planning, where connectivity improves by 2\.1 percentage points and Route Exact Match by 2\.2 percentage points, suggesting that exposure to diverse planning constraints strengthens the model’s ability to satisfy individual task requirements\. The complete absence of negative transfer on any metric confirms that the three tasks share underlying transit topology representations\. Rather than competing for model capacity, the complementary planning objectives reinforce the shared spatial knowledge, confirming that the transit knowledge encoded in the dataset is task\-agnostic and supports unified deployment with a single model\.

Table 5:Results onMulti\-Route Generationwith 10,000 test samples across four cities\. Qwen3\-4B\-25 denotes CPT on 25% of session data\. Qwen3\-4B\-Joint is fine\-tuned on the combined SFT data of all three tasks\.Table 6:Data scaling onOptimal Route Generation: Qwen3\-4B trained with varying CPT session data fractions\. All variants share identical static descriptions and SFT data\.
#### Data scaling\.

To examine how CPT data volume affects performance, we train Qwen3\-4B on four reduced session data fractions \(6\.25%, 12\.5%, 25%, 50%\) with 100% as the reference, while retaining all static descriptions and SFT data unchanged\. Table[6](https://arxiv.org/html/2605.22355#S5.T6)reports results on Optimal Route Generation, and results on the remaining two tasks are provided in Appendix[F\.4](https://arxiv.org/html/2605.22355#A6.SS4)\. All metrics improve monotonically with data volume, confirming that the current dataset scale is well\-justified\. Notably, even at 6\.25% of the CPT data, the model already achieves 94\.0% connectivity and 49\.9% Route Exact Match, demonstrating that end\-to\-end map\-free route planning is practically viable with modest data collection effort\. Different metrics exhibit distinct data sensitivity, revealing a clear learning hierarchy: basic network topology is acquired first, with connectivity reaching 94% at the smallest fraction, while precise route matching and numeric calibration are substantially more data\-hungry, as Route Exact Match drops by 21\.1 percentage points and MAPE increases from 1\.33% to 3\.26% at 6\.25%\. This pattern suggests that the model learns the structural “grammar” of transit networks rapidly but requires denser coverage to master fine\-grained route preferences and distance estimation\.

#### GPS\-only ablation\.

To disentangle the contribution of spatial knowledge acquired during training from that of textual cues present in the input query, we remove all natural\-language queries and retain only origin–destination GPS coordinates as input\. Tables[7](https://arxiv.org/html/2605.22355#S5.T7)and[8](https://arxiv.org/html/2605.22355#S5.T8)report results on Optimal Route Generation under this setting\. General\-purpose LLMs mostly drop to<<1% Route Exact Match, indicating their route planning relies on textual semantics of origin and destination names rather than spatial understanding of coordinates\. Their connectivity actually*increases*under GPS\-only input, e\.g\., DeepSeek\-V4 rises from 64\.9% to 80\.3%, yet Station Grounding plummets from 72\.0% to 16\.8%, confirming that without textual cues LLMs cannot ground the query spatially and fall back to memorized high\-frequency stations\. In contrast, our domain\-specific models exhibit near\-zero degradation\. Qwen3\-4B retains 70\.4% Route Exact Match compared to 71\.0% with text, and 4B\-Joint retains 72\.9% compared to 73\.7%, demonstrating that the planning capability is grounded in spatial representations learned through CPT rather than dependent on textual input\.

Table 7:GPS\-only ablation on general\-purpose LLMs forOptimal Route Generationover 1,000 test samples across four cities\. All textual cues are removed and only GPS coordinates are provided as input\. Estimation Accuracy and MAPE are omitted because Route Exact Match samples are too few to yield reliable estimates\. Column headers abbreviate full model names as in Table[2](https://arxiv.org/html/2605.22355#S4.T2)\.Table 8:GPS\-only ablation on our domain\-specific models forOptimal Route Generationwith 10,000 test samples across four cities\. Only raw GPS coordinates are provided as input\.
#### Additional experiments\.

CPT training dynamics \(Appendix[F\.1](https://arxiv.org/html/2605.22355#A6.SS1)\), single\-city vs\. multi\-city CPT \(Appendix[F\.2](https://arxiv.org/html/2605.22355#A6.SS2)\), effect of continual pre\-training \(Appendix[F\.3](https://arxiv.org/html/2605.22355#A6.SS3)\), data scaling and GPS\-only ablation on the remaining tasks \(Appendix[F\.4](https://arxiv.org/html/2605.22355#A6.SS4)\), and comparison with tool\-augmented LLMs \(Appendix[F\.5](https://arxiv.org/html/2605.22355#A6.SS5)\)\.

## 6Conclusion

We presented TransitLM, a large\-scale dataset of over 13 million transit route planning records across four Chinese cities, together with a three\-task benchmark and evaluation metrics that establish a standardized protocol for map\-free transit route generation\. Our experiments demonstrate that end\-to\-end transit route planning through pure text generation is feasible without any external map or routing engine: the topological, spatial, and behavioral knowledge required can be acquired entirely from data\. The resulting representations capture genuine spatial structure rather than depending on textual cues in the input query, as evidenced by near\-zero performance degradation under GPS\-only input where general\-purpose LLMs collapse\. Joint training further confirms that the acquired knowledge is task\-agnostic, as the three planning capabilities reinforce each other with no negative transfer\. The current dataset covers four cities from a single platform and captures only static route structures\. Extending to broader geographies and incorporating real\-time dynamics are natural next steps\.

## References

- \[1\]J\. Achiam, S\. Adler, S\. Agarwal, L\. Ahmad, I\. Akkaya, F\. L\. Aleman, D\. Almeida, J\. Altenschmidt, S\. Altman, S\. Anadkat,et al\.\(2023\)GPT\-4 technical report\.arXiv preprint arXiv:2303\.08774\.Cited by:[§1](https://arxiv.org/html/2605.22355#S1.p2.1)\.
- \[2\]\(2010\)Fast routing in very large public transportation networks using transfer patterns\.InEuropean Symposium on Algorithms,pp\. 290–301\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[3\]H\. Bast, D\. Delling, A\. Goldberg, M\. Müller\-Hannemann, T\. Pajor, P\. Sanders, D\. Wagner, and R\. F\. Werneck\(2016\)Route planning in transportation networks\.InAlgorithm engineering: Selected results and surveys,pp\. 19–80\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[4\]T\. Brown, B\. Mann, N\. Ryder, M\. Subbiah, J\. D\. Kaplan, P\. Dhariwal, A\. Neelakantan, P\. Shyam, G\. Sastry, A\. Askell,et al\.\(2020\)Language models are few\-shot learners\.Advances in Neural Information Processing Systems33,pp\. 1877–1901\.Cited by:[§1](https://arxiv.org/html/2605.22355#S1.p2.1)\.
- \[5\]S\. Chaudhuri, P\. Purkar, R\. Raghav, S\. Mallick, M\. Gupta, A\. Jana, and S\. Ghosh\(2025\)TripCraft: a benchmark for spatio\-temporally fine grained travel planning\.InProceedings of the 63rd Annual Meeting of the Association for Computational Linguistics,pp\. 17035–17064\.Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[6\]X\. Cheng, Y\. Hu, X\. Zhang, L\. Xu, Z\. Pan, X\. Li, and Y\. Liu\(2025\)TravelBench: a real\-world benchmark for multi\-turn and tool\-augmented travel planning\.arXiv preprint arXiv:2512\.22673\.Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[7\]Y\. De Montjoye, C\. A\. Hidalgo, M\. Verleysen, and V\. D\. Blondel\(2013\)Unique in the crowd: the privacy bounds of human mobility\.Scientific reports3\(1\),pp\. 1376\.Cited by:[Appendix H](https://arxiv.org/html/2605.22355#A8.p1.1)\.
- \[8\]D\. Delling, J\. Dibbelt, and T\. Pajor\(2019\)Fast and exact public transit routing with restricted pareto sets\.InProceedings of the Twenty\-First Workshop on Algorithm Engineering and Experiments,pp\. 54–65\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[9\]D\. Delling, T\. Pajor, and R\. F\. Werneck\(2015\)Round\-based public transit routing\.Transportation Science49\(3\),pp\. 591–604\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[10\]J\. Dibbelt, T\. Pajor, B\. Strasser, and D\. Wagner\(2018\)Connection scan algorithm\.Journal of Experimental Algorithmics23,pp\. 1–56\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[11\]E\. W\. Dijkstra\(2022\)A note on two problems in connexion with graphs\.InEdsger Wybe Dijkstra: his life, work, and legacy,pp\. 287–290\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[12\]B\. Fang, Z\. Yang, and X\. Di\(2025\)TraveLLM: could you plan my public transit alternatives in face of a network disruption?\.In2025 IEEE 28th International Conference on Intelligent Transportation Systems \(ITSC\),pp\. 4711–4717\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[13\]J\. Feng, J\. Zhang, T\. Liu, X\. Zhang, T\. Ouyang, J\. Yan, Y\. Du, S\. Guo, and Y\. Li\(2025\)CityBench: evaluating the capabilities of large language models for urban tasks\.InProceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V\. 2,pp\. 5413–5424\.Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[14\]S\. Feng, S\. Wang, S\. Ouyang, L\. Kong, Z\. Song, J\. Zhu, H\. Wang, and X\. Wang\(2025\)Can MLLMs guide me home? A benchmark study on fine\-grained visual reasoning from transit maps\.arXiv preprint arXiv:2505\.18675\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[15\]S\. Gururangan, A\. Marasović, S\. Swayamdipta, K\. Lo, I\. Beltagy, D\. Downey, and N\. A\. Smith\(2020\)Don’t stop pretraining: adapt language models to domains and tasks\.InProceedings of the 58th Annual Meeting of the Association for Computational Linguistics,pp\. 8342–8360\.Cited by:[§3\.2](https://arxiv.org/html/2605.22355#S3.SS2.p2.1),[§5\.1](https://arxiv.org/html/2605.22355#S5.SS1.p2.1)\.
- \[16\]M\. Haklay and P\. Weber\(2008\)OpenStreetMap: user\-generated street maps\.IEEE Pervasive Computing7\(4\),pp\. 12–18\.Cited by:[§2\.2](https://arxiv.org/html/2605.22355#S2.SS2.p1.1)\.
- \[17\]P\. E\. Hart, N\. J\. Nilsson, and B\. Raphael\(1968\)A formal basis for the heuristic determination of minimum cost paths\.IEEE Transactions on Systems Science and Cybernetics4\(2\),pp\. 100–107\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[18\]J\. Hoffmann, S\. Borgeaud, A\. Mensch, E\. Buchatskaya,et al\.\(2022\)Training compute\-optimal large language models\.InAdvances in Neural Information Processing Systems,pp\. 30016–30030\.Cited by:[§3\.3](https://arxiv.org/html/2605.22355#S3.SS3.p4.1)\.
- \[19\]L\. Huang, W\. Yu, W\. Ma, W\. Zhong,et al\.\(2025\)A survey on hallucination in large language models: principles, taxonomy, challenges, and open questions\.ACM Transactions on Information Systems43\(2\),pp\. 1–55\.Cited by:[§1](https://arxiv.org/html/2605.22355#S1.p2.1)\.
- \[20\]S\. Kambhampati, K\. Valmeekam, L\. Guan, M\. Verma, K\. Stechly, S\. Bhambri, L\. P\. Saldyt, and A\. B\. Murthy\(2024\)Position: LLMs can’t plan, but can help planning in LLM\-modulo frameworks\.InInternational Conference on Machine Learning,Cited by:[§1](https://arxiv.org/html/2605.22355#S1.p2.1)\.
- \[21\]S\. Lai, Y\. Ning, Z\. Yuan, Z\. Chen, and H\. Liu\(2025\)USTBench: benchmarking and dissecting spatiotemporal reasoning of LLMs as urban agents\.arXiv preprint arXiv:2505\.17572\.Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[22\]K\. Li, Y\. Tao, X\. Wen, Q\. Sun, Z\. Gong, C\. Xu, X\. Zhang, and T\. Ji\(2025\)GridRoute: a benchmark for LLM\-based route planning with cardinal movement in grid environments\.arXiv preprint arXiv:2505\.24306\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[23\]Z\. Li, W\. Zhou, Y\. Chiang, and M\. Chen\(2023\)GeoLM: empowering language models for geospatially grounded language understanding\.InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing,pp\. 5227–5240\.Cited by:[§4\.2](https://arxiv.org/html/2605.22355#S4.SS2.SSS0.Px2.p1.1)\.
- \[24\]S\. Meng, Y\. Wang, C\. Yang, N\. Peng, and K\. Chang\(2024\)LLM\-A\*: large language model enhanced incremental heuristic search on path planning\.InFindings of the Association for Computational Linguistics: EMNLP 2024,pp\. 1087–1102\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[25\]L\. Moreira\-Matias, J\. Gama, M\. Ferreira, J\. Mendes\-Moreira, and L\. Damas\(2013\)Predicting taxi–passenger demand using streaming data\.IEEE Transactions on Intelligent Transportation Systems14\(3\),pp\. 1393–1402\.Cited by:[§1](https://arxiv.org/html/2605.22355#S1.p2.1),[§2\.2](https://arxiv.org/html/2605.22355#S2.SS2.p1.1)\.
- \[26\]H\. Ni, F\. Liu, X\. Ma, L\. Su, S\. Wang, D\. Yin, H\. Xiong, and H\. Liu\(2025\)TP\-RAG: benchmarking retrieval\-augmented large language model agents for spatiotemporal\-aware travel planning\.InProceedings of the 2025 Conference on Empirical Methods in Natural Language Processing,pp\. 12403–12429\.Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[27\]L\. Ouyang, J\. Wu, X\. Jiang,et al\.\(2022\)Training language models to follow instructions with human feedback\.InAdvances in Neural Information Processing Systems,Vol\.35,pp\. 27730–27744\.Cited by:[§5\.1](https://arxiv.org/html/2605.22355#S5.SS1.p2.1)\.
- \[28\]A\. Panagopoulou, A\. Purohit, A\. Kulshrestha, S\. Yazdani, and M\. Goyal\(2025\)MapTrace: scalable data generation for route tracing on maps\.arXiv preprint arXiv:2512\.19609\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[29\]S\. Rajbhandari, J\. Rasley, O\. Ruwase, and Y\. He\(2020\)Zero: memory optimizations toward training trillion parameter models\.InSC20: international conference for high performance computing, networking, storage and analysis,pp\. 1–16\.Cited by:[Appendix E](https://arxiv.org/html/2605.22355#A5.p1.1)\.
- \[30\]T\. Schick, J\. Dwivedi\-Yu, R\. Dessì, R\. Raileanu, M\. Lomeli, E\. Hambro, L\. Zettlemoyer, N\. Cancedda, and T\. Scialom\(2023\)Toolformer: language models can teach themselves to use tools\.Advances in Neural Information Processing Systems36,pp\. 68539–68551\.Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[31\]J\. Shao, B\. Zhang, X\. Yang, B\. Chen, S\. Han, W\. Wei, G\. Cai, Z\. Dong, L\. Guo, and Y\. Li\(2025\)ChinaTravel: an open\-ended benchmark for language agents in Chinese travel planning\.InNeurIPS 2025 Workshop on Evaluating the Evolving LLM Lifecycle,Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[32\]Y\. Shen, Z\. Huang, Z\. Wang,et al\.\(2026\)TRIP\-Bench: a benchmark for long\-horizon interactive agents in real\-world scenarios\.arXiv preprint arXiv:2602\.01675\.Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[33\]Z\. Song, J\. Zhang, C\. Qin,et al\.\(2026\)MobilityBench: a benchmark for evaluating route\-planning agents in real\-world mobility scenarios\.arXiv preprint arXiv:2602\.22638\.Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[34\]K\. Valmeekam, M\. Marquez, S\. Sreedharan, and S\. Kambhampati\(2023\)On the planning abilities of large language models – a critical investigation\.InAdvances in Neural Information Processing Systems,Vol\.36,pp\. 75993–76005\.Cited by:[§1](https://arxiv.org/html/2605.22355#S1.p2.1)\.
- \[35\]K\. Wang, Y\. Shen, C\. Lv, X\. Zheng, and X\. Huang\(2025\)TripTailor: a real\-world benchmark for personalized travel planning\.InFindings of the Association for Computational Linguistics: ACL 2025,pp\. 9705–9723\.Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[36\]L\. Wang, H\. Wei, Y\. Guan, L\. Ouyang, D\. Xu, X\. Han, M\. Zhang, M\. Chen, D\. Sun, D\. Gong,et al\.\(2026\)China public transport operation network dataset \(CPTOND\-2025\): national\-scale bus\-metro vector dataset\.Scientific Data\.Cited by:[§1](https://arxiv.org/html/2605.22355#S1.p2.1),[§2\.2](https://arxiv.org/html/2605.22355#S2.SS2.p1.1)\.
- \[37\]J\. Wei, M\. Bosma, V\. Zhao, K\. Guu, A\. W\. Yu, B\. Lester, N\. Du, A\. M\. Dai, and Q\. V\. Le\(2022\)Finetuned language models are zero\-shot learners\.InInternational Conference on Learning Representations,Cited by:[§5\.1](https://arxiv.org/html/2605.22355#S5.SS1.p2.1)\.
- \[38\]J\. Wong\(2013\)Leveraging the general transit feed specification for efficient transit analysis\.Transportation Research Record2338\(1\),pp\. 11–19\.Cited by:[§1](https://arxiv.org/html/2605.22355#S1.p2.1),[§2\.2](https://arxiv.org/html/2605.22355#S2.SS2.p1.1)\.
- \[39\]J\. Xie, K\. Zhang, J\. Chen, T\. Zhu, R\. Lou, Y\. Tian, Y\. Xiao, and Y\. Su\(2024\)TravelPlanner: a benchmark for real\-world planning with language agents\.InInternational Conference on Machine Learning,pp\. 54590–54613\.Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[40\]S\. Xing, Z\. Sun, S\. Xie, K\. Chen, Y\. Huang, Y\. Wang, J\. Li, D\. Song, and Z\. Tu\(2025\)MapBench: can large vision language models read maps like a human?\.arXiv preprint arXiv:2503\.14607\.Cited by:[§2\.1](https://arxiv.org/html/2605.22355#S2.SS1.p1.1)\.
- \[41\]A\. Yang, A\. Li, B\. Yang, B\. Zhang, B\. Hui, B\. Zheng, B\. Yu, C\. Gao, C\. Huang, C\. Lv,et al\.\(2025\)Qwen3 technical report\.arXiv preprint arXiv:2505\.09388\.Cited by:[§1](https://arxiv.org/html/2605.22355#S1.p2.1),[§5\.1](https://arxiv.org/html/2605.22355#S5.SS1.p1.1)\.
- \[42\]J\. Yuan, Y\. Zheng, C\. Zhang, W\. Xie, X\. Xie, G\. Sun, and Y\. Huang\(2010\)T\-drive: driving directions based on taxi trajectories\.InProceedings of the 18th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems,pp\. 99–108\.Cited by:[Appendix H](https://arxiv.org/html/2605.22355#A8.p1.1),[§1](https://arxiv.org/html/2605.22355#S1.p2.1),[§2\.2](https://arxiv.org/html/2605.22355#S2.SS2.p1.1)\.
- \[43\]H\. S\. Zheng, S\. Mishra, H\. Zhang, X\. Chen, M\. Chen, A\. Nova, L\. Hou, H\. Cheng, Q\. V\. Le, E\. H\. Chi,et al\.\(2024\)NATURAL PLAN: benchmarking LLMs on natural language planning\.arXiv preprint arXiv:2406\.04520\.Cited by:[§2\.3](https://arxiv.org/html/2605.22355#S2.SS3.p1.1)\.
- \[44\]Y\. Zheng, X\. Xie, and W\. Ma\(2010\)GeoLife: a collaborative social networking service among user, location and trajectory\.IEEE Data Engineering Bulletin33\(2\),pp\. 32–39\.Cited by:[Appendix H](https://arxiv.org/html/2605.22355#A8.p1.1),[§2\.2](https://arxiv.org/html/2605.22355#S2.SS2.p1.1)\.
- \[45\]Y\. Zheng\(2015\)Trajectory data mining: an overview\.ACM Transactions on Intelligent Systems and Technology6\(3\),pp\. 1–41\.Cited by:[§2\.2](https://arxiv.org/html/2605.22355#S2.SS2.p1.1)\.

## Appendix AData Visualization

Figure[3](https://arxiv.org/html/2605.22355#A1.F3)visualizes the spatial distribution of route planning origins across the four cities\. The heatmaps reveal dense coverage in urban cores with natural dispersion toward suburban areas, confirming that the dataset reflects real\-world transit demand patterns rather than synthetic or uniformly sampled coordinates\.

![Refer to caption](https://arxiv.org/html/2605.22355v1/x3.png)Figure 3:Geographic distribution of route planning origins across the four cities\. Density reflects real\-world transit demand concentration in urban cores\.
## Appendix BCPT Corpus Sample

The CPT corpus consists of two complementary components: \(1\)session recordsderived from real\-world transit planning sessions, each pairing an origin–destination request with candidate routes, and \(2\)static descriptionsof transit lines and stations\. The original corpus is in Chinese; English translations are provided below for readability\.

#### Session Records\.

Each session record follows aquery→\\rightarrowroute optionsstructure\. The query specifies the city, origin–destination GPS coordinates, and POI names\. Each candidate route details the transport mode, line name, per\-segment distance and time, fare, boarding/alighting stations with coordinates, and the complete station ID sequence\.

CPT Session RecordQuery:How to get to Yongtai Dongli? City:BeijingOrigin:116\.398261, 39\.889556Dest:116\.358844, 40\.034880Option 1\(Subway, 21\.3 km, 55 min, 5 yuan\) Walk 170 m \(2 min\) to bus\-899931 \(Zhushikou, 116\.398375, 39\.889961\)\. Take Subway Line 8 to bus\-893448 \(Yongtaizhuang, 116\.354580, 40\.037728\), 20\.3 km, 41 min\. Walk 880 m to destination\. Stations:bus\-899931, bus\-900093, …, bus\-893448\.Option 2\(Bus, 20\.8 km, 1h 55min, 5 yuan\) Walk 524 m to bus\-899401 \(Banzhang Rd, 116\.394073, 39\.890199\)\. Take Bus 5 to bus\-897760 \(Madian Bridge S\., 116\.397834, 39\.959271\), 10\.7 km, 54 min\. \[Transfer\]Take Bus 625 to bus\-892356 \(Qinghe, 116\.348232, 40\.030627\), 8\.3 km, 34 min\. Walk 1\.4 km to destination\. Stations:bus\-899401, …, bus\-897760, \[transfer\], bus\-897760, …, bus\-892356\.

#### Static Descriptions\.

The corpus also includes structured descriptions of individual transit lines and stations, encoding attributes such as route length, stop count, operating hours, fare policy, coordinates, and connectivity to neighboring stations\.

CPT Static DescriptionsLine Description Line:Zhuan\-117 \(Tiantongyuan North Hub – Yandan\) Type:Micro\-circulation busLength:5\.3 kmStops:9 Hours:05:50–22:30Fare:2 yuan \(flat\) Stop sequence: \#1 Tiantongyuan North Hub \(bus\-901618\)→\\rightarrow\#2 Tiantong Beiyuan Block 1 North Gate \(bus\-902625\)→\\rightarrow\#3 Tiantong Beiyuan Block 2 North Gate \(bus\-903364\)→\\rightarrow\#4 Shiziying \(bus\-904346\)→\\rightarrow\#5 Tiantong Beiyuan Block 3 North Gate \(bus\-904981\)→\\rightarrow\#6 Qixing Rd South \(bus\-905417\)→\\rightarrow\#7 Yanchengyuan Intersection South \(bus\-905008\)→\\rightarrow\#8 Yanchengyuan \(bus\-905518\)→\\rightarrow\#9 Yandan \(bus\-905652\)\.Station Description Station:Pinggu No\.4 Middle School \(bus\-1000071\) District:Pinggu, BeijingLines served:2 Coordinates:\(117\.089436, 40\.130547\) Connectivity:From this station, take Line Ping\-2 \(Passenger Terminal – Pinggu No\.7 Primary School\) to Yuming School \(bus\-1000202\)\.

## Appendix CBenchmark SFT Examples

Each benchmark task uses a standardized prompt–label format\. The prompt contains a system instruction describing the task, followed by a user request with origin–destination coordinates\. The label is a structured JSON object encoding the expected route\. Below we show representative examples for all three tasks; the original text is in Chinese and translated here for readability\.

#### Optimal Route Generation\.

Given origin–destination coordinates, the model generates a single optimal transit route as a structured JSON object\.

Prompt & LabelSystem Prompt You are a public transit route planning expert, familiar with bus and subway networks\.Task:Given the user’s origin and destination coordinates, plan an optimal transit route\.Input:query,start\(lng, lat\),end\(lng, lat\),city\.Output \(JSON\):line\_sequence,station\_sequence\(with\[Transfer\]\),total\_distance,total\_time,total\_fare,start\_transfer\_mode/distance,end\_transfer\_mode/distance\.Prompt \{"query": "How to get to BIT \(South Gate\)?", "start": "116\.395310,39\.963284", "end": "116\.316356,39\.957053", "city": "Beijing"\}Label \{"line\_sequence": \["Subway Line 12", "Subway Line 4"\], "station\_sequence": \["bus\-899733", "bus\-898054", \.\.\., "bus\-888019", "\[Transfer\]", "bus\-887631", "bus\-887990"\], "total\_distance": "9\.2 km", "total\_time": "49 min", "total\_fare": "4 yuan", "start\_transfer\_mode": "walking", "start\_transfer\_distance": "896 m", "end\_transfer\_mode": "walking", "end\_transfer\_distance": "759 m"\}

#### Preference\-Aware Planning\.

In addition to coordinates, the prompt includes a user preference constraint\. The model must produce a route that satisfies the stated preference while maintaining overall quality\.

Prompt & LabelSystem Prompt You are a public transit route planning expert, familiar with bus and subway networks\.Task:Given the user’s origin and destination coordinates along with a stated preference, plan a transit route that satisfies the preference while maintaining overall route quality\.Input:query\(with preference\),start\(lng, lat\),end\(lng, lat\),city\.Output \(JSON\):line\_sequence,station\_sequence\(with\[Transfer\]\),total\_distance,total\_time,total\_fare,start\_transfer\_mode/distance,end\_transfer\_mode/distance\.Prompt \{"query": "How to get to Jingshan Park by bus? Bus\-first\.", "start": "116\.421180,39\.880405", "end": "116\.396551,39\.925875", "city": "Beijing"\}Label \{"line\_sequence": \["Bus 128 \(Xiaocunqiao N\.\-\-Beijing No\.39 Middle School\)"\], "station\_sequence": \["bus\-903008", "bus\-902952", "bus\-902743", "bus\-902705", "bus\-902688", "bus\-902629", "bus\-902600", "bus\-902571", "bus\-902555", "bus\-902495", "bus\-902472", "bus\-901722", "bus\-900713", "bus\-899614"\], "total\_distance": "7\.0 km", "total\_time": "53 min", "total\_fare": "2 yuan", "start\_transfer\_mode": "walking", "start\_transfer\_distance": "143 m", "end\_transfer\_mode": "walking", "end\_transfer\_distance": "145 m"\}

#### Multi\-Route Generation\.

The model produces three diverse transit routes for a single origin–destination pair\. Each route should adopt a different mode or line combination to offer meaningful travel alternatives, while maintaining overall route quality\.

Prompt & LabelSystem Prompt You are a public transit route planning expert, familiar with bus and subway networks\.Task:Given origin–destination coordinates and city, plan three diverse transit routes using different mode or line combinations\.Input:query,start\(lng, lat\),end\(lng, lat\),city\.Output \(JSON\):Three route objects \(first,second,third\), each containingroute\_tag,line\_sequence,station\_sequence,total\_distance,total\_time,total\_fare,start/end\_transfer\_mode/distance\.Prompt \{"query": "How to get from Tongji Univ\. to Shanghai Pudong Intl\. Airport by public transit? Give me a few options\.", "start": "121\.513244,31\.282003", "end": "121\.808681,31\.142267", "city": "Shanghai"\}Label \{"first": \{"route\_tag": "Subway", "line\_sequence": \["Subway Line 18", "Subway Line 2"\], "station\_sequence": \["bus\-1670095", …, "bus\-1677113", "\[Transfer\]", "bus\-1677227", …, "bus\-1701975"\], "total\_distance": "41\.1 km", "total\_time": "1h 22min", "total\_fare": "7 yuan", "start\_transfer\_mode": "walking", "start\_transfer\_distance": "169 m", "end\_transfer\_mode": "walking", "end\_transfer\_distance": "22 m"\}, "second": \{"route\_tag": "Bus\+Subway", "line\_sequence": \["Subway Line 18", "Maglev Line"\], "station\_sequence": \[…\], …\}, "third": \{"route\_tag": "Bus", "line\_sequence": \["Airport Express Line 4"\], "station\_sequence": \[…\], …\}\}

## Appendix DEvaluation Metrics

This appendix provides the formal definitions of all evaluation metrics introduced in Section[4](https://arxiv.org/html/2605.22355#S4)\. The metrics cover four complementary dimensions:Connectivityverifies structural correctness of the predicted station sequence;Access Feasibilitychecks whether first/last\-mile access is physically plausible;Route Overlapmeasures structural match between predicted and label routes; andNumeric Field Accuracyassesses the accuracy of predicted numeric fields\. In addition, Preference\-Aware Planning and Multi\-Route Generation define task\-specific metrics for preference compliance and route diversity, respectively\. Table[9](https://arxiv.org/html/2605.22355#A4.T9)provides a quick\-reference summary of all metric abbreviations\.

Table 9:Evaluation metrics and abbreviations\.MetricAbbr\.DescriptionEvaluation DimensionsConnectivityConnConsecutive stations reachable in the transit network\[0\.4pt/3pt\] Access FeasibilityFirst/last\-mile access plausibilityStation GroundingSGFirst/last station within mode\-specific distance of ODDistance PlausibilityDPPred\. access dist\. matches OD\-to\-station straight\-line\[0\.4pt/3pt\] Route OverlapStructural match between predicted and label routesLine OverlapLOIoU of full line sets including access segmentsStation Sequence OverlapSSOIoU of station ID setsRoute Exact MatchREMFraction of samples with LO = 1 and SSO = 1\[0\.4pt/3pt\] Numeric Field AccuracyAccuracy of predicted numeric fieldsEstimation AccuracyEAAvg\. pass rate over distance, time, and fareMean Absolute Percentage ErrorMAPEAvg\. relative error over distance, time, and fareTask\-specific MetricsPreference CompliancePCStated preference satisfiedRoute DiversityRDPairwise line\-set dissimilarity

### D\.1Connectivity

Connectivity is the first evaluation dimension, verifying that the predicted station sequence forms a structurally valid path in the transit network\. A predicted route is*connected*if and only if every consecutive station pair\(si,si\+1\)\(s\_\{i\},s\_\{i\+1\}\)in the generated sequence is reachable, either on the same line or via a valid transfer recorded in the city’s transfer table\. Connectivity is reported as the percentage of test samples whose predicted routes are fully connected:

Conn=1N∑i=1N𝟏\[∀1≤j<L\(i\),\(sj\(i\),sj\+1\(i\)\)∈ℰ\]\\text\{Conn\}=\\frac\{1\}\{N\}\\sum\_\{i=1\}^\{N\}\\mathbf\{1\}\\\!\\left\[\\,\\forall\\,1\\leq j<L^\{\(i\)\},\\;\(s\_\{j\}^\{\(i\)\},s\_\{j\+1\}^\{\(i\)\}\)\\in\\mathcal\{E\}\\,\\right\]\(1\)whereL\(i\)L^\{\(i\)\}is the length of the predicted station sequence for sampleiiandℰ\\mathcal\{E\}is the set of station pairs that are adjacent on a shared line or connected via an inter\-line transfer\. Connectivity serves as a prerequisite: all subsequent metrics except task\-specific ones \(PC, RD\) are computed only on connected samples\.

### D\.2Access Feasibility

Access Feasibility is the second evaluation dimension\. While Connectivity verifies reachability among intermediate stations, this metric validates the first/last\-mile segments, jointly ensuring that the entire origin\-to\-destination path is both connected and accessible\. For each access segment, letdgeod\_\{\\text\{geo\}\}denote the straight\-line \(Haversine\) distance between the origin/destination and the predicted boarding/alighting station, and letdpredd\_\{\\text\{pred\}\}denote the predicted access distance\. Letas\(i\)a\_\{\\mathrm\{s\}\}^\{\(i\)\}andae\(i\)a\_\{\\mathrm\{e\}\}^\{\(i\)\}denote the start and end access segments of sampleii\.

#### Station Grounding\.

This metric evaluates whether the model can implicitly map raw GPS coordinates to nearby transit stations without any explicit coordinate\-to\-station lookup module\. A high pass rate indicates that the model has learned spatial grounding purely from training data\. The straight\-line distance between the origin/destination and the predicted boarding/alighting station must not exceed a mode\-specific threshold:

The pass rate is:

SG=1N​∑i=1N𝟏​\[dgeo​\(as\(i\)\)≤τms∧dgeo​\(ae\(i\)\)≤τme\]\\text\{SG\}=\\frac\{1\}\{N\}\\sum\_\{i=1\}^\{N\}\\mathbf\{1\}\\\!\\left\[\\,d\_\{\\text\{geo\}\}\(a\_\{\\mathrm\{s\}\}^\{\(i\)\}\)\\leq\\tau\_\{m\_\{\\mathrm\{s\}\}\}\\;\\wedge\\;d\_\{\\text\{geo\}\}\(a\_\{\\mathrm\{e\}\}^\{\(i\)\}\)\\leq\\tau\_\{m\_\{\\mathrm\{e\}\}\}\\,\\right\]\(2\)whereτm\\tau\_\{m\}is the mode\-specific threshold from the table above\.

#### Distance Plausibility\.

While Station Grounding validates spatial proximity, this metric further verifies that the predicted access distance is physically realistic rather than a hallucinated value\. A plausible access distance must satisfy two conditions:

- •dpred≥dgeod\_\{\\text\{pred\}\}\\geq d\_\{\\text\{geo\}\}\(predicted distance must not fall below the geometric lower bound\)
- •dpred≤3⋅dgeod\_\{\\text\{pred\}\}\\leq 3\\cdot d\_\{\\text\{geo\}\}\(predicted distance not unreasonably large\)

Letϕ​\(a\)=𝟏​\[dgeo​\(a\)≤dpred​\(a\)≤3⋅dgeo​\(a\)\]\\phi\(a\)=\\mathbf\{1\}\[d\_\{\\text\{geo\}\}\(a\)\\leq d\_\{\\text\{pred\}\}\(a\)\\leq 3\\cdot d\_\{\\text\{geo\}\}\(a\)\]\. The pass rate is:

DP=1N​∑i=1Nϕ​\(as\(i\)\)⋅ϕ​\(ae\(i\)\)\\text\{DP\}=\\frac\{1\}\{N\}\\sum\_\{i=1\}^\{N\}\\phi\(a\_\{\\mathrm\{s\}\}^\{\(i\)\}\)\\cdot\\phi\(a\_\{\\mathrm\{e\}\}^\{\(i\)\}\)\(3\)The upper\-bound factor of 3 is empirically set as a plausibility threshold: real\-world access distances rarely exceed three times the straight\-line distance, so predictions beyond this bound are considered implausible\.

### D\.3Route Overlap

Route Overlap is the third evaluation dimension, quantifying the structural match between a predicted route and its ground\-truth counterpart\. For Optimal Route Generation and Preference\-Aware Planning, the single predicted route is directly compared against the label\. For Multi\-Route Generation, the first predicted route is used for comparison, as the task requires the first output route to be the ground\-truth route, and the training and evaluation data are constructed accordingly\. Both Line Overlap and Station Sequence Overlap are defined via Intersection\-over\-Union \(IoU\):

IoU​\(A,B\)=\|A∩B\|\|A∪B\|\\text\{IoU\}\(A,B\)=\\frac\{\|A\\cap B\|\}\{\|A\\cup B\|\}\(4\)ForLine Overlap\(LO\),AAandBBare the full line sets of the predicted and ground\-truth routes, including first/last\-mile access segments \(e\.g\., cycling, taxi\)\. ForStation Sequence Overlap\(SSO\),AAandBBare the corresponding station ID sets\.

Route Exact Match\(REM\) measures the fraction of samples whose predicted and ground\-truth routes are structurally identical in both lines and stations:

REM=1N​∑i=1N𝟏​\[LO\(i\)=1∧SSO\(i\)=1\]\\text\{REM\}=\\frac\{1\}\{N\}\\sum\_\{i=1\}^\{N\}\\mathbf\{1\}\\\!\\left\[\\,\\text\{LO\}^\{\(i\)\}=1\\;\\wedge\\;\\text\{SSO\}^\{\(i\)\}=1\\,\\right\]\(5\)

### D\.4Numeric Field Accuracy

Numeric Field Accuracy is the fourth evaluation dimension, measuring how accurately the model predicts route\-level numeric attributes\. Letℱ=\{distance,time,fare\}\\mathcal\{F\}=\\\{\\text\{distance\},\\text\{time\},\\text\{fare\}\\\}denote the set of route\-level numeric fields\. Evaluation is restricted to samples that achieve Route Exact Match, i\.e\., bothLO=1\\text\{LO\}=1andSSO=1\\text\{SSO\}=1, as only under this condition do the ground\-truth numeric fields constitute valid references\. Letℳ\\mathcal\{M\}denote this set of matched samples\.

Estimation Accuracy \(EA\)\.For each fieldf∈ℱf\\in\\mathcal\{F\}, a prediction passes if it satisfieseithera relative toleranceoran absolute tolerance:

EAf=1\|ℳ\|​∑i∈ℳ𝟏​\[\|y^f\(i\)−yf\(i\)\|yf\(i\)≤10%​or​\|y^f\(i\)−yf\(i\)\|≤ϵf\]\\text\{EA\}\_\{f\}=\\frac\{1\}\{\|\\mathcal\{M\}\|\}\\sum\_\{i\\in\\mathcal\{M\}\}\\mathbf\{1\}\\\!\\left\[\\frac\{\|\\hat\{y\}\_\{f\}^\{\(i\)\}\-y\_\{f\}^\{\(i\)\}\|\}\{y\_\{f\}^\{\(i\)\}\}\\leq 10\\%\\;\\;\\text\{or\}\\;\\;\|\\hat\{y\}\_\{f\}^\{\(i\)\}\-y\_\{f\}^\{\(i\)\}\|\\leq\\epsilon\_\{f\}\\right\]\(6\)whereϵtime=5​min\\epsilon\_\{\\text\{time\}\}=5\\,\\text\{min\},ϵdistance=500​m\\epsilon\_\{\\text\{distance\}\}=500\\,\\text\{m\}, andϵfare=1​CNY\\epsilon\_\{\\text\{fare\}\}=1\\,\\text\{CNY\}\. The reported EA is the average across all fields:EA=1\|ℱ\|​∑f∈ℱEAf\\text\{EA\}=\\frac\{1\}\{\|\\mathcal\{F\}\|\}\\sum\_\{f\\in\\mathcal\{F\}\}\\text\{EA\}\_\{f\}\. The dual\-tolerance design ensures that predictions with small absolute error but inflated relative error \(due to small denominators\) are not penalized, and likewise for predictions with small relative error but large absolute difference\.

Mean Absolute Percentage Error \(MAPE\)\.While EA provides a binary pass/fail judgment, MAPE quantifies the continuous error magnitude\. The per\-field MAPE is:

MAPEf=1\|ℳ\|​∑i∈ℳ\|y^f\(i\)−yf\(i\)\|yf\(i\)\\text\{MAPE\}\_\{f\}=\\frac\{1\}\{\|\\mathcal\{M\}\|\}\\sum\_\{i\\in\\mathcal\{M\}\}\\frac\{\|\\hat\{y\}\_\{f\}^\{\(i\)\}\-y\_\{f\}^\{\(i\)\}\|\}\{y\_\{f\}^\{\(i\)\}\}\(7\)The reported MAPE is the average across all fields:MAPE=1\|ℱ\|​∑f∈ℱMAPEf\\text\{MAPE\}=\\frac\{1\}\{\|\\mathcal\{F\}\|\}\\sum\_\{f\\in\\mathcal\{F\}\}\\text\{MAPE\}\_\{f\}\.

### D\.5Preference Compliance

Preference Compliance is a task\-specific metric for Preference\-Aware Planning that evaluates whether the model can generate routes adhering to an explicit user preference\. Letrgtr\_\{\\text\{gt\}\}denote the ground\-truth route\. For each preference type, compliance is determined by a hard rule:

The tolerance factorα\\alphafor shortest time accounts for the inherent imprecision of predicted numeric values\. Preference Compliance is reported as the percentage of test samples whose predicted routes satisfy the corresponding rule\. Note that the theoretical upper bound of this metric is below 100%: routes that strictly satisfy a preference may have poor overall quality, so the ground\-truth labels prioritize route quality and do not always comply with the hard rule\.

### D\.6Route Diversity

Route Diversity is a task\-specific metric for Multi\-Route Generation that evaluates whether the model can produce structurally distinct alternatives rather than near\-duplicate routes\. For each sample, the pairwise dissimilarity over all\(32\)=3\\binom\{3\}\{2\}=3route pairs is:

RD\(k\)=13​∑\(i,j\)\(1−IoU​\(ℒi\(k\),ℒj\(k\)\)\)\\text\{RD\}^\{\(k\)\}=\\frac\{1\}\{3\}\\sum\_\{\(i,j\)\}\(1\-\\text\{IoU\}\(\\mathcal\{L\}\_\{i\}^\{\(k\)\},\\mathcal\{L\}\_\{j\}^\{\(k\)\}\)\)\(8\)whereℒi\(k\)\\mathcal\{L\}\_\{i\}^\{\(k\)\}is the full line set of routeiiin samplekk, including cycling and taxi access segments\. The reported metric is the average over allNNtest samples:RD=1N​∑k=1NRD\(k\)\\text\{RD\}=\\frac\{1\}\{N\}\\sum\_\{k=1\}^\{N\}\\text\{RD\}^\{\(k\)\}\. Values range from 0 \(all routes identical\) to 1 \(no shared lines\)\. Route Diversity should be evaluated jointly with the four evaluation dimensions, as maximizing diversity alone may sacrifice route quality\. The two metrics together capture whether the model produces varied yet practically viable alternatives\.

## Appendix EHyperparameters

Table[10](https://arxiv.org/html/2605.22355#A5.T10)summarizes all hyperparameters used in training and inference\. During CPT, all sequences are packed to the fixed sequence length with no padding, so the training budget is measured in steps rather than epochs\. During SFT, sequences are not packed and instead processed at their natural length with standard padding; the loss is computed only on the response tokens, with prompt tokens masked\. Both stages use DeepSpeed ZeRO\-3\[[29](https://arxiv.org/html/2605.22355#bib.bib44)\]for distributed training\. Greedy decoding with a fixed seed is used for all benchmark evaluations to ensure deterministic and reproducible outputs\.

Table 10:Hyperparameters for training and inference\.
## Appendix FAdditional Experiments

### F\.1CPT Training Dynamics

Figure[4](https://arxiv.org/html/2605.22355#A6.F4)plots the CPT training loss for the three backbone models over approximately 15k steps \(≈\\approx3 epochs\)\. All models drop from\>\>1\.0 to approximately 0\.1 within the first 2k steps, indicating that domain\-specific token distributions are learned early regardless of model capacity\. The inset \(steps 4k–14k\) reveals a stable ordering Qwen3\-4B<<Qwen3\-1\.7B<<Qwen3\-0\.6B in loss, consistent with downstream performance in Tables[3](https://arxiv.org/html/2605.22355#S5.T3)–[5](https://arxiv.org/html/2605.22355#S5.T5)\. Loss continues to decrease through Epochs 2 and 3 \(e\.g\., 4B: 0\.084→\\to0\.070\), suggesting that later epochs further consolidate transit\-domain knowledge rather than overfit\. Wall\-clock training time on 64 PPUs is approximately 6 days for Qwen3\-4B, 3 days for Qwen3\-1\.7B, and 1\.5 days for Qwen3\-0\.6B, scaling approximately with model size\.

![Refer to caption](https://arxiv.org/html/2605.22355v1/x4.png)Figure 4:CPT training loss curves for Qwen3\-0\.6B, Qwen3\-1\.7B, and Qwen3\-4B over≈\\approx15k steps\. The inset magnifies steps 4k–14k to highlight the sustained loss reduction and the capacity gap across model sizes\.
### F\.2Single\-City vs\. Multi\-City CPT

Our framework introduces every station ID as a new token in the vocabulary\. Scaling from one city to four increases the station vocabulary from 38,792 to 120,845, a 3\.1×\\timesexpansion\. Because the total CPT data volume is held constant, each Beijing station receives roughly one\-third as many training examples under the multi\-city setting\. This ablation examines whether the resulting token\-level sparsity degrades per\-city performance, and whether cross\-city training provides compensating knowledge transfer\. To this end, we train a single\-city model on Beijing data only, using the same Qwen3\-4B base and identical CPT data volume as the four\-city model\. Both models are evaluated on the Beijing test set of 10,000 samples for Optimal Route Generation\. Table[11](https://arxiv.org/html/2605.22355#A6.T11)reports the comparison\.

Table 11:Single\-city vs\. multi\-city CPT onOptimal Route Generation, evaluated on the Beijing test set with 10,000 samples\. The single\-city model is trained on Beijing data only, while the multi\-city model covers all four cities\. Both use the same total CPT data volume and identical SFT data\.Δ\\Deltadenotes the change from Beijing\-only to four\-city\.↑\\uparrow/↓\\downarrowindicate higher/lower is better\.Bold: better of the two\.Despite a 3\.1×\\timesvocabulary expansion and proportionally fewer per\-station training examples, the four\-city model trails the Beijing\-only model by only 3\.5 percentage points in Route Exact Match\. This confirms that token\-level sparsity introduced by city scaling does not cause significant performance degradation\. Station Grounding and Estimation Accuracy are slightly higher under multi\-city training, suggesting that shared spatial patterns across cities provide positive knowledge transfer that partially compensates for reduced per\-station coverage\. The minor increase in MAPE and decrease in route\-level overlap metrics represent a modest cost of distributing the same data budget across a larger station vocabulary\. These results validate that the proposed framework scales gracefully to additional cities, directly supporting the future direction of extending coverage to broader geographies\.

### F\.3Effect of Continual Pre\-Training

To isolate the contribution of continual pre\-training, we construct an SFT\-only baseline that bypasses the CPT stage and instead trains the base Qwen3\-4B model directly on the same volume of session data used by CPT\-25%, reformatted as supervised fine\-tuning examples\. This ensures that the comparison controls for total data volume rather than merely removing a training stage\. We additionally include CPT\-25%, CPT\-100%, and the multi\-task 4B\-Joint model\. All variants share identical station token vocabulary and are evaluated on the same test set\. Each configuration is evaluated under both standard text input and GPS\-only input to probe the robustness of the learned representations\. Table[12](https://arxiv.org/html/2605.22355#A6.T12)reports the results\.

Table 12:Effect of continual pre\-training onOptimal Route Generationwith 10,000 test samples\. SFT\-only bypasses the CPT stage and trains on the same session data volume as CPT\-25%, reformatted as SFT examples\. All variants share identical station token vocabulary and test set\. Each configuration is evaluated under standard text and GPS\-only input\.↑\\uparrow/↓\\downarrowindicate higher/lower is better\.Bold: best;underline: second best\.Under standard text input, SFT\-only achieves the highest Route Exact Match at 74\.9%, surpassing even CPT\-100% at 71\.0% and 4B\-Joint at 73\.7%\. However, the GPS\-only evaluation reverses this ranking\. When textual cues are removed, SFT\-only Route Exact Match drops by 8\.8 percentage points, Estimation Accuracy collapses by 21\.8 percentage points, and MAPE nearly quadruples from 1\.35% to 4\.96%\. All CPT\-based models remain nearly unchanged, with Route Exact Match declining by at most 0\.8 percentage points\. The 4B\-Joint model exhibits the smallest EA degradation at only 0\.5 percentage points and the lowest GPS\-only MAPE at 1\.52%\.

This asymmetry reveals that the two training strategies produce representations of fundamentally different nature\. The SFT\-only model relies disproportionately on textual cues in the query to infer spatial context, yielding strong performance when such cues are available but degrading sharply without them\. CPT forces the model to acquire spatial representations from raw transit network data before any task\-specific supervision\. The resulting representations encode network topology and spatial relationships independently of prompt templates, making them inherently task\-agnostic\. The 4B\-Joint results confirm this directly\. Built on CPT\-derived representations, Joint training achieves the best GPS\-only performance across all metrics, demonstrating that CPT\-stage spatial knowledge transfers to multi\-task settings with no negative interference\. SFT\-only training, having entangled spatial knowledge with task\-specific input formats, lacks this transferable foundation and cannot support multi\-task co\-optimization\.

Table 13:Data scaling onPreference\-Aware Planning: Qwen3\-4B trained with varying CPT session data fractions \(6\.25%, 12\.5%, 25%, 50%\) with 100% as the reference\. All variants share identical static descriptions and SFT data\.↑\\uparrow/↓\\downarrowindicate higher/lower is better\.Bold: best;underline: second best\.Table 14:Data scaling onMulti\-Route Generation: Qwen3\-4B trained with varying CPT session data fractions \(6\.25%, 12\.5%, 25%, 50%\) with 100% as the reference\. All variants share identical static descriptions and SFT data\.↑\\uparrow/↓\\downarrowindicate higher/lower is better\.Bold: best;underline: second best\.Table 15:GPS\-only ablation on our domain\-specific models forPreference\-Aware Planningwith 10,000 test samples across four cities\. All textual cues are removed and only origin–destination GPS coordinates with preference type are provided as input\.↑\\uparrow/↓\\downarrowindicate higher/lower is better\.Bold: best;underline: second best\.Table 16:GPS\-only ablation on our domain\-specific models forMulti\-Route Generationwith 10,000 test samples across four cities\. All textual cues are removed and only origin–destination GPS coordinates are provided as input\.↑\\uparrow/↓\\downarrowindicate higher/lower is better\.Bold: best;underline: second best\.Table 17:Tool\-augmented LLM results onOptimal Route Generationover 1,000 test samples\. Each LLM retrieves candidate routes from the Amap transit routing API and selects the best one\. Estimation Accuracy and MAPE are omitted as numeric fields are inherited from the API\. Column headers follow Table[2](https://arxiv.org/html/2605.22355#S4.T2)\.
### F\.4Data Scaling and GPS\-only Ablation on Other Tasks

Tables[13](https://arxiv.org/html/2605.22355#A6.T13)and[14](https://arxiv.org/html/2605.22355#A6.T14)extend the data scaling analysis from Section[5](https://arxiv.org/html/2605.22355#S5)to Preference\-Aware Planning and Multi\-Route Generation\. Both tasks exhibit the same monotonic improvement across all metrics as CPT data volume increases, confirming that the learning hierarchy observed on Optimal Route Generation generalizes to preference\-conditioned and multi\-route settings\. Task\-specific metrics also improve consistently, with Preference Compliance rising from 87\.3% to 89\.8% on Preference\-Aware Planning and Route Diversity from 0\.507 to 0\.545 on Multi\-Route Generation\.

Tables[15](https://arxiv.org/html/2605.22355#A6.T15)and[16](https://arxiv.org/html/2605.22355#A6.T16)report the GPS\-only ablation results on the same two tasks\. Consistent with the findings in Section[5](https://arxiv.org/html/2605.22355#S5), all domain\-specific models maintain strong performance when textual cues are removed\. The 4B\-Joint model achieves the best GPS\-only results across nearly all metrics on both tasks, with Route Exact Match reaching 51\.8% on Preference\-Aware Planning and 66\.1% on Multi\-Route Generation\. Model size scaling follows the same pattern observed on Optimal Route Generation, with larger models consistently outperforming smaller ones under GPS\-only input\.

### F\.5Comparison with Tool\-Augmented LLMs

A natural concern is whether the comparison in Table[2](https://arxiv.org/html/2605.22355#S4.T2)adequately represents the strongest competing paradigm\. In production systems, general\-purpose LLMs are typically augmented with external tools rather than used in isolation\. To address this, we evaluate a retrieval\-augmented generation configuration where each LLM operates as an agent that invokes the Amap transit routing API to retrieve candidate routes for a given origin\-destination pair, and then selects the optimal route from the returned set\.

This setup constitutes the most competitive industrial alternative to end\-to\-end generation\. Unlike TransitLM, it is not map\-free, as the system depends on an external routing engine with access to the full transit network topology, real\-time service schedules, and traffic conditions\. We use the same six general\-purpose LLMs, the same 1,000 test samples, and the same simplified output format as Table[2](https://arxiv.org/html/2605.22355#S4.T2)\. Numeric fields such as distance, time, and fare are directly inherited from the routing API with real\-time traffic information and are therefore not comparable to static ground\-truth labels\. We omit Estimation Accuracy and MAPE from this evaluation accordingly\. Connectivity below 100% reflects cases where the LLM fails to return a valid structured response\.

Table[17](https://arxiv.org/html/2605.22355#A6.T17)shows that tool\-augmented LLMs achieve strong route quality, with Line Overlap reaching 0\.848 and Route Exact Match up to 74\.4%\. This is expected given that the ground\-truth route is likely present among the retrieved candidates, reducing the task to selection rather than generation\. Compared with Table[2](https://arxiv.org/html/2605.22355#S4.T2), the tool\-augmented configuration improves Route Exact Match from below 40\.2% to above 71\.7% across all models, confirming that general\-purpose LLMs alone lack the transit topology knowledge necessary for accurate route generation\.

TransitLM achieves comparable performance without any external tool access\. Our 4B\-Joint model attains 0\.835 Line Overlap and 0\.847 Station Sequence Overlap \(Table[3](https://arxiv.org/html/2605.22355#S5.T3)\), while the best tool\-augmented model reaches 0\.848 and 0\.834 on the same two metrics\. Notably, TransitLM is evaluated on complete intermediate station sequences, a strictly harder output space than the boarding\-and\-alighting\-only format used by the tool\-augmented models, yet still surpasses them on Station Sequence Overlap\. The two paradigms trade leads across metrics, with neither holding a consistent advantage\. This confirms that continual pre\-training on transit data effectively internalizes routing knowledge equivalent to a production\-grade routing engine, enabling fully self\-contained route generation without API latency, network availability constraints, or usage quotas\.

## Appendix GLimitations and Future Work

The dataset covers four Chinese cities with 120,845 stations, and all text is in Chinese\. Whether the training framework generalizes to networks with different topologies, transfer conventions, and languages remains unverified\. Moreover, because each station is represented as a dedicated vocabulary token, geographic expansion incurs linear vocabulary growth\. Nationwide coverage of China alone would require roughly 1\.8 million station tokens, over ten times the current vocabulary, imposing substantial memory and computational overhead\. Efficient vocabulary compression or hierarchical encoding schemes are needed to make such scaling practical\.

The dataset records a static network snapshot and cannot reflect real\-time congestion, temporary route adjustments, service suspensions, or newly opened stations and lines\. Currently, the only way to incorporate network changes is retraining on data that includes the new entities\. Future work could explore methods to reduce the retraining overhead required for topological updates, and investigate retrieval\-augmented generation to inject real\-time status information at inference time\.

Two further limitations apply\. The data originates from a single navigation platform whose route ranking strategy may not generalize to others\. The evaluation protocol relies on structural comparison against routing engine outputs and does not incorporate real\-trip validation or user satisfaction assessment\.

## Appendix HEthics and Privacy

TransitLM is constructed from route planning query logs returned by a commercial navigation engine\. Unlike GPS trajectory datasets such as T\-Drive\[[42](https://arxiv.org/html/2605.22355#bib.bib3)\]or GeoLife\[[44](https://arxiv.org/html/2605.22355#bib.bib13)\], which record continuous multi\-day movement traces from which individual mobility patterns can be re\-identified\[[7](https://arxiv.org/html/2605.22355#bib.bib45)\], each record in TransitLM is an isolated origin\-destination planning request with no temporal continuity\. The dataset is sampled from a single calendar day, and no timestamps are retained in the released corpus\. User identifiers are removed prior to dataset construction, and no linkage key exists across records\. Consequently, even though GPS coordinates are precise, it is infeasible to associate multiple records with the same individual or reconstruct longitudinal mobility patterns\. The released data contains only route\-structural metadata, including station sequences, line identifiers, transfer points, and numeric estimates of distance, time, and fare\. No demographic attributes, device fingerprints, or personally identifiable information is present\. The model trained on this dataset is optimized exclusively for generating structured transit routes, and its training data contains no user profiles, behavioral histories, or content applicable to surveillance or recommendation scenarios\. Its failure modes are limited to route infeasibility or numeric estimation error, neither of which constitutes societal harm\.

## Appendix IQualitative Examples

Figures[5](https://arxiv.org/html/2605.22355#A9.F5)–[8](https://arxiv.org/html/2605.22355#A9.F8)present qualitative outputs from the Qwen3\-4B\-Joint model on a fixed origin–destination pair in Beijing\. All four examples share identical GPS coordinates, enabling direct comparison across tasks and input modalities\. The left panel of each figure displays the route plotted on a map using the station\-level GPS coordinates from the model output, and the right panel shows the structured generation including line sequences, transfer points, distance, travel time, fare, and first/last\-mile access mode\. The entire output is produced through autoregressive text generation without any external map\-matching engine or routing algorithm\.

Figure[5](https://arxiv.org/html/2605.22355#A9.F5)shows the Optimal Route Generation result\. Given a natural\-language query and origin–destination coordinates, the model generates a two\-segment subway route with a single transfer, covering 21\.4 km in 1 h 17 min at ¥5\. The generated station sequence forms a spatially coherent path, and the model correctly identifies walking as the first/last\-mile access mode with plausible distances\.

Figure[6](https://arxiv.org/html/2605.22355#A9.F6)illustrates Preference\-Aware Planning on the same OD pair with an added “bus first” constraint\. The model switches entirely from subway to bus lines, producing a route via Bus 405 and Bus 1 Express that avoids all subway segments\. This demonstrates that the model has learned to condition its route selection on user preferences rather than defaulting to the shortest\-path solution\.

Figure[7](https://arxiv.org/html/2605.22355#A9.F7)presents Multi\-Route Generation, where the model produces three distinct alternatives for the same query\. The three routes span different transport modalities, with Route 1 using subway only, Route 2 combining subway with cycling for last\-mile access, and Route 3 relying on bus\. Due to space constraints, only Route 2 is visualized\. The diversity across routes confirms that the model captures multiple valid planning strategies rather than collapsing to a single solution\.

Figure[8](https://arxiv.org/html/2605.22355#A9.F8)repeats the Optimal Route Generation task with the textual query removed, retaining only raw GPS coordinates as input\. The model produces a route nearly identical to Figure[5](https://arxiv.org/html/2605.22355#A9.F5), selecting the same subway lines and transfer station with comparable distance and travel time estimates\. This consistency provides a concrete illustration of the GPS\-only robustness reported in Section[5](https://arxiv.org/html/2605.22355#S5), confirming that the spatial knowledge acquired through CPT operates independently of textual cues in the input\.

![Refer to caption](https://arxiv.org/html/2605.22355v1/x5.png)Figure 5:Optimal Route Generation example from the 4B\-Joint model in Beijing\. Given a natural\-language query and origin–destination coordinates, the model generates a two\-segment subway route with transfer, distance, time, fare, and first/last\-mile access estimates\. The left panel shows the route plotted on a map from station\-level GPS coordinates in the model output, and the right panel displays the structured generation\.![Refer to caption](https://arxiv.org/html/2605.22355v1/x6.png)Figure 6:Preference\-Aware Planning example on the same OD pair with an added “bus first” constraint\. The model avoids all subway segments and generates a bus\-only route via Bus 405 and Bus 1 Express, demonstrating preference compliance\.![Refer to caption](https://arxiv.org/html/2605.22355v1/x7.png)Figure 7:Multi\-Route Generation example on the same OD pair\. The model produces three alternatives spanning subway, subway with cycling, and bus\. Route 2 is visualized due to space constraints\.![Refer to caption](https://arxiv.org/html/2605.22355v1/x8.png)Figure 8:GPS\-only Optimal Route Generation on the same OD pair with the textual query removed\. The generated route is nearly identical to Figure[5](https://arxiv.org/html/2605.22355#A9.F5), confirming that spatial grounding is independent of input modality\.