Route with stops

When calculating an EV route with the Chargetrip Route API, you can add intermediate stops between the origin and destination using via.

Stops allow you to customize routing for real-world travel scenarios, such as charging at a preferred charge station, picking up passengers or stopping at a restaurant.

Types of stops

Chargetrip supports two types of intermediate stops:

Stop duration

You can configure the duration of every stop. Depending on the type of stop (charging or non-charging), the stop_duration is configured in different locations and has different behaviors:

1. In non-charging stops

The stop duration is configured at input.via.properties.location.stop_duration. This duration represents the exact stop duration and is added directly to the total trip duration without affecting the vehicle charging or driving time.

2. In charging stops

The stop duration is configured at input.via.properties.station.stop_duration. This value represents the minimum stop duration. The vehicle remains at the station for at least this long, but the route planner may extend the stop depending on the configured charge_mode:

• ALWAYS_TO_MAX_CHARGE: Extends charging time if needed to reach the maximum configured SoC. If the requested stop_duration exceeds the time required to reach the maximum SoC, the remaining time is logged as idle stopover.

• OPTIMIZE_TRAVEL_TIME: Extends the stay beyond stop_duration only if doing so reduces overall trip time (for example, by eliminating a subsequent charging stop). Otherwise, charges for the exact requested duration. If the requested stop_duration exceeds the time required to reach the optimal SoC, the remaining time is logged as idle stopover.

If no value is provided, the planner optimizes charging duration purely based on the route’s charge_mode.

Add a station to an existing route

A common scenario is a user picking a charging station for a route that already has stops, for example an alternative station that is shown in your UI. The no-code solution uses this approach to add a station as a via stop automatically, without any re-ordering logic, so the route updates seamlessly.

The order of the via array is the order in which the stops are visited. A station that is appended at the end is visited last, even if it is located near the start of the route. To insert it at the right position, compare the location of the station with the waypoints that are already on the route:

1. Collect the waypoints in order.

   Take the origin, every existing via stop and the destination from the request_input of the route you want to change. Every waypoint on the request_input has its geometry available, including stops that were created with only a station_id.

2. Draw a line through the waypoints.

   Connect the waypoints in order to form a line. Each part of this line between two waypoints is a segment.

3. Find the segment closest to the station.

   Use a geospatial library to find the point on the line that is nearest to the coordinates of the station. For example, turf.js offers nearestPointOnLine, which also returns the index of the segment that contains this point. That index is the index of the waypoint the segment starts at.

4. Insert the station after that waypoint.

   The waypoint list starts with the origin, so the index of a waypoint in this list matches the position where a new item is inserted into via to end up right after it. An index of 0 means the station is inserted as the first stop.

5. Never insert after the destination.

   When the nearest point is on the last segment, the index can point at the destination. Inserting there would place the station after the end of the route, so use the previous waypoint instead. This way the station is inserted as the last stop before the destination.

Things to keep in mind

• The line connects the waypoints with straight segments and does not follow the roads of the route. Alternative stations are always within a corridor of 5 to 10 km around the route, so they never deviate much from it and the closest segment is mostly accurate. For stations outside this corridor, other solutions might be more suitable.
• The request_input of the route is the source of truth. Build the new request from it and keep all other fields, such as the vehicle and the charging settings, unchanged.

Examples

mutation CreateRouteWithWaypoint {  createRoute(    input: {      vehicle: {        id: "60b8d5a2f1c8e9001b9e2831"        charging: { mode: OPTIMIZE_TRAVEL_TIME }      }      origin: {        type: Point        coordinates: [4.9041, 52.3676]      }      destination: {        type: Point        coordinates: [6.9583, 50.9375]      }      via: [        {          geometry: {            type: Point            coordinates: [5.1214, 52.0907] # Utrecht          }          properties: {            location: {              name: "Utrecht Central"              stop_duration: 1800 # 30 minutes in seconds            }          }        }      ]    }  ) {    id    status  }}

mutation CreateRouteWithChargingVia {  createRoute(    input: {      vehicle: {        id: "60b8d5a2f1c8e9001b9e2831"        charging: { mode: OPTIMIZE_TRAVEL_TIME }      }      origin: {        type: Point        coordinates: [4.9041, 52.3676]      }      destination: {        type: Point        coordinates: [6.9583, 50.9375]      }      via: [        {          properties: {            station: {              station_id: "5e849ea2837bc43df65d19a2"              stop_duration: 1800            }          }        }      ]    }  ) {    id    status  }}

mutation CreateRouteWithChargingVia {  createRoute(    input: {      vehicle: {        id: "60b8d5a2f1c8e9001b9e2831"        charging: { mode: OPTIMIZE_TRAVEL_TIME }      }      origin: {        type: Point        coordinates: [4.9041, 52.3676]      }      destination: {        type: Point        coordinates: [6.9583, 50.9375]      }      via: [        {          properties: {            station: {              station_id: "5e849ea2837bc43df65d19a2"            }          }        }      ]    }  ) {    id    status  }}