Client được cài đặt trong đề tài này là một trình duyệt. Trình duyệt Web này
được viết bằng trang ngơn ngữ HTML kết hợp với Javascript. Khi mở trang web của ứng dụng lần đầu tiên trong một phiên làm việc trên máy tính, client sẽ gửi một yêu cầu đến server để lấy bản đồ .svg. Khi đã nhận được tập tin .svg này từ server, trang Web ở phía client sẽ tựđộng cập nhật nội dung tập tin .svg này vào trong cửa sổ trình duyệt. Bộ hiển thị SVG (SVG Viewer) sẽ tựđộng xây dựng lại phần khung trong chứa thẻ ‘svg’ cửa sổ trình duyệt.
Hình 4.6 Minh họa yêu cầu hiển thị nội dung ở phía client 4.8.1.2 Vấn đề tương tác với nội dung SVG ở phía client
SVG cĩ một đặc tính là định dạng véc-tơ được thiết kế sao cho các thành phần bên trong nội dung cĩ thể tương tác trực tiếp với người sử dụng thơng qua cây phân cấp DOM (Document Object Model) (Mơ hình đối tượng tài liệu). Phía client sẽ tận dụng đặc tính này của SVG để đơn giản hĩa việc xử lý thao tác. Mỗi thành phần sẽ
giao tiếp với người sử dụng. Khi người sử dụng nhấn chuột lên một thành phần (chẳng hạn như một con đường) thì thành phần đĩ sẽ tựđộng phát sinh một sự kiện và gửi lên nút trên cùng trong cây phân cấp DOM
Client
http://169.254.131.98:port/GetSVG
Câu lệnh yêu cầu tập tin .svg
Server
160
Hình 4.7 Cây DOM quản lý qui trình bắt sự kiện
Người dùng tương tác với thành phần này thơng qua đoạn mã Javascript. Đoạn thực thi tương ứng cho mỗi sự kiện cĩ thểđược nhúng nội tuyến vào trong tập tin .svg, hoặc cĩ thểđược đặt trong một tập tin Javascript khác rồi tham chiếu đến tập tin Javascript này từ trong tập tin .svg.
Vậy bằng cách thao tác với một điểm, một đường, hoặc một vùng, ta cĩ thể
truy vấn thơng tin mà thành đĩ chứa. Trong trường hợp của ứng dụng bản đồ thì đĩ là thơng tin về tọa độ, chiều dài, cĩ bao nhiêu nhà trên đường đang tương tác.
Khi cĩ những thơng tin này, người lập trình cĩ thể tìm đường đi từ một đỉnh tới một đỉnh khác.
4.8.1.3 Tìm đường đi từ giữa hai điểm
Khi đã xác định được tọa độ hai điểm mà người dùng cần tìm đường đi giữa chúng, client sẽ gửi câu lệnh yêu cầu server thực hiện việc tìm kiếm đường đi với
161
dịch vụ web (web service) chạy ở phía server. Sau khi việc tìm đường đã hồn tất, server thơng báo lại kết quả cho client cũng thơng qua cùng một web trên.
Client căn cứ vào kết quả trả về mà hiển thị thơng tin trên bản đồ .svg. Thơng tin trả về là một tập các tọa độ kề nhau để đi từđiểm A đến điểm B, với A,B là hai
điểm đã được chọn để tìm kiếm đường đi.
4.8.1.4 Vấn đề thay đổi tỉ lệ phĩng to thu nhỏ
Bộ hiển thị SVG đã hỗ trợ chức năng phĩng to thu nhỏ. Người dùng cĩ thể
phĩng to đến mức tùy ý mà luơn an tâm rằng ảnh khơng bị vỡ.
(Ghi chú: Chức năng phĩng to trong Adobe SVG Viewer là Ctrl+ kéo chuột)
Một cách khác là sử dụng tính năng của server WFS. Khi cần phĩng to vùng nào, người dùng chọn một đường bao ngồi của vùng đĩ. Server dữ liệu sẽ thực hiên chức năng truy vấn đến vùng đĩ, chỉ chọn những tọa độ nằm trong vùng mong muốn.
Ưu điểm của kiến trúc trên:
− Các xử lý truy vấn dữ liệu được thực hiện ngay bên phía client, khơng cần phải chuyển về sever.
− Tốc độ đáp ứng tương tác nhanh hơn so với việc chuyển tồn bộ hàm về server.
Khuyết điểm của kiến trúc trên:
− Do server nằm phân tán nên việc truy vấn dữ liệu mới từ server sẽ tốn thời gian truyền tải tập tin .svg trên mạng. (adsbygoogle = window.adsbygoogle || []).push({});
− Kích thước tập tin .svg khơng được quá lớn vì nếu như thế sẽ làm cho thời gian truyền tải và thời gian hiển thị nội dung SVG gia tăng.
162
− Mỗi lần cần nội dung mới ở server giao diện thì phải chờ cho bộ hiển thị SVG xây dựng xong hình ảnh trong tập tin .svg được trả về. Khi đĩ người dùng phía client mới thấy được ảnh SVG.
4.8.2 Mơ tả chi tiết server
Server gồm hai phần con là UIServer (viết tắt của User Interface Server, được gọi là server giao diện) và DataServer (server chuyên chứa dữ liệu).
Trong kiến trúc ứng được trình bày ở hình phía trên, UIServer gồm hai phần nhỏ nữa là “Bản đồ ASPX” và “Service tìm đường”. DataServer gồm hai phần con là Geoserver và Microsoft SQL Server.
Sau đây là mơ tả cho từng phần con:
4.8.2.1 Mơ tả chi tiết “Bản đồ ASPX”
Server con này nhận yêu cầu truy vấn tập tin .svg. Sau đĩ gửi yêu cầu này xuống cho Geoserver. Geoserver đĩng vai trị là một server dữ liệu, chuyên cung cấp dữ liệu dạng .gml. Sau đĩ sever “Bản đồ ASPX” sẽ chuyển đổi dữ liệu này sang
định dạng .svg.
Để viết được server con này, người phát triển phải hiểu cú pháp của GML và SVG, chẳng hạn như chuyển một “LineString(10,10 14,234)” từ GML sang “line x1 = 10, y1=10 x2=14 y2=234 stroke-width = 1” trong định dạng SVG.
Câu lệnh yêu cầu tập tin .svg
Client Server Tập tin .svg “Bản đồ ASPX” Geoserver Hình 4.8. Mơ tả chức năng server “Bản đồ ASPX”
163
4.8.2.2 Mơ tả “Service tìm đường”
Chức năng của “Service tìm đường” là tìm đường đi giữa hai điểm được phía client yêu cầu. Server con này sẽ truy vấn trên cơ sở dữ liệu (CSDL) trong Microsoft SQL Server để lấy thơng tin cần thiết cho việc tìm đường. Mơ tả chi tiết của cấu trúc bảng trong SQL Server sẽđược mơ tảở mục 4.4.2.4
Hình 4.9. Mơ tả server “Service tìm đường”
4.8.2.3 Mơ tả Geoserver
Hình 4.10. Mơ tả Geoserver
dinhDau, toaDo1, dinhCuoi, toaDo2 Câu lệnh yêu cầu tìm đường
Client
Server
Kết quả: Danh sách các tọa độ
“Service tìm đường” MS SQL Server Tập tin hình học (shape file) *.frm *.myd, *.myi MySQL Server 4.1 Geoserver 1.3
164
Geoserver đĩng vai trị là server chuyên cung cấp dữ liệu. Ứng dụng sử dụng bốn lớp dữ liệu là: đường, bách hĩa tổng hợp, bệnh viện, trường học. Trong các lớp trên, lớp đường được lấy từ dữ liệu của MySQL. Các lớp cịn lại được lấy từ
shapefile.
Hiện nay ứng dụng sử dụng hai nguồn dữ liệu là shape file và MySQL. Đối với shape file thì chỉ cần nạp tập tin .shp vào. Đối với MySQL thì phải nạp tập tin dữ liệu vào MySQL, sau đĩ kết nối MySQL với Geoserver.
Hình 4.11. Kết xuất của Geoserver
Các tập tin dữ liệu .gml được Geoserver phát sinh sẽ được server “Bản đồ ASPX” chuyển sang tập tin .svg. (adsbygoogle = window.adsbygoogle || []).push({});
Ứng dụng sử dụng phương thức HTTP POST và tác vụ GetFeatureType.
4.8.2.3.1 Phương thức HTTP POST
Sử dụng phương thức HTTP POST sẽ yêu cầu client chuyển các yêu cầu trong phần thân tài liệu POST vào trong dịng URL. Khi này WFS khơng bao giờ được phép yêu cầu thêm bất cứ tham số phụ nào để bổ sung vào cuối dịng URL nhằm mục đích xây dựng một kết quả hợp lệ cho yêu cầu tác vụ.
Geoserver hỗ trợ cả hai phương thức HTTP GET và HTTP POST. Sử dụng phương thức nào cũng cho kết quả như nhau. Tuy nhiên, ứng dụng cĩ sử dụng gĩi
Geoserver 1.3 Tập tin GML Bản đồ ASPX
Chuyển đổi dữ liệu sang SVG
Tập tin SVG
165
CarbonTools giao tiếp với Geoserver, mà một lớp trong cơng cụ này (lớp HandlerWFS) chỉ hỗ trợ phương thức HTTP POST. Do đĩ, luận văn sử dụng phương thức HTTP POST để cài đặt. Từđĩ, phần báo cáo chỉ đề cập HTTP POST, cịn phần mơ tả chi tiết nằm ngồi phạm vi nghiên cứu. (xin xem thêm tập tin “04- 094_Web_Feature_Service_Implementation_Specification_V1[1].1.pdf”, phần HTTP POST trong thư mục Ref\ThamKhaoChinh\GIS)
4.8.2.3.2 Tác vụ GetFeatureType
Tác vụ GetFeature cho phép nhận về các tính năng từ một WFS. Một yêu cầu GetFeature được xử lý bởi một WFS. Khi giá trị của thuộc tính outputFormat được thiết lập là text/gml; subtype=gml/3.1.1, một tài liệu GML chứa kết quả sẽđược trả
về cho trình khách (client).
Nếu một WFS cài đặt “Xlink traversal” (tạm dịch là bộ phân tích liên kết), thì một WFS client cĩ thể dùng thuộc tính traverseXlinkDepth và traverseXlinkExpiry
để yêu cầu các thành phần được định danh bằng một liên kết. Yêu cầu: (Request)
Mã hĩa dạng XML của một yêu cầu GetFeature được định nghĩa theo giản đồ
phân đoạn XML sau:
<xsd:element name="GetFeature" type="wfs:GetFeatureType"/> <xsd:complexType name="GetFeatureType">
<xsd:complexContent>
<xsd:extension base="wfs:BaseRequestType"> <xsd:sequence>
<xsd:element ref="wfs:Query" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="resultType" type="wfs:ResultTypeType" use="optional" default="results"/> <xsd:attribute name="outputFormat" type="xsd:string" use="optional" default="text/xml; subtype=3.1.1"/> <xsd:attribute name="maxFeatures" type="xsd:positiveInteger" use="optional"/>
166 <xsd:attribute name="traverseXlinkDepth" type="xsd:string" use="optional"/> <xsd:attribute name="traverseXlinkExpiry" type="xsd:positiveInteger" use="optional"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:simpleType name="ResultTypeType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="results"/> <xsd:enumeration value="hits"/> </xsd:restriction> </xsd:simpleType>
<xsd:element name="Query" type="wfs:QueryType"/> <xsd:complexType name="QueryType">
<xsd:sequence>
<xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element ref="wfs:PropertyName"/>
<xsd:element ref="ogc:Function"/> </xsd:choice>
<xsd:element ref="ogc:Filter" minOccurs="0" maxOccurs="1"/> <xsd:element ref="ogc:SortBy" minOccurs="0" maxOccurs="1"/> </xsd:sequence> <xsd:attribute name="handle" type="xsd:string" use="optional"/> <xsd:attribute name="typeName" type="wfs:TypeNameListType" use="required"/> <xsd:attribute name="featureVersion" type="xsd:string" use="optional"/>
<xsd:attribute name="srsName" type="xsd:anyURI" use="optional"/> </xsd:complexType> <xsd:simpleType name="Base_TypeNameListType"> <xsd:list itemType="QName"/> </xsd:simpleType> <xsd:simpleType name="TypeNameListType"> <xsd:restriction base="wfs:Base_TypeNameListType"> <xsd:pattern value="((\w:)?\w(=\w)?){1,}"/> </xsd:restriction> </xsd:simpleType>
167
4.8.2.3.3 CarbonTools: cơng cụ hỗ trợ kèm theo Geoserver
CarbonTools là một cơng cụ phát triển phần mềm được thiết kế dành riêng cho nhà phát triển và phân tích thơng tin địa lý. Cơng cụ này đĩng gĩi các giải pháp tương tác thuộc về khơng gian địa lý như các đặc tả của OGC (Open Geospatial Consortium). CarbonTools là một sản phẩm của nhiều năm kinh nghiệm, cơng cụ (adsbygoogle = window.adsbygoogle || []).push({});
này giải quyết nhiều vấn đề và đưa ra một giao diện lập trình ứng dụng (API).
Gĩi CarbonTools được thiết kế cho phép mở rộng. Thư viện cốt lõi cung cấp một nền mở cho phép mở rộng hỗ trợ cho các nguồn dữ liệu khơng gian địa lý mới, các bộ quản lý dịch vụ và nhiều kĩ thuật trực quan mới, …. Hơn thế nữa, một lượng lớn các giải pháp cĩ thể được cung cấp khi sử dụng CarbonTools: các ứng dụng desktop độc lập, các mở rộng phần mềm của phía thứ ba, các dịch vụ Web .Net và nhiều hơn thế nữa.
Các cơng cụ CarbonTools .Net, kèm theo bộ cung cụ này, cung cấp một mở
rộng cho các cơng cụ .Net Form. Điều này làm cho các tác vụ WMS/WFS/GML phức tạp cĩ thể được thực hiện bằng cách kéo thả các thành phần vào Form. Các
điều khiển này cung cấp một khởi điểm tốt để phát triển các ứng dụng thỏa OGC.
Để giúp đỡ nhà phát triển, một số tiện ích được kèm theo gĩi này cùng với mã nguồn đầy đủ. Trong sốđĩ là CarbonViewer, một bộ hiển thị WMS/WFS/GML độc lập.
CarbonTools gồm cĩ 9 gĩi riêng rẽ:
• CarbonTools.Controls : Chứa các điều khiển hỗ trợ lập trình giao diện
• CarbonTools.Core.Base : Chứa các lớp cơ sở. • CarbonTools.Core.Drawing : Chứa các lớp hỗ trợ vẽ hình. • CarbonTools.Core.Features : Chứa các lớp dùng cho quản lý dữ liệu địa lý … • CarbonTools.Core.Geometries: Chứa các lớp về đối tượng hình học như đường thẳng, đa giác….
168
• CarbonTools.Core.OGCCapabilities : Chứa các lớp hỗ trợ phân tích khả
năng của một WFS hay WMS.
• CarbonTools.Core.WFS : Chứa các lớp hỗ trợ giao tiếp, gởi các yêu cầu WFS tới WFS server.
• CarbonTools.Core.WMS: Chứa các lớp hỗ trợ giao tiếp, gởi các yêu cấu WMS tới WFS server
Trong các gĩi trên, gĩi được sử dụng chính trong chương trình phát sinh bản
đồ SVG là CarbonTools.Core.WFS, các lớp trong gĩi này là:
Class Description
HandlerWFS Quản lý tương tác với một WFS thỏa đặc tả của OGC
QueryBuilder Chuyển dữ liệu nguồn (SourceWFS) thành một câu truy vấn dịch vụ thỏa đặc tả WFS của OGC
SourceWFS Quản lý dữ liệu truy cập và truy vấn đối với một dịch vụ WFS thỏa đặc tả WFS của OGC. Dữ liệu quản lý bao gồm :
• Address (Một dịnh danh tài nguyên cho dịch vụ)
• BBox (Đường bao của vùng địa lý)
• FilterProperty (Tên thuộc tính chứa hình học mà đường bao sẽ được áp dụng)
169
Tên cột Kiểu dữ liệu Chiều dài Cho phép rỗng
Id Số nguyên 4 khơng Name Chuỗi 255 Cĩ daiLo Số nguyên 4 Cĩ yêu cầu) • Layers (các lớp dữ liệu) • Maxfeature (Số tính năng tối đa cần lấy) ….
WFSLayerType Kiểu và tên lớp được dùng trong câu truy vấn
Ta sẽ dùng SourceWFS để lưu trữ các thơng tin về một yêu cầu GetFeature.
Đồng thời dùng HandlerWFS để gửi yêu cầu đi và nhận dữ liệu trả về từ WFS server, sau đĩ xử lý và tạo nội dung SVG .
4.8.2.4 Mơ tả Microsoft SQL Server (adsbygoogle = window.adsbygoogle || []).push({});
Microsoft SQL Server là server chuyên cung cấp dữ liệu cho việc tìm kiếm
đường đi. Trong SQL Server, các bảng sau được sử dụng:
• MapNetworkWithLength
• MapNetworkDanhSachNodeKe
• MapNetworkArc_AutoWithDirection Sau đây là mơ tả cho từng bảng trên:
• Bảng MapNetworkWithLength
Bảng 4.1. Bảng MapNetworkWithLength Trong đĩ:
170 o Name : tên của đường
o daiLo : (nhận giá trị 0 hoặc 1). Nếu là 0 thì khơng phải là đại lộ. Nếu là 1 thì đĩ là đại lộ.
• Bảng MapNetworkArc_AutoWithDirection
Bảng 4.2. Bảng MapNetworkArc_AutoWithDirection Trong đĩ:
o Id : chính là chiều dài một đoạn tối tiểu
o Path : khĩa ngoại tham chiếu đến khĩa chính trong bảng MapNetworkWithLength
o nodeStart : đỉnh bắt đầu của đoạn tối tiểu o nodeEnd : đỉnh kết thúc của đoạn tối tiểu
o arc : danh sách mơ tả tọa độ trong thực tế của đoạn tối tiểu
o direction: (nhận -1, 0 , 1). Nếu là 0 thì đi được cả hai chiều. Nếu là +1 thì chỉ đi được từ nodeStart đến nodeEnd. Nếu là -1 thì chỉđi được từ
nodeEnd đến nodeStart.
• Bảng MapNetworkDanhSachNodeKe
Tên cột Kiểu dữ liệu Chiều dài Cho phép rỗng
id Số nguyên 4 khơng Path Số nguyên 4 Cĩ nodeStart Số nguyên 4 Cĩ nodeEnd Số nguyên 4 Cĩ Arc Chuỗi 65536 Cĩ Direction Số nguyên 2 Cĩ
Tên cột Kiểu dữ liệu Chiều dài Cho phép rỗng
id Số nguyên 4 khơng
DanhSachNodeKe Chuỗi 4 Cĩ
171 Trong đĩ:
o Id : chính là chiều dài một đoạn tối tiểu
o DanhSachNodeKe: danh sách những node kề với node cĩ mã số là id.
4.8.3 Mơ tả chi tiết quá trình tìm kiếm đường đi
Quá trình tìm kiếm đường đi được thực hiện bằng thuật tốn Dijkstra. Sau đây là mơ tả thuật tốn Dijkstra.
Gọi đỉnh bắt đầu là s0, đỉnh kết thúc là t0. Thuật tốn sử dụng các mảng sau:
o doDai : kích thước n phần tử (với n là số đỉnh (số node) trong đồ thị). Phần tử thứ i của mảng này lưu chiều dài từđỉnh bắt đầu s0 đến đỉnh i. o daDuyet : kích thước n phần tử. Phần tử thứ i của mảng này xác định (adsbygoogle = window.adsbygoogle || []).push({});
nút thứ i đã được duyệt hay chưa. Nếu giá trị này là true thì cĩ nghĩa là
đã duyệt rồi. Nếu giá trị này là false thì cĩ nghĩa là chưa duyệt
o truoc : kích thước n phần tử. Phần tử thứ i của mảng này xác định nút trước nút thứ i là nút nào. Mảng này dùng để xác định đường đi.
Goi tập S là tập các đỉnh đĩng. Đỉnh đĩng là đỉnh mà hiện nay đã duyệt qua. Gọi tập T là tập các đỉnh mở, tức chưa xét
• Bước 1: gán S= {s0}, T = T \ {s0} u = s0;
• Bước 2: tìm đỉnh mở v cĩ sao cho doDai[v] giá trị nhỏ nhất. Nếu v trùng u thì cĩ nghĩa là đã tìm được đường đi. Khi này chuyển sang bước 4. Nếu khơng thì chuyển sang bước 3.
172
• Bước 3: cập nhật giá trị doDai, daDuyet từ đỉnh v. Xét các đỉnh kề v. Nếu doDai[v] chưa cĩ (tức nhận giá trị VO_CUC) thì cập nhật bằng doDai[u] + chieuDai[u,v].
Nếu doDai[v] cĩ rồi thì chỉ cập nhật nếu doDai[u] + chieuDai[u,v] < doDai[v].
Nếu cĩ cập nhật giá trị doDai[v] thì cần phải cập nhật lại giá trị của truoc[v] = u.
Lặp lại bước 2.
• Bước 4: Truy tìm đường đi dựa vào mảng truoc. Quy tắc truy tìm như
sau
o Bước 4.1: Gán u = t0. Đưa t0 vào danh sách đường đi.
o Bước 4.2: Với mỗi đỉnh u hiện cĩ, ta gán v = truoc[u]. Nếu v == VO_CUC thì dừng lại. Ngược lại, đưa v vào danh sách đường đi, gán u=v, rồi lặp lại bước 4.2.
173
Chương 5 TỔNG KẾT
5.1 Kết luận
Sau thời gian nghiên cứu, chúng em đã tìm hiểu được cấu trúc tập tin ảnh véc- tơ SVG, kĩ thuật viết script và các kĩ thuật liên quan để xây dựng được: