Digital Twin đô thị — P.2: Cấu trúc CityGML và cách kiểm tra dữ liệu một cách hệ thống

Ở Phần 1, chúng ta đã thống nhất một nguyên tắc cốt lõi: CityGML chính là Semantic Single Source of Truth (SSOT) của toàn bộ dự án, trong khi các định dạng như 3D Tiles, OBJ, hay FBX chỉ là các output formats phục vụ mục đích hiển thị. Nếu cố chạy theo một model 3D thiên về visual nhưng nghèo semantic, dự án sẽ thất bại ngay khi bước vào giai đoạn analysis và simulation. 

Tuy nhiên, khoảng cách từ tư duy lưu trữ bằng chuẩn gốc cho đến việc xử lý file thực tế là một bài toán rất nặng. Nhận source data CityGML nặng vài chục GB từ vendor, điều tối kỵ là ném thẳng nó vào data pipeline (như FME) hay các 3D engine (Cesium, Unreal). Parse mù quáng một file XML khổng lồ mà không rõ cấu trúc nội tại sẽ trực tiếp gây ra lỗi Out of Memory (OOM) hoặc crash hệ thống.

Để trả lời câu hỏi ở cuối Phần 1: “Làm sao biết bộ dữ liệu mình có đang chứa đúng object, attribute và structure để dùng cho bài toán?”, bạn buộc phải tiến hành inspect và validate data theo quy trình hệ thống dưới đây trước khi đưa vào production pipeline.

1. OGC Open Standard & Bản chất thực sự của CityGML

OGC (Open Geospatial Consortium) là tổ chức quốc tế chuyên thiết lập các open standard cho geospatial data. Trong hệ sinh thái này, CityGML là một tiêu chuẩn cốt lõi (GML3 application schema) dùng để lưu trữ và trao đổi các 3D city model.

Đừng nhầm lẫn CityGML với các pure graphic formats như FBX hay OBJ. CityGML là một cơ sở dữ liệu (Database) định dạng XML text-based. Điểm ăn tiền của CityGML nằm ở chỗ nó duy trì tính toàn vẹn và mối liên kết chặt chẽ giữa geometry, topology và semantic thông qua cấu trúc LOD (Level of Detail).

2. “Giải phẫu” cấu trúc bên trong CityGML

Cấu trúc CityGML được module hóa cực kỳ chặt chẽ thông qua các XML Namespace. Thay vì nhồi nhét mọi thứ, nó chia data thành các không gian độc lập như core (lõi), bldg (building), tran (transportation) hay veg (vegetation).

Dưới đây là schema xương sống của một file CityGML:

XML

<?xml version="1.0" encoding="UTF-8"?>
<core:CityModel xmlns:core="http://www.opengis.net/citygml/2.0"
    xmlns:bldg="http://www.opengis.net/citygml/building/2.0"
    xmlns:gml="http://www.opengis.net/gml">
    
    <!-- 1. Bounding Box & CRS: Tọa độ ranh giới và Hệ quy chiếu -->
    <gml:boundedBy>
        <gml:Envelope srsName="urn:ogc:def:crs,crs:EPSG::25832">
            <gml:lowerCorner>458868.0 5438343.0 112.0</gml:lowerCorner>
            <gml:upperCorner>458892.0 5438362.0 117.0</gml:upperCorner>
        </gml:Envelope>
    </gml:boundedBy>

    <!-- 2. Feature Node: Chứa object thực tế -->
    <core:cityObjectMember>
        <bldg:Building gml:id="UUID_7b1a5a6f-ddad">
            <!-- Metadata (Semantic) -->
            <gml:name>Building A</gml:name>
            <bldg:yearOfConstruction>1985</bldg:yearOfConstruction>
            
            <!-- Geometry & LOD -->
            <bldg:lod2Solid>
               <gml:Solid>
                   <gml:exterior>...</gml:exterior>
               </gml:Solid>
            </bldg:lod2Solid>
        </bldg:Building>
    </core:cityObjectMember>
</core:CityModel>

Khi đọc đoạn code trên, kỹ sư chỉ cần quan tâm đến việc parse 3 nodes chính:

1. <gml:Envelope>: Xác định vùng không gian bao (Bounding Box) và Hệ quy chiếu (CRS).
2. <core:cityObjectMember>: Định danh loại object.
3. <bldg:lodXSolid>: Xác định cấu trúc hình học tương ứng với cấp độ LOD.

3. Actionable Checklist: 5 bước Validate dữ liệu hệ thống

Làm sao để biết file CityGML vendor deliver đáp ứng đúng object, attribute và structure của bài toán? Hãy chạy tuần tự 5 bước validate sau trước khi import data vào hệ thống.

Bước 1: Validate XML Schema (XSD)

• Action: Không dùng mắt thường. Chạy script Python (dùng library lxml với cơ chế iterparse để tránh nuốt sạch RAM) hoặc các tool chuyên dụng để đối chiếu toàn bộ file với bộ XSD chuẩn của OGC (ví dụ: core.xsd, building.xsd).
• Lý do: Vendor rất hay tự định nghĩa các custom tag sai chuẩn hoặc thiếu khai báo namespace. Bỏ qua bước này, parser của các map engine đích sẽ dính lỗi Fatal Error và crash hệ thống ngay lập tức.

Bước 2: Inspect Hệ Quy Chiếu (Coordinate Reference System – CRS/EPSG)

• Action: Đọc giá trị srsName trong node <gml:Envelope>. GML quy định CRS gốc này sẽ được kế thừa (inherit) cho toàn bộ cấu trúc geometry bên trong.
• Điểm nghẽn thực tế: Dữ liệu thu thập từ thiết bị bay (Drone/LiDAR) thường trả về raw data ở hệ tọa độ quốc tế WGS84 (EPSG:4326). Nhét thẳng vào map engine nội địa sẽ làm model lệch vị trí hàng chục mét. Bạn buộc phải xác định CRS hiện tại để thiết lập cấu hình cho tool Transform (qua FME hoặc GDAL/ogr2ogr) chuyển tọa độ về hệ tọa độ phẳng VN-2000 (ví dụ EPSG:3405 cho Hà Nội) trước khi render.

Bước 3: Profile loại Object & LOD Geometry bằng CLI/XPath

• Action: Tuyệt đối không tin vào cách đặt tên file kiểu District1_LOD2.gml hay Bridge_Data.gml. Mở Terminal dùng xmlstarlet hoặc grep để inspect nhanh mật độ tag đối tượng thực tế bên trong:Bash# Lệnh đếm số lượng và phân loại object dựa trên XML Namespace xmlstarlet el hanoi_citygml.gml | sort | uniq -c
• Case study:
  • Nếu file tên là Bridge_Data nhưng lệnh CLI trả về toàn tag <bldg:Building> mà không có <brid:Bridge>, hãy Reject file ngay lập tức sau 3 giây.
  • Nếu bài toán là tính toán bức xạ mặt trời (solar panel), hệ thống cần bóc tách độ nghiêng mặt mái. Nếu query XPath trả về toàn thẻ <bldg:lod1Solid> (khối hộp đơn giản – extruded polygon) thay vì <bldg:lod2Solid> hoặc <bldg:RoofSurface>, bộ data này hoàn toàn vô dụng.

Bước 4: Validate Tính toàn vẹn liên kết (Referential Integrity)

• Action: Dùng engine Schematron chạy bộ rules referentialIntegrity.sch do OGC cung cấp để check tự động các quan hệ tham chiếu chéo nội tại.
• Lý do: Để tối ưu dung lượng, CityGML thường dùng thuộc tính xlink:href trỏ đến một gml:id nhằm tái sử dụng cấu trúc geometry hoặc dán mác Texture. Khi vendor thực hiện cắt nhỏ file theo lưới không gian rất dễ làm đứt link, để lại các thẻ href trỏ đến một ID “dead”. Hậu quả khi hiển thị lên WebGIS là mô hình bị rách cấu trúc (broken polygon) hoặc vỡ toàn bộ texture.

Bước 5: Map UUID và Extract Attribute Theo Use Case

• Action: Quét và bóc tách các attribute quyết định khả năng phân tích của bài toán (ví dụ: bài toán ngập lụt cần check tag <bldg:storeysBelowGround> để lấy thông tin tầng hầm). Đồng thời, check tính độc nhất (Unique) của khóa gml:id.
• Điểm nghẽn thực tế: Các 3D city model do nhiều đơn vị sản xuất hiện nay thường gặp tình trạng “giàu graphic nhưng mù metadata”, thiếu hoàn toàn thông tin địa chính cơ bản. Đừng cố gắng nhồi nhét text attribute vào file XML vì sẽ làm phình dung lượng file một cách vô ích.
• Giải pháp tối ưu: Dùng chính gml:id làm Primary Key (PK). Giữ file XML CityGML gọn nhẹ (chỉ lưu geometry và các thuộc tính core) để làm mượt pipeline render. Toàn bộ thông tin địa chính, hồ sơ quy hoạch chi tiết sẽ được lưu trữ tách biệt ở một relational database (PostgreSQL/PostGIS) và thực hiện join với mô hình 3D theo realtime thông qua UUID này.

Kết luận: Làm chủ cấu trúc là làm chủ Pipeline

Khi bạn đã làm chủ được khả năng inspect cấu trúc CityGML, bạn không còn phụ thuộc vào việc mở phần mềm lên và cầu nguyện cho nó chạy. Bạn kiểm soát được chất lượng dữ liệu đầu vào, biết rõ nó có đáp ứng được yêu cầu của bài toán thực tế hay không.

Đọc tiếp Phần 3: Chúng ta sẽ đi sâu vào khái niệm LOD (Level of Detail) trong CityGML – một yếu tố thường bị hiểu nhầm nhiều nhất trong các dự án Digital Twin đô thị. Câu hỏi đặt ra không phải là làm thế nào để mô hình “chi tiết hơn”, mà là: Mức độ chi tiết LOD nào là đủ cho bài toán, và tại sao việc tăng LOD vô tội vạ lại là cái bẫy làm sập toàn bộ hệ thống vận hành?