Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Mã hoá địa lý là quá trình chuyển đổi địa chỉ ("1600
Amphitheatre Parkway, Mountain View, CA") đến toạ độ địa lý
(37.423021, -122.083739), mà bạn có thể sử dụng để đặt
điểm đánh dấu hoặc định vị bản đồ. API Nền tảng Google Maps cung cấp hai
phương pháp mã hoá địa lý:
Mã hóa địa lý phía máy khách,
lệnh này được thực thi trong trình duyệt, thường là trong
phản hồi hành động của người dùng. API JavaScript của Maps cung cấp
các lớp đưa ra yêu cầu cho bạn. Phương pháp này được mô tả trong
API JavaScript của Maps
.
Mã hóa địa lý phía máy chủ HTTP,
cho phép máy chủ của bạn truy vấn trực tiếp
Các máy chủ của Google để mã hoá địa lý. API mã hoá địa lý là môi trường web
cung cấp chức năng này. Thông thường, bạn tích hợp tính năng này
dịch vụ với mã khác đang chạy phía máy chủ. Mã hoá địa lý phía máy chủ
được mô tả trong
API mã hoá địa lý
.
Ví dụ về mã hoá địa lý phía máy khách và phía máy chủ
Dưới đây là mẫu mã hóa địa lý phía máy khách sẽ lấy
của địa chỉ đó, mã hoá địa lý địa lý đó, di chuyển trung tâm của bản đồ đến vị trí đó và thêm
điểm đánh dấu bản đồ ở đó:
Bộ mã hoá địa lý phía máy chủ cũng cung cấp định dạng XML thay thế cho
JSON. Để biết thêm ví dụ, hãy xem
API mã hoá địa lý
và
thư viện ứng dụng cho Python
và các ngôn ngữ khác.
Những điều cần cân nhắc về hạn mức và chi phí
Chi phí, hạn mức và giới hạn số lần yêu cầu mã hóa địa lý thúc đẩy các chiến lược được nêu trong
tài liệu.
Dịch vụ mã hóa địa lý có tỷ lệ giới hạn ở 3.000 QPM (truy vấn mỗi phút),
được tính bằng tổng số truy vấn phía máy khách và phía máy chủ.
Khi chạy yêu cầu mã hoá địa lý phía máy khách theo các khoảng thời gian định kỳ, chẳng hạn như
trong một ứng dụng di động, yêu cầu của bạn có thể trả về lỗi nếu tất cả người dùng của bạn
thực hiện các yêu cầu cùng một lúc (ví dụ: tất cả cùng một giây trong mỗi
phút). Để tránh điều này, hãy cân nhắc một trong các cách sau:
Đưa khoảng thời gian ngẫu nhiên vào yêu cầu của bạn (dao động). Đảm bảo yêu cầu
là ngẫu nhiên trên toàn bộ cơ sở người dùng của bạn.
Câu trả lời ngắn gọn là "hầu như luôn luôn". Lý do là:
Phản hồi và yêu cầu phía máy khách cung cấp trải nghiệm nhanh hơn, hiệu quả hơn
mang tính tương tác cao hơn cho người dùng.
Yêu cầu phía máy khách có thể bao gồm thông tin cải thiện mã hoá địa lý
chất lượng: ngôn ngữ người dùng, khu vực và khung nhìn.
Cụ thể, mã hoá địa lý phía máy khách tốt nhất khi mã hoá địa lý địa chỉ
dựa trên thông tin đầu vào từ người dùng.
Có hai cấu trúc cơ bản để mã hoá địa lý phía máy khách:
Thực hiện mã hóa địa lý và hiển thị hoàn toàn trong trình duyệt. Ví dụ:
người dùng nhập địa chỉ trên trang của bạn. Ứng dụng của bạn mã hoá địa lý ứng dụng đó. Sau đó
trang của bạn sử dụng mã địa lý để tạo điểm đánh dấu trên bản đồ. Hoặc ứng dụng của bạn
một số phân tích đơn giản bằng cách sử dụng mã địa lý. Không có dữ liệu nào được gửi đến máy chủ của bạn.
Điều này làm giảm tải trên máy chủ của bạn.
Thực hiện mã hoá địa lý trong trình duyệt rồi gửi đến máy chủ.
Ví dụ: người dùng nhập địa chỉ trên trang của bạn. Đơn đăng ký của bạn
mã hoá địa lý bản sao đó trong trình duyệt. Sau đó, ứng dụng này sẽ gửi dữ liệu này đến máy chủ của bạn. Chiến lược phát hành đĩa đơn
máy chủ phản hồi bằng một số dữ liệu, chẳng hạn như các địa điểm yêu thích lân cận. Chiến dịch này
cho phép bạn tuỳ chỉnh câu trả lời dựa trên dữ liệu của riêng mình.
Khi nào sử dụng mã hoá địa lý phía máy chủ
Mã hoá địa lý phía máy chủ được sử dụng tốt nhất cho các ứng dụng
yêu cầu bạn mã hoá địa lý các địa chỉ mà không cần dữ liệu đầu vào từ khách hàng. Một ví dụ phổ biến
là khi bạn nhận được một tập dữ liệu độc lập với thông tin đầu vào của người dùng,
Chẳng hạn như bạn có một tập hợp các giá trị cố định, hữu hạn và đã biết
các địa chỉ cần mã hoá địa lý. Mã hoá địa lý phía máy chủ có thể
cũng có thể hữu ích như một bản sao lưu khi mã hoá địa lý phía máy khách không thành công.
Một số mối lo ngại có thể xảy ra là việc tăng độ trễ một cách không cần thiết cho người dùng,
và kết quả mã hoá địa lý có chất lượng thấp hơn phía máy khách vì có ít
có thông tin trong yêu cầu.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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."]]
