xServer2: Handling of optimization on islands such as Sylt, Helgoland, ...
Posted: Mon Apr 14, 2025 2:50 pm
Hi there,
these days I've been challenged with the following issue:
Now with the tour optimization call a user can decide whether violated DIMA relations are allowed to occur in an xTour2 response:
com.ptvgroup.xserver.xtour.PlanToursOptions
With this kind of underlying HPR and LINKING the tour optimization does no nonger depend on the PlanToursOptions.
Very important: Be aware that you can't override the linking behaviour at runtime if you use HPR by ID: this also means that you would have to override the linking properties when creating the HPR.
these days I've been challenged with the following issue:
- The player wants to perform an xtour2 optimization of stops on German islands (such as Sylt, Helgoland, Westerland, ...) in combination with locations on the mainland. He encounters unscheduled orders on the island and wonders, what causes this.
- The process of optimization is based on various steps:
- The xTour2.planTours is based on distance matrices built with xDima2.createDistanceMatrix
- The matrices are based on HPRs created through startCreateHighPerformanceRoutingNetwork (xData2)
- The article below therefore combines both routing and optimization properties
- With a "usual" (or default) linking which allows all network classes vrom 0 to 7 the linking connects the waypoint to the closest bicycle lane. Though the linking was sucessful the start of the route is seen as VIOLATED because a car is not allowed to drive on that type of road,
- With the regular settings many relations on the island are violated (the red lines in the image)
com.ptvgroup.xserver.xtour.PlanToursOptions
- ignoreRouteViolations (def=true): If this field is set to true, route violations are ignored. No route violation is reported at the tour events. If this field is set to false, automatic planning will not create a tour with a route violation. Input tours with a route violation will be treated as violated tours and therefore will not be changed by the automatic planning. At the leg report and at the tours response route violated is set regardless of this field.
- ignoreReachabilityViolations (def=true):
If this field is set to true, reachability violations are ignored. No reachability violation is reported at the tour events. If this field is set to false, automatic planning will not create a tour with a reachability violation. Input tours with a reachability violation will be treated as violated tours and therefore will not be changed by the automatic planning. At the leg report estimated by direct distance is set regardless of this field.
- Now I created a new HPR which sets the allowed network classes to 0..6. So the bicycle lanes are forbidden in the linking.
- Now this HPR creates routes without violations. Though there's a significant distance between the inpu8t coordinate and the linked segment on the road network.
With this kind of underlying HPR and LINKING the tour optimization does no nonger depend on the PlanToursOptions.
- Left: unscheduled orders due to violated relations in the DIMA. "ignoreRouteViolations" and "ignoreReachabilityViolations" are set to FALSE.
Right: all orders scheduled (no red/yellow ball icons)
Very important: Be aware that you can't override the linking behaviour at runtime if you use HPR by ID: this also means that you would have to override the linking properties when creating the HPR.