bus took alternative road, missed the planned route path and missed stop - TC still produced predictions and didn't drop autoassignment

[wkulesza]

Expected functionality When bus diverts from the planned route, misses a stop and follows an alternative road, TC should drop the autoassigner.

Describe the bug Bus took an alternative road, missing planned route and missing a planned stop - TC kept auto-assigner and thus produced prediction uninterruptedly. The stop was approx. 400m away from the path that the bus took. The diversion took approx 1:30mins after which the bus continued on the planned route path (bus after following an alternative road, reconnected with the route path) and perhaps that was too little time for TC to drop the autoassignment ?

Screenshots

Blue arrows show the alternative path that the bus followed, while red arrows show the route path, that the bus should take along with stop that was missed by the bus.

Version: Newest version of transitime/transitclock and transitclock docker.

Configuration: traccar data as AVL and auto-assigner enabled

[scrudden]

Hi Wojciech,

This is an area I am interesting in particularly as it involves disruption to normal behavior.

So, there are a number of current options to consider here.

The first would be the setting for the number of bad matches that are allowed before a vehicle is made unpredictable. This will be influenced by frequency of the AVL feed. How frequently are you reading the data from Traccar? If it was off route for less than (allowableNumberOfBadMatches * polling frequency) then it will remain predictable.

https://github.com/TheTransitClock/transitime/blob/05ca94eeb7121d84f1c7958e8ed6c25bce4caea7/transitclock/src/main/java/org/transitclock/configData/CoreConfig.java#L193-L198

The other options to consider are the spatial criteria for a bad match. In your case this one may help.

https://github.com/TheTransitClock/transitime/blob/05ca94eeb7121d84f1c7958e8ed6c25bce4caea7/transitclock/src/main/java/org/transitclock/configData/CoreConfig.java#L168-L182

Also, be aware that these distance criteria can be set more specifically for different routes on the network.

Hope this helps.

Cheers,

Sean.

[Raven888888]

Hi @scrudden thanks for the clear explanation.

"Also, be aware that these distance criteria can be set more specifically for different routes on the network."

This configuration variable is transitclock.core.maxDistanceFromSegmentForAutoAssigning and is global for 1 Core which has many routes on the network. How to set this variable uniquely for different routes?