Hi Marko,
I have not checked everything in detail, but here are some quick comments that hopefully help a bit:
On a more unrelated note: Since xServer 2.37 xRoute will also report TOUR_EVENTs of type "DRIVING" after each non-driving TOUR_EVENT (after BREAK and SERVICE events). Keep that in mind when upgrading to that or a newer version. The event structure in your screenshot would look differently then as it should be WaypointEvent, TourEvent (Service), TourEvent (Driving), WaypointEvent, TourEvent (Service), TourEvent (Driving), ...
From analyzing the response, the pattern appears to be (check attached image):
All events following a waypoint belong to it.
Except for the last waypoint, where SERVICE events are listed before the waypoint.
That is correct and even documented like that, see "Sorting Order"
in the technical concept on Route Events.
I fully understand that this looks odd. The reason, as far as I know, is because the API was designed and developed in several steps. Before the TOUR_EVENTs were introduced, it was already defined that the last event must be a WAYPOINT_EVENT. In order to not break this behaviour and applications relying on that, the TOUR_EVENTs at the last waypoint have to appear before the last WAYPOINT_EVENT.
1. I also enabled the nodes property and considered linking them through nodeIndex, but found out that that`s not the proper property to use.
That is because for non-zero service times there will be a segment of type NOT_DRIVING.
Code: Select all
{
"distance": 0,
"travelTime": 1,
"travelSpeed": 0,
"trafficDelay": 0,
"violated": false,
"eventIndices": [
2
],
"type": "NOT_DRIVING"
}
To identify events at the same location I would rather use the field "distanceFromStart" (or the coordinates). Note that if you have two identical waypoints you would have the sequence WaypointEvent, TourEvent, WaypointEvent, TourEvent all with the same value for distanceFromStart. Obviously, if this happens at the last two waypoints, this can be annoying to deal with. (It improves with xServer 2.37 and later because there would be a DRIVING event with a duration of 0 in between.) Which brings me to your question:
I’d like to ask whether there’s a more reliable or official way to link SERVICE tour events with their corresponding waypoints ?.
Unfortunately, some kind of special handling is required. Before applying your logic to evaluate the events you could patch the response and move the last WaypointEvent before the TourEvents at this waypoint. Out of my head I don't know how this influences the consistency of other pointers (for example the eventIndices in the segments list), but if you operate only on the events, this might be feasible. When moving this WaypointEvent, you should adapt the "travelTimeFromStart" by subtracting the duration of the service events.
Another way would be to look at the events from the end until the TourEvents corresponding to the last WaypointEvent are identified, so that you can handle them properly when processing the event list (from the start).
