Comment obtenir l'équivalent de la précision dans Google Map Geocoder V3

Question

Je veux obtenir un géocodage de google, et j'avais l'habitude de le faire avec le V2 de l'API. Google envoyer dans le json une assez bonne information, la précision, la référence ici: http://code.google.com/intl/fr-FR/apis/maps/documentation/javascript/v2/reference.html#GGeoAddressAccuracy

Dans V3, Google ne semble pas me envoyer exactement la même information. Il y a le tableau "adresse_component", qui semble plus grand si la précision est meilleure, mais pas exactement. Par exemple, j'ai une demande de précision au numéro de rue, le tableau est de taille 8. Une autre requête est la précision de l'itinéraire, donc moins de précision, mais le tableau est toujours de taille 8, car il y a une ligne 'sublocalité », qui n'apparaissent pas dans le premier cas. Ok, pour un résultat, Google envoie un «type» de données, qui a la «meilleure» précision. Ces types sont ici: http://code.google.com/intl/fr-FR/apis/maps/documentation/geocoding/#Types Mais, il n'y a pas de véritable ordre, et si je ne veux pas le résultat meilleur que postal_code, je n'ai aucune idée de comment faire ça. Alors, comment puis-je obtenir cet équivalent de la précision V2, sans code bête et horrible?

Answer 1

Eh bien, il y a le location type, ce qui est pas si mal:

stocke LOCATION_TYPE des données supplémentaires sur l'emplacement spécifié. Les valeurs suivantes sont actuellement prises en charge:

"ROOFTOP" indique que le résultat renvoyé est un géocodage précis pour lequel nous avons des informations de localisation précises jusqu'à la précision de l'adresse de rue. "RANGE_INTERPOLATED" indique que le résultat renvoyé reflète une approximation (généralement sur une route) interpolée entre deux points précis (tels que des intersections). Les résultats interpolés sont généralement renvoyés lorsque les géocodes de toit ne sont pas disponibles pour une adresse de rue.

« GEOMETRIC_CENTER » indique que le résultat retourné est le géométrique centre d'un résultat comme une polyligne (par exemple, une rue) ou polygone (région). »

« APPROXIMATIVE » indique que le retournée résultat est environ.

je teste si le location_type est différent d'environ, et il donne de bons résultats.

Answer 2

Avec Google dévalorisant leur API v2 géocodage la Cette année, il y aura une tonne de gens qui migreront leur logique de géocodage vers v3 et cette question va se poser: Comment mapper la chaîne 'location_type' à une 'exactitude' équivalente?

Voici une carte décente:

"ROOFTOP" -> 9 
[Everything else] -> 4 to 8 (aka the text string might as well read "GARBAGE") 

Si autre chose que TOITURE est spécifié, utilisez la zone du « nord-est » et « ouest » pour décider s'il est assez précis pour vous.

Maintenant, que devrait-il se passer si vous n'obtenez pas quelque chose de «précis»? Exécutez une requête de recherche de texte Google Adresses pour la même adresse.Google Adresses effectue également le géocodage et, avec la facturation activée, vous pouvez obtenir 10 000 requêtes de recherche de texte par jour (sans limite de tarif) et Google affirme qu'elles ne factureront pas la carte (elles l'utilisent uniquement pour vérifier le compte). Avec la facturation, vous obtenez 100 000 requêtes, mais les requêtes de recherche de texte Places ont un «coût» de 10 fois le montant d'une requête Places régulière, d'où la limite de 10 000 susmentionnée. Les lieux peuvent être fastidieux et vous ne devriez considérer les réponses qu'avec un seul résultat. Parfois, les requêtes Google Adresses ne renvoient pas de code postal, en particulier si aucune n'est envoyée. Si vous avez besoin du code postal, prenez les résultats lat/lng de la requête Places et renvoyez-le dans le géocodeur, qui crachera généralement une adresse avec un code postal (et très souvent une correspondance ROOFTOP).

Il convient de noter que la limite de courtoisie officielle de l'API de géocodage est de 2 500 demandes par jour avec une limite de débit d'une par seconde par adresse IP. Par conséquent, en suivant la formule ci-dessus va probablement décimer et peut même réduire de moitié le nombre de géocodages à votre disposition.

Si vous avez besoin de plus que la limite de Google Géocodage (qui n'en a pas?), Inventez votre propre mini service de géocodage avec quelque chose comme la base de données OpenStreetMap. Clonez les parties d'OpenStreetMap dont vous avez besoin et écrivez votre propre géocodeur (ou utilisez une bibliothèque). Ensuite, vous pouvez géocoder le contenu de votre cœur sans limite de quantité ou de taux. Si vous utilisez toujours Google Maps, vous pouvez utiliser le géocodeur de Google comme solution de repli si le géocodeur OSM n'est pas suffisamment précis pour tous les cas. Alternativement, si vous faites confiance à vos utilisateurs pour qu'ils ne soumettent pas (vraiment?) De fausses données et qu'ils utilisent le service de géocodage Google, vous pouvez également abuser du navigateur Web d'un utilisateur en lui fournissant des informations de géocodage. à votre serveur. Vous risquez d'épuiser la limite quotidienne de l'utilisateur et vous risquez que quelqu'un pousse des données fausses, mais si vous vous occupez de tous ces problèmes, vous en souciez-vous? Quoi qu'il en soit, les conseils ci-dessus devraient suffire pour une utilisation provisoire pour la plupart des utilisateurs afin de faire fonctionner une API v3 fonctionnelle. Ran dans ce problème moi-même, donc pensé que je partagerais avec la communauté une solution à mi-chemin décent. Je pense toujours que v2 était la meilleure API - les cotes d'exactitude des entiers au lieu des chaînes de texte laides gagnent toujours.