Route Polylines vs. Via-Points in Fleet Systems#
Overview#
This guide aligns our position regarding the trade-offs about routing autonomous vehicles in Fleet Systems.
It focuses specifically on why it is imprudent to accept route polylines as input into Fleet Systems, and introduces via-points as the preferred approach.
Background#
Underpinning this architecture is a shared map which is flashed to the vehicle and provided to AD Alliance member companies by MobileEye. This map is then enhanced and augmented “up the stack” until the MOIA Routing and Maps teams expose it to external and internal consumers.
Route Polylines vs. Via-Points#
The following table illustrates the key differences between these two approaches:
Route Polyline |
Via-Points |
|---|---|
Precise line-by-line routing instructions |
Waypoint hints for route calculation |
|
|
GeoJSON Example (note the heading arrows) |
Note: These examples don’t necessarily use the same encoding as MOIA routing and Fleet APIs. They are illustrative in GeoJSON for convenience.
Comparing Route Polylines and Via-Points in Operations#
Why We Don’t Accept Route Polylines from API Consumers#
The following reasons are broadly listed in order of impact on dispatch-ability:
1. Route Polylines Must Be Generated on the Same Underlying Map at the Same Version#
Impact: High likelihood of rejection by MOIA routing system or lower-level systems (e.g., MobileEye).
One of the key metrics is the “dispatch-ability” of incoming Missions into Fleet Systems. Accepting a route polyline that may not be based on the same map has both a high likelihood of being rejected by the MOIA routing system or lower-level systems (i.e., MobileEye). This binds disparate systems together in a highly restrictive way.
⚠️ Warning: Route polylines generated on anything but the exact correct map have a high likelihood of not being dispatch-able.
2. Route Polylines from Outside Will Lack Awareness of Our Geonet Modifications and Metadata#
Impact: Routes may violate MOIA-specific constraints and be undriveable.
On top of the map and geonet we import into the Fleet Systems product, we may also add metadata to our own layers. This includes:
Avoiding problematic streets
Closing certain parts of the geonet due to operational concerns
Marking “undriveable” segments based on MOIA operations expertise
⚠️ Warning: Route polylines that violate constraints added in the MOIA maps layer have a high likelihood of not being dispatchable.
3. MobileEye’s “ValidateRoute” API Has Limitations#
Impact: API validation doesn’t guarantee actual driving behavior.
Even though MobileEye’s “ValidateRoute” Cloud API can “validate” a route, the actual driven polyline may be subtly different. This is mostly due to superficial factors such as map version, precision of GPS coordinates, etc. Even if we accept a route polyline and validate it against the MobileEye API, they might “confirm” this route and then drive something different!
⚠️ Warning: Route polylines that are close enough for MobileEye to accept might result in a different actual driven polyline due to heuristic matching at MobileEye.
4. SDS Route Updates Require Careful Coordination with Vehicle Locality#
Impact: Unsafe vehicle maneuvers can result from incompatible route updates.
Starting the SDS driving requires careful coordination about vehicle locality and where the route polyline starts. If the vehicle is traveling eastbound on one route and suddenly receives a mission update to adopt a different route starting from a distant location, there is high likelihood of rejection.
The SDS is too close to an intersection, and the updated route may cause the vehicle to attempt an unsafe maneuver (urgent turn). For this reason, the SDS rejects mission updates where there is insufficient commonality in the first few hundred meters of a route polyline.
5. Route Polylines Have a Short Half-Life#
Impact: Polylines become stale due to continuous environmental and system changes.
Even within the MOIA Fleet Systems product, a route polyline has a short half-life because:
The map may change
Turn restrictions and other metadata might change
The vehicle might move
⚠️ Warning: For this reason we generate route polylines at the last possible second before dispatching the Mission to the vehicle. As the vehicle moves, we constantly look at the destination waypoint and calculate new routes in case the vehicle deviates.
6. Precise Polylines Imply Unachievable Compliance Guarantees#
Impact: Real-world conditions prevent guaranteed route adherence.
Even when we would accept a route polyline as input, even if the SDS would guarantee to drive it, there are still scenarios where the SDS might deviate from the route it agreed to drive. There are also cases where either:
The safety driver might take-over to steer around real-world obstacles
The remote assistance operator might intervene
Unexpected environmental conditions require deviation
⚠️ Warning: Even in a perfect data world with perfect maps and a perfect SDS, real-world conditions mean we cannot guarantee following a route polyline precisely.
Via-Points as the Solution to Route Polyline Pain Points#
Taking the points above as evidence that neither with perfect software nor a perfect real-world operating environment will route polylines ever be “stable enough” to operate at scale with a fleet of vehicles, the “via-point” concept was introduced in 2024.
Via-Points Concept#
The general premise of via-points is to allow a consumer of the Fleet Systems APIs to strongly hint which locations on the driveable geonet should be visited when calculating a route.
Example: The red line in the following diagram represents a polyline that a consumer wants to inject. However, the segment on Beherenstraße is not driveable.
If we accepted the red route polyline into Fleet Systems, we would have to reject the whole Mission.
By accepting via-points which hint where to travel, we can travel approximately 90% of the planned route and still visit all via-points (blue route polyline):
Limitations of Via-Points#
1. Over-Specifying Via-Points Undermines the Feature#
Over-specifying via-points (e.g., every 5 meters) undermines the usefulness of the feature and has a high risk of being rejected by the system as un-routable.
“Abusing” via-points to try and force route polylines into the system would also lead to un-dispatchable-routes. The via-point density must be:
High enough to visit the interesting ODD features or customer waypoints
Not so high that it becomes impossible to apply MOIA geonet routing expertise
Here’s an example with reasonable density:
Note: We have no “defense” against this, but pseudo polylines made of via-points too close together have a high risk of being rejected by the system as un-routable.
2. Via-Points Have Practical Limits#
Via-points are intended to “chain together” a loose approximation of something that can be easily coerced into a valid route polyline. There is a limit to how many via-points can be added, though this limit was largely arbitrary.
In a pathological case where a consumer abuses via-points (e.g., 12 via-points in a circle on opposite sides of the city), this would lead to enormous routes. The system would route from Wedding, to Oberspree, to Steglitz, to Marzahn, to Oberspree, etc.
The resulting route polyline would cover hundreds of kilometers of geonet, and the API response would be on the order of multiple megabytes. The compute time would be high enough that we would risk the stability of Fleet Systems if we allowed consumers to request arbitrary numbers of via-points.
Note: We can raise the limit any time, or remove the input limit and raise errors if the resulting route polyline would be too large or long.
3. Via-Points Cannot Guarantee Exact Route Specification#
Via-points as the main API virtually guarantees that a consumer cannot with 100% certainty say where the vehicle will drive. This is an operational fact where graph theory and our desire for perfect software modeling does not translate to the real-world environment. We must adapt our software systems to the reality of the operating environment.
Note: Being outside the lab and operating in the real world means we have to compromise, but this is as true between V&V and FleetSystems as it is between Uber and FleetSystems, or MAAS Unit.
Advice for Fleet Systems API Consumers#
If you need to drive specific routes, follow these recommendations:
1. Use Dense-Enough Via-Points Arrays#
Dispatch missions into the MOIA Fleet System using “dense enough” via-points arrays. For visiting ODD features, this should be sufficient. If the ~100 via-point limit is prohibitive, approach us about increasing the limit.
2. Dispatch Shorter Missions#
Dispatch more, but shorter missions into the system with “dense enough” polylines. Shorter missions have a higher chance of being executed to the end without loss of SDS, disengagement, core crashes, safety driver take-overs, etc. “Completed” missions are ideal.
3. Account for Route Deviation#
Accept that statistically, maybe 70-90% of a route you hoped for might be executed exactly as planned. Account for this in the data science models which consume the resulting test-data.
If there is a decent overlap between the polyline driven and the route polyline V&V tooling hoped to drive, any valid data produced should be used “optimistically”. Misses or violations due to deviation should be captured in another drive, maybe on another day, maybe in different conditions.
4. Track Adherence Metrics#
Track the Fréchet distance or other metrics to measure how close your preferred route polyline was to the route actually driven. Look for root-causes if the distance is too large. See if there’s a target value we can aim to align between the DVS/ARTs.
The polyline we drove is available in the data lake and events. We suggest comparing the after-the-fact polyline with the planned route polyline. Tracking something like Fréchet distance would help quantify the difference in “adherence” between real-world and theoretical performance.
Last Updated: 2026-03-16