• [x] FreeGeoIpProvider
• [x] HostIpProvider
• [x] IpInfoDbProvider
• [x] YahooProvider (REMOVED)
• [x] GoogleMapsProvider
• [x] GoogleMapsBusinessProvider
• [x] BingMapsProvider
• [x] OpenStreetMapsProvider
• [x] CloudMadeProvider
• [x] GeoipProvider
• [x] MapQuestProvider
• [x] OIORestProvider
• [x] GeocoderCaProvider
• [x] GeocoderUsProvider
• [x] IGNOpenLSProvider
• [x] DataScienceToolkitProvider
• [x] YandexProvider
• [x] GeoPluginProvider
• [x] GeoIPsProvider
• [x] MaxMindProvider
• [x] MaxMindBinaryProvider
• [x] GeonamesProvider
• [x] IpGeoBaseProvider
• [x] BaiduProvider
• [x] TomTomProvider
• [x] ArcGISOnlineProvider

@willdurand @Baachi What do you think ?

The website is still showing the documentation for the 3.x major version, as well as a very outdated provider list.

http://geocoder-php.org/Geocoder/

I think we should either update the site (and have it automatically be re-built/deployed using CI on merge to master) or direct users to the github repo.

I'll to look into it and create a PR when I have a chance.

This PR relates to #523

To be more SOLID our value objects should have interfaces. This will allow others to write providers that may return more data than we have defined in our models.

This is WIP because Im not happy with the *Interface suffix. We need to come up with better names. Or, are we happy with names like AddressInterface?

This PR also removes the toString function in favor for __toString

TODO

• [x] Be confident with the interface names
• [x] Update changelog

This is an improvment to the MapQuest provider, that we talked about in #839

I have tried to stay away from the code in the Common directory, but I could not avoid some small minor changes there to make it all fit together. Hope this will be ok.

This providers would allow to geolocation info from MaxMind`s .dat files. A developer should install MaxMind's php lib himself and include it.

I want to know Is it really possiblt to add such provider to a lib? If so we can discuss what should be added (tests\docs for example).

UPDATED

tests and doc is updated, The PR is ready to merge.

PR for for ticket #392. To sum up: replace every occurrence of region and county (no "r"), with a generic admin level array.

TODOs:

• [x] delete Region and County from Model namespace;
• [x] add Admin to Model namespace;
• [x] update failing test for Providers;
• [x] fix all providers code;
• [x] update string formatter;
• [x] update documentation;
• [x] squash all commit :)
• [x] update all tests (USE_CACHED_RESPONSES=false)

I'll like to hear you feedback about:

1. [minor] In AbstractProvider::getDefaults the admins value defaults to [] to simplify a bit the code. Is it ok?
2. Is Admin a clear class name or it is better to call it AdminLevel (as in #392)?
3. I'm using a simple array for admin levels, where the index is the "depth" in the hierarchy. Is this enough for you?
4. string formatter is now using %R and %P for Region and County, but this no longer make sense. What should be used? %A1, %A2,%A3,%A4? %A0, %A1, %A2,%A3 (as the array index, not the admin level)? %X, %Y,%Z,%W (as in math :)? Something else?

I'm not sure when MaxMind made the change, but they've split out their web services in to different service offerings, with different credits required for each and different result orders.

http://dev.maxmind.com/geoip/web-services

I added an additional parameter to the MaxMindProvider that indicates the service, and then properly parsed and validated the different results.

I've been able to test the 'City/ISP/Org' API and the 'Omni' API, but I don't have credits for the rest.

Additionally, they added support for IPv6.

Hey guys,

PSR6 has been released weeks ago and so we have a standard for caching. The feature has been wished thousand times so i started to work on it. Currently this is only a proof of concept and i will finished it if we all fine with the idea.

My intention is currently: We provide multple strategies and the user can decide how he wants to cache the response. Currently i wrote the stale-if-error strategy and the expire strategy, because i think these are the most common behaviours.

Please provide feedback :smile:

Hey William,

The library is really popular (971 Stars on GitHub and 37063 Downloads on Packagist), which is really :cool: . But i think geocoder has a missing feature, caching.

I created already a CacheProvider in the BazingaGeocoderBundle, so i would suggest to move this provider to the core library.

What do you think about this change?

Hi,

This project is just great, I'm looking forward to use the propel behavior. But first, a simple try does not work, i did this:

<?php
                                                $geocoder = new \Geocoder\Geocoder();
                                                $adapter = new \Geocoder\HttpAdapter\SocketHttpAdapter();

                                                $geocoder->registerProviders(array(
                                                    new \Geocoder\Provider\GoogleMapsProvider($adapter, 'API_KEY'),
                                                )); // yes i changed API_KEY by mine

// IP based
                                                // Street address based
$result = $geocoder->geocode('10 rue Gambetta, Paris, France');
                                                var_dump($result);
                                                ?>

I have this result:

Geocoder\Exception\NoResultException

Could not execute query http://maps.googleapis.com/maps/api/geocode/json?address=10%20rue%20Gambetta%2C%20Paris%2C%20France&sensor=false&language=API_KEY

But if, i type this link in my browser, I do have a result. Is that normal?

I see where there have been previous issues with this. But as it stands with 2.4.1 the current use of "client=" is incorrect.

For me, if I change it to client_id it works:

http://maps.googleapis.com/maps/api/geocode/json?address=31.4789%20-97.0926&sensor=false&client_id=<my_client_id>

Some addresses have a "neighbourhood" field, for example :

https://nominatim.openstreetmap.org/reverse?format=xml&lat=35.685939&lon=139.811695&zoom=18&addressdetails=1

In jsonResultToLocation(), this field is not processed, so we can't get that value through the reverseQuery() method.

Is the doc updated? When i try to use $provider = new \Geocoder\Provider\ArcGISList\ArcGISList($httpClient); says class not found, but if i use $provider = new Geocoder\Provider\ArcGISOnline\ArcGISOnline($httpClient); it works, so im i doing something wrong or ?

[...] is it possible to get the address id also when the provider list the results ..

For example arcgis have an id to identify that address, its possible to get that info also on the result array?

Originally posted by @mrelliot69 in https://github.com/geocoder-php/Geocoder/issues/1163#issuecomment-1263963499

I noticed the OpenRouteService::API_URL is being hard-coded into file Geocoder\Provider\OpenRouteService (vendor\geocoder-php\openrouteservice-provide\OpenRouteService.php)

Could someone please push the following code into the next version of OpenRouteService (updating Pelias would do the trick)

vendor\geocoder-php\pelias-provider\Pelias.php

/**
 * @param HttpClient $client  an HTTP adapter
 * @param string     $root    url of Pelias API
 * @param int        $version version of Pelias API
 */
public function __construct(HttpClient $client, string $root, int $version = 1)
{
    $this->_setPeliasApiRoot($root, $version);
    parent::__construct($client);
}

/**
 * Set the API root and version, see "_setPeliasApiRoot"
 * @param string     $root    url of Pelias API
 * @param int        $version version of Pelias API
 */
public function set_Pelias_ApiRoot(string $root, int $version = 1)
{
    return $this->_setPeliasApiRoot($root, $version);
}

/**
 * Set the API root and version
 * @param string     $root    url of Pelias API
 * @param int        $version version of Pelias API
 */
protected function _setPeliasApiRoot(string $root, int $version = 1)
{
    $this->root    = sprintf('%s/v%d', rtrim($root, '/'), $version);
    $this->version = $version;
}

vendor\geocoder-php\openrouteservice-provider

const API_URL = 'https://api.openrouteservice.org/geocode';
const API_VERSION = 1;

/**
 * @var string
 */
private $apiKey;

/**
 * @param HttpClient $client an HTTP adapter
 * @param string     $apiKey an API key
 */
public function __construct(HttpClient $client, string $apiKey)
{
    if (empty($apiKey)) {
        throw new InvalidCredentials('No API key provided.');
    }
    
    $this->apiKey = $apiKey;
    parent::__construct($client, self::API_URL, self::API_VERSION);
    $this->_set_ORS_API_Root(self::API_URL, self::API_VERSION, TRUE);
}

/**
 * Set the Openrouteservice URL
 * @param string $root
 * @param integer $version
 * @param boolean $check_version
 * @return void
 */
public function set_ORS_API_Root(string $root, $version, $check_version = false)
{
    return $this->_set_ORS_API_Root($root, $version, $check_version);
}

/**
 * Set the Openrouteservice URL
 * @param string $root
 * @param integer $version
 * @param boolean $check_version
 * @return void
 */
protected function _set_ORS_API_Root(string $root, $version, $check_version = false)
{
    parent::_setPeliasApiRoot($root, $version);
    if (filter_var($check_version, FILTER_VALIDATE_BOOLEAN)) {
        $this->_check_ORS_API_Root_Version($root, $root, $version);
    }
}

/**
 * Openrouteservice does not use /v1 in first version, but plan to add
 *  /v2 in next version.
 *
 * @see https://ask.openrouteservice.org/t/pelias-version-in-api-url/1021
 * @param string $root
 * @param string $new_root
 * @param string $version
 * @return void
 */
protected function _check_ORS_API_Root_Version(string &$root, string $new_root, $version)
{
    $version_ok = true;
    $version_ok = ($version_ok && is_numeric($version));
    $version_ok = ($version_ok && ($version === self::API_VERSION));
    $version_ok = ($version_ok && is_string($new_root));
    $version_ok = ($version_ok && !empty($new_root));
    $version_ok = (bool) $version_ok;
    
    if ($version_ok) {
        $root = $new_root;
    }
}

I came across some reverse geocoding results where Nominatim.php didn't return a 'locality'. In my opinion, this latlng query should have 'Purmerend' as its locality, as it's the municipal boundary:

https://nominatim.openstreetmap.org/ui/reverse.html?lat=52.50741&lon=4.93279&zoom=18 https://nominatim.openstreetmap.org/ui/details.html?osmtype=W&osmid=6593763&class=highway

Upon debugging, I noticed that inside jsonResultToLocation(), on line 209, 'municipality' was not considered a 'locality'.

$localityFields = ['city', 'town', 'village', 'hamlet'];

Is this a matter of definition?

Adding 'municipality' fixes my issue:

$localityFields = ['city', 'town', 'village', 'hamlet', 'municipality'];