Hi team,
I’m currently working with the latest Traccar version and ran into a limitation with reverse geocoding.
At the moment, Traccar allows only one geocoder provider at a time (e.g., LocationIQ, MapTiler, Nominatim, etc.).
But in production environments, providers may fail due to network errors, API downtime, or quota limits.
Why Fallback Matters
If a provider goes down or hits a quota, address resolution stops completely.
Example error I encountered:
WARN: Geocoder network error - us1.locationiq.com - UnknownHostException
This means my system could not resolve addresses at all until the provider came back online.
Proposed Solution
Introduce fallback geocoding where:
- The primary geocoder is tried first (e.g., LocationIQ).
- If it fails or returns empty, a secondary geocoder (e.g., MapTiler, Nominatim) is used automatically.
Example XML config
<entry key='geocoder.enable'>true</entry>
<entry key='geocoder.type'>fallback</entry>
<entry key='geocoder.primary'>locationiq</entry>
<entry key='geocoder.secondary'>maptiler</entry>
<entry key='geocoder.cache'>true</entry>
<entry key='geocoder.cacheSize'>20000</entry>
My Attempt
I tried building a custom FallbackGeocoder.java
that checks if the primary fails, then calls a secondary.
It works in principle, but since "fallback"
isn’t a built-in type in the current DI setup, I had to patch Traccar code manually to register it.
Here’s a simplified snippet from my experiment:
public class FallbackGeocoder implements Geocoder {
private final Geocoder primary;
private final Geocoder secondary;
public FallbackGeocoder(Config config, Client client) {
this.primary = new LocationIqGeocoder(...);
this.secondary = new MapTilerGeocoder(...);
}
@Override
public String getAddress(double lat, double lon, ReverseGeocoderCallback callback) {
String address = primary.getAddress(lat, lon, callback);
return (address == null || address.isEmpty())
? secondary.getAddress(lat, lon, callback)
: address;
}
}
Request
Would it be possible to add native support for fallback reverse geocoding in Traccar?
This would make deployments much more robust.
Even a simple config allowing primary + secondary providers would cover most real-world needs.
Thanks for considering this improvement!
Hi team,
I’m currently working with the latest Traccar version and ran into a limitation with reverse geocoding.
At the moment, Traccar allows only one geocoder provider at a time (e.g., LocationIQ, MapTiler, Nominatim, etc.).
But in production environments, providers may fail due to network errors, API downtime, or quota limits.
Why Fallback Matters
If a provider goes down or hits a quota, address resolution stops completely.
Example error I encountered:
This means my system could not resolve addresses at all until the provider came back online.
Proposed Solution
Introduce fallback geocoding where:
Example XML config
<entry key='geocoder.enable'>true</entry> <entry key='geocoder.type'>fallback</entry> <entry key='geocoder.primary'>locationiq</entry> <entry key='geocoder.secondary'>maptiler</entry> <entry key='geocoder.cache'>true</entry> <entry key='geocoder.cacheSize'>20000</entry>
My Attempt
I tried building a custom
FallbackGeocoder.java
that checks if the primary fails, then calls a secondary.It works in principle, but since
"fallback"
isn’t a built-in type in the current DI setup, I had to patch Traccar code manually to register it.Here’s a simplified snippet from my experiment:
public class FallbackGeocoder implements Geocoder { private final Geocoder primary; private final Geocoder secondary; public FallbackGeocoder(Config config, Client client) { this.primary = new LocationIqGeocoder(...); this.secondary = new MapTilerGeocoder(...); } @Override public String getAddress(double lat, double lon, ReverseGeocoderCallback callback) { String address = primary.getAddress(lat, lon, callback); return (address == null || address.isEmpty()) ? secondary.getAddress(lat, lon, callback) : address; } }
Request
Would it be possible to add native support for fallback reverse geocoding in Traccar?
This would make deployments much more robust.
Even a simple config allowing primary + secondary providers would cover most real-world needs.
Thanks for considering this improvement!