slow down Reverse Geocoding processing
We're aware of the problem, but unfortunately there's no solution yet. I would recommend creating a GitHub ticket for it.
one more question.
I have set:
<string key="geocoder.onRequest">true</string>
<string key="geocoder.ignorePositions">true</string>
<string key="geocoder.reuseDistance">40</string>
<string key="geocoder.cacheSize">40000</string>At the start and end of movement, and when the ignition is turned on and off, a request to retrieve the address is sent. The address should be cached.
Why trip/stops reports do not fetch data from the cache, only re-queries are sent? (For example, the end of trip address should be exactly the same as the ignition off address)
Caching should work, but the coordinates have to match exactly.
Something's wrong here
I checked. In my case, the events "device moving" and "device stopped" have exactly the same coordinates as the start and end addresses in the Trips reports. According to how it should work - when generating Trips reports, addresses should be taken from the cache - but they are not.
It seems that when "device moving" and "device stopped" events occur, addresses are not automatically cached... Does the cache work differently in the new version ? expires ?
I checked on a server with an older version of Traccar and it's OK there. When generating the Trips report, addresses are fetched from the cache and they are all shown in the report when you press "show" just once. (Same config on both servers)
Of course in the latest version, the cache itself works because when I click "show" button several times in the Trips report, all addresses will finally be cached and on next retries the reverse geocoder is not queried anymore.
I don't recall any changes to the caching logic.
I can see some difference between the latest version and the older ones. In both cases I have identical reversegeocoding settings.
Version 5.6 if an event occurs, e.g. I send a command and receive a result, then reversegeocoding is not performed automatically.
Older versions - if I send a command and receive a result, the response also includes an address - reverse geocoding is performed automatically.
Has anything changed in how the <string key="geocoder.onRequest">true</string> option works ?
It seems, for older versions it don't work same way and reversegeocoding is performed for every event, not just the one for which there is a notification.
I think this is the reason why the device moving/stopped event doesn't cause the address to be written to the cache and why there are so many requests to the reversegeocoding service when generating the Trips report.
It seems, for older versions it don't work same way and reversegeocoding is performed for every event, not just the one for which there is a notification.
That's correct. There was a change at some point to not do geocoding for events that don't have notifications. It saved a large number of unnecessary requests.
These were not always unnecessary requests. If you have a reversegeocoding service with a high daily limit of queries and a small limit of queries per second, this function worked perfectly, because addresses for all events were cached and then when generating Trips or Stops reports everything was immediately taken from cache without worrying about geocoder queries per second limits.
According the change you wrote about, (In new versions) if I set geocoder.onRequest to false, will reversegeocodnig be performed for every event or for none?
There's no configuration option to enable old behavior.
Free tiers of reverse geocoding services often have second rate-limits. E.g. for LocationIQ - 2 queries per second. When generating Trips and Stops reports, many queries are sent in very short time, which always exceed these limits, so after generating the report, many addresses are missing and you have to click "show" many times for all addresses to appear...
Is there any parameter in the configuration that would slow down the processing of trip/stop reports ? e.g. 1 trip per second? Such an action would slightly extend the time of generating reports - but the addresses would always be complete.