The Map is Not the Territory: Routing for Real Life at Omio
Language can really derail us sometimes. By and large, we experience it as static, stable. In reality, it’s nothing of the sort. It’s constantly evolving, absorbing new meanings and uses. Meanwhile, it’s essentially the operating system that enables us to think and make sense of the world. That’s an unruly tension, especially when it comes to how we understand problems and go about solving them.
Take the word network. If we scroll the version history of the term back to (say…) the late 1980’s, prior to the arrival of the internet, we get a much less elastic, somewhat less catch-all term. Almost always spatial. Roll things back another half-century, and we’re more often than not talking about something related to transit. At Omio, we’re sort of straddling everything in between that moment and the present — reconciling hands-on cartography and virtual information infrastructure. Both as networks. Both as different things.
That same distinction within a given vocabulary or category also applies to routes.
When an aspiring traveler runs a search on Omio for transit options between Munich and Amsterdam, what they get back reflects the integration of multiple operators, each owning a set of stations in a region for a given mode of travel (train, bus, flight or ferries). Deutsche Bahn, for example, has train stations in almost every city in Germany. At the same time, multiple providers can be operating in the same region for the same mode of travel. The network being leveraged there is subject to a complex set of variables that span schedules, regions, transfer points, suppliers, and more.
In this respect, part of Omio’s promise to the user is not unlike other web-based mapping applications. They should be able to run a search for travel between just about any two places without running into a “no results can be found” page. The primary stick in the spokes, there, is what scientist/philosopher Alfred Korzybski famously noted: The map is not the territory.
His was a broader observation about the differences between the world as it is and the sorts of shorthand we use for representing it. Functionally, it’s as true for us at Omio as it is for Google Maps or Waze . Zen philosopher Alan Watts rephrased the problem in a manner a bit closer to home for us, saying the menu is not the meal. Our promise is a bit more robust than simply not stranding the user at an error page. There’s a physical journey in play, with a number of interlocking dependencies. The travel plan between two points is a thing the user purchases; a set of deliverables they then count on to get them from Point A to Point B. The route and the journey –the menu and the meal– are different things. In theory, an error could mean a user finding themselves stranded somewhere out in the world.
To tackle this, we developed a system we refer to as routing. The first steps toward our routing engine introduced a simple system to manually add routes (Departure A, Arrival B, via C, Provider P1, Provider P2). These routes were transformed by search backend to provider queries A-C via P1 and B-C via P2, instead of the old approach of having a single query A-B for a user search. The routes were based on the data provided by Business Intelligence during the second half of 2018, calculated based on past demand. The system also allowed us to add some routes manually based on common sense observation.
At that point the system was designed to be non-scalable MVP, so the steps were taken to reduce the human factor, deploying the system in an automated way and pre-calculating routed connections as a batch process. Eventually, we moved to real-time calculation instead of pre-calculated batches. This allowed us to calculate the connection between 2 cities upon request, making it possible to service any new combination on time, instead of waiting for the batch update.
In October 2019, Omio acquired Rome2Rio, a platform that enables consumers to search and book transportation options anywhere in the world. One of the main highlights of the acquisition is that it allows us to cooperate and use Rome2Rio’s routing solution. After building our own routing algorithm we opted to use Rome2Rio’s APIs to strengthen our inventory. That came with some challenges.
The first of these was data mismatch. We have our own system of representation for stations and provider names, and it differs from Rome2Rio’s. To overcome these challenges, in an automated way, we used existing services and developed new scripts. For stations we used our suggester-api, making stations searchable. Usually, it allows users to autocomplete a station name, but we expanded it to allow us to search for stations by name, type, and geo-coordinates. And for providers we built a tool to help us to find the best carrier match for an unmapped Rome2Rio agency. All of this notwithstanding, stations and carriers can occasionally slip through the automated cracks.
Rome2Rio’s platform is designed to tell a user if there’s a route from Point A to Point B, and the available transit options between them. At Omio we try to customize everything to the user’s specific case. For example, we make sure that your first leg of transit doesn’t arrive after your next one begins; we don’t want you stepping off a train in Rotterdam to discover your connection to Amsterdam left half an hour ago. We do that by querying Rome2Rio schedules, then querying our provider to make sure that each segment has a ticket and the connection time is both valid and provides a user enough time to actually transfer between them. In other words, Omio provides users with a usable journey, bookable from end to end.
Rome2Rio will generate a route from Point A to Point D that looks like A-B-C-D. A-B is a 500km train journey, C-D is a 350km bus ride, but between the two we have B-C — which is a distance of 9500 meters. Rome2Rio’s system puts travel segments into two categories: Major and Minor. There wasn’t a concrete definition that distinguished these, as a rule. Broadly, anything less than 50km on a long trip wouldn’t qualify as “major”.
According to that definition the C-B segment is minor, and at some point we decided that a minor segment of less than 10km would qualify as local transport (tram, subway, taxi, or walking) since that could easily be a distance within a city. We also decided that if the segment is minor, can cause station or provider mapping to fail, or is operated by a carrier for which Omio doesn’t sell tickets or is not a form of transport we service (train, bus, flight and ferry), we would remove it from the route and keep the other segments.
This all proved to be an error in judgment. Simply put, the 10km threshold was too high. It could easily be a distance between two cities, and worse — not serviced by local transport. Conversely, if it’s within the same city, it might be serviced by a train we sell tickets for. Additionally, minor segments can’t just be removed if they have problems. In long-distance routes, “minor” segments can be 50km or more. That’s… a lot. To resolve this we opted to decrease the minimum distance to 1500 meters, since it’s a reasonably walkable distance between two stations (even with luggage and kids). Further, a segment longer than that that requires local transport like a tram or subway, or fails to be mapped, will prevent the whole route from being displayed to the user.
Ultimately, we reduced that 10km threshold to 1.5km. It was the obvious move; the obvious way to align the proverbial menu with the meal on the user end.
We’re working hard on our promise to help travelers book any journey, from anywhere to anywhere, working from their perspective. That involves including more routes in our results, trying to solve issues with segments that fail in mapping, adding more providers, and trying to find ways to include local transport and enhance transfer options between segments for users.
What we learned in all this is: Not every problem is solvable through strictly technical approaches. Some just require thinking about things from a different vantage. Or perhaps just thinking as much about the real-life territory as we do about the map.
