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

Objectif

Il est souvent nécessaire de valider l'emplacement d'un lieu. Différents 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 d'emplacement : l'API Address Validation et l'API Geocoding.

L'API Address Validation est une offre Google Maps Platform qui aide les clients à vérifier si une adresse est exacte ou non.

Le processus de geocoding de 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 consulter un aperçu général des différences entre Address Validation et l'API Geocoding, cliquez ici.

<ph type="x-smartling-placeholder">

Quand choisir Address Validation ou API Geocoding ?

Address-Validation-vs-Geocoding

Remarques concernant l'organigramme ci-dessus:

  • Le cas d'utilisation "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 qui peut être intégrée aux interfaces utilisateur.
  • Vous avez peut-être connaissance de problèmes de qualité des données dans vos adresses existantes. Même si vous n'avez besoin que de géocodes, nous vous recommandons d'exécuter ces établissements via l'API Address Validation pour corriger les ensembles de données.

En fonction de l'arbre de décision ci-dessus, il existe de nombreuses situations dans lesquelles vous pouvez choisir d'utiliser un produit plutôt qu'un 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 existe une forte probabilité que les données soient douteuses ou lorsque l'obtention d'une adresse incorrecte aura un impact négatif en aval. En effet, l'API Address Validation fournit davantage de commentaires sur la raison pour laquelle une entrée n'a pas reçu de résultat très précis.
  • Vous devez corriger les entrées utilisateur (par exemple, faute d'orthographe ou champs manquants), ce qui augmente la probabilité d'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 pour classer les types de bâtiments en deux catégories : résidentiel ou commercial.

Vous pouvez choisir d'utiliser l'API Geocoding sur Address Validation dans les cas suivants:

  • Votre objectif principal est de déterminer la position d'une adresse, et la précision des adresses individuelles n'est peut-être pas 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, c'est pourquoi l'API Address Validation n'est pas disponible dans toutes les régions cibles.

Voici quelques exemples illustrant 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 différentes composantes de l'adresse (rue, ville, État, etc.). Elle peut également expliquer précisément pourquoi l'adresse n'est pas valide jusqu'à un niveau PREMISE.

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

{
  "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 sur Fake St, l'API a déterminé qu'il est possible qu'une rue puisse avoir ce nom, mais il ne peut pas être mis en correspondance avec les données d'adresse appropriées.

En utilisant le résultat de l'API comme résultat, on peut en déduire que la composante 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 "Californie" comme vous pouvez le voir sur la capture d'écran de l'outil de geocoding que vous pouvez essayer ici:

alt_text

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

Exemple de fautes d'orthographe

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

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

Les API Address Validation et Geocoding sont toutes deux en mesure de corriger ces erreurs et d'obtenir le résultat du 76 Buckingham Palace Road, London, SW1W 9TQ, Royaume-Uni. 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. Une logique métier peut être implémentée en fonction de cet indicateur afin de vérifier la correction auprès du fournisseur de données, par exemple un client lors d'un paiement en ligne.

Données manquantes et exemples d'erreurs d'orthographe

Bollschestraße 86, 12587, Allemagne

Le nom de rue de l'adresse ci-dessus est erroné, et la ville (localité) de Berlin est manquante.

L'API Address Validation peut corriger ces deux erreurs et renvoie un géocode de 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 à résoudre 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'appartement (Ste 123), qui n'existe pas à l'intérieur du bâtiment.

L'API Address Validation est capable de valider l'adresse auprès du PREMISE (111 8th Ave) et de fournir des métadonnées sur l'établissement, y compris s'il s'agit d'une adresse commerciale.

sur site:

"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 définie sur 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 divers indices dans la réponse qui peuvent vous aider à comprendre les détails de l'adresse fournie.

L'API Geocoding fonctionne de manière à 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 sera évaluée 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 l'élément 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:

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

Envoyer une requête avec uniquement 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 exacte à 100 %. C'est pourquoi nous avons besoin de l'API Address Validation.

Vous pouvez utiliser les techniques ci-dessus pour améliorer la précision des adresses à 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 commentaires exacts pour déterminer l'exactitude des résultats.

Type d'emplacement

Pour bien comprendre cette section, vous devez connaître les différents types de lieux pouvant être renvoyés dans 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 aussi précises 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é ne correspond à aucun des résultats ci-dessus.

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

Ce type de correspondance "false" est un problème très difficile à résoudre avec l'API Geocoding. Vous pouvez tout au moins envisager de mettre en œuvre une validation 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 corriger 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 ne peut pas identifier exactement l'adresse, la réponse contient alors:

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

Il est encore plus important que les types de lieux ci-dessus de prendre en compte le moment où partial_match = true se trouve 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 a pu trouver une partie de l'adresse demandée.

Nous vous conseillons d'examiner la demande initiale pour déterminer si l'adresse est incomplète. Les correspondances partielles sont généralement 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é.

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 signalées comme des correspondances partielles.

Adresses synthétiques

L'API Geocoding peut renvoyer des emplacements pour les termes "synthétiques" d'adresses qui n'existent pas comme des lieux précis dans la base de données de Google.

Dans de tels scénarios, 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: 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'aborderons donc pas ici plus de détails.

Bonnes pratiques

Spécifier une 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 mettent en œuvre cette méthode de deux manières différentes:

  • API Geocoding – Pondération de la région

    Si vous savez que les géocodes seront situés dans un pays donné, vous obtiendrez de bien meilleurs résultats en utilisant la pondération géographique. Par exemple, si vous effectuez un géocodage au Canada, nous vous recommandons d'ajouter &region=ca à vos requêtes pour pondérer le Canada. Veuillez noter que la pondération de la région ne préfère des résultats que dans cette région. Vous pouvez toujours obtenir des résultats en dehors de la région.

  • API Address Validation - Region Code

    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 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'é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 les détails d'une 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 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 les API Address Validation et Geocoding. En résumé, envisagez d'utiliser l'API Address Validation dans les cas suivants:

  • Une adresse postale exacte est requise, en particulier pour la distribution des messages.
  • On sait que les données d'entrée sont de mauvaise qualité. L'API Address Validation est plus indulgente sur les 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 "Résidentiel" ou "Commercial" (disponible dans certaines régions).

Étapes suivantes

Téléchargez le livre blanc Améliorer le processus de paiement, la livraison et les opérations grâce à des adresses fiables , et regardez le webinaire Améliorer les processus de paiement, de livraison et des opérations avec Address Validation .

Documentation complémentaire suggérée:

Contributeurs

Google tient à jour cet article. Ce message a été initialement rédigé par les contributeurs suivants.

Principaux auteurs:

Henrik Valve | Ingénieur solutions

Thomas Anglaret | Ingénieur solutions

Sarthak Ganguly | Ingénieur solutions