L’accès à ces services se fait simplement via une requête HTTP. Et comme rien ne vaut un bon exemple, voici comment appeler le service Google pour localiser "37 boulevard des capucines, Paris" :
http://maps.google.com/maps/geo ?q=37+boulevard+des+capucines%2Cparis&output=xml&key=...
Et voici la même requête mais via Yahoo cette fois-ci : http://local.yahooapis.com/MapsService/V1/geocode ?street=37+boulevard+des+capucines&city=...
Maintenant que le décor est planté, comparons d’un peu plus près ces deux services.
Avec Yahoo, l’adresse est entrée avec plusieurs paramètres :
| paramètre | valeur |
|---|---|
| street | 37 boulevard des capucines |
| city | Paris |
| zip | 75002 |
| state | France |
Il n’est pas obligatoire de renseigner tous les paramètres, mais évidemment, plus on en renseigne, plus on a de chances de lever les ambigüités. Exemple : La recherche de city=Lancaster renvoie un très grand nombre de solutions :
<ResultSet>
<Result precision="zip">
<Latitude>34.698905</Latitude>
<Longitude>-118.144779</Longitude>
<City>Lancaster</City>
<State>CA</State>
<Country>US</Country>
</Result>
<Result precision="zip">
<Latitude>39.571800</Latitude>
<Longitude>-95.302239</Longitude>
<City>Lancaster</City>
<State>KS</State>
<Country>US</Country>
</Result>
etc...
Si l’on précise que l’on souhaite city=Lancaster, state=UK , une seule réponse est retournée :
<ResultSet>
<Result precision="zip">
<Latitude>54.044535</Latitude>
<Longitude>-2.799029</Longitude>
<City>Lancaster, Lancashire</City>
<State>United Kingdom</State>
<Country>GB</Country>
</Result>
</ResultSet>
Yahoo propose également une alternative à la saisie des paramètres street, city, zip, et state. Il est possible de saisir un seul paramètre : location, contenant l’adresse complète. Cette solution est moins efficace que la solution précédente, mais dans certains cas où les adresses ont été stockées de manière peu formalisée, il n’est pas possible de séparer la rue, la ville, le code postal et le pays.
Contrairement à Yahoo, Google ne permet la saisie que via un seul paramètre :
| paramètre | valeur |
|---|---|
| q | 37 boulevard des capucines, Paris |
Pour faciliter l’interprétation par Google de l’adresse saisie, il est préférable d’utiliser la virgule pour séparer la rue, la ville, le code postal, et le pays.
Cependant, cela montre une lacune importante : les ambigüités peuvent être beaucoup plus nombreuses qu’avec Yahoo. Par exemple, si on recherche q=Georgia , Google va-t-il retourner le pays ? L’état américain ? Une ville ? Une rue d’Angleterre ? Donc comme pour Yahoo, plus l’adresse est complète, moins il y a d’ambigüités : q=Georgia,USA , q=Georgia,UK .
Mais il s’agit d’un point qui peut dans certain cas s’avérer très gênant.
Yahoo propose 2 formats de sortie : xml ou php serialisé. Le choix se fait avec le paramètre output :
| format | exemple |
|---|---|
| xml | output=xml |
| php serialisé | output=php |
Ces 2 formats sont très facilement exploitables : coté client (javascript), on préfèrera le xml, et coté serveur, si on est en technologie php, la question ne se pose même pas !
La réponse xml est formalisée par ce schéma xsd. On voit donc que la réponse est relativement simple :
En plus de ces champs, Yahoo renvoie 2 champs permettant de qualifier la pertinence de la réponse :
Google propose plusieurs formats, le choix se fait également avec le paramètre output :
| format | exemple |
|---|---|
| xml | output=xml |
| kml | output=kml |
| csv | output=csv |
| json | output=json |
Les formats xml et json sont aussi bien adaptés à des technologies clientes que serveur. Le format kml sert surtout si on souhaite exploiter le résultat sur une carte Google Maps par exemple. Et enfin, un format un peu à part, le csv : non seulement basique, le strict minimum est renvoyé, ce qui permet de l’exploiter sans utiliser de librairie particulière.
Google semble avoir oublié ce qu’est un schéma xml, donc on se contentera d’analyser un exemple pour comprendre comment sont structurées les informations de sortie. D’emblée, on remarque que la structuration est nettement plus arborée :
Cette arborescence n’est pas adaptée pour une adresse. Elle détaille trop certains points, tout en en oubliant d’autres essentiels. Par exemple, on ne récupère pas le nom du pays. Mais le plus important (coordonnées longitude / latitude) est néanmoins très facilement accessible.
Comme Yahoo, Google renvoie également 2 champs qualifiant sa réponse :
Si Yahoo trouve plusieurs localisations, la réponse listera l’ensemble des localisations (jusqu’à 50).
Exemple : street=vaugirard&city=paris :
...
<Latitude>48.841465</Latitude>
<Longitude>2.318725</Longitude>
<Address>boulevard de Vaugirard</Address>
...
<Latitude>48.841360</Latitude>
<Longitude>2.317941</Longitude>
<Address>galerie de Vaugirard</Address>
...
<Latitude>48.835936</Latitude>
<Longitude>2.293624</Longitude>
<Address>rue de Vaugirard</Address>
...
Comme Yahoo, Google est supposé pouvoir retourner une liste de plusieurs réponses dans le cas où l’adresse saisie présente des ambigüités, mais en pratique cela n’arrive quasiment jamais.
Soit Google renvoie une seule réponse qui lui paraît la plus légitime. Exemple : q=Vienne
...
<address>Wien, Austria</address>
...
Soit il diminue la précision. Exemple : q=Vaugirard, Paris
...
<AddressDetails Accuracy="1">
<Country>
<CountryNameCode>FR</CountryNameCode>
...
Google ne gère donc pas ce problème de manière satisfaisante.
Maintenant, que se passe-t-il si l’adresse n’a pas été trouvée ? On a vu dans le paragraphe précédent que si l’adresse n’a été trouvée que partiellement, une position est retournée associée d’une précision. Cependant, le service n’est pas toujours capable de retourner une adresse partielle.
Testons la recherche de "rue Clever-Age, Paris" :
street=rue+clever-age&city=paris
...
<Result precision="zip" warning="The street could not be found. Here is the center of the city.">
<Latitude>48.856925</Latitude>
<Longitude>2.341210</Longitude>
...
...
<Status>
<code>602...
Cela montre un inconvénient important de Google : s’il n’a pas l’adresse dans sa base de données, il renvoie un code d’erreur 602 (adresse introuvable) plutôt que de retourner une position approximative accompagnée d’une précision.
Dans le cas d’une application qui a besoin de localiser des adresses, même approximativement, si l’on utilise Google, il faut donc faire plusieurs requêtes pour localiser un site : une première avec l’adresse complète. Puis si Google renvoie "adresse introuvable", l’application faire une 2eme requête, mais sans la rue. Etc... jusqu’à ce que Google renvoie une localisation.
Dans le cadre d’un projet, il fallait localiser environ 1300 adresses.
Caractéristiques de ces adresses :
| Résultats | Yahoo | |
|---|---|---|
| Adresses trouvées avec une bonne précision | 25% | 5% |
| Adresses trouvées avec une mauvaise précision | 70% | 84% |
| Adresses introuvables | 5% | 11% |
Quelques remarques qui se dégagent de cette expérience :
Le service Yahoo est bridé à 5.000 requêtes par jour et par adresse IP. Au delà, un message d’erreur xml explicite est retourné.
Le service Google est quant à lui limité à 15.000 requêtes par jour et par clé.
L’utilisation de Yahoo est donc très limitée, non seulement par le nombre de requêtes, mais également par le fait que la comptabilisation se fait par adresse IP et pas par clé, ce qui peut-etre très gênant lorsque plusieurs applications sont installées sur un réseau interne par exemple.
D’autres facteurs peuvent se montrer déterminants pour le choix du fournisseur de service :
Performances : la rapidité des réponses peut-être déterminante pour certaines applications.
Erreurs internes et autres frivolités : dans cet article, les seules réponses étudiées sont "adresse localisée" et "adresse introuvable". Il faut cependant savoir qu’on peut avoir d’autres réponses, de la plus obscure "erreur interne" jusqu’à des erreurs légèrement plus explicites, telles que "adresse indisponible". Par exemple, si l’on fait des requêtes à Google trop rapidement, on obtient une erreur 620 ("too many queries"). L’appel au service de géolocalisation de Google depuis un client javascript est donc très limité en raison de ce point précis.
Géolocalisation de commerces : un peu hors-sujet, mais Yahoo propose d’autres services, dont la géolocalisation de commerces. Google offre également un service similaire, mais encapsulé dans une couche Javascript, et donc moins facilement accessible.
D’un point de vue technique, Yahoo a nettement l’avantage sur Google, pour les raisons suivantes :
Cependant, en pratique, Google semble avoir une base de données nettement plus exhaustive, couvrant le monde entier.
Si les adresses à localiser concernent le monde entier, mon conseil serait donc d’utiliser Google. Si les adresses à localiser concernent les principaux pays occidentaux, la solution Yahoo me semble plus appréciable, à condition que le nombre de requêtes ne soit pas trop important.
Comme les 2 services sont néanmoins très proches (REST, XML, de nombreuses similitudes sur les modèles de données manipulés), il n’est pas si difficile d’implémenter les 2 solutions et de comparer les résultats pour affiner son choix.
Article sympa et facile à lire.
Le tableau dans la section "Illustration par un projet concret" est (à mon sens) au premier abord pas très lisible. Il serait peut être plus judicieux d’utiliser les termes (Adresses trouvées avec une localisation exacte et Adresses trouvées avec une localisation inexacte).
Voila, félicitation à l’auteur tout de même !
Effectivement, ce n’est peut-être pas assez clair :
Sur les 1300 adresses, Yahoo n’a réussi qu’à localiser de manière "exacte" 5% de ces adresses, c’est à dire les adresses dont la rue est connue de Yahoo.
Et Yahoo a réussi à localiser 84% des adresses avec une "mauvaise précision", c’est à dire que Yahoo connaissait la ville, mais pas la rue.
Bonjour Humphrey,
Effectivement, OpenStreetMap est plein d’avenir. Couplé à Mapnik et OpenLayers ou à d’autres solutions comme FireEagle, c’est sans doute une des pierres fondatrices de l’avenir de la géolocalisation. Tout les composants d’une plateforme de cartographie libre sont en train de se mettre en place, et une bonne idée pour les projets proposant de la cartographie sur le Web serait déjà d’employer la solution d’abstraction proposée par Mapstraction... Cela pourrait être utile en vue d’un changement de fournisseur, un jour !
Ceci dit, je ne crois pas que la base d’OpenStreetMap soit exposée à des webservices permettant de localiser des adresses (ce dont traite ce billet), si ?
Bonjour, bel article en effet.
Sinon pour ma part sans avoir fait de statistiques précises il m’a semblé que la précision était meilleure sur Yahoo lorsque l’on utilisait le module de geolocalisation de Yahoo Pipes. Et notamment pour la géolocalisation d’un code postal + ville, yahoo pipes est souvent bien meilleur que Google.
J’en profite pour citer un petit article de mon blog : http://www.clocal.fr/2008/01/20/villes-et-code-postaux-geolocalises/
Bonjour,
j’utilise depuis longtemps l’API Yahoo ! Maps pour afficher des cartes et obtenir les latitudes longitudes de multiples adresses à Paris... ou IDF http://www.parisetudiant.com/agenda/sortir-a-paris-bon-plan.php
et je suis en train de tester l’API google en meme temps car l’API Yahoo ! montre des signes de faibllesse en fiabilité en répondant 8 fois sur 10 par des erreurs ;
Je dois dire que Yahoo ! trouve la pluspart des adresses que je lui donne mais en effet Google indique quelques degres de plus de precisions La précision est donc plutot égale... Mais pas la fiabilité La grosse différence est de la fiabilité des outils Yahoo ! montre des signes de faiblesses dans l’affichage de certaines cartes sur IE6 et les cartes en version image sont bien plus fiable par exemple ici sur la partie mobile http://www.parisetudiant.com/m/sortir-a-paris-evenement.php ?ne=39271