Reverse Geocode still attempted for filtered positions?

To prevent using up the daily limited quota of LocationIQ Geocoding service enquiries, I'd added filtering to the traccar.xml config file: <entry key='filter.distance'>50</entry> To idea to prevent Traccar server processing 1000's of identical locations each day. Filter itself seems to work fine.

However I've noticed in the Traccar server log, about 10% of the filtered-out positions show a reverse geocode WARNing.

I suspect the Traccar server is attempting a reverse geocode requests on every location, whether filtered or not and this 10% is the ongoing failure rate at the time.

Is this a bug in Traccar server?

Two examples (HEX translated)
2017-04-25 21:27:29 DEBUG: [0C080D82: 11675 < 82.132.232.81] HEX: imei:359710040657075,tracker,1704252127,,F,202721.000,A,5153.3188,N,00026.2792,W,0.00,0;
<strong>2017-04-25 21:27:29  WARN: Geocoding failed - Empty address - GeocoderException (JsonGeocoder:74 < ...)</strong>
2017-04-25 21:27:29  INFO: Position filtered by Distance filters from device: 359710040657075 with id: 31

2017-04-25 21:40:38 DEBUG: [A2379D2C: 11675 < 82.132.236.38] HEX: imei:359710042078619,tracker,1704252140,,F,204035.000,A,5153.3954,N,00026.2517,W,0.00,0;
<strong>2017-04-25 21:40:38  WARN: Geocoding failed - Empty address - GeocoderException (JsonGeocoder:74 < ...)</strong>
2017-04-25 21:40:38  INFO: Position filtered by Distance filters from device: 359710042078619 with id: 25

I wouldn't call it a bug. That's just how it works at the moment. Geocoder is before filtering in the pipeline.

I'm following up on this, since I'm running into the same problem, and think it would be a good idea to filter first and then geocode; after all, if I'm filtering out positions (say, within 50 to 100 metres), than I'm sort of assuming that these are all the same "place". Any chance of (re)implementing the pipeline so that filtering takes place before geocoding ?

I ran into this recently when my mobile data went south, but it seems the client stores data that it cannot send, and then sends a whole bunch of (older) positions, so when it connected to WiFi, it sent the data to the server to reverse geocode, and of course due to the high number of requests per second, got this "error"

Alternatively might there be a way to rate-limit updates to 1/sec, so as not to go over (many) of the free reverse geocoding services. If you use the defaults, the client updates every 5 minutes, so that you'd have a maximum of 288 requests on a daily basis; even if you stored a complete days worth of positions, it would take no more than 5 minutes (300 seconds) to send the 288 reverse geocoding requests at 1 per second....

Anyway, thanks for traccar -- its fabulous!

For any suggestions about new features and modifications you should use GitHub. I agree that it's probably good idea to re-order pipeline.

As for rate limiting, I don't think it's a good idea. I imagine that most people would prefer to upload all data as soon as possible because you won't get live data till all historical records are uploaded. Also, many customers use higher rate than default 5 minutes.