2.3.7. Cấu trúc tệp ngôn ngữ CityGML
Phần định nghĩa đối tượng CityGML
CityGML được xây dựng trên nền tảng ngôn ngữ XML nên cấu trúc file dữ liệu trong CityGML sẽ giống như các file XML tiêu chuẩn. Mỗi file dữ liệu CityGML sẽ bao gồm phần thơng tin đầu file XML có sử dụng phần định nghĩa đối tượng dữ liệu và phần dữ liệu. Đối với những dữ liệu XML
phức tạp như GML và CityGML thì thường phần định nghĩa đối tượng sẽ được đặt ở các file riêng biệt để cấu trúc dữ liệu tường minh và logic hơn.
Dưới đây là một ví dụ về file dữ liệu CityGML và phần định nghĩa đối tượng dữ liệu. <?xml version="1.0" encoding="UTF-8"?> <core:CityModel xmlns:bldg="http://www.opengis.net/citygml/building/1.0" xmlns:luse="http://www.opengis.net/citygml/landuse/1.0" xmlns:app="http://www.opengis.net/citygml/appearance/1.0" xmlns:xAL="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0" <gml:boundedBy>
<gml:Envelope srsName="EPSG:32648" srsDimension="3"> <gml:lowerCorner>580445.001829352 2330374.80919873 0</gml:lowerCorner> <gml:upperCorner>580453.035917497 2330386.47790763 4.000008000016</gml:upperCorner> </gml:Envelope> </gml:boundedBy> <core:cityObjectMember> <bldg:Building gml:id="gml_72c19331-432f-47d5-8ba8-0c8bbe181c65"> <gml:name>dc_riverside_building</gml:name> <bldg:LoD2MultiSurface>
<gml:MultiSurface srsName="EPSG:32648" srsDimension="3"> <gml:surfaceMember> <gml:CompositeSurface> <gml:surfaceMember> <gml:Polygon> <gml:exterior> <gml:LinearRing> <gml:posList>580452.48324957 2330386.47790763 4.000008000016 580453.035917497 2330375.17501116 4.000008000016 580445.554497261 2330374.80919873 4.000008000016 580452.48324957 2330386.47790763 4.000008000016</gml:posList> </gml:LinearRing>
</gml:exterior> </gml:Polygon> </gml:surfaceMember> <gml:surfaceMember> <gml:Polygon> <gml:exterior> <gml:LinearRing> <gml:posList>580445.001829352 2330386.11209503 4.000008000016 580452.48324957 2330386.47790763 4.000008000016 580445.554497261 2330374.80919873 4.000008000016 580445.001829352 2330386.11209503 4.000008000016</gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gml:surfaceMember> <gml:surfaceMember> <gml:Polygon gml:id="fme-gen-cdfce69e-d9be-4351-aded- 2cfb07d10714"> <gml:exterior> <gml:LinearRing> <gml:posList>580445.001829352 2330386.11209503 0 580452.48324957 2330386.47790763 4.000008000016 580445.001829352 2330386.11209503 4.000008000016 580445.001829352 2330386.11209503 0</gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gml:surfaceMember> <gml:surfaceMember> <gml:Polygon gml:id="fme-gen-1ec65636-6d14-4df6-9d66- b69aea3d5aa0"> <gml:exterior> <gml:LinearRing> <gml:posList>580445.001829352 2330386.11209503 0 580452.48324957 2330386.47790763 0 580452.48324957 2330386.47790763 4.000008000016 580445.001829352 2330386.11209503 0</gml:posList> </gml:LinearRing>
</gml:exterior> </gml:Polygon> </gml:surfaceMember> <gml:surfaceMember> <gml:Polygon gml:id="fme-gen-1902bd45-af94-47a5-bfcc- 379e3e34a074"> <gml:exterior> <gml:LinearRing> <gml:posList>580452.48324957 2330386.47790763 0 580453.035917497 2330375.17501116 4.000008000016 580452.48324957 2330386.47790763 4.000008000016 580452.48324957 2330386.47790763 0</gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gml:surfaceMember> <gml:surfaceMember> <gml:Polygon gml:id="fme-gen-d3eaa247-202b-417c-97b7- 3577b79aee61"> <gml:exterior> <gml:LinearRing> <gml:posList>580452.48324957 2330386.47790763 0 580453.035917497 2330375.17501116 0 580453.035917497 2330375.17501116 4.000008000016 580452.48324957 2330386.47790763 0</gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gml:surfaceMember> <gml:surfaceMember> <gml:Polygon gml:id="fme-gen-d672a158-f460-493c-a915- 54ed16703fd7"> <gml:exterior> <gml:LinearRing> <gml:posList>580445.554497261 2330374.80919873 0 580445.554497261 2330374.80919873 4.000008000016 580453.035917497 2330375.17501116 4.000008000016 580445.554497261 2330374.80919873 0</gml:posList> </gml:LinearRing>
</gml:exterior> </gml:Polygon> </gml:surfaceMember> <gml:surfaceMember> <gml:Polygon gml:id="fme-gen-03617c7d-5264-420e-b4fd- 54afaaa16a90"> <gml:exterior> <gml:LinearRing> <gml:posList>580453.035917497 2330375.17501116 0 580445.554497261 2330374.80919873 0 580453.035917497 2330375.17501116 4.000008000016 580453.035917497 2330375.17501116 0</gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gml:surfaceMember> <gml:surfaceMember> <gml:Polygon gml:id="fme-gen-921ffc9c-927b-479c-a0a1- 9147b1aaacd2"> <gml:exterior> <gml:LinearRing> <gml:posList>580445.001829352 2330386.11209503 0 580445.001829352 2330386.11209503 4.000008000016 580445.554497261 2330374.80919873 4.000008000016 580445.001829352 2330386.11209503 0</gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gml:surfaceMember> <gml:surfaceMember> <gml:Polygon gml:id="fme-gen-cbe779b9-4d41-43b1-801a- e1b70e455ab3"> <gml:exterior> <gml:LinearRing> <gml:posList>580445.554497261 2330374.80919873 0 580445.001829352 2330386.11209503 0 580445.554497261 2330374.80919873 4.000008000016 580445.554497261 2330374.80919873 0</gml:posList> </gml:LinearRing>
</gml:exterior> </gml:Polygon> </gml:surfaceMember> </gml:CompositeSurface> </gml:surfaceMember> </gml:MultiSurface> … </core:CityModel>
Trong file dữ liệu CityGML trên, phần đầu <“?xml version='1.0' encoding='UTF-8' standalone='yes'?>” là chỉ báo về version của XML, mã font dữ liệu là UTF-8. Phần tiếp theo <CityModel xmlns: “…” là địa chỉ tham khảo namespace của các đối tượng dữ liệu CityGML. Phần chính của file dữ liệu là phần mô tả các đối tượng dữ liệu trong CityGML (Trong đoạn file dữ liệu là dữ liệu mô tả một đối tượng dữ liệu là building, có cấu trúc được xây dựng theo chuẩn dữ liệu GML bao gồm: các bề mặt tường của building, các tọa độ điểm của đường bao ngoài mỗi mặt tường, v.v…
2.3.8. Độ chính xác của mơ hình 3D theo LoD
Theo OGC (2017) thì độ chính xác của mơ hình 3D theo chuẩn dữ liệu CityGML có thể được chia theo các mức độ LoD theo bảng dưới đây:
Bảng 2.1 Độ chính xác của mơ hình CityGML theo các mức LoD
LoD0 LoD1 LoD2 LoD3 LoD4
Quy mơ mơ
hình Vùng, miền Tỉnh, thành phố Quận, dự án Mơ hình một hoặc một số cơng trình (phía ngồi) Mơ hình một hoặc một vài cơng trình (phía trong) Phân loại độ
chính xác Thấp nhất Thấp Trung bình Cao Rất cao Độ chính xác
tuyệt đối của điểm 3D (mặt
bằng/độ cao)
Thấp hơn
LoD1 5/5m 2/2m 0.5/0.5m 0.2/0.2m
Mức độ tổng
quát hóa Thể hiện lớp sử dụng đất Đối tượng có kích thước> 6 x 6m/3m Đối tượng có kích thước> 4 x 4m/2m Đối tượng có kích thước> 2 x 2m/1m
2.3 Chuẩn dữ liệu IFC
2.3.1 Giới thiệu về chuẩn dữ liệu IFC
Chuẩn IFC (Industry Foundation Classes) là chuẩn định dạng mở được phát triển bởi buildingSMART, giúp trao đổi dữ liệu giữa các phần mềm, phục vụ cho cơng tác quản lý mơ hình BIM trong suốt vịng đời của dự án. Mơ hình IFC có thể mơ tả một cơng trình được sử dụng như thế nào, trơng nó như thế nào, nó được xây dựng ra sao và nó hoạt động như thế nào. IFC cũng có thể mơ tả các thành phần của tòa nhà, các hệ thống máy móc, hệ thống điện, và rất nhiều các thơng tin khác liên quan tới tịa nhà. Định dạng này cho phép tiến hành phân tích cấu trúc và năng lượng dễ dàng bằng các phần mềm chuyên dụng. Dữ liệu IFC cũng được tổ chức theo LoD, bắt đầu từ 100 tới 500.
Hình 2.4 Một mơ hình 3D tịa nhà theo định dạng IFC
2.3.2 Cấu trúc của IFC
Cấu trúc của mơ hình dữ liệu IFC được chia thành bốn lớp: miền (domain), khả năng tương tác (interoperability), lõi (core) và các lớp tài nguyên (resource layers). Mối quan hệ giữa các lớp này được minh họa trong Hình 2.5. Các lớp được phân cấp tham chiếu nghiêm ngặt theo nguyên tắc ngón tay cái tức là việc tham chiếu chỉ có thể xảy ra trong hệ thống phân cấp từ trên xuống. Điều này có nghĩa là dữ liệu trong lớp tài nguyên phải độc lập và khơng tham chiếu đến các lớp ở trên nó. Tuy nhiên, tất cả các lớp khác có thể tham chiếu dữ liệu từ lớp tài nguyên cũng như tất cả các lớp khác bên dưới chúng. Chỉ có lớp tài nguyên mới tham chiếu trong cùng một lớp. Lớp tài nguyên chứa lược đồ tài nguyên bao gồm các định nghĩa cơ bản nhằm mô tả các đối tượng trong các lớp ở trên. Lớp lõi bao gồm các mô-đun hạt nhân và phần mở rộng. Hạt nhân xác định cấu trúc mơ hình và phân tách, cung cấp các khái niệm cơ bản về các đối tượng, các mối quan hệ, các định nghĩa về kiểu loại, các thuộc tính và vai trị của đối tượng. Phần mở rộng của lõi là sự chun mơn hóa của các lớp được định nghĩa trong hạt nhân. Lớp tương tác cung cấp giao diện cho các mơ hình miền, do đó cung cấp cơ chế trao đổi để
cho phép khả năng tương tác giữa các tên miền. Lớp miền chứa các mơ hình miền cho các quy trình trong các miền AEC (Architecture, Engineering and Construction) hoặc các loại ứng dụng cụ thể, chẳng hạn như kiến trúc, kỹ thuật kết cấu (IAI, 1999a; IAI, 1999b: IAI, 2000)
Hình 2.5. Cấu trúc mơ hình dữ liệu IFC (IAI, 1999b; IAI, 2000)
Chuẩn dữ liệu IFC thường được lưu ở dạng tệp text ASCII. Lược đồ mô tả việc chuyển tệp ASCII đối tượng tổng hợp với các quan hệ và kế thừa kiểu như thế nào. Mặc dù người dùng có thể đọc trực tiếp các thông tin trên tệp ASCII, nhưng việc chuyển tệp này thành mơ hình phải được tiến hành trên các phần mềm chuyên dụng. Định dạng của tệp tin IFC dựa trên tiêu chuẩn ISO (10303-21) và được gọi là "STEP-file". Hình 2.6 mơ tả dữ liệu nguồn IFC trích từ tệp vật lý STEP (ISO 10303-21) chứa thơng tin về một tịa nhà, và Hình 2.7 biểu diễn trực quan mơ hình tịa nhà trong phần mềm BIM. Trong khi mỗi dòng của cú pháp được gán một số thứ tự duy nhất, nội dung trong các tệp vật lý STEP không được cấu trúc theo bất kỳ thứ tự cụ thể nào, ranh giới của các dữ liệu cũng không rõ ràng nếu người dùng đọc trực tiếp dữ liệu; tức là không thể trao đổi một phần dữ liệu trên các tệp STEP chỉ bằng cách
cắt và dán các dòng mã (Yang và Eastman, 2007). Dữ liệu cá thể phải được tạo ra khi nội dung của tệp được phân tích cú pháp thành các cấu trúc đối tượng và các cấu trúc ngữ nghĩa được xây dựng.
Hình 2.6 Một phần dữ liệu của mơ hình IFC lưu trữ ở định dạng STEP (AC11-Institute-Var-2-IFC model courtesy of the Open IFC Model
Hình 2.7 Mơ hình một tịa nhà theo chuẩn dữ liệu IFC (Solibri Model Viewer, AC11-Institute-Var-2-IFC model courtesy of the Open IFC Model
Repository 2012)
2.3.3. Các phiên bản của IFC
Chuẩn dữ liệu IFC đã được phát hành với nhiều phiên bản khác nhau và không ngừng phát triển. Hai phiên bản hiện có liên quan là IFC 2x3 và IFC 4 (Các phiên bản trước là 1.0, 1.5, 1.5.1. Sau đó, có 2x, 2x2 Sau đó, phiên bản mới nhất có thể được đặt tên là IFC2x4 nhưng thay vào đó họ đơn giản hóa việc đặt tên phiên bản hiện tại thành IFC4 và sau đó là phiên bản chính sắp tới cho IFC 5).
Mặc dù, IFC 2x3 là bản phát hành trước đó, nó vẫn là phiên bản đang được sử dụng nhiều nhất hiện nay. Lý do là các phần mềm BIM phổ biến chưa được cập nhật để hỗ trợ cho phiên bản mới này. Ngoài ra rất nhiều dự án đang thực hiện sử dụng các lược đồ IFC2X3. Tuy nhiên, phiên bản IFC2x3 chứa một số hạn chế và buildingSMART đang cố gắng sửa các lỗi này trong các bản phát hành sau (IFC4, IFC5 và hơn thế nữa).
IFC4 mở rộng hỗ trợ cho các yếu tố hình học và các thơng số của cơng trình, mở rộng thêm các dịch vụ và miền cấu trúc, và bổ sung thêm định dạng XML đơn giản. IFC5 hiện đang trong giai đoạn lập kế hoạch phát triển. Cập nhật chính cho bản phát hành này dự kiến sẽ mở rộng hơn nữa các khả năng đưa vào các tham số của cơng trình và sự bao gồm của miền cơ sở hạ tầng.
CHƯƠNG 3: PHƯƠNG PHÁP MƠ HÌNH HĨA THÀNH PHỐ 3D TRÊN NỀN WEB BẰNG CÔNG CỤ MÃ NGUỒN MỞ
3.1 Giới thiệu một số thư viện mã nguồn mở biểu diễn dữ liệu 3D trên web
3.1.1 CesiumJS
CesiumJS là một thư viện JavaScript mã nguồn mở có thể mơ hình hóa địa cầu trên nền web. Nó sử dụng WebGL để cung cấp khả năng tăng tốc phần cứng và hỗ trợ plugin độc lập, cũng như chức năng đa nền tảng và trình duyệt chéo. CesiumJS cho phép hiển thị dữ liệu địa lý thông qua các tiêu chuẩn OGC với khả năng tương tác dữ liệu. Nó cũng cho phép hiển thị các mơ hình 3D dựa trên định dạng dữ liệu glTF.
Hình 3.1 Hình ảnh quả địa cầu biểu diễn bằng thư viện CesiumJS
3.1.2 Three.js
Three.js là một thư viện JavaScript trình duyệt chéo và Giao diện lập trình ứng dụng (API) được sử dụng để tạo và hiển thị đồ họa máy tính 3D hoạt hình trên trình duyệt web. Cũng giống như Cesimum, Three.js sử dụng
WebGL. Nó cũng là thư viện mã nguồn mở được lưu trữ trong một kho lưu trữ trên GitHub (https://github.com/mrdoob/three.js). Tuy nhiên, three.js không hỗ trợ tọa độ địa lý, vì vậy khi mơ hình hóa các đối tượng địa lý cần phải tính chuyển tọa độ sang hệ tọa độ của three.js.
3.1.3 Eegeo.js
Eegeo.js là một API bản đồ 3D nguồn mở được xây dựng trên Leaflet, thư viện biểu diễn dữ liệu không gian trên web phổ biến. Eegeo.js cho phép biểu diễn bản đồ 3D động, liền mạch, thực tế của thế giới ngay trên trình duyệt bằng WebGL.
Hình 3.2 Ví dụ biểu diễn trực quan mơ hình 3D bằng eegeo.js
3.2 Mơ hình hóa 3D bằng công cụ mã nguồn mở 3DcityDB (so sánh với vizicities) và thư viện CesiumJS vizicities) và thư viện CesiumJS
3DCityDB là một bộ cơng cụ mã nguồn mở có chức năng lưu trữ, biểu diễn, và quản lý mơ hình 3D thành phố ảo trên CSDL quan hệ (https://www.3dcitydb.org). Một trong những tính năng chính của 3DCityDB là khả năng xuất dữ liệu 3D ra nhiều định dạng khác nhau có thể biểu diễn trên Web như KML/COLLADA, JSON, GlTF. Hơn nữa, 3DCityDB hoạt động dựa trên CSLD PostGIS, phần mở rộng của Hệ quản trị CSDL mã nguồn mở Postgres. Điều này cho phép quản lý, truy cập, hiển thị dữ liệu trên
web bằng các dịch vụ web theo chuẩn của OGC (Prandi và nnk, 2015). Giải pháp sử dụng cơng cụ này để mơ hình hóa thành phố 3D có thể gồm 4 bước chính: (1). Chuyển dữ liệu 3D sang chuẩn CityGML; (2) Chuyển mơ hình 3D sang định dạng KML/COLLADA, JSON, GlTF; (3) Tải dữ liệu thuộc tính lên các dịch vụ cho phép lưu trữ và truy cập dữ liệu dạng bảng; (4) Trực quan hóa dữ liệu 3D bằng thư viện CesiumJS. Sơ đồ được minh họa như trong Hình 3.3:
Hình 3.3 Giải pháp trực quan hóa dữ liệu 3D bằng 3DCityDB và Cesium
3.2.1. Chuyển mơ hình 3D sang định dạng CityGML
Nếu mơ hình 3D ban đầu khơng ở định dạng CityGML thì cần chuyển định dạng sang chuẩn CityGML để có thể nhập vào công cụ 3DCityDB Importer-Exporter Tool. Cách đơn giản nhất để xây dựng mơ hình 3D theo chuẩn CityGML là ghi lại thông tin dữ liệu 3D theo cấu trúc dữ liệu CityGML bằng các công cụ soạn thảo văn bản. Tuy nhiên cách này chỉ có thể thực hiện được với các mơ hình 3D có mức độ chi tiết thấp (LoD0, LoD1). Đối với mô hình 3D có độ chi tiết cao hơn (từ LoD2) trở lên, các yếu tố hình học của mơ hình thường rất phức tạp, ngồi ra phải gắn thêm các ảnh texture cho mơ hình,
Mơ hình 3D Chuyển sang định dạng CityGML Chuyển sang định dạng KML/COLLADA, JSON, GlTF
Biểu diễn dữ liệu trên web bằng CensiumJS Dữ liệu thuộc tính Google FusionTalbe, Google SpreadSheet
do đó để chuyển mơ hình 3D sang định dạng CityGML cần sử dụng các công cụ chuyển đổi ví dụ như Safe Software-FME (https://www.safe.com/), công cụ chuyển đổi CityEditor tích hợp trên Sketchup (https://www.3dis.de/cityeditor/).
3.2.2. Chuyển mơ hình 3D từ chuẩn dữ liệu CityGML sang định dạng KML/COLLADA, JSON, GlTF
Mơ hình 3D ở định dạng CityGML không phù hợp để biểu diễn trực tiếp trên nền web, do đó cần chuyển mơ hình sang định dạng có thể hiển thị trên web như KML/COLLADA JSON, GlTF. Các định dạng được hỗ trợ trong nhiều ứng dụng, chẳng hạn như Google Earth, Cesium, NASA World Wind hoặc ArcGIS Explorer. Hơn nữa, định dạng này cho phép làm nổi bật đối tượng và tương tác các với mơ hình. Bước chuyển đổi này có thể tiến hành bằng cách sử dụng công cụ 3DCityDB Importer-Exporter.
3DCityDB Importer-Exporter (giao diện đồ họa như Hình 3.4) là một cơng cụ kèm theo trong gói 3DCityDB được viết trên ngơn ngữ Java cho phép xuất và nhập dữ liệu khơng gian để mơ hình hóa thành phố 3D ảo. Công cụ này hỗ trợ cả giao diện đồ họa GUI và giao diện dòng lệnh. Với dao diện dòng lệnh, cơng cụ cho phép thực hiện các quy trình xử lý tự động lập trong tệp .BAT hoặc nhúng vào các phần mềm khác. Cơng cụ này có một số tính năng chính như dưới đây:
Kết nối được với CSDL Oracle Locator/Spatial và PostgreSQL/PostGIS
Đọc/Ghi dữ liệu CityGML
Xuất dữ liệu ra định dạng KML/COLLADA, JSON, GlTF bao gồm cả các dữ liệu texture
Xuất dữ liệu thuộc tính ra dạng bảng
Phê chuẩn dữ liệu CityGML
Hình 3.4 Giao diện chính của cơng cụ 3DCityDB Importer-Exporter
3.2.3. Trực quan hóa mơ hình 3D trên Web
Để biểu diễn dữ liệu 3D trên web, 3DCityDB sử dụng thư viện mã nguồn mở CesiumJS. Trong gói 3DCityDB được tích hợp sẵn một Web Client, với các thư viện JavaScipt được lập trình sẵn. 3D Web Client của 3DCityDB có cấu trúc hệ thống được minh họa như Hình 3.5 (Yao và nnk, 2016). Dữ liệu thuộc tính của mơ hình (nếu được lưu sẵn trên mơ hình 3D ở dạng CityGML) có thể được xuất ra bằng cơng cụ 3DCityDB Importer- Exporter như đã trình bày ở trên, hoặc nhập dữ liệu vào bảng excel sau đó thể tải dữ liệu này lên các dịch vụ lưu trữ dữ liệu dạng bảng của Google như Google FusionTable hoặc Google SpreadSheet. Mơ hình 3D sẽ liên kết với bảng thuộc tính này để hiển thị khi được truy vấn. Cesium cho phép hiển thị nhiều loại bản đồ nền thơng qua Imagery Server và các dữ liệu địa hình thơng
qua Terrain Server. Các thư viện được cung cấp đều ở dạng mã nguồn mở, do đó người dùng có thể tùy biến theo yêu cầu.
CHƯƠNG 4: THỰC NGHIỆM
4.1 Giới thiệu khu vực thực nghiệm, dữ liệu và các công cụ sử dụng