xây dựng ứng dụng tra cứu thông tin tìm đường xe buýt kết hợp nhận diện giọng nói

LỜI CẢM ƠN
Trong suốt quá trình học tập và hoàn thành luận văn này, tôi đã nhận được rất
nhiều sự quan tâm, sự hướng dẫn, giúp đỡ quý báu của quý Thầy, Cô, gia đình và bạn
bè.
Với lòng kính trọng và biết ơn sâu sắc, tôi xin được bày tỏ lời cảm ơn chân thành
tới Th.s Đặng Nhân Cách, người thầy kính mến đã hết lòng giúp đỡ, dạy bảo, hướng
dẫn và tạo mọi điều kiện thuận lợi cho tôi trong suốt quá trình nghiên cứu tìm hiểu để
hoàn thành luận văn.
Tiếp theo, tôi cũng xin chân thành cám ơn quý Thầy, Cô trong khoa Công Nghệ
Thông Tin, đặc biệt là chuyên nghành Mạng Máy Tính và Truyền Thông đã tạo rất
nhiều điều kiện để tôi học tập.
Cuối cùng con xin gửi lời biết ơn tới gia đình, nơi đã sinh thành, nuôi dưỡng và
động viên con rất nhiều trong thời gian qua.
Mặc dù tôi đã có nhiều cố gắng để hoàn thành luận văn bằng tất cả sự nhiệt tình
và năng lực của mình, tuy nhiên do trình độ lý luận cũng như kinh nghiệm thực tiễn
còn hạn chế nên bài báo cáo không thể tránh khỏi những thiếu sót, tôi rất mong nhận
được những đóng góp quý báu của quý Thầy, Cô để tôi có thể có thêm kinh nghiệm rút
ra cho bản thân.
TP.HCM, ngày 22 tháng 12 năm 2013
Sinh viên thực hiện
Đỗ Minh Tuấn
LỜI CAM ĐOAN
Tôi xin cam đoan rằng đây là luận văn tốt nghiệp của riêng tôi dưới sự hướng dẫn
trực tiếp của Th.S Đặng Nhân Cách. Những tài liệu và bảng biểu phục vụ cho việc
phân tích, nhận xét, đánh giá được tôi thu thập từ các nguồn khác nhau được trích dẫn
rõ ràng có ghi trong phần “Tài liệu tham khảo“ và không hề sao chép nội dung từ bất
kỳ đồ án nào khác.
Nếu phát hiện có bất kỳ sự gian lận nào tôi xin hoàn toàn chịu trách nhiệm trước
Hội đồng, cũng như kết quả luận văn của mình.
TP.HCM, ngày 22 tháng 12 năm 2013
Sinh viên thực hiện

Đỗ Minh Tuấn
MỤC LỤC
3
DANH MỤC CÁC TỪ VIẾT TẮT
Từ viết tắt Ý nghĩa
API Application Programming Interface
GPS Global Positioning System
HTTP HyperText Transfer Protocol
JSON JavaScript Object Notation
UI User Interface
XML Xtensible Markup Language
4
DANH MỤC HÌNH ẢNH
5
LỜI MỞ ĐẦU
1. Tính cấp thiết của đề tài:
Trong giao thông công cộng có rất nhiều loại phương tiện như xe đạp, xe máy…
và đặc biệt là xe buýt. Mục tiêu của TP.HCM là phát triển hệ thống xe buýt làm nền
tảng cho sự phát triển bền vững hệ thống giao thông công cộng, thu hút người dân đi xe
buýt, góp phần giảm ùn tắt giao thông, tạo nếp sống văn minh đô thị.
Hiện nay nhu cầu tìm đường đi và thông tin các tuyến xe buýt của hành khách,
đặc biệt là sinh viên đang rất cần thiết, tuy nhiên công cụ hỗ trợ cho nhu cầu này hiện
nay là rất ít và chưa được hoàn hảo.
Với nhu cầu đó, đề tài “Xây dựng ứng dụng tra cứu thông tin, tìm đường xe
buýt kết hợp nhận diện giọng nói” đã được chọn để nghiên cứu, tìm hiểu. Đề tài xây
dựng một ứng dụng cung cấp một số chức năng hỗ trợ người tham gia xe buýt như tìm
đường đi chính xác, trực quan trên bản đồ, xem thông tin lộ trình xe buýt, giá, khoảng
cách, tìm các trạm xe xung quanh vị trí của mình và đặc biệt là ứng dụng còn hỗ trợ
người dùng sử dụng giọng nói trong việc tìm kiếm đường đi.
2. Tình hình nghiên cứu:

Vấn đề ứng dụng tra cứu, tìm kiếm xe buýt đã xuất hiện trên nền tảng web như
trên trang của sở giao thông vận tải TP.HCM, tuy nhiên trên nền
tảng thiết bị di động Android thì vẫn còn ít và chưa đầy đủ các tính năng cần thiết.Ứng
dụng của chính Google thì dữ liệu xe buýt đã cũ, các tuyến mới chưa được cập nhật
nên đã gây khó khăn cho người sử dụng.
Điển hình ứng dụng trên nền tảng di động Android đó là ứng dụng Pbus của một
nhóm sinh viên Đại Học Bách Khoa TP.HCM. Trên nền tảng Ios thì có ứng dụng
IUBUS của sinh viên trường Đại Học Khoa Học Tự Nhiên TP.HCM.
6
3. Mục đích nghiên cứu:
Đề tài được xây dựng nhằm tạo ra một ứng dụng hữu ích, hỗ trợ đặc biệt cho sinh
viên, người dân khi đi xe buýt để đảm bảo những thông tin chính xác, nhanh chóng, tiết
kiệm chi phí, thời gian cho người dùng, đặc biệt có thể góp phần thu hút người dân đi
xe buýt.
Người dùng có thể chủ động thiết lập địa điểm để thông báo khi gần đến để tránh
đi quá lộ trình cần đi, đồng thời ứng dụng còn sử dụng hệ thống nhận diện giọng nói để
hỗ trợ người dùng khi không thể thao tác bằng tay.
4. Nhiệm vụ nghiên cứu:
- Khảo sát lộ trình của các tuyến xe buýt trong Thành Phố Hồ Chí Minh.
- Khảo sát tọa độ của từng trạm của các tuyến xe buýt.
- Tìm kiếm, lựa chọn và so sánh để đưa ra các tuyến đường tốt nhất.
- Hiển thị những cảnh báo khi người dùng gần tới hoặc khi đi xa địa điểm cần
thiết.
- Hỗ trợ nhận diện giọng nói cho người dùng khi không thể thao tác bằng tay.
5. Phương pháp nghiên cứu:
- Tham khảo dữ liệu các tuyến xe buýt, các trạm xe buýt cùng các tọa độ của các
trạm trên website của sở giao thông vân tải TP.HCM.
- Tham khảo tài liệu giấy từ nguồn luận văn của thư viện trường.
- Tham khảo các lý thuyết cơ bản của Android thông qua các API được Google
đưa lên chính website của mình.

- Phần mềm của nhóm tự động lưu dữ liệu xe buýt từ trang web của sở giao thông
vận tải về cơ sở dữ liệu.
7
- Thử nghiệm dữ liệu hiển thị trên điện thoại di động Android.
6. Các kết quả đạt được của đề tài:
- Hiển thị thông tin dữ liệu của tất cả các tuyến xe buýt trong TP.HCM như lượt
đi, lượt về, giá vé…
- Xem lộ trình của tuyến xe trực quan trên bản đồ.
- Bắt vị trí hiện tại bằng GPS hoặc mạng.
- Chức năng xem nhanh các trạm quanh vị trí hiện tại hoặc một điểm trên bản đồ.
- Tính toán địa chỉ hiện tại, cung cấp thông tin độ chính xác và nguồn lấy vị trí
hiện tại.
- Tìm kiếm giữa 2 địa điểm, kết quả trả về ưu tiên chuyển tuyến ít nhất, thời gian
ít nhất và khoảng cách ngắn nhất.
- Chia sẻ kết quả tìm kiếm hoặc dữ liệu xe buýt thông qua tin nhắn, mail hoặc các
mạng xã hội như Facebook.
- Hỗ trợ tìm kiếm lộ trình xe buýt, các trạm dừng và đường đi xe buýt giữa 2
điểm bằng giọng nói.
7. Kết cấu của Luận Văn Tốt Nghiệp
Luận Văn Tốt Nghiệp bao gồm 4 chương, tên của từng chương như sau:
Chương 1: Kiến thức nền tảng.
Nội dung chương 1 trình bày các khái niệm của hệ điều hành Android, kiến thức,
lý thuyết cơ bản, các công nghệ và cơ sở dữ liệu nhằm để xây dựng ứng dụng.
Chương 2: Phân tích xây dựng ứng dụng.
Nội dung chương 2 trình bày các bước để xây dựng, phân tích mô tả ứng dụng,
các yêu cầu tính năng cần thiết của ứng dụng, cơ sở dữ liệu và các biểu đồ.
8
Chương 3: Kết quả xây dựng ứng dụng.
Nội dung chương 3 trình bày các vấn đề khi xây dựng ứng dụng, kết quả các tính
năng chính của ứng dụng, kiểm tra và đánh giá ứng dụng.

Chương 4: Kết luận.
Nội dung chương 4 trình bày các kết quả đạt được của ứng dụng, ưu điểm và
nhược điểm của ứng dụng, hướng phát triển của ứng dụng.
9
CHƯƠNG 1: KIẾN THỨC NỀN TẢNG
1.1. Hệ điều hành Android
Android là một hệ điều hành dựa trên nền tảng Linux thiết kế dành cho các thiết
bị di động có màn hình cảm ứng như điện thoại thông minh và máy tính bảng.
Ban đầu, Android được phát triển bởi Tổng công ty Android, với sự hỗ trợ tài
chính từ Google và sau này được chính Google mua lại vào năm 2005. Android ra mắt
vào năm 2007 và chiếc điện thoại đầu tiên chạy Android được bán vào tháng 10 năm
2008
[2]
.
Android có mã nguồn mở và Google phát hành mã nguồn theo giấy phép Apache.
Chính mã nguồn mở cùng với một giấy phép không có nhiều ràng buộc đã cho phép
các nhà phát triển thiết bị mạng di động và các lập trình viên nhiệt huyết được điều
chỉnh và phân phối Android một cách tự do.
Ngoài ra, Android còn có một cộng đồng lập trình viên đông đảo, chuyên viết các
ứng dụng để mở rộng chức năng của thiết bị, bằng một loại ngôn ngữ lập trình Java.
Vào tháng 10 năm 2012, có khoảng 700.000 ứng dụng trên Android và số lượt tải ứng
dụng từ Google Play ước tính khoảng 25 tỷ lượt
[2]
.
Những yếu tố này đã giúp Android trở thành nền tảng điện thoại thông minh phổ
biến nhất thế giới, vượt qua Symbian vào quý 4 năm 2010, và được các công ty công
nghệ lựa chọn khi họ cần một hệ điều hành không nặng nề, có khả năng tinh chỉnh, và
giá rẻ chạy trên các thiết bị công nghệ cao thay vì tạo dựng từ đầu.
Bản chất mở của Android cũng khích lệ một đội ngũ đông đảo lập trình viên và
những người đam mê sử dụng mã nguồn mở để tạo ra những dự án do cộng đồng quản

lý.
10
Những dự án này bổ sung các tính năng cao cấp cho những người dùng thích tìm
tòi hoặc đưa Android vào các thiết bị ban đầu chạy hệ điều hành khác.
1.1.1. Những đặc trưng của hệ điều hành Android
- Application framework: cho phép sử dụng lại và thay thế các thành phần trong
lập trình ứng dụng.
- Dalvik virtual machine: tối ưu hóa cho thiết bị di động.
- Intergrated browser: trình duyệt tích hợp, dựa trên cơ chế WebKit mã nguồn mở.
- SQLite: cơ sở dữ liệu trong môi trường di động.
- Media support: hỗ trợ các định dạng audio, video và hình ảnh thông dụng.
- GSM Telephony: mạng điện thoại di động (phụ thuộc vào phần cứng).
- Bluetooth, EDGE, 3G, và WiFi :các chuẩn kết nối dữ liệu (phụ thuộc vào phần
cứng).
- Camera, GPS, la bàn, và gia tốc kế: (phụ thuộc vào phần cứng).
1.1.2. Các tính năng trong hệ điều hành Android
Các tính năng được hổ trợ tùy thuộc vào cấu hình phần cứng và phần mềm.
- Storage: Sử dụng SQLite, một cơ sở dữ liệu quan hệ nhẹ cho việc lưu trữ dữ
liệu.
- Connectivity: Hỗ trợ GSM/EDGE, IDEN, CDMA, EV-DO, UMTS, Bluetooth
(bao gồm AD2P và AVRCP), Wifi, LTE và WiMAX.
- Messaging: hỗ trợ cả SMS và MMS.
- Web browser: Dựa trên mã nguồn mở Webkit, cùng với công nghệ JavaScript
V8 của Chrome.
11
- Hardware support: Accelerometer Sensor, Camera, Digital Compass, Proximity
Sensor và GPS.
- Multi-touch: Hỗ trợ màn hình cảm ứng đa điểm.
- Multi-tasking: Hỗ trợ ứng dụng đa tác vụ.
1.1.3. Kiến trúc ứng dụng trongAndroid

Mô hình sau thể hiện đầy đủ kiến trúc các thành phần của hệ điều hành Android
Hình 1.1: Kiến trúc và các thành phần của hệ điều hành Android
[8]
Linux kernel (nhân Linux)
Kernel Linux hoạt động như một lớp trừu tượng hóa giữa phần cứng và tầng dưới
của phần mềm. Lớp này chứa tất cả các thiết bị mức thấp điều khiển các thành phần
phần cứng khác nhau của một thiết bị Android.
12
Libraries
Libraries bao gồm một tập hợp các thư viện lập trình chứa mã lệnh cung cấp
những tính năng và thao tác chính trên hệ điều hành. Các thư viện được tập hợp thành
một số nhóm như: System C Library, Media Libraries, LibWebCore, Surface Manager,
SGL, SQLite, Free Type, SSL, Open GL/EL.
Android runtime
Tại cùng một tầng với Libraries, Android runtime cung cấp một bộ lõi thư viện
cho phép các nhà phát triển viết các ứng dụng android bằng cách sử dụng ngôn ngữ lập
trình java. Tầng này có 2 bộ phận bao gồm thư viện lõi (Core Library) và một máy ảo
java tên là Davik (Davik Virtual Machine).
Framework
Android cung cấp cho các nhà phát triển khả năng xây dựng các ứng dụng cực kỳ
phong phú và sáng tạo. Cơ bản tất cả các ứng dụng là một bộ các dịch vụ và các hệ
thống, bao gồm các View, Content Provider, Resource Manager, Notification Manager,
Activity Manager.
Applications
Đây là lớp ứng dụng giao tiếp với người dùng. Các ứng dụng cho android cũng
như các ứng dụng được tải về và cài đặt từ AndroidMarket hay bất kỳ ứng dụng nào
được viết được tại tầng này.
Các ứng dụng phải viết bằng Java và có phần mở rộng là .apk. Khi mỗi ứng dụng
được chạy, nó có một máy ảo Davik được dựng lên để phục vụ cho nó.
1.1.4. Các khái niệm cơ bản trong lập trình Android

Activity
Activity là một thành phần rất quan trọng của bất kỳ ứng dụng Android nào.
13
Một activity thể hiện một giao diện đồ họa người dùng. Mỗi activity là một lớp
con của lớp cơ sở Activity. Lớp Activity đảm nhận việc tạo ra một cửa sổ (window) để
người lập trình đặt lên đó một giao diện UI.
Một Activity có thể mang nhiều dạng khác nhau: một cửa sổ toàn màn hình (full
screen window), một cửa sổ floating (với windowIsFloating) hay nằm lồng bên trong
một Activity khác (với ActivityGroup)
[8]
.
Sau đây là sơ đồ các sự kiện trong vòng đời của một Activity:
Hình 1.2: Vòng đời của Activity
[7]
14
Service
Service là 1 trong 4 thành phần chạy chính trong 1 ứng dụng Android (Activity,
Service, BroadcastReceiver, ContentProvider).
Một service không có giao diện trực quan, nó chạy trên nền trong một khoảng
thời gian không xác định.
Trong khi kết nối, người sử dụng có thể giao tiếp với service thông qua giao diện
mà service đó trưng ra.
Sơ đồ các sự kiện trong vòng đời của một service:
Hình 1.3: Vòng đời của Service
[8]
15
Content provider
Một content provider tạo ra một tập cụ thể các dữ liệu của ứng dụng khả dụng cho
các ứng dụng khác. Dữ liệu có thể được lưu trữ trong hệ thống file, trong một cơ sở dữ
liệu SQLite.

Broadcast Receive
Một Broadcast Receiver là một thành phần không làm gì ngoài việc nhận và đáp
lại các thông báo Broadcast. Nhiều broadcast khởi đầu trong mã hệ thống.
View
Trong một ứng dụng Android, giao diện người dùng được xây dựng từ các đối
tượng View và ViewGroup. Có nhiều kiểu View và ViewGroup. Mỗi một kiểu là một
con của class View và tất cả các kiểu đó được gọi là các Widget.
Hình 1.4: Cấu trúc View trong Android
[7]
16
Intent
Là cầu nối giữa các Activity: Ứng dụng Android thường bao gồm nhiều Activity,
mỗi Activity hoạt động độc lập với nhau và thực hiện những công việc khác nhau.
Intent chính là người đưa thư, giúp các Activity có thể triệu gọi cũng như truyền các dữ
liệu cần thiết tới một Activity khác.
1.2. Cơ sở dữ liệu SQLite
1.2.1. Khái niệm về SQLite
SQLite là hệ thống cơ sở dữ liệu quan hệ nhỏ gọn, hoàn chỉnh được Richard Hipp
viết dưới dạng thư viện bằng ngôn ngữ lập trình C.
SQLite là một bộ thư viện dùng trong lập trình để hiện thực một SQL Database
Engine có khả năng tự tổ chức quản lý dữ liệu, không cần server, không cần cấu hình
mà vẫn hỗ trợ đầy đủ các tính năng quản lý thao tác. SQLite hiện đang là SQL
Database Engine được sử dụng nhiều nhất trên thế giới do tính cơ động cao, dễ sử
dụng, gọn nhẹ, hiệu quả và tin cậy
[7]
.
1.2.2. Ưu điểm của SQLite
SQLite có các ưu điểm sau:
- Tin cậy : Các hoạt động transaction (chuyển giao) trong cơ sở dữ liệu được
thực

hiện trọn vẹn, không gây lỗi khi xảy ra sự cố phần cứng.
- Không cần cài đặt cấu hình.
- Tuân theo chuẩn SQL92.
- Kích thước chương trình gọn nhẹ.
- Không cần phần mềm phụ trợ.
- Phần mềm tự do với mã nguồn mở được chú thích rõ ràng.
17
1.2.3. Nhược điểm của SQLite
Ngoài các ưu điểm kể trên thì SQLite cũng có những nhược điểm sau nếu đem so
sánh với các CSDL mạnh khác như Oracle Database, SQL Server:
- Tính đồng thời: SQLite sử dụng cơ chế khóa Coarse-gained Locking có thể hỗ
trợ nhiều người đọc dữ liệu, nhưng chỉ có một người có thể ghi dữ liệu một lúc mà
thôi.
- Kết nối mạng: Các lỗ hỏng trong việc triển khai các hệ thống tập tin trong môi
trường mạng có thể gây ra nhiều lỗi do các tập tin có thể bị mở và điều chỉnh từ xa.
- Chỉ phù hợp với các ứng dụng có quy mô dữ liệu nhỏ: SQLite không phải là lựa
chọn lý tưởng để đáp ứng các nhu cầu xử lý trên một khối dữ liệu lớn, phát sinh liên
tục.
1.3. Webservice
1.3.1. Khái niệm về Webservice
Webservice là sự kết hợp các máy tính cá nhân với các thiết bị khác, các cơ sở dữ
liệu và các mạng máy tính để tạo thành một cơ cấu tính toán ảo mà người sử dụng có
thể làm việc thông qua các trình duyệt mạng hoặc ứng dụng có kết nối mạng.
Hình 1.5: Webservice
[1]
18
1.3.2. Một số đặc điểm cơ bản của Webservice
Một webservice có thể được truy cập thông qua web.
Một webservice có giao diện dịch vụ. Giao diện này giúp cho webservice có thể
được gọi bởi bất kỳ một ứng dụng nào hay bởi webservice nào khác.

1.3.3. Phân loại Webservice
Dịch vụ ứng dụng và dịch vụ hệ thống (Application and System Service).
Một Application Service thể hiện một hành động của user như duyệt thư email,
hay kiểm tra tỷ số hối đoái. Một System Service thể hiện yêu cầu của kiến trúc hệ
thống và sự quản lý như bảo mật, lưu trữ và chịu lỗi, quản lý transaction hay essaging.
Một dịch vụ có hai đặc điểm chính: Interface và Registration. Sử dụng Interface,
một dịch vụ có thể được gọi từ một chương trình khác. Một Service được đăng ký
trong một Registry.
1.3.4. Ưu và nhược điểm Webservice
Ưu điểm:
- Dịch vụ Web cung cấp khả năng hoạt động rộng lớn với các ứng dụng phần
mềm khác nhau chạy trên những nền tảng khác nhau.
- Sử dụng các giao thức và chuẩn mở. Giao thức và định dạng dữ liệu dựa trên
văn bản, giúp các lập trình viên dễ dàng hiểu được.
- Nâng cao khả năng tái sử dụng.
- Thúc đẩy hệ thống tích hợp, giảm sự phức tạp của hệ thống, hạ giá thành hoạt
động, phát triển hệ thống nhanh và tương tác hiệu quả với hệ thống của các doanh
nghiệp khác.
19
Nhược điểm:
- Những thiệt hại lớn sẽ xảy ra vào khoảng thời gian chết của Dịch vụ Web, giao
diện không thay đổi, có thể lỗi nếu một máy khách không được nâng cấp, thiếu các
giao thức cho việc vận hành.
- Có quá nhiều chuẩn cho dịch vụ Web khiến người dùng khó nắm bắt.
- Phải quan tâm nhiều hơn đến vấn đề an toàn và bảo mật.
1.4. Google Maps API Web Services
1.4.1. Khái niệm Google Map
Google Maps là một dịch vụ ứng dụng và công nghệ bản đồ trực tuyến trên web
miễn phí, được cung cấp bởi Google và hỗ trợ nhiều dịch vụ dựa vào bản đồ như
Google Ride Finder và một số có thể dùng để nhúng vào các trang web của bên thứ ba

thông qua Google Maps API. Nó cho phép thấy bản đồ đường phố, đường đi cho xe
đạp, cho người đi bộ và xe hơi, và những địa điểm kinh doanh trong khu vực cũng như
khắp nơi trên thế giới.
Năm 2006, Google đã giới thiệu một ứng dụng Java có tên là Google Maps for
Mobile. Mục đích để chạy trên bất kỳ thiết bị di động nào có cung cấp nền tảng Java.
Rất nhiều tính năng chính của phiên bản Google Maps trên web có mặt trong ứng
dụng.
1.4.2. Khái niệm Google Maps API Web Services
Google Maps API Web Services là một tập các giao diện HTTP cung cấp thông
tin địa lý cho ứng dụng.
Google Maps API Web Services bao gồm:
• Directions API
• Distance Matrix API
20
• Elevation API
• Geocoding API
• Time Zone API
1.4.3. Sử dụng Google Maps API Web Services
Google Maps API cung cấp các dịch vụ như là các giao diện phục vụ cho việc
yêu cầu dữ liệu địa lý và sử dụng dữ liệu đó trong ứng dụng của nhà phát triền. Các
dịch vụ này được thiết kế để sử dụng với một ứng dụng bản đồ.
Các Google Maps API Web Services sử dụng chuỗi yêu cầu HTTP tới một đường
dẫn URL đặc biệt và gửi các thông số URL tới các services.
URL request thường có dạng như sau:
/>- service: Loại dịch vụ.
- output: Kết quả ở dạng tập tin JSON hay XML.
- parameters: Các tham số phù hợp.
Truy cập SSL
Có thể truy cập Google Maps API Web Services thông qua HTTPS. Truy cập
Google Maps API Web Service thông qua HTTPS được khuyến khích sử dụng nếu ứng

dụng có chứa những dữ liệu nhạy cảm như tọa độ người dùng.
/>Theo dõi sử dụng với tham số sensor
Sử dụng Google Maps API yêu cầu nhà phát triển phải chỉ ra rằng ứng dụng có sử
dụng một cảm biến (ví dụ cảm biến GPS) để xác định vị trí người dùng trong bất cứ
yêu cầu nào cho service. Điều này là đặc biệt quan trọng cho các thiết bị di động.
21
Nếu ứng dụng Google Maps API sử dụng bất cứ dạng cảm biến để xác định vị trí
của thiết bị phải thiết lập giá trị của tham số sensor = true.
Kết quả trả về
Kết quả trả về của Google Direction API khá dễ hiểu nhưng lại ít thân thiện với
người sử dụng. Khi gởi yêu cầu và nhận được kết quả, tốt nhất là không hiển thị tất cả
những gì nhận được mà chỉ cần trích xuất một số thông tin phù hợp. Tóm lại là cần
phải phân tích cú pháp kết quả nhận được và chỉ trích xuất một số thông tin có ích.
1.4.4. Google Geocoding API
Mã hóa địa lý là gì
Mã hóa địa lý là quá trình chuyển địa chỉ sang tọa độ địa lý để đánh dấu trên bản
đồ. Có thể mô tả mã hóa địa lý giống như chuyển đổi từ “Ngã tư hàng xanh” qua tọa
độ địa lý bao gồm vĩ độ 10.802740 và kinh độ 106.695590.
Ngoài ra dich vụ Google Geocoding API còn cho phép giải mã từ tọa độ địa lý
sang địa chỉ cụ thể.
Google Geocoding API cung cấp một phương thức trực tiếp để truy cập bộ mã
hóa địa lý thông qua giao thức HTTP.
Giới hạn sử dụng
Google Geocoding API giới hạn ở 2.500 truy vấn mỗi ngày. Nếu trả phí con số
này tăng lên 100.000 truy vẫn mỗi ngày. Các giới hạn này được đặt ra để ngăn chặn sự
lạm dụng dịch vụ. Nếu vượt quá giới hạn này ứng dụng sẽ không thể truy cập được sau
24 giờ, nếu tiếp tục vượt ở 24 giờ tiếp theo thì dịch dụ Geocoding API có thể sẽ chặn
ứng dụng.
22
Geocoding API request

Chuỗi request URL thường có dạng như sau:
/>HTTPS được khuyến cáo sử dụng cho các ứng dụng có dùng những dữ liệu nhạy
cảm của người dùng:
/>Output có thể là xml hoặc json.
- Tham số của chuỗi request URL:
Một số tham số là bắt buộc phải được gán giá trị, một số là tùy chọn. Trong một
chuỗi URL hợp chuẩn mỗi tham số được phân cách bằng ký tự (&).
• address(bắt buộc): Địa chỉ muốn mã hóa địa lý.
• latlng(bắt buộc): Giá trị kinh độ - vĩ độ của điểm muốn lấy địa chỉ gần
nhất.
• region(tùy chọn): Mã vùng, dùng hệ thống tên miền quốc gia.
• language(tùy chọn): Thiết lập ngôn ngữ sẽ trả về trong kết quả.
• sensor(bắt buộc): Cho biết yêu cầu tìm đường có phải đến từ một thiết bị
có cảm biến vị trí hay không. True hoặc false.
Kết quả mã hóa địa lý
Geocoding API sẽ trả về một trong hai loại tập tin là JSON hoặc XML.
Chuỗi request URL:
/>%20chieu&sensor=false&language=vi-VI
Cấu trúc tập tin trả về có hai phần tử gốc:
23
• status: Thông báo trạng thái của kết quả.
• result: Chứa một tập thông tin kết quả.
- Thẻ status có các trạng thái sau:
• OK: Kết quả trả về bình thường.
• ZERO_RESULTS: Địa chỉ không tồn tại hoặc giá trị kinh độ - vĩ độ không
đúng.
• OVER_QUERY_LIMIT: Thông báo đã gởi quá số lượng yêu cầu trong một
khoảng thời gian.
• REQUEST_DENIED: Ứng dụng đã bị dịch vụ Google Geocoding API
chặn.

• INVALID_REQUEST: Thông báo chuỗi request URL không hợp lệ.
- Thẻ result có các trạng thái sau:
• type[]: Một tập thẻ type cho biết kiểu của kết quả trả về. Chứa một hay
nhiều kiểu của địa danh, ví dụ khi mã hóa địa lý Ngã tư hàng xanh sẽ trả
về hai giá trị type là political và locality.
• formatted_address: Địa chỉ bằng chữ.
• address_component[]: Chứa một mảng các thành phần địa lý.
- Mỗi thẻ address_component chứa:
• type[]: Kiểu của thành phần địa lý.
• long_name: Tên đầy đủ của thành phần địa lý.
• short_name: Tên viết tắt của thành phần địa lý.
24
- Các giá trị của type:
• street_address: Địa chỉ đường.
• route: Địa chỉ tuyến đường (chỉ có ở Mĩ).
• intersection: Ngã tư lớn, giao nhau giữa hai con đường chính.
• political: Địa chỉ hành chính.
• country: Quốc gia, là địa chỉ cấp cao nhất.
• administrative_area_level_1: Địa chỉ hành chính cấp 1 dưới cấp quốc gia,
ở Việt Nam là tỉnh hoặc các thành phố trực thuộc Trung ương, ở Mỹ là
bang.
• administrative_area_level_2: Địa chỉ hành chính cấp 2 dưới cấp quốc gia.
Ở Việt Nam là các quận của thành phố trực thuộc Trung ương.
• administrative_area_level_3: Địa chỉ hành chính cấp 3 dưới cấp quốc gia.
Chỉ có ở Mỹ và một số quốc gia.
• locality: Thành phố hoặc thị xã.
• sublocality: Địa chỉ hành chính dưới cấp locality.
• neighborhood: Khu phố.
• premise: Một địa điểm được đặt tên, thường là một tòa nhà hoặc một cụm
các tòa nhà được đặt chung tên.

• subpremise: Cấp dưới của premise, thường là một tòa nhà nằm trong một
cụm được đặt tên.
• postal_code: Mã bưu chính.
Kết quả hiển thị XML
25