Trips detection problem

Ákos5 years ago

Hello!

I have a problem with trips detection. Read everything in documentation and in forum topics, and i think the ignition cause the problem.
We have a car. Use for pizza delivering. When stop about 3 minute one place, the driver doesn't switch off the engine. (Ignition true). This stop is not in trips list, but speed is 0, distance 0 until 3 minutes.
Another place, where stop 3 minutes with switched off engine(ignition false), i see in trips that stop.
I use this relevant config:

<entry key='report.trip.minimalParkingDuration'>120</entry>
<entry key='report.trip.minimalTripDuration'>165</entry>
<entry key='report.trip.minimalTripDistance'>280</entry>
<entry key='report.trip.useIgnition'>false</entry>

How could i avoid this case? Are there any configs that i can use?

Thanks.

Tony Shelver5 years ago

In our current system, we experience the same problem. We also have an issue that occasionally the flame-out or flame-on (ignition off / on) gets lost. Another issue is improperly installed trackers that do not have the ignition wire correctly linked.

I wrote myself a report that examines the track events and then groups together those based around the same position as a stop. I also measure the distance travelled between the stops.
The report is configurable by (my) customer for the length of time that constitutes a stop. For some customers this is 2 minutes, for others it's 20 minutes.
We also give the reverse geocoded address for each stop location.

If you do this, you will want to consider that some GPS devices 'wander' at when at a stop over a period of time. So you need to define a radius for the stop outside of which is considered the next movement, otherwise you will get multiple false stops instead of one longer stop (for example, overnight).

Another issue is how you write the report, as it will need to run through every tracking event for the vehicles in the report. If your report writer is doing this remotely through an API, you will have significant data transmission latency. Also, you will need to consider the effective of the latitude on how you calculate the stop radius (distance in meters for a given number of latitude degrees changes as you travel north / south from the equator).

In our case we use Postgresql / PostGIS on a separate analytics / reporting database, with the position also stored as a geographical point datatype, due to the poor design of our existing tracking system DB (not Traccar).
I use a stored procedure plus PostGIS functions to extract the stops entirely within the database, so performance is not an issue. By far the biggest performance hit is pulling reverse geocodes from Google Maps API.
If you extend the Traccar reports, you can probably use the same Java functions and server-based processing as Traccar does, which also should give good performance.

Anton will probably have a better idea though :)

Ákos5 years ago

Thank you Tony for explining your solution.

Based on traccar documentation i think it should work.
(https://www.traccar.org/documentation/trips-stops/)
My situation is very similar with first example. moving - stop 3 minutes - moving.
minimalParkingDuration(120) is lower than the real stop duration. The example not mentioned ACC status. But in fact the code have to use ACC.

Anton, could you help identify which condition is responsible for making trips in code?
Or anyone who have more proficiency than me in java code?

Thanks a lot.

Ernesto Vallejo5 years ago