v.net.timetable(1)

v.net.timetable 🚌✨

okay bestie, we're in the GRASS GIS User's Manual and today's main character is v.net.timetable — the one that figures out the shortest path using actual timetables. yes, like real bus schedules. she's giving transit-planning icon energy and honestly? obsessed. 💅

---

✨ NAME ✨

v.net.timetable — finds shortest path using timetables. periodt. 🕐🛣️

🏷️ KEYWORDS 🏷️

vector, network, shortest path 🌈

📜 SYNOPSIS 📜

v.net.timetable
v.net.timetable --help
v.net.timetable input=name  [layer=string]  output=name
[arc_layer=string]   [node_layer=string]   [arc_column=string]
[arc_backward_column=string]   [node_column=string]
[walk_layer=string]  route_id=name stop_time=name to_stop=name
walk_length=name  [--overwrite]  [--help]  [--verbose]  [--quiet]
[--ui]

🚩 Flags 🚩

• --overwrite — let your output files just bulldoze whatever's already there. allow output files to overwrite existing files 💥
• --help — print usage summary, i.e. the "hey what do I even type" button 🫶
• --verbose — verbose module output, she's chatty and that's valid 💬
• --quiet — quiet module output, she's giving nothing and that's also valid 🤫
• --ui — force launching the GUI dialog. windows girlies rise 🪟

🎛️ Parameters 🎛️

• input=name [required] — name of input vector map. or a data source for direct OGR access 👀
• layer=string — layer number or name. vector features can have category values in different layers, and this number decides which layer we're on. when you're using direct OGR access, this is the layer name instead. Default: 1
• output=name [required] — name for output vector map 💖
• arc_layer=string — arc layer. same deal: vector features can have category values in different layers, this number picks which one. with direct OGR access it's the layer name. Default: 1
• node_layer=string — node layer. you already know the drill — vector features can have categories in different layers, this number chooses. direct OGR access = layer name. Default: 2
• arc_column=string — arc forward/both direction(s) cost column (number) 💸
• arc_backward_column=string — arc backward direction cost column (number) ⬅️
• node_column=string — node cost column (number) 💰
• walk_layer=string — layer number or name with walking connections, or -1. a single vector map can be connected to multiple database tables, and this number determines which table to use. with direct OGR access this is the layer name. Default: -1
• route_id=name [required] — name of column with route ids Default: route_id
• stop_time=name [required] — name of column with stop timestamps Default: stop_time
• to_stop=name [required] — name of column with stop ids Default: to_stop
• walk_length=name [required] — name of column with walk lengths Default: length

---

💫 DESCRIPTION 💫

v.net.timetable finds the shortest path between two points using timetables. no cap. she reads input from standard input — one query per line — and writes output to standard output, plus to the output map, plus to tables linked to layers 1 and 2. she's doing the most and honestly we love that for her.

every line of input has to follow one of these two formats:

PATH_ID FROM_X FROM_Y TO_X TO_Y START_TIME MIN_CHANGE MAX_CHANGES WALK_CHANGE
PATH_ID FROM_STOP TO_STOP START_TIME MIN_CHANGE MAX_CHANGES WALK_CHANGE

where PATH_ID is the identificator of a query, used in the output map so you can tell the queries apart. the search begins at START_TIME. MIN_CHANGE gives the minimum number of time (inclusively) for a change from one route to another. MAX_CHANGES is the maximum number of changes allowed — or -1 if it's infinity, because boundaries are a construct 🦋. WALK_CHANGE is 1 or 0 depending on whether walking from a stop to another stop counts as a change or not.

and finally: in the latter format the path is found from FROM_STOP to TO_STOP, and in the former it's found from the stop closest to the (FROM_X, FROM_Y) coordinates to the stop closest to the (TO_X, TO_Y) coordinates. 💅

for each input query, the module outputs a description of the shortest path to standard output. for example, using the tables given below, for this input:

47 130 300 0 1 5 0

you get this output:

Route 15, from 130 leaving at 15 arriving to 250 at 22
Walk from 250 leaving at 22 arriving to 300 at 24

moreover — yes, moreover, she's fancy — the module writes the path to the output map and stores all the info you'd need to reconstruct the path into the tables. the table for stops/points is linked to layer 1 and after the query it looks like this:

cat|path_id|stop_id|index|arr_time|dep_time
1|47|130|1|0|15
2|47|250|2|22|22
3|47|300|3|24|24

where CAT is the category of a point in the map, PATH_ID is the path identificator, STOP_ID is the identificator of the stop as used in the input map, INDEX is the index of the stop on the path (so index=1 is the first stop visited, and so on...), and ARR_TIME and DEP_TIME are the arrival time and departure time respectively. 📅 arrival time for the first stop on the path is always equal to START_TIME, and departure time for the last stop is always equal to the arrival time. symmetry, we stan.

the table linked to the second layer corresponds to subroutes taken between stops. for the query above you get:

cat|path_id|from_id|to_id|route_id|index|from_time|to_time
1|47|130|250|15|1|15|22
2|47|250|300|-1|2|22|24

where CAT is the category of lines of subroute between stops FROM_ID to TO_ID, ROUTE_ID is the identificator of the route taken — or -1 if walking 🚶 — INDEX and PATH_ID are as above, and FROM_TIME and TO_TIME are the times between which the route is taken.

the output map contains the points at the positions of used stops. if a subroute is taken between two stops, a line segment gets added between the two corresponding points. and finally, instead of a straight line segment, the actual paths of routes can be given in a paths layer. if this parameter is used, then each line in the input map must contain identificators as category numbers of all routes passing through the line. then the module finds the path between two stops and writes this path instead. in the case of walking from one stop to another, a straight line between the stops is used. simple as that. 🎀

---

📝 NOTES 📝

timetables are stored in a table linked to the given layer of the input map. a timetable is made of routes, and each route is just a sequence of stops with specified arrival times. if two sequences of stops differ only in times, they still count as two different routes. for example, if there's a bus line that leaves every 20 minutes and follows exactly the same path every single time, you still need a separate route for every time. that's just how it is, bestie, no shortcuts 😭

for each stop (given by the category number of the point), the table storing info about the routes must contain the list of all routes stopping at that stop (given by route identificators) together with arrival times. so the table has to have three columns: stop — which is the key of the table — route_id, and stop_time, where each triple corresponds to a route arriving at a stop at a certain time. here's a valid table, for example:

cat|route_id|stop_time
100|5|0
130|5|10
150|5|20
250|5|30
300|5|40
260|15|5
130|15|15
250|15|22
150|35|17
250|35|27
300|35|37
100|35|50

note that stop_time is an integer, so you can use any units and offset you want to specify arrival times. freedom 💅

also, walking connections between stops can be given by a table linked to the walking layer of the input map. if this parameter is -1, then walking between stops is not allowed, sorry. the table must contain three columns: stop — which is the key of the table — to_stop, and length. a record in the table says it takes length units of time to walk from stop to to_stop. here's a valid table:

cat|length|to_stop
250|2|300

⚠️ beware bestie: this only means it's possible to walk from stop 250 to stop 300 — not the other way round. it's giving one-way street energy. 🚧

---

🌸 EXAMPLES 🌸

say we wanna find a path from the stop with identificator 130 to the stop with category 300, starting at time 0, with one time unit for change, a maximum of 5 changes, and with walking not considered a change of route. we use this command:

echo "47 130 300 0 1 5 0" | v.net.timetable \
     input=buses output=path layer=5 walking=6 path=7

but if we know the coordinates of the places instead, then this one might be the move:

echo "47 10.31 54.31 90.21 28.21 0 1 5 0" | v.net.timetable \
     input=buses output=path layer=5 walking=6 path=7

---

👀 SEE ALSO 👀

• v.net
• v.net.path
• v.net.distance

---

👑 AUTHORS 👑

• Daniel Bundala, Google Summer of Code 2009, Student
• Wolf Bergenheim, Mentor

---

🧚 SOURCE CODE 🧚

available at: v.net.timetable source code (history)

accessed: Saturday Jan 17 05:41:27 2026 ⏰

main index | vector index | topics index | keywords index | graphical index | full index

© 2003-2025 GRASS Development Team, GRASS GIS 8.4.2 Reference Manual

---

and that's the whole page, bestie 🫶 this was v.net.timetable(1) from GRASS 8.4.2 — go plan some routes, slay, and remember: timetables are just routes with main character energy 💖✨🎀🦋