GPS Filtering and Ignition Events Optimization — Traccar 6.15.3

Hello,

We use Traccar 6.15.3 with PostgreSQL for our GPS tracking platform.

We enabled static filtering to reduce unnecessary GPS positions while vehicles are parked and minimize server load.

Our current configuration is:

<entry key="filter.enable">true</entry>
<entry key="filter.invalid">true</entry>
<entry key="filter.zero">true</entry>
<entry key="filter.static">true</entry>
<entry key="filter.accuracy">100</entry>
<entry key="filter.skipLimit">1800</entry>

However, we are experiencing two issues:

Stop detection can take 30–60 minutes because our backend requires two distinct stationary GPS fixes to confirm a stop.

Ignition ON/OFF events may be delayed or missed due to static position filtering.

We tested filter.skipLimit=300 in a local simulation, which improved stop detection but increased the number of stored positions.

My question: What is the best way to process GPS positions and ignition events in real time while minimizing PostgreSQL writes?

Is it possible to separate real-time processing from position storage without modifying Traccar's source code?

Thank you for your advice!

Is your concern storage size or database connection bandwidth? Have you tried batching writes?

Hi Anton,

Our main concern is reliable real-time stop detection and ignition events, while avoiding unnecessary database growth and write overhead.

We enabled static filtering primarily to reduce the number of redundant positions stored while vehicles are parked, not because we have confirmed a database bandwidth bottleneck.

Unfortunately, filtering these positions delays stop confirmation and may suppress ignition transitions.

We haven't verified whether position write batching is enabled in our current configuration. We'll check that.

Would you recommend enabling batching and relaxing static filtering in this situation?

Would batching help with write performance while keeping all incoming positions, or is there a better native approach to preserve real-time events without storing every redundant stationary position?

Thank you for your guidance!

Batching will improve database writing performance, if that's an issue.