Generate shapes from stops

For a feed with no route geometry, GTFS·X can build shapes.txt automatically: group trips into unique stop patterns, route each one along the street network (or connect the stops with straight lines), and link the result back onto every trip that follows it. One recipe, reachable from two places in the editor, fully undoable.

What it is

Without shapes.txt, a rider-facing trip planner draws a straight line between consecutive stops instead of following the street a bus actually drives. Generate shapes from stops closes that gap. It groups every trip that lacks usable geometry by its exact ordered sequence of served stops (same route, same direction, same stops in the same order), then builds one shape per unique sequence and writes the new shape_id back onto every trip that shares it.

The result is real geometry where there was none: instant if you pick straight lines, or road-following if you let it snap.

Who needs this

Feeds authored in a spreadsheet-style GTFS builder frequently ship with an empty shapes.txt, because drawing route geometry is an optional, more advanced step those tools don't require. National RTAP's GTFS Builder is the common example: an agency fills in routes, stops, and schedules in a guided Excel workbook, exports a feed, and never touches shapes.

That feed isn't broken. It's valid GTFS, and it will import and validate cleanly in GTFS·X. It just renders as crow-flies straight lines between stops in every consumer app until it has geometry, which looks unfinished next to services whose map shows the bus following the actual street.

How to run it

Two entry points open the same dialog:

Right after importing a shapeless feed

When GTFS·X detects, on import, that the feed has no usable route geometry, a callout offers to generate shapes right away, before you start editing.

Any time, from Validation

A feed with no route geometry always carries a "no route geometry" warning in the Validation panel. Select it and the right-rail fix recipe shows a Generate shapes button; click it to open the dialog on demand, whenever you're ready.

Both paths land on the same preview: how many stop patterns need geometry, across how many routes, and how many trips will be linked once you run it.

Choosing a mode

• Snap to roads (recommended, the default). Each pattern's ordered stops are routed along the street network via the Mapbox Directions API (the same road routing the timetable's Estimate times uses), producing geometry that follows the actual streets between stops.
• Straight lines between stops. Connects the stops directly, with no network call, so it's instant. Choose this when the alignment genuinely doesn't follow the mapped road network: a ferry crossing, a rail alignment in its own right-of-way, or a rural road that isn't in the road graph.

One shape per stop pattern

Trips are grouped by route, direction, and the exact ordered list of served stops, not one shape per trip. Two trips that visit the same stops in the same order (the normal case for most scheduled service) share a single generated shape; only trips whose stop sequence actually differs (a short-turn, an express that skips stops, a loop) get their own. On a real National RTAP feed used to validate this recipe, 86 trips collapsed to 19 unique stop patterns, so 19 shapes covered the whole feed.

Reviewing the result

When the run finishes, the summary reports how many shapes were created and how many trips were linked, plus three outcomes worth a second look:

• Matched cleanly. Snapped to the road network with no gap.
• Matched only partially. The road network had a gap the router couldn't bridge; these are flagged for review.
• Fell back to straight lines. Either the snap failed for that specific pattern, or straight-line mode was chosen for the whole run.

The whole run is undoable in one step from the result screen. After committing, a generated shape is just a shape: open the route in Routes & shapes, find it under that route's Shapes tab, and use Edit Shape, Simplify, Trim, or re-Snap on it like anything you'd drawn by hand.

Limits

• It's a best guess from stop positions alone. Routing between stops can't know which of two parallel one-way streets the driver actually takes, a turn restriction the schedule assumes, a deviation made to serve one rider, or a loop that revisits the same street twice.
• Truncated routes are caught automatically. Generated geometry is checked against the straight-line distance through the stops; if the routing service returns something implausibly short (a sign the route got cut off), GTFS·X discards it and falls back to a straight line for that pattern instead of writing a broken shape. This is why a pattern can come back as a straight line even when you chose Snap to roads.
• Spot-check before you rely on it. Treat generated geometry as a strong starting point, not a final answer, especially any pattern flagged as a partial match; hand-correct where the routed path doesn't match the real route.
• Snap mode needs an internet connection (the Directions API call is online); straight-line mode doesn't.