.1 Sơ đồ luồng dữ liệu

Hình III-22: Sơ đồ luồng dữ liệu của hệ thống III.3.2Mô tả hoạt động

Người sử dụng phía client đưa ra yêu cầu – request của họ (có thể là một yêu cầu về bản đồ hoặc yêu cầu về tìm kiếm, request này được đưa đến lớp AS. Lớp AS sẽ phân tích request, xem request của người sử dụng thuộc dạng nào (request về bản đồ hay request về dịch vụ định vị, tìm đường) rồi đưa đến dịch vụ thích hợp ở lớp DataService. Dịch vụ thích hợp ở lớp DataService sẽ tiến hành thực thi request và vào database để lấy về dữ liệu thích hợp. Dữ liệu lấy về từ Database được đưa trở lại lớp Dataservice, từ lớp DataService lại đưa trở lại lớp AS để biến đổi cho phù hợp với yêu cầu dữ liệu đầu ra ở phía client. Phía client nhận được kết quả trả về sẽ hiển thị kết quả đến người sử dụng. Cụ thể:

 Lớp Database: Lớp Database lưu trữ toàn bộ cơ sở dữ liệu của hệ thống, bao gồm cơ sở dữ liệu cho dịch vụ bản đồ nền, dịch vụ định tuyến tối ưu (Route) và dịch vụ Geocode.

 Lớp dịch vụ: Lớp Data Service bao gồm các application server cung cấp dịch vụ cho hệ thống. Dịch vụ bản đồ thông qua chuẩn WFS của OGC, dịch vụ Route và Geocode cũng được thực thi theo chuẩn OpenLS của OGC. Tại lớp này dữ liệu được trả về theo định dạng GML/XML.

 Lớp Application Server (AS): Lớp AS có nhiệm vụ nhận các request tạo ra từ phía client, phân tích request, đọc metadata của hệ thống, đưa/tạo request đến các dịch vụ tương ứng, nhận dữ liệu trả về từ các dịch vụ và tiến hành xử lý dữ liệu đưa về phía client để hiển thị/xử lý. Trong thực thi của lớp AS bao gồm phần thực thi dịch vụ OpenLS Presentation Service của OGC.

 Lớp ứng dụng phía Client: Lớp ứng dụng phía client có nhiệm vụ đáp ứng các tương tác của người dùng, tạo request đưa đến lớp AS, nhận dữ liệu được trả về từ AS, hiển thị dữ liệu đến người dùng. Dữ liệu được đưa về phía Client theo định dạng SVG/XML.

Request

Client AS Data Service Database

Request

Response Response

Response

Formatted: Dutch (Netherlands)

III.3.3Các quy định chung trong thiết kế hệ thống

 Từng module trong hệ thống vừa có chức năng phân tích request và có chức năng phân tích response trả về, vì vậy cần đảm bảo:

 Tính chính xác của thông tin

 Tính ổn định và liên tục của hệ thống

 Ngoài ra trong thiết kế hệ thống cũng phải tuân thủ các nguyên tắc của phát triển phần mềm nói chung: tính tiện dụng, tính module hóa cáo, tính mở, tính bảo mật

III.4 Mô tả các module trong hệ thống

III.4.1Thiết kế hệ thống cơ sở dữ liệu

Với ứng dụng GIS cho máy PC chúng ta có thể đưa về lượng dữ liệu lớn để hiển thị bản đồ thích hợp trên màn hình PC. Nhưng nếu đưa cùng một lượng dữ liệu như vậy để hiển thị trên màn hình nhỏ của thiết bị di động thì rất lãng phí đường truyền và mất nhiều thời gian xử lý dữ liệu để phía thiết bị di động hiển thị bản đồ. Vì vậy vấn đề đặt ra là làm sao để thiết kế được hệ cơ sở dữ liệu thích hợp cho việc hiển thị dữ liệu bản đồ trên thiết bị di động ở từng mức độ khung nhìn khác nhau để đảm bảo có thể hiển thị dữ liệu ở các thiết bị khác nhau.

III.4.2Thiết kế lớp dịch vụ 2.5.2.1. Tổng quan 2.5.2.1. Tổng quan

Lớp dịch vụ có nhiệm vụ lấy ra dữ liệu phù hợp với yêu cầu. Để dễ dàng truy nhập đến dữ liệu bản đồ, hệ thống sử dụng giao diện truy vấn chuẩn WFS. Có một số dự án nguồn mở và một số nhà cung cấp dịch vụ GIS thương mại thực thi tiêu chuẩn này.Hình III.3Hình III.3 minh họa kiến trúc bên trong của một node WFS [20].

Hình III.33. Kiến trúc bên trong của node WFS

Web Server

Thực thi WFS Lưu trữ dữ liệu

bên trong

http request đi vào http respond đi ra Truy vấn WFS dưới dạng XML Kết quả trả về dưới dạng GML

Truy vấn được chuyển thành ngôn ngữ truy vấn bên trong

Kết quả trả về dưới dạng tập kết quả theo truy vấn bên trong

Formatted: Dutch (Netherlands)

2.5.2.2.Thực thi dịch vụ WFS

Thực thi WFS (hay các dịch vụ khác của OGC [11]) yêu cầu tạo ra tài liệu XML phù hợp với OGC. Mỗi dịch vụ có một tập lược đồ XML định nghĩa cách diến tả dịch vụ mà nó cung cấp các khả năng của dịch vụ. Chúng ta sử dụng các lược đồ này để ràng buộc dữ liệu, tạo tài liệu XML và đảm bảo các tài liệu này là phù hợp với chuẩn. Sự liên kết giữa các lược đồ của OGC được minh họa trong Hình III.4Hình III.4

Hình III.44. Sự liên kết giữa các lƣợc đồ của OGC

WFS định nghĩa một số các dạng Request như ở bảng sau:

Request Ý nghĩa

GetCapabilities WFS mô tả khả năng của mình bằng một tài liệu XML. Request dạng này sẽ trả về tài liệu này.

DescribeFeatureType WFS có thể tạo ra cơ chế mô tả các loại Feature dịch vụ có

GetFeature Cho phép nhận về các đặc tính theo định dạng XML GetFeatureWithLock Có chức năng tương tự như GetFeature, ngoại trừ request

này chỉ ra rằng WFS phải khóa các Feature được chọn LockFeature Mục đích của Request này là đưa ra cơ chế khóa Feature

để đảm bảo tính nhất quán

Transaction Hoạt động chuyển đổi dữ liệu được sử dụng cho các thể hiện của các Feature truy nhập web.

Bảng III-11 Một số dạng Request trong WFS

Formatted: Dutch (Netherlands)

Trong hệ thống dịch vụ của chúng ta chỉ thực thi những giao diện cơ bản của WFS (Basic WFS). Những giao diện này bao gồm GetCapabilities, DescribeFeatureType và GetFeature.

Một trong những thách thức trong thực thi WFS của OGC là có thể tạo ra và phân tích tài liệu XML có Filter. Filter được dùng để định nghĩa các ràng buộc trong câu truy vấn. GetFeature (và GetFeatureWithLock) có thành phần <Query> trong đó có thể có thành phần <Filter> để ràng buộc truy vấn. Nếu không có thành phần

<Filter> trong <Query> thì truy vấn không bị ràng buộc và tất cả các thể hiện của Feature nên được trả về. Filter có thể được dùng để đưa ra cả các ràng buộc không gian và ràng buộc phi không gian trong câu lệnh truy vấn.

Filter có thể bao gồm một toán tử thuộc một trong ba loại sau:

 Toán tử không gian

 Toán tử so sánh

 Toán tử logic

2.5.2.3.Module định vị (geocoding [28])

 Khả năng thực hiện geocode

Hệ thống thực hiện các kiểu chức năng định vị sau: - Định vị vùng quản lý hành chính thích hợp. - Định vị mã bưu điện thích hợp.

- Định vị đường phố thích hợp. - Định vị giao nhau của đường phố.

- Định vị các vị trí theo yêu cầu người sử dụng (point of interest).

 Định vị vùng quản lý hành chính thích hợp

Nếu thông tin vùng quản lý như settlement, municipality và region được chỉ ra và không có các thông tin như đường phố hay tên của POI, geocoder thực hiện chức năng định vị vùng quản lý hành chính thích hợp.

Một câu lệnh SQL được gửi đến bảng GC_AREA để tìm kiếm vùng thích hợp với dữ liệu đầu vào. Nếu không có một mã bưu điện nào phù hợp thì kết quả trả về là vùng thích hợp. Ngược lại nếu có một mã bưu điện thì chức năng định vị mã bưu điện được thực thi. Kết quả của quá trình định vị này được so sánh với kết quả của quá trình định vị vùng quản lý thích hợp. Kết quả trả về là các kết quả phù hợp với cả hai quá trình định vị trên. Kết quả của quá trình định vị vùng thích hợp sẽ được trả về nếu nó khác rỗng và ngược lại.

 Định vị mã bƣu điện

Nếu đầu vào chỉ có thông tin mã bưu điện mà không có các thông tin khác như đường phố, tên của POI thì Geocoder thực hiện định vị mã bưu điện. Một câu lệnh SQL được gửi đến GC_POSTAL_CODE để tìm ra trung tâm của mã bưu điện và các

Formatted: Dutch (Netherlands)

 Định vị địa chỉ đƣờng phố:

Geocoder có thể thực hiện thuật toán matching dựa trên thông số chính xác mà người dùng đã nhập vào đối tượng địa chỉ:

EXACT: Tất cả các trường phải chính xác hoàn toàn.

RELAX_STREET_TYPE: Kiểu đường phố có thể khác với tên chính thức. RELAX_POI_NAME: Tên của POI không cần phải chính xác hoàn toàn. RELAX_HOUSE_NUMBER: Số nhà và kiểu đường phố không cần phải chính xác.

RELAX_BASE_NAME: Tên cơ sở, số nhà và kiểu đường phố không cần phải chính xác.

RELAX_POSTAL_CODE: mã bưu điện, tên cơ sở, số nhà và kiểu đường phố khong cần phải chính xác.

RELAX_MUNICIPALITY: tìm địa chỉ bên ngoài thành phố nhưng trong cùng một quốc gia và chứa cả RELAX_POSTAL_CODE.

RELAX_ALL: giống với RELAX_MUNICIPALITY

Ngay cả khi tiêu chí relax không được xác định, bộ định vị cố gắng tìm kiếm kết quả thích hợp nhất hay gần thích hợp nhất dựa trên số lượng ký tự không chính xác để xác định kết quả thích hợp nhất. Bộ định vị có thể trả về nhiều kết quả được sắp xếp theo thứ tự của tính chính xác.

 Thuật toán

 Tìm kiếm thành phố

Với thông tin settlement, municipality, region và mã bưu điện, đầu tiên chức năng định vị vùng quản lý được thực hiện để tìm ra thành phố nơi mà chứa đường phố cần tìm. Tùy thuộc vào từng nước mà cần thông tin settlement hoặc municipality hay cả hai thông tin này để tìm kiếm.

 Tìm đƣờng phố trong thành phố

Một câu lệnh query được gửi đến GC_ROAD để xác định đường phố có tên với dữ liệu đầu vào trong thành phố. Thuộc tính base_name là tiêu chí tìm kiếm cơ sở. Id của vùng thích hợp với thành phố trong bước tìm thành phố để hạn chế tìm kiếm đường phố trong thành phố. Nếu thành phố thích hợp là municipality thì một municipality_id được sử dụng trong tiêu chí tìm kiếm và ngược lại. Nếu không tìm thấy đường phố thì trung tâm của thành phố được trả về.

Nếu tìm thấy đường phố, sử dụng id của đường phố tìm được từ GC_ROAD, một câu lệnh query được gửi tới GC_ROAD_SEGMENT để tìm các đoạn phố trên đường phố đã tìm được. Chỉ số đường phố trên một đoạn phố được xác định bởi giải chỉ số đường phố trên đoạn phố đó.

Nếu không tìm thấy số nhà cho trước trên đường phố thì kết quả trả về là trung tâm đường phố. Kết quả trả về bao gồm thông tim về số nhà trung tâm, tọa độ, mã bưu điện, các thông tin này được lưu trong bảng GC_ROAD.

 Định vị số nhà:

Một khi đã xác định được đoạn phố chứa địa chỉ tìm kiếm, áp dụng tính toán nội suy tịnh ttiến để tìm ra chính xác tọa độ lat/lon của vị trí đó. Quá trình tính toán dựa trên phần trăm của chỉ số địa chỉ đoạn phố thuộc vào giải địa chỉ.

%=abs(số nhà – sốnhà đầu)/(sốnhà cuối – số nhà đầu)

 Định vị điểm giao nhau của phố:

Kiểu đối tượng SDO_GEO_ADDR chứa một trường gọi là INTERSECTSTREET. Nếu trường này có giá trị khác null thì bộ định vị sẽ bỏ qua tất cả số nhà trong trường số nhà để tìm kiếm điểm giao nhau của phố.

Đầu ra của phép tìm kiếm này là một địa chỉ đường phố chính xác về tọa độ lat/lon. Đường phố trong trường đường phố được sử dụng như là tham chiếu cơ sở và số nhà sẽ được đặt vào một trong những điểm phố giao nhau.

 Định vị POI:

Nếu người dùng nhập vào một tên chứa trường địa chỉ thì chương trình sẽ thực thi tìm kiếm POI. Tên này sẽ được tìm từ bảng GC_POI để tìm ra được POI yêu cầu.

Thông tin vùng quản lý hoặc/và mã bưu điện là tùy chọn nhưng đó là thông tin cần thiết để tăng tốc độ quá trình xử lý.

2.5.2.4.Module tìm đƣờng (routing)

Dịch vụ tìm đường xác định tuyến đường đi ngắn nhất cho người sử dụng. Người sử dụng phải đưa vào điểm bắt đầu (thường là một địa điểm/địa chỉ xác định hay từ một điểm click trên bản đồ) và điểm đích (có thể là bất kỳ vị trí nào, ví dụ một nơi mà họ chỉ có địa chỉ đường phố hay là một địa điểm có được từ dịch vụ Directory Service). Module tìm đường sẽ chỉ ra tuyến đường ngắn nhất từ điểm bắt đầu đến điểm đích tới người sử dụng cùng những chỉ dẫn đường đi cụ thể.

III.4.3Thiết kế lớp Application Server (AS) 2.5.3.1. Tổng quan

Lớp AS giữ hai nhiệm vụ trong hệ thống. Nhìn từ phía client lớp Portal cung cấp các giao diện truy vấn metadata để hỗ trợ các thông tin cấu hình động cho ứng dụng phía client. Lớp AS cũng có nhiệm vụ giao tiếp trực tiếp với thông tin bản đồ hiển thị bằng cách cung cấp sự thực thi các giao diện để hiển thị bản đồ như OpenLS Presentation Service. Lớp AS thiết lập điểm truy nhập chính đến platform của hệ thống vì vậy cung cấp một số tài liệu và hướng dẫn người dùng cơ bản khi hình thành việc quản lý website. Nhìn từ phía dịch vụ Application Service, lớp AS làm việc như một lớp ảo riêng biệt bao phủ lên nhiệm vụ của lớp dịch vụ. Sự tách biệt hai nhiệm vụ này trong hệ thống rất quan trọng trong việc linh hoạt cho hệ thống dịch vụ. Việc module hóa tăng lên cũng đồng nghĩa với việc duy trì, bảo dưỡng ứng dụng dễ dàng hơn. Khi cách thực thi thì các nhiệm vụ này có thể được tổ hợp với nhau và hoạt động trong

Formatted: Dutch (Netherlands)

Hình III.55. Kiến trúc chi tiết của lớp AS 2.5.3.2. Thực thi dịch vụ OpenLS Presentation Service của OGC

Dịch vụ Presentation Service [27] hiển thị thông tin đồ họa trên đầu cuối Mobile. Bất cứ một ứng dụng OpenLS nào có thể gọi đến dịch vụ này để nhận được bản đồ của vùng mong muốn mà có kèm hoặc không kèm theo vùng bản đồ đè lên bản đồ nền để minh họa một hoặc nhiều OpenLS ADTs như RouteGeometry, Point of Interest, Area of Interest, Location, Position và Address. Dịch vụ này cũng có thể được dùng để hiển thị chỉ dẫn đường đi từ RouteInstructions List ADT hoặc Route Maneuver List ADT.

Các Use Cases

 Use Case 1

A muốn nhìn xem nhà của anh ta nằm ở đâu trên bản đồ. Để thỏa mãn yêu cầu này, dịch vụ Presentation Service cần hiển thị bản đồ nền cùng với vị trí trí nhà của A nằm trên đó.

 Use Case 2

Kế hoạch một chuyến đi nghỉ ra đình, A muốn xem đường đi từ nhà anh ta ở 122 Hoàng Quốc Việt, Hà nội đến khách sạn Daewoo nơi anh ta đã đặt phòng trước. Để thỏa mãn yêu cầu này dịch vụ Presentation Service cần hiển thị bản đồ tuyến đường đi với hai điểm đầu, cuối nằm trên bản đồ nền.

 Lƣợc đồ của dịch vụ Presentation Service

Hình III.6Hình III.6 và Hình III.7Hình III.7 minh họa file XML định nghĩa Request và Respond của lược đồ XML cho dịch vụ Presentation Service.

Metadata Query Processing

OpenLS WFS query query User Interface Generation Content Transcoding GetCapability WFS/Presenta tion Service Application Server

Formatted: Dutch (Netherlands)

Hình III.66. Lƣợc đồ XML cho Request trong Presentation Service

Hình III.77. Lƣợc đồ XML cho Request trong Presentation Service

 Hình thành dịch vụ Presentation Service

Hình III.8Hình III.8 minh họa luồng hệ thống Presentation Service[22]. Trước tiên, người sử dụng đưa vào tham số của dịch vụ Presentation Service. Các dữ liệu như width, height và định dạng được thiết lập cho khởi tạo bản đồ. Chúng ta kết nối với DB với các hoạt động không gian sẽ sinh ra bản đồ của POI, vị trí và thông tin định

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands) tuyến. Các tham số đầu ra sử dụng Literal XML.Hình III.9Hình III.9 minh họa luồng

sinh ra bản đồ của dịch vụ Presentation Service.

Hình III.88. Luồng củ a hê ̣ thống Presentation Service

Hình III.99. Luồng tạo bản đồ

Hệ thống khuyến nghị ở đây là dịch vụ Presentation Service trên thiết bị mobile như dịch vụ Web Service kết nối với một mạng không dây. Ở phía Server, kiến trúc của dịch vụ Presentation Service bao gồm phần đầu vào bằng định dạng XML, phần kết nối DB, phần tạo bản đồ và phần tạo ra tham số đầu ra. Nếu client yêu cầu bản đồ

.2 Mối quan hệ giữa GIS và LBS

.2 Các dịchvụ dựa trên vị trí