Optimisation de l'utilisation des quotas lors du géocodage
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Le geocoding est le processus de conversion des adresses ("1600
Amphitheatre Parkway, Mountain View, CA") par des coordonnées géographiques
(37.423021, -122.083739), que vous pouvez utiliser pour placer
les repères ou positionner la carte. Les API Google Maps Platform offrent
approches du geocoding:
Geocoding côté client
qui s'exécute dans le navigateur, généralement
en réponse à une action de l'utilisateur. L'API Maps JavaScript fournit
classes qui effectuent les requêtes à votre place. Cette approche est décrite dans la
API Maps JavaScript
documentation.
Geocoding côté serveur HTTP
qui permet à votre serveur d'interroger directement
les serveurs de Google pour les géocodes. L'API Geocoding correspond au Web
qui fournit cette fonctionnalité. Généralement, vous intégrez ce
avec un autre code qui s'exécute côté serveur. Geocoding côté serveur
est décrit dans le
API Geocoding
documentation.
Exemples de géocodage côté client et côté serveur
Voici un exemple de geocoding côté client, qui accepte une
adresse, la géocode, déplace le centre de la carte vers ce lieu, puis ajoute une
sur la carte:
Le geocoder côté serveur propose également un format XML comme alternative au
JSON. Pour voir d'autres exemples, consultez les
API Geocoding
documentation et
bibliothèques clientes pour Python
et d'autres langues.
Remarques concernant 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.
Le débit du service de géocodage est limité à 3 000 RPM (requêtes par minute),
calculé en additionnant les requêtes côté client et côté serveur.
Lors de l'exécution de requêtes de geocoding côté client à intervalles réguliers, par exemple
dans une application mobile, vos requêtes peuvent renvoyer des erreurs si tous vos utilisateurs
effectuant des demandes au même moment (par exemple, à la même seconde
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 requêtes
sont aléatoires sur toute votre base d'utilisateurs.
La réponse courte est « presque toujours ». Pour les raisons suivantes :
Les requêtes et réponses côté client permettent d'obtenir
une expérience interactive
pour les utilisateurs.
Une requête côté client peut inclure des informations qui améliorent le geocoding
qualité: langue de l'utilisateur, région et fenêtre d'affichage.
En particulier, le géocodage côté client est préférable lors du geocoding d'adresses.
en fonction des données saisies par l'utilisateur.
Le géocodage côté client présente deux architectures de base :
Réalisation de tout le géocodage et l'affichage dans le navigateur. Par exemple,
l'utilisateur saisit une adresse
sur votre page. Votre application la géocode. Ensuite,
votre page utilise le géocode pour créer un repère sur la carte. Ou votre application le fait
une analyse simple à l'aide du géocode. Aucune donnée n'est envoyée à votre serveur.
Cela réduit la charge du serveur.
Réalisation du géocodage dans le navigateur, puis envoi du résultat au serveur.
Par exemple, l'utilisateur saisit une adresse sur votre page. Votre application
le géocode dans le navigateur. L'application envoie ensuite les données à votre serveur. La
répond avec des données, telles que des points d'intérêt à proximité. Ce
vous permet de personnaliser une réponse en fonction de vos propres données.
Dans quels cas utiliser le géocodage côté serveur
Le geocoding côté serveur est mieux adapté aux applications
vous obligent à géocoder des adresses sans intervention du client. Exemple courant
lorsque l'on obtient un ensemble de données
qui est fourni indépendamment de l'entrée utilisateur,
Par exemple, si vous disposez d'un ensemble fixe, fini et connu de
les adresses e-mail devant être géocodées. Le geocoding côté serveur peut
Elle peut également servir de solution de secours en cas d'échec du geocoding côté client.
Certains problèmes possibles sont
une augmentation inutile de la latence pour l'utilisateur,
et des résultats de géocodage de moins bonne qualité que ceux côté client, car moins
sont disponibles dans la demande.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/05 (UTC)."],[[["\u003cp\u003eGeocoding transforms addresses into geographic coordinates for map placement, offered through client-side (browser-based) and server-side (HTTP) approaches by the Google Maps Platform.\u003c/p\u003e\n"],["\u003cp\u003eClient-side geocoding, ideal for user-input addresses, provides a faster experience and leverages user context for improved accuracy.\u003c/p\u003e\n"],["\u003cp\u003eServer-side geocoding is suitable for geocoding pre-defined address datasets or as a fallback when client-side geocoding fails.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Maps Platform's geocoding service is rate limited to 3,000 queries per minute, and each request is billed individually.\u003c/p\u003e\n"],["\u003cp\u003eConsider caching, request staggering, or inexact repeating alarms to manage costs and avoid rate limits, especially in high-frequency scenarios.\u003c/p\u003e\n"]]],["Geocoding converts addresses to geographic coordinates. Google Maps offers client-side (browser-based) and server-side (direct server queries) approaches. Client-side geocoding, preferred for user input, utilizes the Maps JavaScript API, as seen in the provided JavaScript example. Server-side geocoding, via the Geocoding API, is ideal for pre-existing datasets or as a client-side backup, and shown in the Python example that return a JSON format. Geocoding is rate-limited to 3,000 queries per minute and incurs a per-request cost.\n"],null,["Geocoding is the process of converting addresses (\"1600\nAmphitheatre Parkway, Mountain View, CA\") to geographic coordinates\n(37.423021, -122.083739), which you can use to place\nmarkers or position the map. The Google Maps Platform APIs provide two\napproaches to geocoding:\n\n- **Client-side geocoding** , which is executed in the browser, generally in response to user action. The Maps JavaScript API provides classes that make the requests for you. This approach is described in the [Maps JavaScript API\n documentation](/maps/documentation/javascript/geocoding).\n- **HTTP server-side geocoding** , which allows your server to directly query Google's servers for geocodes. The Geocoding API is the web service that provides this functionality. Typically, you integrate this service with other code that is running server-side. Server-side geocoding is described in the [Geocoding API\n documentation](/maps/documentation/geocoding).\n\nExamples of client-side and server-side geocoding\n\nHere is a sample of **client-side geocoding** which takes an\naddress, geocodes it, moves the center of the map to that location, and adds a\nmap marker there: \n\n```javascript\ngeocoder = new google.maps.Geocoder();\ngeocoder.geocode({ 'address': address }, function(results, status) {\n if (status == google.maps.GeocoderStatus.OK) {\n map.setCenter(results[0].geometry.location);\n var marker = new google.maps.Marker({\n map: map,\n position: results[0].geometry.location\n });\n }\n});\n```\n\nFor more examples, see the\n[Maps JavaScript API\ndocumentation](/maps/documentation/javascript/geocoding).\n\nHere is an example using Python to do a **server-side\ngeocoding** request: \n\n```python\nimport urllib2\n\naddress=\"1600+Amphitheatre+Parkway,+Mountain+View,+CA\"\nkey=\"my-key-here\"\nurl=\"https://maps.googleapis.com/maps/api/geocode/json?address=%s&key=%s\" % (address, key)\n\nresponse = urllib2.urlopen(url)\n\njsongeocode = response.read()\n```\n\nThis produces a JSON object with the following content: \n\n```javascript\n{\n \"status\": \"OK\",\n \"results\": [ {\n \"types\": street_address,\n \"formatted_address\": \"1600 Amphitheatre Pkwy, Mountain View, CA 94043, USA\",\n \"address_components\": [ {\n \"long_name\": \"1600\",\n \"short_name\": \"1600\",\n \"types\": street_number\n }, {\n \"long_name\": \"Amphitheatre Pkwy\",\n \"short_name\": \"Amphitheatre Pkwy\",\n \"types\": route\n }, {\n \"long_name\": \"Mountain View\",\n \"short_name\": \"Mountain View\",\n \"types\": [ \"locality\", \"political\" ]\n }, {\n \"long_name\": \"San Jose\",\n \"short_name\": \"San Jose\",\n \"types\": [ \"administrative_area_level_3\", \"political\" ]\n }, {\n \"long_name\": \"Santa Clara\",\n \"short_name\": \"Santa Clara\",\n \"types\": [ \"administrative_area_level_2\", \"political\" ]\n }, {\n \"long_name\": \"California\",\n \"short_name\": \"CA\",\n \"types\": [ \"administrative_area_level_1\", \"political\" ]\n }, {\n \"long_name\": \"United States\",\n \"short_name\": \"US\",\n \"types\": [ \"country\", \"political\" ]\n }, {\n \"long_name\": \"94043\",\n \"short_name\": \"94043\",\n \"types\": postal_code\n } ],\n \"geometry\": {\n \"location\": {\n \"lat\": 37.4220323,\n \"lng\": -122.0845109\n },\n \"location_type\": \"ROOFTOP\",\n \"viewport\": {\n \"southwest\": {\n \"lat\": 37.4188847,\n \"lng\": -122.0876585\n },\n \"northeast\": {\n \"lat\": 37.4251799,\n \"lng\": -122.0813633\n }\n }\n }\n } ]\n}\n```\n\nThe server-side geocoder also provides an XML format as an alternative to\nJSON. For more examples, see the\n[Geocoding API\ndocumentation](/maps/documentation/geocoding) and the\n[client libraries](/maps/documentation/geocoding/client-library) for Python\nand other languages.\n\nQuota and cost considerations\n\nGeocoding costs, quotas, and rate limits drive the strategies outlined in this\ndocument.\n\nCost\n\n\n[Quota-per-day (QPD) limits are no longer in use](/maps/documentation/geocoding/usage-and-billing#requests-per-day-qpd-limits-have-ended-effective-june-11-2018) for geocoding requests.\nInstead, each geocoding request, whether client-side through the browser or server-side through the\nGeocoding API web service, is\n[billed at a per-each price](/maps/documentation/geocoding/usage-and-billing#new-payg).\nTo manage your cost of use, consider\n[capping your daily quota](/maps/documentation/geocoding/usage-and-billing#set-caps).\n| **Important:** To use the Google Maps Platform APIs, you must [enable billing](/maps/documentation/geocoding/usage-and-billing#important-enable-billing) on each of your projects. If you choose not to add a billing account, your maps will be degraded, or other Maps API requests will return an error.\n\nRate limits\n\nThe geocoding service is rate limited to 3,000 QPM (queries per minute),\ncalculated as the sum of client-side and server-side queries.\n\nWhen running client-side geocoding requests at periodic intervals, such as\nin a mobile app, your requests may return errors if all of your users are\nmaking requests at the same time (for example, all at the same second of every\nminute). To avoid this, consider one of the following:\n\n- Introduce random intervals to your requests (jitter). Ensure requests are random across your entire userbase.\n- If developing for Android, use an [inexact\n repeating alarm](https://developer.android.com/develop/background-work/services/alarms/schedule#repeating).\n- If developing for Android, select an appropriate [location\n strategy](https://developer.android.com/training/location/retrieve-current).\n\nCaching\n\nSee\n[Geocoding API Policies](/maps/documentation/geocoding/policies#pre-fetching-caching-or-storage-of-content) about caching.\n\nWhen to use client-side geocoding\n\nThe short answer is \"almost always.\" The reasons are:\n\n- Client-side request and response provide a faster, more interactive experience for users.\n- A client-side request can include information that improves geocoding quality: user language, region, and viewport.\n\nIn particular, client-side geocoding is best when geocoding addresses\nbased on input from the user.\n\nThere are two basic architectures for client-side geocoding:\n\n- Do the geocoding and the display entirely in the browser. For instance, the user enters an address on your page. Your application geocodes it. Then your page uses the geocode to create a marker on the map. Or your app does some simple analysis using the geocode. No data is sent to your server. This reduces load on your server.\n- Do the geocoding in the browser and then send it to the server. For instance, the user enters an address on your page. Your application geocodes it in the browser. The app then sends the data to your server. The server responds with some data, such as nearby points of interest. This allows you to customize a response based on your own data.\n\nWhen to use server-side geocoding\n\nServer-side geocoding is best used for applications that\nrequire you to geocode addresses without input from a client. A common example\nis when you get a dataset that comes independently of user input,\nfor instance if you have a fixed, finite, and known set of\naddresses that need geocoding. Server-side geocoding can\nalso be useful as a backup for when client-side geocoding fails.\n\nSome possible concerns are an unnecessary increase in latency for the user,\nand geocoding results of a lesser quality than client-side because less\ninformation is available in the request."]]