Allow intermediate stops (waypoints) for Car bookings (Road Trip)

[tbard1]

Problem
The multi-leg route editor with "Add stop" currently only exists for Trains and Planes. Car bookings only expose a single departure/arrival pair via the generic location picker, with no way to insert a planned stop along the route.

This matters because Car is the one transport type that's actually routed on real roads via OSRM (Cars... follow real roads, routed on demand via a public OSRM router). A road trip is exactly the case where a driver plans waypoints — the map/route feature is there, but the UI to feed it multiple points isn't.

Current behavior

• Manual "Car" form: only from / to.
• The multi-leg editor with "Add stop" is only surfaced for trains.

Desired behavior

• Extend the multi-leg route editor (already built for trains) to Car.
• Each stop should support the same "generic location picker" already used for car departure/arrival, plus an optional planned arrival/departure time at that stop.
• When adding a stop, also let the user pick from the trip's already-planned Places (the same quick-pick list already used elsewhere, e.g. "the day's own places and hotels appear as quick picks" in the transit search dialog) — instead of only free-text/location search. This avoids re-searching a location that's already in the trip's place pool, and keeps the stop linked to the same Place record used in the itinerary.
• On the map, the OSRM route should be recalculated through all waypoints in order, not just start→end.

Why this is low-risk to build
The endpoints data model already appears to support this generically — role: "from" | "to" | "stop" with a sequence field exists at the API/schema level for all transport types, not just trains. This looks like a UI-only gap rather than a data-model change: the multi-leg editor component built for trains could likely be reused for Car with minimal changes, and OSRM already accepts multiple waypoints natively. The "quick pick from planned places" pattern also already exists elsewhere in the app (transit search dialog), so it's precedent, not a new interaction.

Alternative I'm using today
Creating several back-to-back Car reservations (leg 1, leg 2, …) as a workaround — it works but clutters the Reservations/Transports tab and loses the "one rental, one continuous trip" semantics (e.g. a single car rental confirmation number spanning 3 days with 2 planned stops).

Additional context
Happy to test on my self-hosted instance if a beta/flag is added.

[Firewolf1337]

Would like to see that too. It is hard to plan a road trip atm.

[gflinch]

I wanted to follow up on this because the waypoint request touches on something I’ve been looking for in trip-planning software for a long time.

I’m an old Microsoft Streets & Trips user, and one thing I still haven’t found a great replacement for is its approach to planning a road trip before you actually take it.

I’m not really looking for TREK to become a turn-by-turn navigation application. Google Maps, Apple Maps, etc. already handle that. What I miss is being able to sit down before a trip and actually work with the route as part of planning the itinerary.

My normal process is something like this:

I start with where we’re leaving from and where we’re ultimately going. Then I start working out what happens between those two points.

Maybe there’s an attraction we’d like to visit along the way. We need lunch somewhere around noon. We might need fuel after 250 miles. Perhaps there’s a scenic route I’d rather take even though it’s slower. Or I find something interesting that’s 15 minutes off the route and want to see what adding it does to the rest of the day.

What made Streets & Trips useful was being able to experiment with those decisions and immediately see their consequences.

For example:

Home — depart 8:00 AM
→ 1 hr 45 min driving
Museum — arrive 9:45 AM, stay 2 hours
→ depart 11:45 AM
→ 1 hr 10 min driving
Lunch — arrive 12:55 PM, stay 45 minutes
→ depart 1:40 PM
→ 2 hr 20 min driving
Hotel — arrive 4:00 PM

If I move the museum, remove lunch, add another stop, or change how long we’re staying somewhere, the rest of the day’s times should adjust.

That’s really the feature I’m interested in: the road route becoming part of the itinerary planning process instead of simply being a line connecting itinerary items.

Looking through TREK, it seems like some of the foundation for this may already exist. Transport reservations already have ordered from, stop, and to endpoints, and the road routing code appears capable of routing through multiple points and returning individual route legs with distance and duration.

So I wonder if the first useful step could be fairly modest:

• Allow multiple ordered stops on a car journey.
• Allow those stops to be reordered.
• Show driving distance and estimated driving time for each leg.
• Allow a departure time and optionally a planned duration at each stop.
• Calculate the resulting estimated arrival/departure times down the route.

Even just that would get surprisingly close to the part of Streets & Trips that I miss most.

There are much bigger ideas that could grow from this eventually — finding POIs along a route, fuel/range planning, offline/local routing data, MCP/AI-assisted planning, daily driving limits, etc. — but I don’t want to turn this request into “please recreate Streets & Trips.”

I’m mainly interested in whether this basic road-trip planning workflow fits the direction you see TREK going.

For me, TREK already does a lot of the difficult part very well: organizing the trip once I’ve decided what we’re doing. I’d love to also be able to use it for the process of figuring out how we’re getting there and what makes sense to do along the way.