Objectif
Il est souvent nécessaire de valider l'emplacement d'un lieu. Différents services Google Maps Platform peuvent vous aider dans ce cas d'utilisation. Ce document vous aide à choisir entre les deux principaux services de validation de position : l'API Address Validation et l'API Geocoding.
L'API Address Validation est une offre de Google Maps Platform qui aide les clients à vérifier si une adresse est exacte ou non.
Avec l'API Geocoding, le geocoding consiste à convertir des adresses en coordonnées géographiques, que vous pouvez utiliser pour placer des repères sur une carte ou une position sur la carte.
Pour obtenir une présentation générale des différences entre Address Validation et Geocoding, cliquez ici.
Quand choisir Address Validation ou l'API Geocoding ?
Remarques concernant l'organigramme ci-dessus:
- Le cas d'utilisation "Interaction utilisateur" désigne le moment où un utilisateur est présent pour interagir avec les résultats.
- Places Autocomplete est une API JavaScript. Elle peut donc être intégrée aux interfaces utilisateur.
- Vous avez peut-être entendu parler de problèmes de qualité des données dans vos adresses existantes. Ainsi, même si vous souhaitez simplement utiliser des géocodes, il est recommandé d'exécuter ces établissements via l'API Address Validation pour corriger les ensembles de données.
Il existe de nombreuses situations dans lesquelles vous pouvez choisir, en fonction de l'arbre de décision ci-dessus, d'utiliser un produit plutôt que l'autre. Mais d'autres situations peuvent impliquer l'utilisation des deux produits pour atteindre vos objectifs.
Vous pouvez choisir d'utiliser l'API Address Validation plutôt que l'API Geocoding dans les cas suivants:
- Il y a de fortes chances que des données soient douteuses ou qu'une adresse incorrecte ait un impact négatif en aval. En effet, l'API Address Validation fournit davantage de commentaires sur les raisons pour lesquelles une entrée n'a pas reçu un résultat de précision élevée.
- Vous devez corriger les entrées utilisateur (par exemple, des fautes d'orthographe ou des champs manquants), ce qui augmente la probabilité d'obtenir un résultat précis.
- Votre région cible renvoie plus de métadonnées de l'API Address Validation que de l'API Geocoding (par exemple, la classification du type de bâtiment en tant que bâtiment résidentiel ou commercial).
Vous pouvez choisir d'utiliser Geocoding plutôt que l'API Address Validation dans les cas suivants:
- Votre objectif principal est de récupérer la position d'une adresse et la précision de chaque adresse n'est pas nécessairement essentielle.
- Par exemple, pour générer une carte de densité à partir d'un grand ensemble de données.
- Vous avez besoin d'une solution globale et l'API Address Validation n'est pas disponible dans toutes les régions cibles.
Vous trouverez ci-dessous quelques exemples des fonctionnalités de l'API Address Validation comparées à celles de l'API Geocoding.
Exemple d'adresse non valide
1 Fake St, Mountain View, CA 94043, États-Unis
L'API Address Validation décompose cette entrée en ses composants d'adresse individuels (rue, ville, État, etc.). Il peut également fournir des commentaires détaillés sur la raison pour laquelle l'adresse n'est pas valide jusqu'à un niveau PREMISE.
La rue Fake Stand n'existe pas à Mountain View, en Californie, et l'API Address Validation le reflète dans les informations de niveau des composants renvoyées:
{
"componentName": {
"text": "Fake St",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
}
Dans ce cas, la propriété importante à inspecter est confirmationLevel. En renvoyant UNCONFIRMED_BUT_PLAUSIBLE pour Fake St, l'API a déterminé qu'une rue pourrait avoir ce nom comme nom, mais elle ne peut pas être mise en correspondance avec les données d'adresse correspondantes.
En utilisant le résultat de l'API en tant que commentaire, on peut déduire que le composant "street" de cette entrée (Fake St) est en cause.
En utilisant la même adresse avec l'API Geocoding, l'API peut établir une correspondance avec le mot "Californie", comme illustré dans la capture d'écran de l'outil de geocoding que vous pouvez essayer ici:
Cependant, le résultat est un géocode de l'ensemble de l'état, avec un minimum d'informations sur les composants potentiellement défectueux.
Exemple de faute d'orthographe
76 Buckingamm Palace Road, Londn, SW1W 9TQ, Royaume-Uni
L'adresse ci-dessus contient quelques fautes d'orthographe, l'une dans le nom de la rue et l'autre dans la localité.
L'API Address Validation et l'API Geocoding sont toutes deux capables de corriger ces erreurs et d'obtenir le résultat du 76 Buckingham Palace Road, Londres, SW1W 9TQ. Toutefois, l'API Address Validation peut fournir plus d'informations sur le processus.
Examinez l'un des composants d'adresse qui ont été mal orthographiés lors de la saisie:
{
"componentName": {
"text": "Buckingham Palace Road",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel": "CONFIRMED",
"spellCorrected": true
}
}
L'API Address Validation renvoie un indicateur pour indiquer qu'une correction a été apportée au champ. Vous pouvez implémenter la logique métier à l'aide de cet indicateur pour vérifier la correction auprès du fournisseur de données (par exemple, lorsqu'un client effectue un paiement en ligne).
Exemple de données manquantes et d'erreurs d'orthographe
Bollschestraße 86, 12587, DE
L'adresse ci-dessus comporte une faute d'orthographe dans le nom de la rue et ne contient pas la ville (localité) de Berlin.
L'API Address Validation est capable de corriger ces deux erreurs et renvoie un geocode de niveau PREMISE et une adresse validée au niveau PREMISE:
Bölschestraße 86, 12587 Berlin, DE
Dans ce cas, l'API Geocoding ne parvient pas à contourner les erreurs de saisie et renvoie le résultat ZERO_RESULTS.
Exemple de métadonnées d'adresse supplémentaires
111 8th Avenue Ste 123, New York, NY 10011-5201, États-Unis
Cette adresse est correcte, à l'exception du numéro d'unité (Ste 123), qui n'existe pas à l'intérieur du bâtiment.
L'API Address Validation peut valider l'adresse du PREMISE (111 8th Ave) et fournir des métadonnées sur l'établissement, y compris s'il s'agit d'une adresse commerciale
de l'IA générative:
"business": true
De plus, la valeur dpvConfirmation renvoyée dans le uspsData dans la réponse est S:
"dpvConfirmation": "S"
Une valeur dpvConfirmation de S indique que l'adresse est validée au niveau PREMISE, mais que le numéro d'unité fourni dans la saisie n'est pas associé à cette adresse.
L'API Geocoding n'est pas en mesure de fournir ces informations.
Comprendre la réponse de l'API Geocoding
Présentation
Si vous utilisez l'API Geocoding, le résultat du geocoding contient plusieurs indices dans la réponse, qui peuvent être utilisés pour comprendre les détails de l'adresse fournie.
Le fonctionnement de l'API Geocoding consiste à résoudre les composants d'adresse dans une hiérarchie.
Par exemple, 123 Example Street, Chicago, 60007, USA est résolu dans l'ordre suivant:
/ Example Street/ Chicago/ 60007/ USA sont évalués dans cet ordre. La première correspondance dans ce cas est Chicago et, plus précisément, le code postal 60007. Par conséquent, il renvoie l'identifiant Place_id suivant pour ce code postal:
ChIJwRKzf8ixD4gRHiXqucwr_HQ
L'API Geocode contient les informations suivantes dans la réponse:
"partial_match": true,
"place_id": "ChIJwRKzf8ixD4gRHiXqucwr_HQ",
"types": [
"postal_code"
]
L'API Geocoding peut confirmer le type de lieu auquel cette adresse appartient. Pour consulter la liste des adresses types renvoyées par l'API Geocoding, cliquez ici.
Si aucun des composants de l'entrée n'est résolu, l'API renvoie le résultat suivant:
{
"results": [],
"status": "ZERO_RESULTS"
}
Une requête avec une adresse postale sans numéro de rue renvoie un résultat au format suivant:
"types": [
"route"
]
Cela signifie que l'API Geocoding n'a pas pu trouver ni établir de correspondance avec un numéro de rue.
Remarque:Pour savoir si une adresse existe, vérifiez si des paramètres (tels que types ou partial_match, results, status)) sont définis dans la réponse de l'API Geocoding. Cela augmentera progressivement le niveau de confiance quant à l'existence d'une adresse, mais ne la rendra pas précise à 100 %. C'est pourquoi nous avons besoin de l'API Address Validation.
Vous pouvez utiliser les techniques ci-dessus pour accroître la confiance dans la précision de l'adresse à partir d'une seule réponse de l'API Geocoding. Toutefois, contrairement à un résultat de l'API Address Validation, l'API Geocoding ne renvoie pas de retour exact pour déterminer la précision des résultats.
Type d'emplacement
Pour bien comprendre cette section, vous devez connaître les différents types d'emplacement pouvant être renvoyés à partir d'une réponse de l'API Geocoding:
- ROOFTOP indique que le résultat renvoyé est un geocoding précis pour lequel nous disposons d'informations de localisation précises, aussi précisément que l'adresse postale.
- 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 (des intersections, par exemple). Les résultats interpolés sont généralement renvoyés lorsque le géocodage rooftop est indisponible pour une adresse postale.
- GEOMETRIC_CENTER indique que le résultat renvoyé est le centre géométrique d'un résultat, comme une polyligne (par exemple, une rue) ou un polygone (une région).
- APPROXIMATE indique que le résultat renvoyé n'est aucun des exemples ci-dessus.
Si une API Geocoding renvoie une location_type de ROOFTOP ou de RANGE_INTERPOLATED, cela ne signifie pas nécessairement que l'adresse existe. De même, si une API Geocoding renvoie une réponse avec l'indicateur partial_match défini sur true, ce résultat peut vous convenir.
Ce type de fausse correspondance est un problème très difficile à résoudre avec l'API Geocoding. Au minimum, vous pouvez envisager d'implémenter une validation de post-traitement de base sur le pays et la localité de la demande / réponse. Mieux encore, comparez les adresses postales réelles pour détecter les fautes d'orthographe et/ou les adresses incomplètes.
Remarque: Si vous décidez d'utiliser l'API Geocoding, nous vous recommandons d'effectuer régulièrement des contrôles de qualité des données entre la requête initiale et la réponse de l'API Geocoding.
Correspondances partielles et fausses
Si une adresse est une correspondance partielle, c'est-à-dire que l'API Geocoding n'a pas pu l'identifier exactement, la réponse contient:
"partial_match": true,
"types": [
"locality",
"political"
]
Il est encore plus important que les types d'emplacement ci-dessus de prendre en compte le cas où partial_match = true figure dans la réponse. partial_match indique que l'API Geocoding n'a pas renvoyé de correspondance exacte pour la requête d'origine, bien qu'elle ait pu trouver une partie de l'adresse demandée.
Il peut être utile d'examiner la demande initiale afin d'identifier une adresse incomplète. Les correspondances partielles sont souvent renvoyées lorsque l'adresse postale n'existe pas dans la localité spécifiée dans la requête. Les correspondances partielles peuvent aussi être renvoyées lorsqu'une requête correspond à plusieurs lieux au sein de la même localité.
Par exemple, "21 Henr St, Bristol, UK" renvoie une correspondance partielle pour Henry Street et Henrietta Street. Notez que si une requête inclut un composant d'adresse mal orthographié, l'API Geocoding peut suggérer une autre adresse. Les suggestions déclenchées de cette façon ne seront pas marquées en tant que correspondance partielle.
Adresses synthétiques
L'API Geocoding peut renvoyer des adresses pour des adresses "synthétiques" qui n'existent pas en tant qu'établissements précis dans la base de données de Google.
Dans ces scénarios, l'objet de réponse contient souvent un ID de lieu long et la propriété suivante: geometry.location_type=APPROXIMATE.
Si ces indicateurs apparaissent dans la réponse, nous vous conseillons de marquer l'adresse d'entrée comme non valide et d'essayer de la valider à nouveau par un autre moyen.
Remarque: Dans cet autre exemple, avec l'API Address Validation, vous recevez des commentaires directs si une adresse n'existe pas.
Comprendre la réponse de l'API Address Validation
Il existe déjà une excellente documentation sur la façon de comprendre les réponses de l'API Address Validation. Nous n'allons donc pas entrer dans les détails ici.
- Pour obtenir un aperçu de l'objet de réponse, cliquez ici.
- Cliquez ici pour accéder à une démonstration des différents composants de la réponse.
- Dans le document Validation des adresses pour le règlement, vous trouverez une description détaillée de la façon de différencier les bonnes adresses des mauvaises.
Bonnes pratiques
Spécification de la zone géographique
Lorsque vous appelez les API Address Validation ou Geocoding, il est recommandé d'essayer de limiter la zone géographique dans laquelle rechercher cette adresse. Les deux API implémentent cela de deux manières différentes:
API Geocoding – Limiter les résultats à une région
Si vous savez que les géocodes se situent dans un pays spécifique, vous pouvez utiliser la pondération de la région pour obtenir de bien meilleurs résultats. Par exemple, si vous définissez un geocoding au Canada, nous vous recommandons d'ajouter
®ion=caà vos requêtes de pondération vers le Canada. Notez que la pondération de la région ne fait que privilégier les résultats au sein de cette région. Vous pouvez toujours obtenir des résultats en dehors de cette région.API Address Validation – Code de région
De la même manière, l'API Address Validation produit des résultats plus précis si un code ISO2 est transmis dans la requête, à l'aide du champ
regionCode.
Stocker les ID de lieu
Pour stocker des informations Google Maps Platform sur l'établissement pour les futures requêtes, vous pouvez stocker l'ID de lieu indéfiniment dans votre base de données en tant qu'attribut de l'établissement. Vous ne devez effectuer une requête Find Place qu'une seule fois par ID de lieu. Vous pouvez également rechercher l'ID de lieu chaque fois qu'un utilisateur demande des détails sur une transaction.
Pour vous assurer de toujours disposer des informations les plus à jour, actualisez les ID de lieu tous les 12 mois à l'aide d'une requête Place Details avec le paramètre place_id.
Remarque: Veillez également à consulter le guide des bonnes pratiques concernant le geocoding.
Conclusion
Ce document décrit les principales différences entre les API Address Validation et Geocoding. En résumé, pensez à utiliser l'API Address Validation dans les cas suivants:
- Vous devez indiquer une adresse postale exacte, en particulier à des fins de livraison.
- Les données d'entrée sont connues pour être de mauvaise qualité. L'API Address Validation permet d'éviter les erreurs de saisie, de mettre en évidence les éléments d'adresse non vérifiables et d'apporter des corrections aux données saisies.
- Nous avons besoin d'informations supplémentaires pour chaque adresse, par exemple "Résidentiel" ou "Commerce" (disponible dans certaines régions).
Étapes suivantes
Téléchargez le livre blanc Améliorer le processus de paiement, de livraison et d'exploitation avec des adresses fiables et consultez le webinaire Améliorer le processus de paiement, de livraison et d'exploitation avec Address Validation .
Autres ressources suggérées:
- Validation de l'adresse pour le règlement des achats en ligne
- Documentation sur Place Autocomplete
- Documentation de l'API Address Validation
- Rapports Google Maps Platform
Contributeurs
Cet article est mis à jour par Google. Ce commentaire a été écrit initialement par les contributeurs suivants.
Auteurs principaux:
Henrik Valve | Ingénieur solutions
Thomas Anglaret | Solutions Engineer
Sarthak Ganguly | Solutions Engineer