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

Một phần của tài liệu Nghiên cứu mô hình dịch vụ hướng vị trí dựa trên hệ thống thông tin địa lý (Trang 55)

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ị vù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 có 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 có 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 có 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 nó khác rỗng và ngược lại.

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

Nếu đầu vào chỉ có thông tin mã bưu điện mà không có 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 thông tin vùng quản lý có mã bưu điện trùng với đầu vào.

Formatted: Dutch (Netherlands)  Định vị địa chỉ đƣờng phố:

Geocoder có 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ố có 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ị có 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ố có 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ố đó.

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.

Formatted: Dutch (Netherlands)  Đị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í đó. 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 có 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 phé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 đó 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 (có thể là bất kỳ vị trí nào, ví dụ một nơi mà họ chỉ có địa chỉ đường phố hay là một địa điểm có đượ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 có 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 hó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 có thể được tổ hợp với nhau và hoạt động trong cùng một server đơn lẻ (Hình III.5Hình III.5).

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 có thể gọi đến dịch vụ này để nhận được bản đồ của vùng mong muốn mà có 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 có 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 đó.

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)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

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)

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 củ a hê ̣ thống Presentation Service

Hình III.99. Luồng tạo bả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 đồ theo dịch vụ OpenLS như dịch vụ định tuyến đường đi và dịch vụ POI, dịch vụ định tuyến thì hệ thống sẽ cung cấp bản đồ này cho phía client.

III.4.4Lớp ứng dụng phía Client

Ở lớp ứng dụng phía Client, có xem xét đến nhiều platform khác nhau. Client sẽ thực hiện các truy vấn metadata đến dịch vụ của hệ thống và cấu hình GUI của ứng dụng dựa vào kết quả nhận được từ truy vấn metadata. Module tương tác người sử dụng UI (User Interaction) sẽ giao tiếp ứng dụng với người sử dụng. Tất nhiên các tương tác của người sử dụng có thể khởi tạo một truy vấn bản đồ. Modue truy vấn bản đồ cần thông dịch dữ liệu của người sử dụng đang có, thông tin do người sử dụng đưa

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands) vào, thông tin ngữ cảnh hiện có (ví dụ vị trí của người sử dụng) để tạo ra câu truy vấn

thích hợp. Kết quả hình ảnh của bản đồ từ truy vấn sẽ được hiển thị bằng module hiển thị SVG.

Một trong những nhiệm vụ quan trọng của phía client là liên quan đến nội dung thích hợp của bản đồ. Phụ thuộc vào sự thay đổi vị trí của người sử dụng hoặc vào một số tham số ngữ cảnh khác, nội dung và các đặc tính hiển thị của bản đồ có thể thay đổi. Module bản đồ thích ứng (Adaptive Map) sẽ thực hiện các chức năng này. Hình III.10Hình III.10 minh họa mô hình chi tiết của ứng dụng phía client.

Hình III.1010. Kiến trúc chi tiết lớp ứng dụng phía Client

III.5 Kiến trúc chi tiết các module cung cấp dịch vụ

III.5.1Data Services

III.5.1.1Web Feature Service

OGC Web map service cho phép một client hiển thị các ảnh bản đồ từ nhiều các Web Map Service khác trên Internet. Tương tự như vậy OGC Web Feature Service cho phép một client lấy được dữ liệu địa lý được mã hóa theo ngôn ngữ GML từ nhiều Web Feature Service khác.

Các yêu cầu đối với Web Feature Service là:

1. Giao diện phải được định nghĩa dưới dạng XML

2. GML phải được sử dụng để diễn tả các feature trong giao diện

3. Tại tối thiểu một WFS phải có khả năng biểu diễn feature mà được mô tả dưới dạng GML User Interaction GUI Generation Metadata Query Hiển thị SVG Map Query Adaptive Map Input Parameters change Client

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands) 4. Ngôn ngữ xác nhận hoặc sàng lọc được định nghĩa trong ngôn ngữ XML

vad được chuyển hóa từ CQL như định nghĩa trong OpenGIS Catalogue Interface Implementation Specification

5. Lưu trữ dữ liệu sử dụng lưu trữ các đặc tính địa lý để che dấu tại các ứng dụng Client và chúng chỉ hiển thị các dữ liệu thông qua giao diện WFS 6. Sử dụng tạp các Xpath biểu diễn cho các thuộc tính tham chiếu

Giao diện Web Feature Service được mô tả minh họa như Hình III-11Hình III-11 sau:

Hình III-1111. Web feature service Yêu cầu chức năng

Các giao thức để hỗ trợ thực hiện xử lý các yêu cầu tới Web Feature Service. Các yêu cầu xử lý sẽ bắt nguồn như sau:

1. Một ứng dụng Client sẽ yêu cầu lấy tài liệu về năng lực của hệ thống (capabilities Document) từ WFS. Tài liệu như vậy bao gồm mô tả toàn bộ các hoạt động của WFS hỗ trợ và danh sách toàn bộ các loại thuộc tính mà nó có thể phục vụ

2. Ứng dụng Client (tùy chọn) tạo ra một yêu cầu tời Web Feature để định nghĩa một hoặc nhiều loại đối tượng mà WFS có thể phục vụ

3. Dựa trên định nghĩa của các loại đối tượng, ứng dụng Client sinh ra một yêu cầu như trình bày trong tài liệu

4. Yêu cầu này được gửi tới một Web server 5. WFS sẽ kiểm tra và đáp ứng yêu cầu

6. Khi WFS hoàn thành quá trình xử lý yêu cầu, nó sẽ sinh ra một báo cáo trạng thái và gửi nó lại phía client. Trong tình huống có lỗi xảy ra, báo cáo sẽ chỉ ra nguyên nhân

Các hoạt động

Để hỗ trợ giao tác và xử lý truy vần, chúng ta phải định nghĩa các họat động sau

1. GetCapabilities

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

Formatted: Dutch (Netherlands)

2. DescribeFeatureType

3. GetFeature

4. Transaction

5. LockFeature

Dựa trên mô tả các hoạt động ở trên, hai lớp Web Feature Service có thể được định nghĩa

WFS cơ bản

WFS cơ bản sẽ thực thi các hoạt động GetCapabilities, DescribeFeatureType và GetFeature. Nó sẽ được xem như dịch một Web Feature Service chỉ đọc.

WFS giao dịch

Một Web Feature Service giao dịch sẽ hỗ trợ tất cả các hoạt động của một web feature service cơ bản và thêm vào đó nó thực thi các hoạt động giao dịch. Tùy chọn, một WFS giao dịch thực thi các hoạt động LockFeature

III.5.1.2Web Coverage Service III.5.1.2.1 Giới thiệu

Web Coverage Service [29] (WCS) hỗ trợ việc trao đổi dữ liệu địa lý ở mức độ vùng bao phủ (Coverage), có nghĩa là thông tin địa lý biểu thị các hiện tượng thay đổi của không gian. WCS cung cấp sự truy nhập đến tập dữ liệu thông tin địa lý chi tiết theo khuôn dạng hữu ích cho việc hiển thị ở phía client, bao phủ đa giá trị và là đầu vào cho các mô hình và client khác. WCS có thể so với OGC Web Map Service (WMS) và Web Feature Service (WFS) là cùng cho phép client lựa chọn phần dữ liệu thông tin của phía server dựa vào các ràng buộc không gian và các tiêu chí lọc khác. Tuy nhiên không như WMS, WMS lọc và hiển thị dữ liệu không gian để trả về bản đồ tĩnh (được hiển thị như ảnh ở phía server), WCS cung cấp dữ liệu sẵn có cùng với các mô tả chi tiết của dữ liệu cho phép những truy vấn phức tạp đến dữ liệu này và trả về dữ liệu với ngữ nghĩa nguyên gốc của nó (thay vì dạng ảnh), dữ liệu này có thể được giải thích, được ngoại suy … nhưng không được hiển thị. Không giống như WFS trả về những đặc tính (features) không gian rời rạc, WCS trả về sự biểu diễn các hiện tượng thay đổi theo không gian mà liên quan miền không gian thời gian đến phạm vi (có thể đa chiều) của các thuộc tính. WCS cung cấp ba hoạt động: GetCapabilities, GetCoverage và Describe Coverage.

1. GetCapabilities trả về tài liệu XML mô tả dịch vụ và giới thiệu ngắn gọn các tập dữ liệu từ đó client yêu cầu lên WCS. Clients sẽ thực hiện hoạt động GetCapabilities và lưu lại kết quả của nó cho sử dụng trong một phiên (session) hoặc sử dụng lại cho nhiều phiên. Nếu GetCapabilities không thể mô tả dữ liệu sẵn có của nó thì thông tin

Một phần của tài liệu Nghiên cứu mô hình dịch vụ hướng vị trí dựa trên hệ thống thông tin địa lý (Trang 55)

Tải bản đầy đủ (PDF)

(105 trang)