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 l'emplacement : 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.

Geocoding avec l'API Geocoding est le processus de conversion 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.

Vous trouverez ici un aperçu des différences entre l'API Address Validation et l'API Geocoding.

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

Quand choisir l'API Address Validation plutôt que l'API Geocoding ?

Remarques concernant l'organigramme ci-dessus :

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

Dans de nombreuses situations, vous pouvez choisir d'utiliser un produit plutôt qu'un autre en fonction de l'arbre de décision ci-dessus. Toutefois, dans d'autres cas, vous devrez peut-être 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 existe un risque élevé de données douteuses ou l'obtention d'une adresse incorrecte aura un impact négatif en aval. En effet, l'API Address Validation fournit plus de commentaires sur la raison pour laquelle une entrée n'a pas reçu de résultat de 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 à partir de l'API Address Validation qu'à partir de l'API Geocoding, comme la classification du type de bâtiment (résidentiel ou commercial).

Vous pouvez choisir d'utiliser le geocoding plutôt que l'API Address Validation dans les cas suivants :

• Votre objectif principal est de récupérer l'emplacement d'une adresse, et la précision des adresses individuelles n'est peut-être pas essentielle.
  • Par exemple, vous pouvez générer une carte de chaleur à partir d'un grand ensemble de données.
• Vous avez besoin de détails de destination hyperlocaux, tels que les entrées de bâtiment, les contours de bâtiment ou les points de navigation pour les lieux de prise en charge et de dépose (disponibles avec la méthode SearchDestinations dans l'API Geocoding v4).
• 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, USA

L'API Address Validation divise cette entrée en ses composants d'adresse individuels (rue, ville, état, etc.). Elle peut également fournir des commentaires précis sur la raison pour laquelle l'adresse n'est pas valide jusqu'au niveau PREMISE.

Fake St n'existe pas à Mountain View, en Californie, et l'API Address Validation le reflète dans les détails du niveau de composant renvoyé :

{
  "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 par rapport à Fake St, l'API a déterminé qu'il serait possible qu'une rue porte ce nom, mais qu'elle ne peut pas être associée aux données d'adresse correspondantes.

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

En utilisant la même adresse avec l'API Geocoding, elle peut établir une correspondance avec "California", comme vous pouvez le voir dans la capture d'écran de l'outil de geocoding que vous pouvez essayer ici :

Toutefois, le résultat est un géocode de l'ensemble de l'état, avec un minimum de commentaires sur les composants de l'entrée qui étaient potentiellement défectueux.

Exemple de faute d'orthographe

76 Buckingamm Palace Road, Londn, SW1W 9TQ, GB

L'adresse ci-dessus contient deux 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 en mesure de corriger ces erreurs et d'obtenir le résultat 76 Buckingham Palace Road, London, SW1W 9TQ. Toutefois, l'API Address Validation peut fournir plus d'informations sur le processus.

Examinez l'un des composants d'adresse qui a été 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 par rapport à cet indicateur pour vérifier la correction auprès du fournisseur de données, tel qu'un client lors d'un paiement d'e-commerce.

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

Bollschestraße 86, 12587, DE

L'adresse ci-dessus contient une faute d'orthographe dans le nom de la rue et la ville (localité) de Berlin est manquante.

L'API Address Validation est en mesure de corriger ces deux erreurs et renvoie un PREMISE niveau géocode, ainsi qu'une adresse validée au PREMISE niveau :

Bölschestraße 86, 12587 Berlin, DE

L'API Geocoding n'est pas en mesure de surmonter les erreurs de saisie dans ce cas et renvoie un résultat ZERO_RESULTS.

Exemple de métadonnées d'adresse supplémentaires

111 8th Avenue Ste 123, New York, NY 10011-5201, US

Cette adresse est correcte, à l'exception du numéro d'unité (Ste 123), qui n'existe pas dans le bâtiment.

L'API Address Validation est en mesure de valider l'adresse au niveau PREMISE (111 8th Ave) et de fournir des métadonnées sur la propriété, y compris le fait qu'il s'agit d'un

local commercial :

"business": true

De plus, la valeur dpvConfirmation renvoyée dans le cadre de 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 l'entrée 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 géocode contient différents 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 est résolu dans l'ordre suivant :

/ Example Street/ Chicago/ 60007/ USA sera évalué dans cet ordre. Dans ce cas, la première correspondance est Chicago et, plus précisément, le code postal 60007. Par conséquent, il renvoie le 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 à quel type de lieu appartient cette adresse. Vous trouverez ici la liste des adresses types renvoyées par l'API Geocoding.

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

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

Une requête avec uniquement l'adresse de la rue sans numéro de maison renvoie un résultat au format suivant :

"types": [
  "route"
]

Ce qui 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 qu'une adresse peut exister, 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 augmenter la confiance dans la précision de l'adresse à partir d'une réponse de l'API Geocoding seule. Toutefois, contrairement à un résultat de l'API Address Validation, l'API Geocoding ne renvoie pas de commentaires exacts pour déterminer la précision du résultat.

Type d'emplacement

Pour bien comprendre cette section, vous devez comprendre les différents types d'emplacements qui peuvent être renvoyés par une réponse de l'API Geocoding :

• 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 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 la réponse renvoyée 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 éléments ci-dessus.

Si une API Geocoding renvoie un location_type de ROOFTOP ou RANGE_INTERPOLATED, cela ne signifie pas nécessairement que l'adresse existe. De même, si une API Geocoding renvoie l'indicateur partial_match défini sur true, il peut toujours s'agir du bon résultat pour vous.

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 requête / 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.

Correspondance partielle et fausse correspondance

Si une adresse est une correspondance partielle, ce qui signifie que l'API Geocoding n'a pas pu identifier exactement l'adresse, la réponse contient :

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

Plus important encore que les types d'emplacements ci-dessus, il est important de 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, bien qu'elle ait pu trouver une partie de l'adresse demandée.

Vous pouvez examiner la requête d'origine pour vérifier qu'elle ne contient pas d'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 comprend un composant d'adresse mal saisi, l'API Geocoding 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, veuillez marquer l'adresse de saisie comme non valide et essayer de la revalider par un autre moyen.

Remarque : Voici un autre exemple où, avec l'API Address Validation, vous obtenez un commentaire direct si une adresse n'existe pas.

Comprendre la réponse de l'API Address Validation

Il existe déjà une excellente documentation sur la compréhension des réponses de l'API Address Validation. Nous n'entrerons donc pas dans les détails ici.

• Vous trouverez ici une présentation de l'objet de réponse.
• Vous trouverez ici une démonstration illustrant les différents composants de la réponse.
• Dans le document Validation d'adresse pour le paiement, il y a une description détaillée de la façon de différencier les adresses valides des adresses non valides.

Bonnes pratiques

Spécifier la zone géographique

Lorsque vous effectuez des appels vers l'API Address Validation ou l'API 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 : pondération régionale

  Si vous savez que les géocodes se trouveront dans un pays donné, vous obtiendrez de bien meilleurs résultats en utilisant la pondération régionale. Par exemple, si vous effectuez un geocoding au Canada, nous vous recommandons d'ajouter &region=ca à vos requêtes pour favoriser le Canada. Veuillez noter que la pondération régionale ne fait que privilégier les résultats dans 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 Address Validation produit des résultats plus précis si un 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'emplacement pour les requêtes futures, vous pouvez stocker l'ID de lieu indéfiniment dans votre base de données en tant qu'attribut de l'emplacement. Vous ne devriez avoir besoin d'effectuer une requête Find Place qu'une seule fois par placeID. Vous pouvez également rechercher l'ID de lieu chaque fois qu'un utilisateur demande des détails sur une transaction.

Pour toujours fournir des informations à 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 : Veuillez également consulter le guide des bonnes pratiques pour le geocoding.

Conclusion

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

• Une adresse postale exacte est requise, en particulier à des fins de distribution.
• Les données d'entrée sont connues pour être de mauvaise qualité. L'API Address Validation est plus tolérante aux erreurs de saisie, met en évidence les composants d'adresse non vérifiables et corrige les données d'entrée.
• 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 le paiement, la livraison et les opérations avec des adresses fiables et regardez le webinaire Améliorer le paiement, la livraison et les opérations avec la validation d'adresse .

Suggestions de lecture supplémentaires :

• Validation d'adresse pour le paiement d'e-commerce
• Documentation sur Place Autocomplete
• Documentation sur l'API Address Validation
• Rapports Google Maps Platform

Contributeurs

Google gère cet article. Les contributeurs suivants l'ont écrit à l'origine.

Auteurs principaux :

Henrik Valve | Ingénieur de solutions

Thomas Anglaret | Ingénieur de solutions

Sarthak Ganguly | Ingénieur de solutions