Optimisation de l'utilisation des quotas lors du géocodage

Le geocoding consiste à convertir des adresses ("1600 Amphitheatre Parkway, Mountain View, CA") en coordonnées géographiques (37.423021, -122.083739), que vous pouvez utiliser pour placer des repères ou positionner la carte. Les API Google Maps Platform proposent deux approches pour le geocoding :

  • Le geocoding côté client, qui est exécuté dans le navigateur, généralement en réponse à une action de l'utilisateur. L'API Maps JavaScript fournit des classes qui envoient les requêtes à votre place. Cette approche est décrite dans la documentation de l'API Maps JavaScript.
  • Géocodage côté serveur HTTP, qui permet à votre serveur d'interroger directement les serveurs de Google pour obtenir des géocodes. L'API Geocoding est le service Web qui fournit cette fonctionnalité. En règle générale, vous intégrez ce service à un autre code exécuté côté serveur. Le géocodage côté serveur est décrit dans la documentation de l'API Geocoding.

Exemples de géocodage côté client et côté serveur

Voici un exemple de geocoding côté client qui prend une adresse, la géocode, déplace le centre de la carte vers cet emplacement et y ajoute un repère :

geocoder = new google.maps.Geocoder();
geocoder.geocode({ 'address': address }, function(results, status) {
  if (status == google.maps.GeocoderStatus.OK) {
    map.setCenter(results[0].geometry.location);
    var marker = new google.maps.Marker({
      map: map,
      position: results[0].geometry.location
    });
  }
});

Pour obtenir d'autres exemples, consultez la documentation de l'API Maps JavaScript.

Voici un exemple d'utilisation de Python pour effectuer une requête de géocodage côté serveur dans l'API Geocoding v4 :

import json
import urllib.request

address = "1600+Amphitheatre+Parkway,+Mountain+View,+CA"
key = "my-key-here"
url = f"https://geocode.googleapis.com/v4/geocode/address/{address}"
headers = {"X-Goog-Api-Key": key}

req = urllib.request.Request(url, headers=headers)
with urllib.request.urlopen(req) as response:
    result = json.loads(response.read().decode("utf-8"))

Cela crée un objet JSON avec le contenu suivant :

{
  "results": [
    {
      "place": "places/ChIJiSSC8QK6j4AR98Thup8mqTc",
      "placeId": "ChIJiSSC8QK6j4AR98Thup8mqTc",
      "location": {
        "latitude": 37.4224864,
        "longitude": -122.0855962
      },
      "granularity": "ROOFTOP",
      "viewport": {
        "low": {
          "latitude": 37.4211700197085,
          "longitude": -122.08691558029149
        },
        "high": {
          "latitude": 37.4238679802915,
          "longitude": -122.08421761970851
        }
      },
      "bounds": {
        "low": {
          "latitude": 37.4221145,
          "longitude": -122.0860002
        },
        "high": {
          "latitude": 37.4228775,
          "longitude": -122.085133
        }
      },
      "formattedAddress": "Google Building 41, 1600 Amphitheatre Pkwy, Mountain View, CA 94043, USA",
      "postalAddress": {
        "regionCode": "US",
        "languageCode": "en",
        "postalCode": "94043-1351",
        "administrativeArea": "CA",
        "locality": "Mountain View",
        "addressLines": [
          "1600 Amphitheatre Pkwy"
        ]
      },
      "addressComponents": [
        {
          "longText": "Google Building 41",
          "shortText": "Google Building 41",
          "types": [
            "premise"
          ],
          "languageCode": "en"
        },
        {
          "longText": "1600",
          "shortText": "1600",
          "types": [
            "street_number"
          ]
        },
        {
          "longText": "Amphitheatre Parkway",
          "shortText": "Amphitheatre Pkwy",
          "types": [
            "route"
          ],
          "languageCode": "en"
        },
        {
          "longText": "Mountain View",
          "shortText": "Mountain View",
          "types": [
            "locality",
            "political"
          ],
          "languageCode": "en"
        },
        {
          "longText": "Santa Clara County",
          "shortText": "Santa Clara County",
          "types": [
            "administrative_area_level_2",
            "political"
          ],
          "languageCode": "en"
        },
        {
          "longText": "California",
          "shortText": "CA",
          "types": [
            "administrative_area_level_1",
            "political"
          ],
          "languageCode": "en"
        },
        {
          "longText": "United States",
          "shortText": "US",
          "types": [
            "country",
            "political"
          ],
          "languageCode": "en"
        },
        {
          "longText": "94043",
          "shortText": "94043",
          "types": [
            "postal_code"
          ]
        },
        {
          "longText": "1351",
          "shortText": "1351",
          "types": [
            "postal_code_suffix"
          ]
        }
      ],
      "types": [
        "premise",
        "street_address"
      ]
    }
  ]
}

Pour d'autres exemples, consultez la présentation de l'API Geocoding v4 et le guide Géocoder une adresse.

Considérations sur les quotas et les coûts

Les coûts, les quotas et les limites de débit du géocodage déterminent les stratégies décrites dans ce document.

Coût

Les limites de quota par jour (QPD) ne sont pas utilisées pour les requêtes de géocodage. À la place, chaque requête de géocodage, qu'elle soit côté client via le navigateur ou côté serveur via le service Web de l'API Geocoding, est facturée au prix par requête. Pour gérer vos coûts d'utilisation, envisagez de gérer vos limites d'utilisation et vos quotas.

Limites de débit

Le service de géocodage est limité à 3 000 RPM (requêtes par minute), calculées en additionnant les requêtes côté client et côté serveur.

Lorsque vous exécutez des requêtes de géocodage côté client à intervalles réguliers, par exemple dans une application mobile, vos requêtes peuvent renvoyer des erreurs si tous vos utilisateurs effectuent des requêtes en même temps (par exemple, tous à la même seconde de chaque minute). Pour éviter cela, vous avez le choix entre les solutions suivantes :

  • Introduisez des intervalles aléatoires dans vos requêtes (gigue). Assurez-vous que les demandes sont aléatoires sur l'ensemble de votre base d'utilisateurs.
  • Si vous développez pour Android, utilisez une alarme récurrente inexacte.
  • Si vous développez pour Android, sélectionnez une stratégie de localisation appropriée.

Mise en cache

Consultez les Règles de l'API Geocoding concernant la mise en cache.

Architecture côté serveur ou côté client dans la v4

L'API Geocoding v4 (y compris SearchDestinations, GeocodeAddress, GeocodeLocation et GeocodePlace) est conçue comme une API de serveur à serveur. L'appel de points de terminaison v4 depuis votre serveur backend offre des avantages essentiels :

  • Informations d'arrivée hyper-localisées : la méthode SearchDestinations (POST /v4/geocode/destinations) est disponible exclusivement via des requêtes REST ou gRPC côté serveur. Elle renvoie les entrées de bâtiments, les points de navigation routables, les contours de bâtiments et les points de repère à proximité qui ne sont pas disponibles dans les géocodeurs de navigateur côté client.
  • Sécurité renforcée des API : les appels côté serveur protègent vos clés API et vos jetons OAuth contre l'exposition dans les navigateurs clients. Consultez Sécurité des API.
  • Masques de champ de réponse : les points de terminaison v4 côté serveur sont compatibles avec les masques de champ, ce qui vous permet de ne demander que les champs dont votre application a besoin pour réduire la taille de la charge utile et la latence.

Quand utiliser la recherche de navigateur côté client ?

Pour les applications de navigateur interactives qui répondent aux frappes en temps réel, envisagez de combiner Place Autocomplete côté client (pour lever l'ambiguïté de la saisie utilisateur et obtenir un ID de lieu) avec un appel backend à SearchDestinations ou GeocodePlace pour récupérer des détails ou des coordonnées hyperlocaux de manière sécurisée.