At first glance, the new Geolocation 3.0 “find by address” box seems much less accurate than the Google Maps API. Many addresses or street intersections that Google Maps easily finds cannot be found when entered into the Leaflet search box. Is this just a known disadvantage of not using the Google Maps API?
Basically, yes.
As a consequence of not using Google’s API, we have to switch to another geocoding provider. In this case, it’s out of the box set up to use Photon, an engine based on Nominatim, the geocoder from the OpenStreetMap project. Its results are very dependent on OSM’s data, plus have some areas where they generally just perform worse.
We can try to offer some more options for geocoders (the implementation is set up to allow them to be switched out without much trouble), but there aren’t a lot of options that have favorable usage terms: many specifically forbid saving the resulting coordinates, and/or mandate that results only be shown on their own maps. Mapbox, which we otherwise provide support for, falls into this category: their default “free tier” prohibits saving locations.
1 Like
You can still input actual coordinates directly in the “address” box, in both the older (but still relatively recent) Geolocation and the new, if you have them.
Got it. Thanks for the helpful reply. I’m using Geolocation with Contribution where Google Maps API’s facility with ambiguous or incomplete addresses supplied by the user comes in very handy.
By the way, is it your interpretation that the Google Maps API terms DO allow saving lat/long coordinates found using the plugin? Or, if not, is that one reason for moving the plugin away from Google towards Photon?
This topic was automatically closed after 250 days. New replies are no longer allowed.