Créer une fonctionnalité de validation d'emplacement à l'aide de Google Maps Platform

Objectif

Vous avez souvent besoin de valider l'emplacement d'un lieu. Plusieurs services de 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 permet aux clients de vérifier si une adresse est correcte ou non.

Le géocoding avec l'API 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 un aperçu des différences entre l'API Validation d'adresses et l'API Géolocalisation, cliquez ici.

Essayez dès maintenant:accédez à la console Google Cloud et activez l'API Address Validation et l'API Places.

Choisir l'API Address Validation ou l'API Geocoding

Remarques concernant le diagramme de flux ci-dessus:

• Le cas d'utilisation d'interaction utilisateur fait référence à un utilisateur présent pour interagir avec les résultats.
• Place Autocomplete est une API JavaScript, ce qui la rend adaptée à l'intégration dans les interfaces utilisateur.
• Vous avez peut-être remarqué des problèmes de qualité des données dans vos adresses existantes. Par conséquent, même si vous ne souhaitez obtenir que des géocodes, nous vous conseillons d'exécuter ces emplacements via l'API Address Validation pour corriger les ensembles de données.

De nombreuses situations peuvent vous amener à choisir, en fonction de l'arborescence de décision ci-dessus, d'utiliser un produit plutôt qu'un autre. Toutefois, dans d'autres cas, vous pouvez utiliser les 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 les données soient douteuses ou que l'adresse incorrecte ait un impact négatif en aval. En effet, l'API Address Validation fournit plus d'informations sur les raisons pour lesquelles une entrée n'a pas reçu de résultat haute précision.
• Vous devez corriger les entrées utilisateur (par exemple, les fautes d'orthographe ou les champs manquants), ce qui augmente la probabilité d'obtenir un résultat précis en sortie.
• 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 résidentiel ou commercial.

Vous pouvez choisir d'utiliser le géocodage avec 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 des adresses individuelles n'est pas forcément 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.

Voici quelques exemples qui illustrent les fonctionnalités de l'API Address Validation par rapport à 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 composants d'adresse individuels (rue, ville, état, etc.). Il peut également fournir des commentaires précis sur les raisons pour lesquelles l'adresse n'est pas valide au niveau de PREMISE.

Fake St n'existe pas à Mountain View, en Californie, et l'API de validation des adresses le reflète dans les détails au niveau des composants renvoyés:

{
  "componentName": {
    "text": "Fake St",
    "languageCode": "en"
   },
   "componentType": "route",
   "confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
 }

La propriété importante à inspecter dans ce cas est confirmationLevel. En renvoyant UNCONFIRMED_BUT_PLAUSIBLE pour Fake St, l'API a déterminé qu'il était possible qu'une rue porte ce nom, mais qu'elle ne pouvait pas être mise en correspondance avec les données d'adresse associées.

En utilisant le résultat de l'API comme retour, on peut déduire que le composant "rue" de cette entrée (Fake St) est en cause.

En utilisant la même adresse avec l'API Geocoding, vous pouvez trouver une correspondance avec "Californie", comme le montre la capture d'écran de l'outil de géocodage que vous pouvez tester ici:

Cependant, le résultat est un code géographique de l'ensemble de l'État, avec un retour minimal sur les composants de l'entrée qui étaient potentiellement défectueux.

Exemple d'erreur d'orthographe

76 Buckingham Palace Road, Londres, SW1W 9TQ, Royaume-Uni

L'adresse ci-dessus contient quelques erreurs d'orthographe, l'une dans le nom de la rue et l'autre dans la localité.

L'API de validation des adresses et l'API de géocodage sont toutes deux capables de corriger ces erreurs et de renvoyer le résultat suivant : 76 Buckingham Palace Road, Londres, SW1W 9TQ. Toutefois, l'API Address Validation peut vous fournir plus d'informations sur la procédure.

Examinez l'un des éléments de l'adresse mal orthographié 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. Une logique métier peut être implémentée pour ce flag afin de vérifier la correction auprès du fournisseur de données, par exemple un client lors du règlement d'un achat en ligne.

Exemple de données manquantes et d'erreur d'orthographe

Bollschestraße 86, 12587, Allemagne

Le nom de rue de l'adresse ci-dessus comporte une erreur d'orthographe, et la ville (localité) de Berlin est manquante.

L'API Address Validation peut corriger ces deux erreurs et renvoie un code géographique au niveau PREMISE, ainsi qu'une adresse validée au niveau PREMISE:

Bölschestraße 86, 12587 Berlin, DE

Dans ce cas, l'API Geocoding ne parvient pas à corriger les erreurs d'entrée et renvoie la valeur 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é (123), qui n'existe pas dans le bâtiment.

L'API Address Validation peut valider l'adresse de l'PREMISE (111 8th Ave) et fournir des métadonnées sur la propriété, y compris qu'il s'agit d'un établissement commercial.

locaux:

"business": true

De plus, la valeur dpvConfirmation renvoyée dans le uspsData de 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 ne peut pas fournir ces informations.

Comprendre la réponse de l'API Geocoding

Présentation

Si vous utilisez l'API Geocoding, le résultat de géocodage contient divers indices dans la réponse qui peuvent être utilisés pour comprendre les détails de l'adresse fournie.

L'API Geocoding fonctionne en résolvant les composants d'adresse dans une hiérarchie.

Par exemple, 123 Example Street, Chicago, 60007, USA se résout dans l'ordre suivant:

/ Example Street/ Chicago/ 60007/ USA sera évalué dans cet ordre. Dans ce cas, le premier résultat correspond à Chicago, et plus précisément au code postal 60007. Par conséquent, elle renvoie le code 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 d'établissement auquel cette adresse appartient. Pour obtenir la liste des types d'adresse renvoyés par l'API Geocoding, cliquez ici.

Si aucun des composants de l'entrée n'est résolu, l'API renvoie:

{
   "results": [],
   "status": "ZERO_RESULTS"
}

Si vous effectuez une requête avec une adresse sans numéro de maison, le résultat sera le suivant:

"types": [
  "route"
]

Cela signifie que l'API Geocoding n'a pas pu trouver ni faire correspondre un numéro de rue.

Remarque:Pour savoir si une adresse existe, vérifiez si l'un des paramètres (tels que types, partial_match, results, status)) est défini 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 100% précise. C'est pourquoi nous avons besoin de l'API Address Validation.

Vous pouvez utiliser les techniques ci-dessus pour augmenter la confiance dans l'exactitude des adresses à partir d'une seule réponse de l'API Geocoding. Cependant, contrairement aux résultats de l'API Address Validation, l'API Geocoding ne renvoie pas de commentaires exacts 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'emplacements pouvant être renvoyés à partir d'une réponse d'API de géocodage:

• ROOFTOP indique que le résultat renvoyé est un géocode précis pour lequel nous disposons d'informations de localisation précises jusqu'à l'adresse.
• 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 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 tel qu'une polyligne (par exemple, une rue) ou un polygone (région).
• APPROXIMATE indique que le résultat renvoyé ne correspond à aucune des valeurs ci-dessus.

Si une API de géocodage renvoie une valeur location_type de ROOFTOP ou RANGE_INTERPOLATED, cela ne signifie pas nécessairement que l'adresse existe. De même, si une API de géocodage renvoie un résultat avec l'indicateur partial_match défini sur true, il est possible que ce soit le résultat approprié.

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 base après le traitement sur le pays et la localité de la requête / réponse. Mieux encore, comparez les adresses postales réelles pour vérifier qu'elles ne comportent pas de fautes d'orthographe et/ou qu'elles sont complètes.

Remarque: Si vous décidez d'utiliser l'API Geocoding, nous vous recommandons d'effectuer régulièrement des vérifications de la qualité des données entre la requête initiale et la réponse de l'API Geocoding.

Correspondance partielle et fausse correspondance

Si une adresse correspond partiellement, ce qui signifie que l'API de géocodage n'a pas pu l'identifier exactement, la réponse contient les éléments suivants:

"partial_match": true,
"types": [
           "locality",
           "political"
         ]

Plus important encore que les types de zones géographiques ci-dessus, vous devez tenir compte du moment où partial_match = true est dans la réponse. partial_match indique que l'API Geocoding n'a pas renvoyé de correspondance exacte pour la requête d'origine, mais qu'elle a pu en trouver une partie.

Vous pouvez examiner la requête d'origine pour vérifier si l'adresse est incomplète. Les correspondances partielles se produisent le plus souvent pour les adresses qui n'existent 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 de géocodage peut suggérer une autre adresse. Les suggestions déclenchées de cette manière ne seront pas marquées comme une correspondance partielle.

Adresses synthétiques

L'API Geocoding peut renvoyer des emplacements pour des adresses "synthétiques" qui n'existent pas en tant qu'emplacements précis dans la base de données de Google.

Dans ce cas, l'objet de réponse contient souvent un long ID de lieu et la propriété suivante: geometry.location_type=APPROXIMATE.

Si vous rencontrez ces indicateurs dans la réponse, pensez à marquer l'adresse saisie comme non valide et à essayer de la valider à nouveau par un autre moyen.

Remarque: Voici un autre exemple où l'API Address Validation vous fournit des commentaires directs si une adresse n'existe pas.

Comprendre la réponse de l'API Address Validation

Il existe déjà de nombreuses ressources pour comprendre les réponses de l'API Address Validation. Nous n'allons donc pas entrer dans les détails ici.

• Pour en savoir plus sur l'objet de réponse, cliquez ici.
• Démonstration illustrant les différents composants de la réponse
• Le document Validation des adresses pour le règlement explique en détail comment faire la différence entre les bonnes et les mauvaises adresses.

Bonnes pratiques

Spécifier la zone géographique

Lorsque vous effectuez des appels aux API Address Validation ou Geocoding, nous vous recommandons de limiter la zone géographique dans laquelle rechercher l'adresse. Les deux API implémentent cela de deux manières différentes:

• API Geocoding : biais régionaux

  Si vous savez que les codes géographiques se trouvent dans un certain pays, vous obtiendrez de bien meilleurs résultats en utilisant le biais régional. Par exemple, si vous effectuez une géocodage au Canada, nous vous recommandons d'ajouter &region=ca à vos requêtes pour privilégier le Canada. Notez que le biais régional préfère uniquement les résultats de cette région. Vous pouvez toujours obtenir des résultats en dehors de la région.

• API Address Validation – Code de région

  De même, l'API de validation des adresses 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 provenant de Google Maps Platform sur l'emplacement pour de futures requêtes, vous pouvez stocker l'ID de lieu indéfiniment dans votre base de données en tant qu'attribut de l'emplacement. Vous ne devez envoyer une demande de recherche de lieu qu'une seule fois par placeID. Vous pouvez également rechercher l'ID de lieu chaque fois qu'un utilisateur demande des informations sur la transaction.

Pour vous assurer de toujours disposer des informations les plus récentes, actualisez les ID de lieu tous les 12 mois à l'aide d'une requête Informations sur le lieu avec le paramètre place_id.

Remarque: Veillez également à consulter le guide des bonnes pratiques pour le géocodage.

Conclusion

Ce document décrit les principales différences entre les API de validation d'adresse et de géocodage. En résumé, envisagez d'utiliser l'API Address Validation dans les cas suivants:

• Une adresse postale précise est requise, en particulier pour la distribution.
• Les données d'entrée sont connues pour être de mauvaise qualité. L'API Address Validation est plus tolérante envers les erreurs de saisie, met en évidence les éléments d'adresse non vérifiables et corrige les données saisies.
• Des informations supplémentaires sont requises pour une adresse, par exemple si elle est résidentielle ou commerciale (disponible dans certaines régions).

Étapes suivantes

Téléchargez le livre blanc Améliorer les processus de paiement, de livraison et d'exploitation avec des adresses fiables et regardez le webinaire Améliorer les processus de paiement, de livraison et d'exploitation avec la validation des adresses .

Lectures complémentaires suggérées:

• Validation des adresses pour le règlement dans l'e-commerce
• Documentation Place Autocomplete
• Documentation de l'API Address Validation
• Rapports Google Maps Platform

Contributeurs

Cet article est géré par Google. Les contributeurs suivants l'ont initialement rédigé.

Auteurs principaux:

Henrik Valve | Ingénieur solutions

Thomas Anglaret | Ingénieur solutions

Sarthak Ganguly | Ingénieur solutions