Khi một 3D City Model được đưa lên Web, điều chúng ta nhìn thấy cuối cùng thường chỉ là một thành phố 3D có thể xoay, phóng to, thu nhỏ và di chuyển qua lại trên màn hình. Phần giao diện đó khiến quá trình phía sau có vẻ đơn giản hơn thực tế rất nhiều, bởi một mô hình đô thị có thể chứa đồng thời hình học, thuộc tính, ngữ nghĩa và các quan hệ không gian giữa những đối tượng mà nó biểu diễn. Dữ liệu được tổ chức tốt ở tầng mô hình chưa chắc đã phù hợp để truyền tải tới trình duyệt, cũng như một mô hình được tối ưu rất tốt cho việc hiển thị chưa chắc còn giữ được đầy đủ giá trị của dữ liệu đô thị ban đầu.
Đó là lý do CityGML và 3D Tiles thường xuất hiện cùng nhau trong các hệ thống 3D đô thị, nhưng chúng không phải hai định dạng cạnh tranh để lựa chọn một trong hai. CityGML được OGC xây dựng như một conceptual model và exchange format cho việc biểu diễn, lưu trữ và trao đổi các virtual 3D city models; trọng tâm của nó nằm ở cách các đối tượng đô thị được mô hình hóa, bao gồm cả hình học và ngữ nghĩa. 3D Tiles lại giải quyết một bài toán khác: tổ chức và phân phối những tập dữ liệu 3D địa không gian lớn tới các ứng dụng có nhu cầu hiển thị và tương tác. Khi đặt chúng cạnh nhau, câu hỏi đáng quan tâm không còn là “dùng CityGML hay 3D Tiles?”, mà là một 3D City Model phải đi qua những biến đổi nào để từ một mô hình dữ liệu có cấu trúc trở thành dữ liệu có thể vận hành hiệu quả trên Web? (Open Geospatial Consortium)
CityGML giữ lại điều gì trong một 3D City Model?
Nếu chỉ nhìn vào hình ảnh cuối cùng của một tòa nhà, rất khó nhận ra sự khác biệt giữa một mô hình 3D thông thường và một đối tượng trong 3D City Model. Cả hai đều có thể được dựng thành những bề mặt và polygon giống nhau, nhưng ở phía sau hình học đó là hai cách tổ chức thông tin rất khác nhau. Với một mô hình phục vụ visualization đơn thuần, điều quan trọng có thể chỉ là hình dạng, texture và hiệu ứng hiển thị; trong khi với CityGML, hình học là một phần của mô hình, bên cạnh loại đối tượng, thuộc tính, quan hệ và những thông tin mô tả đối tượng đó trong thế giới đô thị.
Chính phần thông tin này làm cho một Building trong 3D City Model không đơn thuần là một mesh. Nó có thể được nhận diện như một đối tượng Building, có các thuộc tính riêng và được biểu diễn ở những mức độ chi tiết khác nhau tùy theo mục đích sử dụng. CityGML vì vậy không được xây dựng chỉ để tạo ra một cảnh 3D đẹp mắt, mà hướng tới việc tạo ra một mô hình đô thị có thể được trao đổi và tiếp tục sử dụng trong nhiều bài toán khác nhau. Đây cũng là lý do CityGML có thể đóng vai trò như một lớp dữ liệu nền cho các ứng dụng quy hoạch, phân tích không gian, mô phỏng và quản lý đô thị. (Open Geospatial Consortium)
Điều này dẫn tới một hệ quả khá quan trọng: không phải tất cả những gì có trong 3D City Model đều cần được đưa nguyên vẹn vào lớp hiển thị. Một ứng dụng Web có thể chỉ cần một phần geometry và một số thuộc tính để phục vụ việc hiển thị hoặc tương tác, trong khi hệ thống phân tích phía sau lại cần những thông tin khác. Vì vậy, khi đưa CityGML vào một pipeline Web 3D, chúng ta thực chất đang đứng trước bài toán lựa chọn và tổ chức lại dữ liệu, chứ không đơn giản là tìm một công cụ để đổi đuôi file.
3D Tiles nằm ở đâu trong pipeline đó?
Đây là chỗ dễ gây nhầm lẫn nhất. Khi một CityGML dataset được chuyển thành 3D Tiles, nhìn từ bên ngoài chúng ta có thể thấy một kết quả rất trực quan: mô hình được mở trong Cesium và thành phố xuất hiện trên màn hình. Nhưng kết quả đó không có nghĩa 3D Tiles là một “phiên bản nhẹ hơn” của CityGML.
OGC định nghĩa 3D Tiles như một standard để truyền tải các tập dữ liệu 3D địa không gian lớn, trong đó có thể bao gồm 3D buildings, BIM/CAD, photogrammetry, point clouds và nhiều loại dữ liệu khác. Điểm quan trọng nằm ở cách dữ liệu được tổ chức để có thể được tải và xử lý theo từng phần thay vì buộc ứng dụng phải lấy toàn bộ dataset ngay từ đầu. Với một mô hình ở quy mô thành phố, cách tổ chức này có ý nghĩa trực tiếp đối với khả năng tương tác của ứng dụng Web. (GitHub)
Vì vậy, nếu CityGML trả lời câu hỏi “mô hình hóa thành phố như thế nào và đối tượng trong đó mang những thông tin gì?”, thì 3D Tiles gần với câu hỏi “làm thế nào để đưa lượng dữ liệu 3D đó tới ứng dụng theo cách phù hợp với việc hiển thị và streaming?”. Hai lớp này có thể liên kết với nhau, nhưng chúng không có cùng vai trò và cũng không nên được xem là hai cách biểu diễn tương đương của cùng một vấn đề.
Từ CityGML đến Web 3D: chuyện gì thực sự xảy ra ở giữa?
Một pipeline điển hình có thể được hình dung theo chuỗi:
Source Data → 3D City Model → CityGML → Validation & Preparation → Conversion / Tiling → 3D Tiles → Web 3D → Application
Nhìn trên sơ đồ, chuỗi này có vẻ giống một quy trình chuyển đổi dữ liệu khá thẳng. Nhưng nếu nhìn kỹ hơn, mỗi mũi tên thực chất đại diện cho một quyết định về dữ liệu. Dữ liệu khảo sát, GIS, BIM, CAD hay các nguồn khác ban đầu có thể có cấu trúc, hệ tọa độ, độ chính xác và mức độ chi tiết khác nhau; khi được tổ chức thành 3D City Model, chúng cần được đưa về một cách biểu diễn có cấu trúc và ngữ nghĩa nhất quán. CityGML có thể đảm nhiệm lớp mô hình hóa đó, nhưng khi mô hình bắt đầu hướng tới Web, yêu cầu lại thay đổi: dữ liệu cần được tổ chức sao cho geometry có thể được phân chia, tải theo phạm vi quan sát và kết hợp với những metadata cần thiết cho ứng dụng. Chính khoảng chuyển tiếp này mới là phần đáng quan tâm của pipeline.
Nói cách khác, Conversion không phải là một thao tác kỹ thuật nằm giữa CityGML và 3D Tiles mà chúng ta có thể bỏ qua. Nó là nơi dữ liệu được chuẩn bị lại cho một mục đích sử dụng khác. LOD nào được giữ lại, geometry được xử lý ra sao, hệ tọa độ được chuyển đổi như thế nào, thuộc tính nào cần được đưa sang lớp hiển thị, dữ liệu được chia tile theo nguyên tắc nào và ứng dụng phía sau sẽ truy cập những thông tin đó ra sao — tất cả đều có thể ảnh hưởng tới kết quả cuối cùng. Nếu chỉ quan tâm đến việc “đưa được mô hình lên Cesium”, chúng ta có thể hoàn thành một bản demo; nhưng nếu mục tiêu là xây dựng một hệ thống có thể tiếp tục mở rộng thành Urban Digital Twin, những quyết định ở lớp trung gian này mới là phần quyết định chất lượng của pipeline.
Một ví dụ thực tế từ PLATEAU
Project PLATEAU của Nhật Bản là một ví dụ khá rõ cho cách hai lớp dữ liệu này được sử dụng trong cùng một hệ sinh thái. PLATEAU cung cấp 3D City Model ở dạng CityGML, đồng thời có các pipeline chuyển đổi CityGML sang 3D Tiles để phục vụ việc phân phối và hiển thị trong môi trường Cesium. Tài liệu của PLATEAU liệt kê nhiều phương án cho quá trình này, trong đó có PLATEAU GIS Converter, FME, Cesium ion và một số công cụ khác. (GitHub)
PLATEAU GIS Converter cũng cung cấp một ví dụ cụ thể: dữ liệu CityGML của 23 quận Tokyo được chuyển đổi sang 3D Tiles để sử dụng trong Cesium. Đây không phải là một pipeline chỉ tồn tại trên lý thuyết; chính PLATEAU đã tách lớp dữ liệu CityGML khỏi lớp dữ liệu phục vụ visualization và phân phối, để cùng một nguồn dữ liệu đô thị có thể được đưa vào những cách sử dụng khác nhau. (GitHub)
Điều đáng chú ý hơn nữa là PLATEAU không coi 3D Tiles đơn giản như một bản sao của CityGML. Tài liệu chuyển đổi của họ mô tả rõ mục đích của việc chuyển CityGML sang 3D Tiles là để dữ liệu 3D City Model có thể được trực quan hóa trong môi trường Cesium, đồng thời vẫn có những quy định về cách tổ chức các thuộc tính chủ đề trong dữ liệu đầu ra. Điều đó cho thấy quá trình chuyển đổi không chỉ liên quan tới geometry; cách các thuộc tính được đưa sang lớp visualization cũng là một phần của thiết kế dữ liệu. (GitHub)
Vậy khi chuyển đổi, dữ liệu nào còn lại?
Đây có lẽ là câu hỏi đáng đặt ra hơn việc “dùng công cụ nào để convert”.
Giả sử một CityGML dataset chứa rất nhiều thông tin về các công trình trong thành phố. Một ứng dụng chỉ cần hiển thị hình khối của các tòa nhà sẽ không cần toàn bộ những thông tin đó; nhưng nếu sau này người dùng muốn chọn một tòa nhà trên màn hình, xem thuộc tính, lọc các công trình theo một điều kiện hoặc sử dụng dữ liệu đó cho một bài toán phân tích, việc loại bỏ metadata ngay từ bước conversion sẽ khiến chúng ta phải quay lại dữ liệu nguồn để lấy thông tin bổ sung. Khi đó, một pipeline tưởng như đã được tối ưu cho Web lại vô tình tạo ra một khoảng cách giữa lớp visualization và lớp dữ liệu đô thị phía sau.
Đây là lý do việc chuyển đổi nên bắt đầu từ use case, thay vì bắt đầu từ câu hỏi “công cụ nào convert CityGML tốt nhất?”. Với mỗi ứng dụng, chúng ta cần xác định trước dữ liệu nào phải được giữ lại, dữ liệu nào chỉ cần ở nguồn, geometry cần tới mức nào, người dùng sẽ tương tác với đối tượng ra sao và lớp Web 3D có cần truy cập metadata hay không. PLATEAU đã phải xây dựng riêng các quy tắc chuyển đổi cho việc đưa CityGML vào 3D Tiles, trong đó có cả cách tổ chức thuộc tính chủ đề, thay vì chỉ thực hiện một phép chuyển đổi hình học đơn thuần. (GitHub)
Một mô hình 3D đẹp chưa phải là một pipeline tốt
Có một điểm rất dễ bị bỏ qua khi xây dựng Digital Twin: phần Web 3D là phần dễ nhìn thấy nhất, nhưng lại không phải nơi quyết định toàn bộ giá trị của hệ thống.
Khi mô hình đã xuất hiện trên màn hình và người dùng có thể bay qua các khu phố, chúng ta thường có cảm giác rằng phần khó nhất đã hoàn thành. Thực tế, đó mới là lúc có thể nhìn thấy kết quả của hàng loạt quyết định được đưa ra trước đó: dữ liệu nguồn được thu thập như thế nào, mô hình hóa ra sao, geometry và semantics có được giữ đúng quan hệ hay không, LOD được lựa chọn thế nào, hệ tọa độ có thống nhất không, dữ liệu có được kiểm tra trước khi chuyển đổi không và cuối cùng những thông tin nào cần được giữ lại khi đưa lên Web.
Nếu những lớp này không được thiết kế ngay từ đầu, chúng ta vẫn có thể tạo ra một Web 3D rất đẹp, nhưng sẽ khó trả lời câu hỏi quan trọng hơn: mô hình đó còn có thể làm được gì ngoài việc hiển thị?
Một Urban Digital Twin cần nhiều hơn một lớp visualization. Nó cần một chuỗi dữ liệu có khả năng tiếp tục được sử dụng cho những bài toán khác nhau, từ phân tích không gian, simulation đến quản lý và vận hành. Trong kiến trúc đó, CityGML có thể đóng vai trò của một lớp mô hình dữ liệu đô thị có cấu trúc và ngữ nghĩa, còn 3D Tiles là một trong những lớp phân phối dữ liệu được tạo ra để đưa thông tin 3D tới môi trường sử dụng. Hai lớp này không thay thế nhau; giá trị nằm ở cách chúng được nối với nhau bằng một pipeline phù hợp.
Góc nhìn của MH&T
Từ góc nhìn của MH&T, câu chuyện CityGML và 3D Tiles vì thế không nên được đặt dưới dạng lựa chọn công nghệ. Điều cần quan tâm trước tiên là kiến trúc dữ liệu: dữ liệu nào là nguồn, dữ liệu nào là lớp trung gian, dữ liệu nào được tối ưu cho visualization và thông tin nào phải tiếp tục tồn tại để phục vụ những ứng dụng khác trong tương lai.
Khi tách được những lớp này, việc lựa chọn công cụ trở nên rõ ràng hơn. CityGML có thể giữ vai trò của mô hình dữ liệu đô thị; 3D Tiles giải quyết bài toán phân phối và streaming; Cesium hoặc một Web 3D engine khác đảm nhiệm lớp hiển thị và tương tác. Nhưng giữa chúng không thể thiếu những bước như validation, coordinate transformation, LOD management, geometry processing và metadata mapping. Chính những phần thường ít được nhìn thấy này mới tạo nên một pipeline có khả năng mở rộng.
Và khi đã nhìn Digital Twin theo cách đó, câu hỏi tiếp theo tự nhiên sẽ không còn là làm thế nào để hiển thị một CityGML trên Web, mà là những nguồn dữ liệu khác có thể đi vào cùng kiến trúc này như thế nào. BIM là một trong những trường hợp đáng quan tâm nhất, bởi dữ liệu BIM và CityGML cùng mô tả thế giới xây dựng nhưng được tạo ra cho những mục đích và cấu trúc rất khác nhau. Khi một mô hình BIM cần trở thành một phần của 3D City Model, chúng ta phải quyết định những thông tin nào được chuyển đổi, những thông tin nào cần giữ lại và chúng sẽ tiếp tục đi qua pipeline CityGML → 3D Tiles như thế nào.
Đó mới là bước tiếp theo của bài toán: BIM và CityGML kết nối với nhau như thế nào trong một Urban Digital Twin?
Nguồn tham khảo: OGC CityGML 3.0; OGC 3D Tiles; Project PLATEAU – PLATEAU GIS Converter và PLATEAU 3D Tiles Streaming Documentation.
