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.

transitime/transitclock/src/main/java/org/transitclock/configData/CoreConfig.java

Lines 193 to 198 in 05ca94e

	private static IntegerConfigValue allowableNumberOfBadMatches =
	new IntegerConfigValue("transitclock.core.allowableNumberOfBadMatches",
	2,
	"How many bad spatial/temporal matches a predictable " +
	"vehicle can have in a row before the vehicle is made " +
	"unpredictable.");

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

transitime/transitclock/src/main/java/org/transitclock/configData/CoreConfig.java

Lines 168 to 182 in 05ca94e

	private static DoubleConfigValue maxDistanceFromSegmentForAutoAssigning =
	new DoubleConfigValue("transitclock.core.maxDistanceFromSegmentForAutoAssigning",
	60.0,
	"How far a location can be from a path segment and still "
	+ "be considered a match when auto assigning a vehicle. Auto "
	+ "assigning is treated separately because sometimes need "
	+ "to make maxDistanceFromSegment really lenient because "
	+ "vehicles do not always follow same route. This is "
	+ "especially true with deviated fixed route service. But "
	+ "don't want the distance to be too lenient when auto "
	+ "assigning because if too lenient then would match to "
	+ "multiple routes and therefore no assignment would be "
	+ "made because the matches would be ambiguous. Therefore "
	+ "maxDistanceFromSegmentForAutoAssigning should be less"
	+ "than or equal to maxDistanceFromSegment.");

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?