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.