Tên Google Traffic Tiles
Địa chỉ Server mt1.google.com
Đường dẫn /vt/lyrs=transit,traffic&x={x}&y={y}&z={z}
Kích thước 256
Độ zoom lớn nhất 1
Độ zoom nhỏ nhất 18
Hình 3.1. Dữ liệu giao thông của Google hiển thị trên nền tảng dữ liệu VMap
Do dữ liệu giao thông thay đổi liên tục, Google Traffic thay đổi sau mỗi năm phút, để tăng tốc thuật toán, chúng ta cần tải về bộ dữ liệu Google Traffic Tiles. Do số lượng ảnh cả Việt Nam và Hà Nội là rất lớn, trong luận văn này tôi tiến hành thử nghiệm tại 12 quận bao gồm:
Ba Đình, Cầu Giấy, Đống Đa, Hà Đông, Hai Bà Trưng, Hoàn Kiếm, Hoàng Mai, Long Biên, Bắc Từ Liêm, Nam Từ Liêm, Tây Hồ, Thanh Xuân.
Xây dựng một công cụ để tải về Google Traffic Tiles: - Ngôn ngữ sử dụng: NodeJS
- Thư viện: request, polygon-lookup - Thu thập tại 12 quận tại Hà Nội
- Độ zoom: 18 (Đây là độ zoom lớn nhất của bộ dữ liệu Google Traffic Tiles mà Google cung cấp)
Từ khung nhìn chọn trước được miêu tả trong Bảng 3.2, công cụ sẽ tính toán ra các thông số Xmax, Ymax, Xmin, Ymin (là tọa độ lớn nhất và nhỏ nhất của các mảnh bản đồ cần tải về) tại độ Zoom 18 để tính toán tất cả các tile ảnh cần tải về. Sử dụng vòng lặp và hàm PolygonLookup cửa thư viện polygon-lookup để lần lượt kiểm tra xem tọa độ các Tile có thuộc 1 trong 12 quận thử nghiệm hay không, nếu có sẽ tải về tương ứng dữ liệu
ảnh đó bằng cách sử dụng thư viện request và lưu trữ dưới dạng cây thư mục {Độ Zoom}/{X}/{Y}.png. Dữ liệu ranh giới hành chính được sử dụng ở đây là dữ liệu hành
chính 1:50.000 của Bộ Tài nguyên và Môi trường dưới định dạng GeoJSON.
Hình 3.2. Dữ liệu ranh giới hành chính
Bảng 3.2. Thông tin thử nghiệm tải về dữ liệu
Góc Bắc (vĩ độ) Góc Tây (kinh độ) Góc Nam (vĩ độ) Góc Đông (kinh độ)
21.379 105.281 20.554 106.027 Công thức tính X từ kinh độ: 𝑌 = 𝑙𝑜𝑛 + 180 360 ∗ 2𝑧𝑜𝑜𝑚 Công thức tính Y từ vĩ độ: 1 − log(tan (𝑙𝑎𝑡 ∗ 𝜋180 ) + 1 cos(𝑙𝑎𝑡 ∗ 𝜋) )
Công thức tính vĩ độ từ Y:
𝑙𝑎𝑡 = 180
𝜋 ∗ arctan(0.5 ∗ (exp(𝑛) − exp (−𝑛)))
- Trong đó n được tính theo công thức sau:
𝑛 = 𝜋 − 2 ∗ 𝜋 ∗ 𝑌 ∗ 𝑧𝑜𝑜𝑚 2𝑧𝑜𝑜𝑚
Kết quả chạy thử nghiệm: - Tổng số tile: 15.128 tile
- Thời gian trung bình tải về: 133,46 giây
Hình 3.3. Một phần dữ liệu thu thập được
3.2 Xây dựng thuật toán tìm đường đi nhanh nhất theo thời gian 3.2.1 Đề xuất phương pháp tìm đường 3.2.1 Đề xuất phương pháp tìm đường
Phương pháp mới được thể hiện trong Hình 3.4. Khi người dùng gửi yêu cầu đến dịch vụ tìm đường mới, thông tin tọa độ của điểm đi và điểm đến sẽ được truyền đền
Thuật toán tìm đường đi nhanh nhất sẽ được trình bày ở phần sau của luận văn. Thuật toán sẽ sử dụng dịch vụ tìm đường hiện tại của VMap (ở đây là GraphHopper) và bổ sung thuật toán tìm đường đi nhanh nhất để đưa ra kết quả là đường đi nhanh nhất kèm thời gian ước lượng thực tế cho người dùng.
Hình 3.4. Kiến trúc hệ thống tìm đường mới
Xây dựng API dẫn đường mới cho VMap: - Ngôn ngữ sử dụng: python
- Thư viện: flask, json, requests, polyline, pickle, sklearn
API dẫn đường mới sẽ có đường dẫn và cấu trúc truy vấn tương tự với dịch vụ hiện có của VMap. Các trường cụ thể được thể hiện ở Bảng 3.3. API khi có yêu cầu gửi lên sẽ sử dụng thư viện request để lấy kết quả chỉ đường từ dịch vụ chỉ đường hiện có của VMap. Dữ liệu đường đi của kết quả chỉ đường này sẽ được truyền vào mô hình sẽ được trình bày bên dưới, đã được lưu lại bằng cách sử dụng thư viện pickle, để tính toán lại ước lượng thời gian di chuyển. Để thay đổi giá trị ước lượng thời gian di chuyển của kết quả trả về, ta cần quan tâm tới 2 thông số là points_encoded và instructions. Nếu người dùng sử dụng thông số points_encoded=”true”, API sẽ sử dụng thư viện polyline để giải mã dữ liệu đường đi đã được mã hóa, truyền dữ liệu đường đi vào mô hình. Nếu
tìm đường của dịch vụ chỉ đường VMap và thêm một thông số time_in_traffic tương ứng với mỗi thông số time của kết quả.
Kết quả trả về dưới dạng JSON, có cấu trúc như ở Bảng 3.4.
Bảng 3.3. Các thông số truy vấn có thể gửi lên
Thông số Miêu tả
point (bắt buộc) Điểm đầu và điểm cuối mà người dung muốn tìm đường. Định dạng [vĩ độ, kinh độ]
vehicle Phương tiện muốn tìm đường. Bao gồm: “car” (oto), “motobike” (xe máy), “bike” (xe đạp) và “foot” (đi bộ)
locale Mặc định: “vn”
Ngôn ngữ hướng dẫn trong kết quả trả về. Ví dụ: “en” ho tiếng Anh hoặc “de” cho tiếng Đức
elevation Mặc định: “false”
Nếu là “true”, thuật toán sẽ ước tính chiều dài của quãng đường bằng cách sử dụng thêm mô hình độ cao số.
details Tham số tùy chọn để truy xuất chi tiết đường dẫn. Bạn có thể yêu cầu chi tiết bổ sung cho tuyến đường: “street_name”, “time”, “distance”, “max_speed”, “toll”, “road_class”, “road_class_link”, “road_access”, “road_environment”, “lanes”, và “surface”
instructions Mặc định: “true”
Trả về các hướng dẫn đi trên tuyến đường
points_encoded Mặc định: “true”
Cho phép thay đổi mã hóa dữ liệu vị trí trong phản hồi. Mặc định là mã hóa polyline, nhỏ gọn nhưng yêu cầu mã máy khách đặc biệt để giải nén. Đặt tham số này thành “false” để chuyển mã hóa sang các cặp tọa độ đơn giản như [kinh độ, vĩ độ] hoặc [kinh độ, vĩ độ, độ cao].
ch.disable Mặc định: “false”
Sử dụng tham số này kết hợp với một hoặc nhiều tham số từ bên dưới.
algorithm Mặc định: “round_trip”
Thay đổi thành “alternative_route” khi bạn muốn trả về nhiều hơn 1 đường đi
alternative_route.max_paths Mặc định: “2”
Nếu algorithm = “alternative_route”, tham số này đặt số lượng đường dẫn tối đa sẽ được tính toán. Tăng có thể dẫn đến các lựa chọn thay thế kém hơn.
Bảng 3.4. Các thông số truy vấn có thể gửi lên
Thông tin Miêu tả
paths Mảng đối tượng (RouteResponsePath)
Hình 3.5. Ví dụ một kết quả tìm đường được trả về bằng API mới
3.2.2 Đề xuất Thuật toán tìm đường đi nhanh nhất
Thuật toán tìm đường đi nhanh nhất có đầu vào là đường đi của người dùng dưới dạng Polyline. Đường đi này là đầu ra của dịch vụ chỉ đường của VMap. Sau đó thuật toán sẽ thực hiện các bước sau:
- Bước 1: Kết quả trả về của dịch vụ chỉ đường của VMap hiện tại bao gồm các hướng dẫn di chuyển cũng như Polyline là tọa độ của các bước di chuyển đó. Mỗi cách di chuyển này ta gọi là 1 Path.
- Bước 2: Từ các Path, ta có được thông tin Polyline bao gồm nhiều Point khác nhau, mỗi 2 Point là một bước đi thẳng theo chỉ dẫn. Ta tách nhỏ Polyline trong Path thành các Polyline lần lượt bao gồm 2 Point liền nhau, ta gọi là Line.
- Bước 3: Từ các Line, ta lần lượt cắt thành các mảnh nhỏ hơn, mỗi đoạn dài ~5.96m (tương ứng 10 pixel trên 1 tile), ta được các Piece. Ta cần sử dụng thư viện shapely
để thực hiện việc này.
- Bước 4: Với mỗi Piece, ta tính toán tâm (Mid-point) và góc so với trục tọa độ. Mục tiêu là ta cần tính toán cửa sổ cần lấy các điểm ảnh trên đó, từ đó xem được đoạn đường đó đang có tình trạng giao thông như thế nào. Để tính toán được Mid- point, em đã sử dụng hàm nội suy interpolate của thư viện shapely để nội suy ra điểm trung tâm. Tuy nhiên, để sử dụng hảm này, ta cần chuyển hệ quy chiếu của 2 điểm của Piece sang hệ quy chiếu UTM. Em đã sử dụng hàm from_latlon và
to_latlon của thư viện utm, với Zone_number=”48” và Zone_letter=”Q”.
- Bước 5: Sử dụng thư viện OpenCV dựng cửa số trên Tile tương ứng với Mid- Point để lấy tất cả các pixel ảnh thuộc của sổ đó, từ đo tính toán được tình trạng giao thông tại Piece đó. Do hệ thống đường của VMap và Google là không trùng khớp hoàn toàn, vì thế ta cần mở rộng của sổ theo chiều dọc để tăng khả năng có dữ liệu. Sau khi thử nghiệm, em thấy độ chiều dọc của cửa sổ có giá trị 30 là hợp lý.
Hình 3.6. Hệ thống đường của VMap và Google không hoàn toàn trùng khớp
Hình 3.7. Ví dụ trích xuất thông tin từ một Tile
- Bước 6: Chuẩn hóa dữ liệu thu được tại điểm đó bằng cách gán điểm trung bình cho các điểm ảnh trong đó. Nếu điểm ảnh đó màu xanh hoặc không có giá trị, gán giá trị bằng 1, nếu màu cam, gán giá trị bằng 2, lần lượt gán 3, 4 với các điểm ảnh màu đỏ và nâu. Ta lấy trung bình và làm tròn để có giá trị của cửa sổ đó. Một vấn
đề gặp phải ở đây là ảnh Google Traffic Tile được kết xuất theo đường với màu chủ đạo là Xanh, Cam, Đỏ và Nâu và được làm nhạt dần ở viền. Để có thể biết chính xác một điểm ảnh là Xanh, Cam, Đỏ hay Nâu ở bảng mã màu RGB là rất khó. Để giải quyết vấn đề này, em đã chuyển đổi ảnh sang bảng mã màu HSV bằng cách sử dụng hàm cvtColor của thư viện OpenCV. Sau khi chuyển sáng mã màu HSV, các pixel màu xanh sẽ có giá trị H (Hue) trong khoảng [57, 90], các pixel màu cam có giá trị H trong khoảng [18, 40], pixel màu đỏ có giá trị H trong khoảng [2, 10], pixel màu nấu có giá trị H trong khoảng [0, 1].
Hình 3.8. Các mức độ giao thông của Google Traffic
- Bước 7: Ta gom tất cả các giá trị của sổ sau khi chuẩn hóa để có đầu vào cho mô hình học máy.
- Bước 8: Chạy mô hình để ước lượng thời gian di chuyển tương ứng với từng Path. Từ đó, ta sắp xếp các Path theo thời gian di chuyển ngắn nhất thay vì đưa ra Path có quãng đường ngắn nhất.
CHƯƠNG 4. TRIỂN KHAI, THỰC NGHIỆM VÀ ĐÁNH GIÁ
4.1 Xây dựng mô hình ước lượng thời gian di chuyển theo tình trạng giao thông 4.1.1 Xây dựng bộ dữ liệu thử nghiệm 4.1.1 Xây dựng bộ dữ liệu thử nghiệm
Xây dựng bộ dữ liệu thử nghiệm bằng cách chọn ngẫu nhiên 1200 điểm đầu và 1200 điểm cuối trong khu vực nội thành Hà Nội. Sử dụng thư viện request của NodeJS để lấy hướng dẫn di chuyển của Dịch vụ tìm đường Google (Google Direction API) và Dịch vụ tìm đường của VMap. Với kết quả trả về của dịch vụ tìm đường VMap, ta sẽ trích xuất đặc trưng theo phương pháp trình bày ở phần trước làm đầu vào của thuật toán học máy. Với kết quả của Dịch vụ tìm đường Google ta sẽ có được thời gian ước lượng di chuyển trong tình trạng giao thông tương ứng với kết quả đầu ra của thuật toán. Kết hợp hai thông tin này ta sẽ có được dữ liệu thử nghiệm. Bộ dữ liệu thử nghiệm được lưu trữ trong cơ sở dữ liệu MongoDB và xuất ra dưới dạng file csv.
- Tổng số dữ liệu: 3401
- Dữ liệu tập train: 3000 dữ liệu - Dữ liệu tập test: 401 dữ liệu
Hình 4.1. Quy trình xây dựng bộ dữ liệu thử nghiệm
4.1.2 Thử nghiệm và tìm mô hình hiệu quả nhất
Tiến hành thử nghiệm các thuật toán khác nhau để xây dựng mô hình tối ưu nhất từ bộ dữ liệu thử nghiệm. Ở đây, em đã thử nghiệm với 2 thuật toán là Hồi quy tuyến
Để đánh giá chất lượng dữ liệu, hệ số xác định R2 và sai số RMSE được sử dụng để phân tích ước lượng thời gian di chuyển. Phân tích hồi qui là nghiên cứu sự phụ thuộc của 1 biến (biến phụ thuộc) vào 1 hay nhiều biến khác (biến độc lập), nhằm mục đích ước lượng (hay dự đoán) giá trị trung bình của biến phụ thuộc trên cơ sở các giá trị biết trước của các biến độc lập.
Mô hình hồi qui tuyến tính k biến: Y = 1+ 2X2 + …+ kXk + U (1) - Y: biến phụ thuộc X2 ,…,Xk : các biến độc lập
- U: sai số ngẫu nhiên - 1 là hệ số tự do
- j là các hệ số hồi quy riêng, cho biết khi Xj tăng 1 đơn vị thì trung bình của Y sẽ thay đổi j đơn vị trong trường hợp các yếu tố khác không đổi (j=2,…,k).
Hệ số xác định 0≤ R2 ≤1 Có thể nói R2 phản ánh tỷ lệ mô hình lý thuyết phản ánh thực tế.
Hình 4.2. Quy trình xây dựng bộ dữ liệu thử nghiệm
Kết quả thử nghiệm cho thấy với mô hình RNN có kết quả tốt hơn với chỉ số R2 không quá khác biệt (chênh lệch 0.0017), tuy nhiên RMSE thấp hơn 27%. Sau khi đã xây dựng được mô hình, em sử dụng thư viện pickle để lưu mô hình xuống ổ cứng.
Bảng 4.1. Kết quả thử nghiệm
Thuật toán R2 RMSE MSE
Hồi quy tuyến tính 0.9175 87.80 7708.51
4.2 Triển khai công cụ thu thập bộ dữ liệu Google Traffic Tiles
Yêu cầu: NodeJS, NPM, PM2.
PM2 là một trình quản lý các tiến trình dành cho các ứng dụng NodeJS. Nó được viết bằng chính NodeJS và Shell. PM2 cũng được tích hợp bộ cân bằng tải (load balancer). Sử dụng lệnh npm i -g pm2 để cài đặt pm2 cho hệ thống.
Thực hiện sao chép tệp tin downloadImgGGTraffic.js vào thư mục /deployment. Chạy lệnh npm i polygon-lookup request để cài đặt thư viện. Chạy lệnh pm2 start
downloadImgGGTraffic.js để chạy công cụ thu thập bộ dữ liệu Google Traffic Tiles. Để
tiến trình luôn chạy dù hệ thống có thể bị khởi động lại, ta sử dụng lệnh pm2 save để lưu danh sách các tiến trình và pm2 startup để khai báo khởi động pm2 cùng hệ thống.
Hình 4.3. Tiến trình thu thập bộ dữ liệu Google Traffic Tiles được khởi tạo
Hình 4.4. PM2 được khai báo khởi động cùng hệ thống
4.3 Triển khai thuật toán cho Nền tảng cung cấp dịch vụ địa chỉ Việt Nam VMap
Yêu cầu: Python, PIP, Flask, Waitress
Tương tự PM2, Waitress là một trình quản lý các tiến trình dành cho các ứng dụng WSGI của Python. Sử dụng lệnh pip install waitress để cài đặt Waitress cho hệ thống. Thực hiện sao chép tệp tin app.py vào thư mục /deployment. Chạy lệnh pip install flask
để cài đặt Flask. Tương tự với các thư viện cần thiết. Chạy lệnh waitress-serve –call
‘flaskr:VMap_direction’ để chạy ứng dụng web dưới dạng tiến trình. Lúc này, tiến trình
đã chạy ở cổng 8000.
Để có thể thay thế trực tiếp Dịch vụ tìm đường cũ của VMap, ta cần cấu hình nginx (công cụ proxy hệ thống VMap đang sử dụng) đến cổng 8000. Vào thư mục
/etc/nginx/conf.d/ và tiến hành chỉnh sửa file VMap.conf. Thêm đoạn mã sau vào phần cấu hình tên miền VMap.vn để cập nhật dịch vụ tìm đường của VMap.
location /route {
proxy_pass http://10.101.3.215:8000; proxy_cache VMap_cache;
proxy_cache_revalidate on; proxy_cache_min_uses 3;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_lock on;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
# Enables WS support
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_redirect off;
}
Sau khi triển khai thành công Dịch vụ tìm đường mới, chúng ta tiến hành thử nghiệm trên ứng dụng nền tảng web và nền tảng di động của VMap. Kết quả di chuyển thực tế được trình bày ở Bảng 4.2.
Hình 4.6. Thử nghiệm tìm đường tương tự trên nền tảng Google Map
Bảng 4.2. Kết quả thử nghiệm thực tế
Google Map VMap cũ Vmap mới Thực tế
144 Xuân Thủy → 716 Láng 17 phút 10 phút 17 phút 17 phút 302 Láng → 275 Nguyễn
Trãi
6 phút 7 phút 6 phút 6 phút
144 Xuân Thủy → 10 Thụy Khuê
Sau khi tiến hành thử nghiệm em nhận thấy thời gian phản hồi của dịch vụ còn chậm. Cụ thể là khoảng 3 giây với yêu cầu tìm đường cho 1 tuyến đường và 8 giây cho một yêu cầu. Chậm hơn rất nhiều so với chỉ khoảng 1 giây cho cả 2 yêu cầu trên khi sử dụng dịch vụ cũ. Lý do của việc này là do quá trình tách đặc trưng từ ảnh Google Traffic Tile tốn rất nhiều thời gian để xử lý. Ngoài ra, thời gian xử lý này còn phụ thuộc của tuyến đường tìm được. Đây là một vấn đề cần giải quyết trong tương lai.
CHƯƠNG 5. KẾT LUẬN VÀ ĐỊNH HƯỚNG
Kết quả đạt được