Overpass API bằng Python: truy vấn OSM và xuất GeoJSON
Overpass API bằng Python là cách lấy đối tượng OpenStreetMap theo vùng và tag qua máy chủ Overpass, rồi chuẩn hóa node, way, relation thành GeoJSON dùng được trên bản đồ. Đây là dữ liệu bản đồ cộng đồng, khác với graph thực thể của Wikidata và khác hẳn việc lấy dữ liệu từ bản đồ thương mại. ProxyVN chạy thử ngày 29/10/2026: máy chủ overpass-api.de trả mã 406 cho mạng lab sau 16 tới 22 giây. Vì vậy phần chuyển GeoJSON được kiểm bằng fixture đúng khuôn JSON của Overpass, và bài ghi rõ phần nào chưa chạy với dữ liệu thật.
Overpass API bằng Python: mục tiêu dữ liệu, quyền và phạm vi truy cập
Phần đầu chốt loại dữ liệu cần lấy, giấy phép của OpenStreetMap và chính sách tải của máy chủ Overpass công cộng.
Dữ liệu cần lấy
Bài lấy ví dụ quán cà phê trong một khung nhỏ quanh hồ Hoàn Kiếm. Mỗi đối tượng cần loại OSM, ID, URL tới trang đối tượng, tên, giờ mở cửa và một điểm tọa độ. Bảng này đủ để vẽ lên bản đồ hoặc đối chiếu với danh sách địa điểm nội bộ.
Khung nhỏ là chủ đích. Truy vấn một quận hay một thành phố trả về hàng nghìn đối tượng và tốn tài nguyên máy chủ. Khi học cú pháp, khung vài trăm mét là đủ để thấy mọi kiểu dữ liệu.
Giấy phép ODbL và ghi công
Dữ liệu OpenStreetMap phát hành theo giấy phép Open Database License. Khi dùng dữ liệu, anh em phải ghi công OpenStreetMap contributors và giữ điều kiện chia sẻ tương tự với cơ sở dữ liệu dẫn xuất.
Script trong bài ghi dòng nguồn và giấy phép vào thuộc tính của FeatureCollection. Cách làm này giúp tệp GeoJSON mang theo attribution khi được chuyển cho người khác. Bài không tư vấn pháp lý, anh em cần đọc điều khoản trước khi đưa dữ liệu vào sản phẩm.
Chính sách tải của máy chủ công cộng
Hướng dẫn dùng chung tài nguyên của Overpass ghi mỗi máy chủ phục vụ khoảng một triệu request mỗi ngày. Người dùng được kỳ vọng gửi tối đa khoảng 10.000 request mỗi ngày và giữ dung lượng tải dưới khoảng 1 GB mỗi ngày.
Tài liệu cũng mô tả cơ chế slot: mỗi request chiếm một slot của người dùng trong suốt thời gian chạy cộng thêm thời gian nghỉ. Request của người dùng ít được ưu tiên hơn request của người dùng nặng. Máy chủ tự cắt tải khi tổng lượng request vượt khả năng.
Overpass công cộng là tài nguyên chung. Truy vấn nhỏ, gửi tuần tự, cache kết quả.
Ranh giới với Wikidata SPARQL
Wikidata trả graph thực thể với mã Q và quan hệ giữa các thực thể. Bài Wikidata SPARQL bằng Python xử lý nguồn đó. Overpass trả đối tượng hình học: điểm, đường, vùng, kèm tag mô tả.
Một quán cà phê nổi tiếng có thể có cả mã Wikidata lẫn đối tượng OSM, nối nhau qua tag wikidata. Nhưng phần lớn quán nhỏ chỉ có trên OSM. Nếu cần tọa độ và hình dạng, Overpass là nguồn đúng.
Ranh giới với bản đồ thương mại
Bài này không lấy dữ liệu từ Google Maps hay bản đồ thương mại nào. Bài proxy scraping Google Maps bàn chủ đề đó với điều khoản riêng. Dữ liệu OSM có giấy phép mở rõ ràng và API chính thức, nên không cần scrape.
Bài cũng không thu dữ liệu vị trí của cá nhân. OSM chứa địa điểm công cộng, đường sá, tòa nhà, không chứa vị trí người dùng.
Tự dựng máy chủ khi cần tải đều
Mã nguồn Overpass là phần mềm mở, có hướng dẫn cài đặt trong tài liệu. Tự dựng máy chủ với dữ liệu một quốc gia giúp nhóm chạy truy vấn bao nhiêu tùy ý mà không ảnh hưởng người khác.
Đổi lại, nhóm phải lo ổ đĩa, bộ nhớ và việc cập nhật dữ liệu từ OSM. Với nhu cầu vài chục truy vấn mỗi ngày, máy chủ công cộng vẫn hợp lý hơn.
Những gì bài không làm
Bài không sửa dữ liệu OSM, không tự dựng máy chủ Overpass và không tải bản dump toàn hành tinh. Bài không hướng dẫn chia request qua nhiều IP để vượt cơ chế slot, vì điều đó đi ngược tinh thần dùng chung tài nguyên mà tài liệu mô tả.
Ai cần bảng địa điểm này
Nhóm nghiên cứu đô thị dùng dữ liệu OSM để đếm tiện ích theo khu vực. Nhà phát triển ứng dụng dùng nó làm lớp nền cho bản đồ riêng. Nhóm dữ liệu dùng nó để đối chiếu danh sách cửa hàng nội bộ với dữ liệu cộng đồng.
Cả ba nhu cầu đều không cần cập nhật từng giây. Lấy một lần, lưu lại, làm mới theo tuần hoặc tháng là đủ. Nhịp chậm như vậy giữ tải lên máy chủ công cộng ở mức tối thiểu.
Overpass API bằng Python: truy vấn đối tượng OSM theo vùng, type, tag và xuất GeoJSON
Phần này giải thích ba loại đối tượng OSM, cú pháp truy vấn và cách mỗi loại biến thành hình học GeoJSON.
Node, way và relation
Node, way, relation
Node là một điểm có tọa độ. Way là chuỗi node có thứ tự, có thể là đường hoặc vòng khép kín. Relation là nhóm node, way hoặc relation khác với vai trò, dùng cho vùng có lỗ, tuyến xe buýt hay ranh giới hành chính.
Một quán cà phê có thể được vẽ thành node nếu chỉ đánh dấu vị trí, hoặc thành way nếu vẽ cả hình tòa nhà. Truy vấn chỉ lấy node sẽ bỏ sót mọi quán được vẽ thành vùng. Vì vậy truy vấn trong bài lấy cả ba loại.
Cú pháp truy vấn theo khung
[out:json][timeout:25];
(
node["amenity"="cafe"](21.0255,105.8480,21.0330,105.8560);
way["amenity"="cafe"](21.0255,105.8480,21.0330,105.8560);
relation["amenity"="cafe"](21.0255,105.8480,21.0330,105.8560);
);
out center tags;Dòng đầu chọn định dạng JSON và thời gian chạy tối đa 25 giây. Khung tọa độ viết theo thứ tự nam, tây, bắc, đông. Khối ngoặc tròn gộp ba truy vấn thành một tập kết quả.
Lệnh out quyết định hình học trả về
out center tags trả tag và một điểm trung tâm cho way và relation, còn node trả tọa độ thật. out geom trả toàn bộ tọa độ của way. out count chỉ trả số lượng, không trả đối tượng. Tài liệu định dạng đầu ra mô tả chi tiết các biến thể.
Với bảng địa điểm, out center đủ dùng và nhẹ hơn nhiều so với out geom. Khi cần vẽ hình dạng tòa nhà, mới dùng out geom cho đúng tập way cần vẽ.
Khuôn JSON của Overpass
Response JSON có version, generator, osm3s và elements. osm3s chứa timestamp_osm_base, thời điểm dữ liệu OSM mà máy chủ đang phục vụ. elements là danh sách đối tượng, mỗi đối tượng có type, id và tùy loại có lat, lon, center, geometry, nodes hoặc members.
Script chuyển đổi đọc type trước, rồi chọn nguồn tọa độ theo thứ tự: tọa độ node, geometry, center. Đối tượng không có nguồn nào bị bỏ qua và ghi vào danh sách bị loại.
GeoJSON viết kinh độ trước
Kinh độ trước, vĩ độ sau
Theo RFC 7946, tọa độ GeoJSON viết kinh độ trước, vĩ độ sau. Overpass trả lat và lon thành hai trường riêng. Lỗi phổ biến nhất là ghi [lat, lon] khiến điểm ở Hà Nội rơi xuống Nam Cực hoặc Ấn Độ Dương.
Script lab ghi [lon, lat] và kiểm mọi kinh độ nằm trong khoảng từ âm 180 tới 180. Phép kiểm này không bắt được mọi lỗi, nhưng bắt được trường hợp đảo trục với dữ liệu Việt Nam, vì vĩ độ khoảng 21 còn kinh độ khoảng 105.
Way khép kín thành Polygon
Way có node đầu trùng node cuối và ít nhất bốn điểm được coi là vòng khép kín, chuyển thành Polygon. Way mở chuyển thành LineString. Relation multipolygon cần ghép các way thành viên theo vai trò outer và inner, việc phức tạp hơn nhiều.
Bài này chỉ dùng center cho relation để giữ script ngắn. Khi cần hình dạng đầy đủ của relation, nên dùng thư viện chuyên dụng thay vì tự ghép vòng.
Lọc nhiều tag cùng lúc
Một truy vấn có thể lọc nhiều điều kiện trên cùng đối tượng, ví dụ amenity=cafe kèm tag name tồn tại. Điều kiện viết liền nhau trong cặp ngoặc vuông là phép và. Điều kiện có dấu ngã cho phép so khớp biểu thức chính quy.
Lọc chặt ngay trong truy vấn giúp máy chủ trả ít dữ liệu hơn. Tốt hơn nhiều so với lấy rộng rồi lọc trong Python, vì phần dữ liệu thừa vẫn tốn tài nguyên máy chủ và băng thông.
Độ mới của dữ liệu
timestamp_osm_base cho biết dữ liệu mới tới đâu. Máy chủ Overpass cập nhật từ OSM theo phút, nhưng có thể trễ khi tải cao. Ghi timestamp này vào tệp kết quả để biết một quán mới thêm hôm qua có thể chưa có hay không.
Chuẩn bị truy vấn, ID và phiên bản khi dùng Overpass API bằng Python
Phần này gom các quyết định trước khi chạy: chọn vùng, chọn tag, đặt timeout, chọn máy chủ và định danh request.
Chọn khung nhỏ hoặc vùng có tên
Khung tọa độ là cách nhanh nhất cho thử nghiệm. Khi cần ranh giới hành chính, Overpass hỗ trợ area theo tên hoặc ID relation, nhưng truy vấn area tốn tài nguyên hơn. Bắt đầu bằng khung nhỏ, kiểm kết quả, rồi mới mở rộng.
Khung trong lab rộng khoảng 0,0075 độ vĩ và 0,008 độ kinh, tức khoảng 800 mét mỗi chiều. Vùng này đủ chứa nhiều quán cà phê và vài tòa nhà có tên.
Chọn tag theo wiki OSM
Tag amenity=cafe là quy ước của cộng đồng OSM. Mỗi loại địa điểm có tag riêng: amenity=restaurant, shop=convenience, tourism=hotel. Viết sai tag thì truy vấn trả rỗng, không báo lỗi.
Nên thử out count trước với tag mới. Nếu số lượng bằng 0 ở khu vực đông đúc, rất có thể tag sai. Phép thử này nhẹ vì không trả đối tượng nào.
Đặt timeout và maxsize
timeout trong dòng đầu là giới hạn thời gian chạy phía máy chủ. maxsize giới hạn bộ nhớ. Đặt giá trị nhỏ cho truy vấn nhỏ giúp máy chủ xếp lịch dễ hơn và trả lỗi sớm nếu truy vấn vô tình quá lớn.
Phía Python, timeout của requests nên lớn hơn timeout của truy vấn vài giây. Lab đặt timeout truy vấn 25 giây và timeout requests 60 giây.
Gửi truy vấn bằng POST
Truy vấn dài nên gửi bằng POST với trường data trong form. GET cũng được nhưng URL dài dễ vượt giới hạn và khó đọc trong log. Lab dùng requests.post với data={"data": truy_vấn}.
Định danh bằng User-Agent
Lab đặt User-Agent ProxyVN-lab/1.0 kèm email giả [email protected]. Khi chạy thật, thay bằng tên dự án và email thật. Máy chủ công cộng dùng thông tin này để liên hệ khi có vấn đề.
Lab không đổi User-Agent sau khi bị từ chối. Đổi chuỗi định danh để né từ chối là hành vi lẩn tránh, không phải sửa lỗi.
Chọn máy chủ
overpass-api.de là máy chủ chính do dự án vận hành. Cộng đồng còn có vài máy chủ công cộng khác với chính sách riêng. Khi dự án cần tải đều đặn, tự dựng máy chủ Overpass từ dữ liệu OSM là cách không phụ thuộc tài nguyên chung.
Ghi tên máy chủ vào cấu hình và vào tệp kết quả. Hai máy chủ khác nhau có thể có timestamp_osm_base khác nhau.
Viết truy vấn thành mẫu
Giữ truy vấn trong một chuỗi mẫu có chỗ trống cho khung tọa độ và tag. Khi đổi vùng hay đổi loại địa điểm, chỉ thay tham số. Ghi truy vấn đầy đủ đã gửi vào tệp kết quả để tái lập.
Đừng ghép chuỗi tag từ đầu vào người dùng mà không kiểm. Dấu nháy kép hay dấu ngoặc lạ trong tag có thể làm hỏng cú pháp và khiến máy chủ chạy một truy vấn khác dự định.
Môi trường lab
Python 3.12.10, requests 2.34.2, json của thư viện chuẩn. Không cần thư viện bọc riêng như overpy cho ví dụ này. Ghi phiên bản vào requirements.txt để tái lập.
Thu dữ liệu và trạng thái máy chủ với Overpass API bằng Python
Overpass không phân trang theo nghĩa thông thường. Một truy vấn trả toàn bộ kết quả hoặc lỗi. Phần này ghi lại kết quả chạy thật và cách chia nhỏ truy vấn.
Kết quả gọi thật ngày 29/10/2026
406 và fixture
Request |
Kết quả |
Giây |
Ghi chú |
|---|---|---|---|
GET /api/status |
406 Not Acceptable |
22,16 |
Trang lỗi nginx, không có nội dung trạng thái |
POST /api/interpreter, out count |
406 Not Acceptable |
16,09 |
Cùng trang lỗi nginx |
POST /api/interpreter lần đầu |
Timeout |
60 |
Hết thời gian chờ ở bước bắt tay TLS |
Máy chủ trả 406 cho cả trang trạng thái lẫn truy vấn nhỏ nhất. Lab không biết lý do cụ thể vì trang lỗi không ghi gì thêm. Có thể là cơ chế cắt tải, có thể là chặn theo dải mạng. Lab dừng ở đó, không thử né.
Vì sao không thử lại bằng cách khác
Đổi User-Agent, đổi IP hay chuyển request qua proxy để có kết quả khác là cách lẩn tránh quyết định của máy chủ. Tài liệu Overpass mô tả rõ máy chủ tự quản lý tải. Khi bị từ chối, cách đúng là chờ, giảm tải hoặc tự dựng máy chủ.
Bài ghi trung thực: lab chưa lấy được dữ liệu OSM thật qua Overpass trong ngày chạy. Phần chuyển GeoJSON bên dưới được kiểm bằng fixture.
Fixture đúng khuôn Overpass
Fixture là tệp JSON tự viết theo đúng khuôn response: version, generator, osm3s và elements. Fixture có tám phần tử với tọa độ giả quanh hồ Hoàn Kiếm, không phải dữ liệu OSM thật. Mục đích là kiểm mọi nhánh của hàm chuyển đổi.
Tám phần tử gồm ba node, một way có center, một way có geometry khép kín, một relation có center, một way thiếu tọa độ và một node trùng lặp. Mỗi phần tử ứng với một tình huống script có thể gặp khi chạy thật.
Hàm chuyển phần tử thành Feature
def to_feature(e):
t = e.get("tags", {})
p = {"osm_type": e["type"], "osm_id": e["id"],
"osm_url": f"https://www.openstreetmap.org/{e['type']}/{e['id']}",
"name": t.get("name"), "opening_hours": t.get("opening_hours")}
if e["type"] == "node":
g = {"type": "Point", "coordinates": [e["lon"], e["lat"]]}
elif "geometry" in e:
ring = [[pt["lon"], pt["lat"]] for pt in e["geometry"]]
closed = ring[0] == ring[-1] and len(ring) >= 4
g = ({"type": "Polygon", "coordinates": [ring]} if closed
else {"type": "LineString", "coordinates": ring})
elif "center" in e:
g = {"type": "Point",
"coordinates": [e["center"]["lon"], e["center"]["lat"]]}
else:
return None
return {"type": "Feature", "geometry": g, "properties": p}Kết quả chạy fixture
Chỉ số |
Giá trị |
|---|---|
Phần tử vào |
8 |
Feature ra |
6 |
Trùng lặp bị bỏ |
1 (node 1001) |
Không có tọa độ |
1 (way 2003) |
Nguồn tọa độ |
3 node, 2 center, 1 geom |
Kiểu hình học |
5 Point, 1 Polygon |
Không có tên |
2 |
Mọi kinh độ của Point nằm trong khoảng hợp lệ. Tệp 286_fixture.geojson ghi thuộc tính nguồn, giấy phép và timestamp_osm_base của fixture.
Chia nhỏ truy vấn thay cho phân trang
Khi vùng lớn, chia khung thành lưới ô nhỏ và chạy tuần tự từng ô. Mỗi ô là một truy vấn độc lập, lỗi ở ô nào chạy lại ô đó. Đối tượng nằm vắt qua ranh giới hai ô sẽ xuất hiện hai lần, nên phải khử trùng theo cặp type và id.
Giữa hai truy vấn, nghỉ vài giây để slot được giải phóng. Tài liệu mô tả mỗi request chiếm slot trong thời gian chạy cộng thời gian nghỉ, nên gửi dồn dập chỉ làm request sau phải chờ.
Ước lượng kích thước trước khi chạy
Chạy out count cho từng loại đối tượng trước khi lấy dữ liệu thật. Số lượng cho biết response sẽ lớn cỡ nào. Với out center tags, mỗi đối tượng thường chiếm vài trăm byte.
Nếu out count trả hàng chục nghìn đối tượng cho một ô, chia ô nhỏ hơn. Đây là bước rẻ nhất để tránh truy vấn quá lớn bị máy chủ hủy giữa chừng.
Đọc trang trạng thái khi máy chủ cho phép
Khi /api/status trả nội dung bình thường, nó cho biết số slot còn trống và thời điểm slot tiếp theo rảnh. Script có thể đọc trang này trước mỗi truy vấn lớn. Trong ngày lab, trang trạng thái trả 406 nên không đọc được.
Đối soát ID, kiểu dữ liệu và giá trị thiếu trong Overpass API bằng Python
Phần này kiểm dữ liệu sau khi chuyển đổi: khóa, trùng lặp, tag thiếu và giá trị tự do.
Khóa là cặp type và id
ID của node, way và relation thuộc ba không gian số riêng. Node 1001 và way 1001 là hai đối tượng khác nhau. Khóa chính phải là cặp type và id, không chỉ id.
Fixture có node 1001 xuất hiện hai lần. Script giữ lần đầu và đếm một trùng lặp. Khi gộp nhiều ô lưới, trùng lặp kiểu này rất thường gặp.
Tag thiếu là bình thường
Hai trong sáu Feature không có tên. Dữ liệu OSM do cộng đồng nhập, có quán chỉ được đánh dấu loại mà chưa ai thêm tên. Ghi None thay vì chuỗi giả.
opening_hours thiếu ở phần lớn đối tượng. Khi báo cáo, ghi tỷ lệ đối tượng có giờ mở cửa để người đọc biết độ phủ của trường này.
Giá trị tag là chuỗi tự do
opening_hours có cú pháp riêng như Mo-Fr 07:00-22:00, nhưng người nhập không phải lúc nào cũng viết đúng. Tag name có thể có tiếng Việt có dấu, tiếng Anh hoặc cả hai qua name:vi và name:en.
Đừng parse opening_hours bằng biểu thức tự viết. Giữ chuỗi gốc, dùng thư viện chuyên dụng khi cần tính quán có đang mở hay không.
Hình học từ center khác hình học thật
Center của way là điểm tính toán, có thể nằm ngoài vùng nếu vùng có hình chữ L hay hình vành khăn. Thuộc tính geom_source trong Feature ghi rõ điểm lấy từ node, center hay geom.
Khi đo khoảng cách chính xác, đừng dùng center của tòa nhà lớn. Lấy geom rồi tính trên hình dạng thật.
Tọa độ có bao nhiêu chữ số
Overpass trả tọa độ với bảy chữ số thập phân, tương đương độ chính xác cỡ centimet. Độ chính xác này lớn hơn nhiều so với độ chính xác thật của dữ liệu nhập tay.
Khi xuất cho bản đồ web, làm tròn tới sáu chữ số giúp tệp nhỏ hơn mà không đổi vị trí thấy được. Giữ bản gốc trong dữ liệu thô nếu cần tính toán.
Way thiếu tọa độ
Way 2003 trong fixture có danh sách nodes nhưng không có geometry hay center. Đây là kết quả của lệnh out không kèm hình học. Script bỏ way này và ghi vào danh sách bị loại.
Khi chạy thật mà thấy nhiều way bị loại, hãy kiểm lại lệnh out. Thường là quên center hoặc geom ở cuối truy vấn.
Giữ URL đối tượng cho từng dòng
Mỗi Feature có osm_url dạng https://www.openstreetmap.org/node/1001. Ai đọc tệp cũng mở được trang đối tượng để kiểm tag và lịch sử chỉnh sửa. Đây là xuất xứ tối thiểu cho dữ liệu cộng đồng.
Bài JSON và CSV khi crawl dữ liệu bàn khi nào giữ thêm JSON thô. Với Overpass, giữ response thô giúp chuyển đổi lại khi đổi logic mà không cần gọi máy chủ.
Lưu kết quả, giới hạn request và khi nào Overpass API bằng Python cần proxy
Phần cuối bàn chuyện lưu trữ, nhịp request và vị trí của proxy với một máy chủ dùng chung.
Lưu GeoJSON kèm attribution
GeoJSON mở được bằng QGIS, Leaflet hay trình xem bản đồ trực tuyến. Lưu thuộc tính source, license và timestamp_osm_base ở cấp FeatureCollection. Khi hiển thị trên web, đặt dòng ghi công OpenStreetMap contributors ở góc bản đồ.
Cache và làm mới theo nhịp chậm
Địa điểm không đổi từng phút. Cache response theo khung và tag, làm mới mỗi tuần là đủ cho phần lớn nhu cầu. Mỗi lần làm mới chỉ tốn một hoặc vài request.
Giữ dưới hướng dẫn tải
Hướng dẫn tối đa khoảng 10.000 request và 1 GB mỗi ngày là mức rộng với nhu cầu thông thường. Truy vấn lưới ô cho cả một tỉnh có thể chạm mức đó. Trước khi chạy, tính số ô và kích thước dự kiến.
Bài rate limit API khi dùng proxy có mẫu bộ đếm request theo ngày. Áp vào Overpass để dừng job khi chạm ngưỡng tự đặt.
Ghi nhật ký mỗi lần chạy
Nhật ký nên có máy chủ, truy vấn, mã trạng thái, thời gian, timestamp_osm_base, số phần tử, số Feature, số bị loại và số trùng lặp. So sánh hai lần chạy giúp phát hiện đối tượng bị xóa hay thêm mới.
Khi nhận mã khác 200, ghi cả nội dung trang lỗi. Lab ghi lại trang lỗi 406 của nginx để sau này đối chiếu nếu máy chủ đổi hành vi.
Proxy không phải cách vượt cơ chế slot
Cơ chế slot và cắt tải của Overpass bảo vệ máy chủ dùng chung. Chia request qua nhiều IP để có thêm slot là lẩn tránh cơ chế đó. Khi lab nhận 406, bài cố ý không thử lại qua proxy.
Proxy trong lab kiểm ở đâu
Lab chạy proxy HTTP có xác thực và proxy SOCKS5 cục bộ, rồi gửi GET /api/status qua từng loại. Mục đích là xác định proxy nằm ở tầng tải, không phải để né 406.
Cách gọi |
Kết quả |
Proxy thấy gì |
|---|---|---|
Trực tiếp |
406 sau 22,16 giây |
Không qua proxy |
Proxy cục bộ, cùng IP thoát |
Không chạy thêm |
Bài không gửi thêm request để tránh tạo tải |
Proxy cục bộ của lab dùng chung IP thoát với máy lab, nên đi qua nó không đổi kết quả. Ở các bài khác cùng cụm, lab đã ghi nhận proxy HTTP chỉ thấy CONNECT tên máy và cổng 443, proxy SOCKS5 thấy tên miền và cổng.
Khi nào cần proxy thật
Proxy cần khi máy chủ xử lý nằm trong mạng chỉ cho ra Internet qua proxy, hoặc khi tổ chức yêu cầu lưu lượng ra ngoài đi qua một IP cố định để giám sát. Cấu hình proxy và mã hóa mật khẩu có ký tự đặc biệt có trong bài định dạng proxy.
Bài Web Scraping proxy là gì phân biệt các vai trò của proxy. Với Overpass, vai trò hợp lý duy nhất là đường đi mạng, không phải tăng hạn mức.
Khi máy chủ của nhóm ở Việt Nam cần một IP thoát cố định để quản trị mạng cho phép đi ra ngoài, proxy tĩnh dễ quản lý hơn proxy xoay. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5. Anh em có thể mua proxy Việt Nam tại trang chủ ProxyVN rồi khai báo vào requests theo tham số proxies.
Giới hạn suy luận của bài
Lab chưa lấy được dữ liệu OSM thật qua Overpass ngày 29/10/2026: máy chủ overpass-api.de trả 406 cho mạng lab. Số liệu về Feature, trùng lặp và tag thiếu đến từ fixture tự viết, không phản ánh dữ liệu quanh hồ Hoàn Kiếm.
Lab chưa thử máy chủ Overpass khác, chưa thử truy vấn area và chưa ghép relation multipolygon. Chính sách tải được trích từ tài liệu Overpass đọc cùng ngày. Lý do của mã 406 không được xác định.
Checklist Overpass API bằng Python
Checklist Overpass API
- Bắt đầu bằng khung nhỏ, thử out count trước.
- Lấy cả node, way và relation.
- Dùng out center cho bảng địa điểm, out geom khi cần hình dạng.
- Ghi tọa độ GeoJSON theo thứ tự kinh độ, vĩ độ.
- Khóa chính là cặp type và id.
- Ghi timestamp_osm_base và attribution ODbL.
- Gửi tuần tự, nghỉ giữa các truy vấn, cache kết quả.
- Bị từ chối thì chờ hoặc tự dựng máy chủ, không né.
Câu hỏi thường gặp về Overpass API bằng Python
Overpass có cần khóa API không?
Không. Máy chủ công cộng không yêu cầu khóa. Đổi lại, máy chủ tự quản lý tải bằng slot và có thể từ chối request khi quá tải.
Vì sao truy vấn chỉ lấy node bị thiếu quán?
Vì nhiều quán được vẽ thành way theo hình tòa nhà. Lấy cả node, way và relation với out center.
Nhận 406 thì làm gì?
Dừng và chờ. Kiểm truy vấn có quá lớn không. Nếu cần tải đều đặn, cân nhắc tự dựng máy chủ Overpass. Đừng đổi User-Agent hay IP để né.
Dữ liệu OSM dùng cho sản phẩm thương mại được không?
Giấy phép ODbL cho phép với điều kiện ghi công và chia sẻ tương tự cơ sở dữ liệu dẫn xuất. Đọc điều khoản trước khi triển khai, bài này không tư vấn pháp lý.
GeoJSON hiển thị sai vị trí là do đâu?
Thường do đảo thứ tự kinh độ và vĩ độ. GeoJSON viết kinh độ trước.
Overpass khác Wikidata ở điểm nào?
Overpass trả đối tượng hình học OSM. Wikidata trả thực thể có mã Q và quan hệ. Hai nguồn nối nhau qua tag wikidata khi có.
Overpass API bằng Python và những điều cần nhớ
Overpass API bằng Python cho anh em đối tượng OSM theo vùng và tag, việc còn lại là tách node, way, relation và ghi GeoJSON đúng thứ tự tọa độ. Lab ngày 29/10/2026 nhận 406 từ máy chủ công cộng nên kiểm hàm chuyển đổi bằng fixture: 8 phần tử vào, 6 Feature ra. Truy vấn nhỏ, ghi attribution, tôn trọng slot. Cần IP thoát cố định cho máy chủ chạy Overpass API bằng Python, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.
