First Mile Logic was probably the first part of the Route Planner AI that made the project feel genuinely different. As a game development student building a route planner for travel covered by DB in Germany, I quickly realized that city-to-city routing is only half the problem. The other half is the practical question at the beginning of the journey: How do I get from point A to the station that begins the rest of the trip?
This question may seem minor, but it becomes significant when you leave dense city centers.
In larger cities, reaching a station is often something you just assume will work. You walk a few minutes, take a tram, or grab whatever local connection is available. But outside the city, on the edge of town, or in rural areas, the first segment changes everything. Suddenly, the nearest useful station is not right around the corner. Maybe the closest stop is technically nearby, but it doesn't actually connect well. Perhaps the station with the best long-distance rail option is farther away. The route may only become viable if the planner can intelligently bridge that first gap.
This is where First Mile Logic became important for Route Planner AI.
The problem I was trying to solve
When I first started thinking about the project, I naturally focused on the most visible part of a trip: the train, the main transfer, the long-distance leg, and the obvious route from one city to another.
However, the more I thought about my travel habits, the more I realized that the beginning of a trip was often the most annoying part. Not because it was the longest, but because it was the least well-integrated.
I was constantly doing the same manual process:
First, I looked up the train connection.
Then, I would check how to get to the station.
Next, I would compare walking, getting dropped off, or taking a local option.
Finally, I would estimate if the entire route was worth it.
I wanted Route Planner AI to eliminate that manual stitching.
First Mile Logic was born from the idea that the planner should not only search from origin to destination, but also understand how to reach the right starting hub for the transit part of the journey.
My first naive approach
My first instinct was the obvious one: Find the nearest station and route the user there.
That worked on paper.
In practice, however, it was too simplistic.
The closest station is not always the best station. Sometimes, the nearest stop is small, slow, or poorly connected. Sometimes, a slightly farther station provides a much stronger connection, especially when long-distance rail is involved. Sometimes, the first-mile segment only makes sense if the planner is willing to use a different mode of transportation for that initial part of the journey.
That was when I stopped thinking in terms of "nearest station" and started thinking in terms of "best reachable station."
This may sound like a minor shift, but it changed the architecture.
Instead of simply adding a fixed local segment at the beginning, I started treating the first mile as a real decision-making layer.
origin
→ candidate stations
→ access route to station
→ onward transit journey
→ combined scoreThis was the first version of First Mile Logic that felt worth keeping.
This is how I started building First Mile Logic.
The core concept was straightforward, even if the implementation was not.
I wanted the system to do three things:
1) Look for a useful station near the origin.
2) Estimate how the user could realistically reach that station.
3) Rank the result as part of the total trip instead of treating it like an afterthought.
The first segment is often more important than it looks, which is what made this interesting. A weak first step can ruin an otherwise great route. A strong first step can unlock a much better overall journey.
This is especially relevant for people outside dense urban areas. If you live farther away from a major station, the route planner should acknowledge the station access problem. It should model it directly.
When First Mile Logic works, it is one of the most satisfying parts of the project. You can literally see the first leg of the journey from point A to the next useful station, and the route suddenly feels complete instead of fragmented.
This matters a lot to me because I started Route Planner AI to stop stitching these steps together manually.
This part is especially interesting outside cities.
The more I worked on it, the more I realized that First Mile Logic is not just a "nice extra." In many cases, it's the difference between a realistic-feeling route and a fake-feeling one.
Inside a large city, the first mile is usually smaller and less dramatic. Outside a city, however, it becomes the deciding factor.
That is exactly why I find it so interesting.
If someone is in a village, on the outskirts of a suburb, or farther away from a major station, the system must answer a more practical question: How can they be brought onto the network most efficiently?
This is where intermodal planning becomes real instead of theoretical.
It was also the first time that the Route Planner AI felt like more than just a front end for train lookups. It was becoming a planner that tried to reason about the entire trip.
The frustrating reality: DB API timeouts and OSM problems.
The difficult part is that First Mile Logic is only as useful as the underlying data and routing layers.
At this stage, those layers were still rough.
The DB API requests that I called directly by URL often gave me timeouts, which became a real development problem. On top of that, the OpenStreetMap side of the stack was unstable during testing. Some requests worked, some were slow, some failed, and some timed out at the worst possible moment.
So, around that time, the current state of the project was honestly a bit heavy.
The logic itself was promising.
However, the actual pipeline was not stable enough yet.
That is an important distinction.
I was not struggling because the First Mile Logic idea was bad. I was struggling because the surrounding infrastructure was unreliable. The Public Overpass documentation explicitly states that requests denied due to rate limits may return an HTTP 429 response code. Additionally, the project documentation clarifies that public instances are only one option, as Overpass can also be self-hosted. This matched the “works, then slows down, then fails” behavior that I encountered while prototyping.
At that point, I had a simple feeling: the system was intelligent enough to be interesting but not stable enough to be considered solved.
I knew I would need a better solution later, whether that meant stronger caching, smarter retries, queues, fallbacks, or changes to the underlying services.
This is what things looked like when they failed:
One reason I want to write this devlog retrospectively is that it's easy to clean up the story too much after the fact.
The reality was messier.
A typical session could look like this:
[First Mile] Searching candidate origin station...
[DB API] Journey request timeout
[OSM] Infrastructure lookup failed
[First Mile] Retrying with fallback station...
[Routing] Partial result returnedThis kind of output isn't glamorous, but it was very real.
Honestly, it taught me a lot.
It forced me to think about route planning not as "call one service and render the answer," but as "assemble a result from multiple unreliable systems and maintain a usable experience anyway."
This lesson ended up being more important than the specific bug of the week.
Reworking the scoring model
Another change I made during this phase was adjusting the evaluation scale.
Once I started adding First Mile Logic, it became clear that my initial scoring system was too simplistic. A route isn't good just because the raw travel time looks decent. Access quality matters too. Comfort matters, too. The type of long-distance connection matters, too. The effort required to reach the rail network also matters.
So, I started reworking the scoring model to reflect these factors.
One adjustment I found interesting was how I treated routes that feed into long-distance ICE or other fast, higher-value rail connections. In those cases, I became more willing to score the first mile by car more positively than before.
This does not mean "car over train" as a general rule.
It means that if the first segment by car gets me to a strong long-distance connection more comfortably and reliably, then spending fuel on that step can make the total route more attractive. In other words, I started rewarding car-assisted access more when the long-distance rail payoff was clearly worthwhile.
This was one of the first moments when the ranking felt less mechanical and more human.
A purely time-based system would miss that nuance.
A better scoring model could express it.
Why I want to improve the car side next is
At the same time, I noticed that my current OSM-based car routes were not always optimal.
They were useful but not optimal.
This is important because if the first mile of the car route is going to influence the ranking, then the quality of the underlying car route needs to be reliable. Currently, this aspect still feels like a weak point.
That is why I knew I wanted to look into TomTom later. TomTom’s official Routing API is a web service for routing, and the platform highlights traffic-aware routing through TomTom Traffic and related route calculation services. This makes it an interesting candidate for improving the car-based side of the Route Planner AI beyond my current OpenStreetMap-based setup.
Even at this stage, I had a clear idea in mind:
The first-mile concept was good, the current implementation was promising, but the driving layer still needed better tooling.
Why does this post matter to me?
This phase of the project is important to me because it's when Route Planner AI stopped being just a UI experiment and started becoming a routing system with an opinion.
That opinion was this:
The first part of the journey matters.
It matters technically because it changes which transit options are reachable.
It also matters practically because people outside city centers immediately experience the consequences.
It also matters conceptually because intermodal planning only becomes meaningful once you stop pretending that the trip begins magically at the station.
This is what First Mile Logic brought to the project.
Despite the timeouts, failures, and current roughness, this was the point at which I started to feel that the project had real direction.
What comes next?
At this point in the timeline, First Mile Logic was one of the most interesting parts of Route Planner AI but also one of the least stable.
The idea worked.
However, the infrastructure did not always cooperate.
The scoring became smarter.
The car side still needed better routing quality.
The timeouts were still not solved.
So, this was not a polished milestone. It was more like a strong system trapped inside a shaky prototype.
Still, that was progress.
Now, the project was no longer just asking, "What train should I take?"
It was starting to ask better questions:
"How do I actually get onto the network in the first place?"
For a route planner like this, that question changes everything.
