Digital Twin đô thị không nên được hiểu như một mô hình 3D phục vụ trình diễn, mà là một phương pháp xây dựng “bản sao số” có khả năng mô tả, phân tích và hỗ trợ ra quyết định dựa trên dữ liệu. Tuy nhiên, chính vì phụ thuộc mạnh vào dữ liệu nên nhiều dự án gặp rào cản ngay từ khâu đầu: hoặc tiếp cận một bộ dữ liệu quá lớn và phức tạp (nhiều lớp, nhiều tệp, nhiều cấu trúc) nhưng thiếu tiêu chí phân loại và quy trình xử lý, dẫn đến không xác định được điểm khởi đầu; hoặc sở hữu mô hình 3D có chất lượng hiển thị cao nhưng nghèo ngữ nghĩa/thuộc tính, khiến nó khó phục vụ các tác vụ phân tích và mô phỏng một cách đáng tin cậy.
Vì vậy, series này được viết theo một trật tự có chủ đích. Trước hết là cách dữ liệu đô thị 3D được phân phối và dùng trong thực tế. Tiếp theo là cấu trúc CityGML, vì đây là chuẩn gốc phổ biến để lưu trữ dữ liệu có ngữ nghĩa. Sau đó, series mới đi vào LOD, hệ tọa độ và quy trình chuyển đổi. Nhờ đi theo lộ trình này, người đọc có thể đánh giá dữ liệu bằng tiêu chí rõ ràng, thay vì đánh giá bằng cảm nhận thị giác
Trong phần 1 này, chúng ta sẽ trả lời hai câu hỏi tưởng đơn giản nhưng quyết định cả dự án: Dữ liệu lấy ở đâu và Định dạng dữ liệu nghĩa là gì.
1) “Lấy dữ liệu ở đâu?” không chỉ là tìm một link tải về
Khi nói về dữ liệu Digital Twin đô thị, nhiều người hình dung một bộ dữ liệu duy nhất. Tuy nhiên, trong thực tế, thành phố số thường được ghép từ nhiều nguồn. Mỗi nguồn phản ánh một nhóm thông tin khác nhau. Vì vậy, câu hỏi quan trọng không phải là tải ở đâu, mà là dữ liệu nào phục vụ trực tiếp cho mục tiêu nào.
Chọn dữ liệu theo mục tiêu sử dụng
Chẳng hạn, với quy hoạch, nhóm dữ liệu ưu tiên thường là ranh giới, sử dụng đất, chỉ tiêu và lớp quy hoạch. Trong khi đó, với vận hành đô thị, trọng tâm chuyển sang tài sản công và hiện trạng hạ tầng. Ngoài ra, dữ liệu quan trọng còn gồm lịch sử sự cố và dữ liệu cảm biến như điện, nước, giao thông, môi trường. Nếu mục tiêu là XR hoặc truyền thông, mô hình 3D cho hiển thị sẽ quan trọng hơn. Khi đó, trải nghiệm người dùng thường là ưu tiên chính. Từ đây, có thể rút ra một nguyên tắc. Mục tiêu sử dụng quyết định loại dữ liệu. Sau đó, loại dữ liệu sẽ quyết định định dạng phù hợp.
Ba nhóm nguồn dữ liệu thường gặp ở Việt Nam
Thứ nhất là dữ liệu do cơ quan nhà nước, địa phương hoặc đơn vị tư vấn cung cấp. Ví dụ gồm bản đồ nền, quy hoạch và hiện trạng. Thứ hai là dữ liệu của doanh nghiệp và dự án. Ví dụ gồm BIM, hồ sơ hoàn công, quản lý tài sản, nhật ký vận hành và IoT. Thứ ba là dữ liệu nguồn mở và dữ liệu quan sát, ví dụ OpenStreetMap, ảnh vệ tinh, ảnh UAV và LiDAR. Nhóm thứ ba giúp tạo bối cảnh nhanh. Tuy nhiên, nhóm này đòi hỏi kiểm tra chất lượng và giấy phép sử dụng.
Nhìn tổng thể, dữ liệu đô thị 3D hiếm khi tồn tại như một gói hoàn chỉnh. Do đó, cách tiếp cận phù hợp là thiết kế kiến trúc dữ liệu đủ linh hoạt để ghép dần từng phần. Đồng thời, dự án cần có tiêu chí kiểm tra và cập nhật ngay từ đầu. Khi thiếu hai yếu tố này, hệ thống thường khó mở rộng và khó duy trì chất lượng theo thời gian.
2) CityGML là gì, và vì sao nhiều quốc gia chọn nó làm “chuẩn gốc”
Khi đã xác định cần mô hình đô thị 3D ở mức dữ liệu, bạn sẽ thường gặp CityGML. CityGML là một chuẩn quốc tế thuộc hệ chuẩn OGC. Chuẩn này mô tả mô hình đô thị 3D dưới dạng dữ liệu có cấu trúc. Về kỹ thuật, CityGML dựa trên XML. Vì vậy, nội dung được tổ chức theo các phần rõ ràng, gồm hình học, đối tượng và thuộc tính.
Điểm quan trọng của CityGML nằm ở ngữ nghĩa. Nói cách khác, dữ liệu không chỉ có hình dạng tòa nhà. Nó còn có thông tin để xác định đối tượng là gì và thuộc lớp nào. Đồng thời, dữ liệu có thể chứa thuộc tính và mức chi tiết. Nhờ vậy, mô hình phù hợp cho phân tích và mô phỏng.
Tuy nhiên, CityGML cũng có nhược điểm thực dụng. Vì là XML và giàu cấu trúc, tệp có thể lớn. Hơn nữa, nhiều công cụ phổ thông không xử lý trực tiếp hiệu quả, đặc biệt là công cụ nội dung 3D. Do đó, câu chuyện định dạng trở nên quan trọng ngay từ giai đoạn triển khai.
3) “Định dạng dữ liệu” không phải chuyện sở thích, mà là chuyện tối ưu theo mục tiêu
Trong Digital Twin đô thị, hiếm khi chỉ dùng một định dạng. Thay vào đó, thường có một định dạng chuẩn gốc để lưu trữ theo cấu trúc. Đồng thời, hệ thống sẽ có nhiều định dạng triển khai cho từng ngữ cảnh sử dụng.
Chẳng hạn, CityGML có thể được xem là định dạng gốc để bảo toàn cấu trúc và thuộc tính. Tuy nhiên, nếu mục tiêu là hiển thị trên web, bạn thường cần định dạng dạng tile. Cách này chia dữ liệu thành các mảnh nhỏ và chỉ tải phần đang xem. Nhờ đó, trải nghiệm sẽ mượt hơn. Ngoài ra, nếu mục tiêu là dựng nội dung trong phần mềm 3D hoặc game engine, bạn sẽ cần định dạng phù hợp với quy trình dựng hình. Ví dụ phổ biến là OBJ hoặc FBX. Còn khi cần ảnh nền địa hình hoặc ảnh trực giao, bạn sẽ làm việc với các định dạng ảnh có gắn tọa độ như GeoTIFF.
Điểm mấu chốt là mỗi định dạng có đánh đổi. Định dạng tối ưu hiển thị thường giảm bớt cấu trúc hoặc thuộc tính. Ngược lại, định dạng tối ưu phân tích thường nặng và cần quy trình xử lý chặt chẽ. Trong khi đó, định dạng cho sản xuất nội dung thường ưu tiên bề mặt và vật liệu. Vì vậy, thay vì hỏi định dạng nào tốt nhất, bạn nên hỏi định dạng nào phù hợp với mục tiêu ở giai đoạn hiện tại.
4) Bài học từ Nhật Bản: phân phối và khuyến khích chuyển đổi theo nhu cầu
Nhật Bản là một ví dụ đáng tham khảo. Ở đó, dữ liệu mô hình đô thị 3D được chuẩn hóa và phân phối qua các cổng dữ liệu địa lý. Điểm đáng học không chỉ là có dữ liệu. Quan trọng hơn là cách tổ chức dữ liệu. CityGML thường được dùng như chuẩn gốc. Ngoài ra, một số đô thị còn cung cấp các bản chuyển đổi hoặc dữ liệu hỗ trợ để người dùng bắt đầu nhanh hơn. Khi bản chuyển đổi không có sẵn, quy trình phổ biến là lọc và cắt theo phạm vi cần dùng. Sau đó, dữ liệu được chuyển đổi từ CityGML sang định dạng phù hợp với công cụ triển khai.
Tư duy này cũng phù hợp với Việt Nam. Nếu cố gắng dùng một định dạng cho mọi mục tiêu, dự án thường gặp hai rủi ro. Thứ nhất là hệ thống quá nặng để vận hành. Thứ hai là dữ liệu bị đơn giản hóa quá mức, nên không đủ cho phân tích. Ngược lại, nếu giữ một chuẩn gốc có cấu trúc, bạn có thể bảo toàn ngữ nghĩa và chất lượng. Đồng thời, các nhánh chuyển đổi theo mục tiêu như web, mô phỏng và nội dung sẽ giúp hệ thống linh hoạt hơn.
5) Lời khuyên cho người mới ở Việt Nam: bắt đầu nhỏ, nhưng bắt đầu đúng
Điểm khó nhất khi bước vào Digital Twin đô thị không nằm ở thiếu công cụ. Vấn đề thường nằm ở thiếu tiêu chí chọn dữ liệu và thiếu quy trình kiểm tra. Vì vậy, người mới có thể bắt đầu theo một logic đơn giản nhưng nhất quán.
Ba bước ra quyết định nhanh ở giai đoạn đầu
Trước hết, hãy khoanh rõ phạm vi không gian, chẳng hạn theo quận, khu đô thị hoặc theo tuyến hạ tầng. Tiếp theo, hãy chốt mục tiêu sử dụng, ví dụ trực quan hóa cho truyền thông hay phân tích và mô phỏng cho ra quyết định. Khi hai yếu tố này đã rõ, nhóm định dạng ưu tiên thường sẽ tự lộ diện. Cuối cùng, hãy duy trì một nguồn dữ liệu gốc đáng tin. Dù triển khai bằng định dạng nào, bạn vẫn cần dữ liệu gốc có cấu trúc để cập nhật, kiểm chứng và mở rộng. Với đô thị, dữ liệu không chỉ lớn, mà còn sống; và thứ khiến hệ thống mạnh lên theo thời gian không phải số lượng file, mà là chất lượng cấu trúc và khả năng cập nhật.
Kết luận: Dữ liệu đúng định dạng là nền móng của Digital Twin “làm ra tiền” và “đỡ rủi ro”
Một Digital Twin đô thị đáng tin bắt đầu từ dữ liệu, không bắt đầu từ mô phỏng. Trước hết, bạn cần xác định dữ liệu lấy từ đâu và giấy phép ra sao. Tiếp theo, bạn cần kiểm tra dữ liệu có cấu trúc hay không. Cuối cùng, bạn phải xác nhận dữ liệu phù hợp với mục tiêu sử dụng.
Ở đây, CityGML đại diện cho tư duy chuẩn gốc có ngữ nghĩa. Trong khi đó, các định dạng chuyển đổi đại diện cho tư duy triển khai theo mục tiêu. Khi kết hợp hai tư duy này, bạn tránh được hai sai lầm phổ biến. Một là làm mô hình hiển thị tốt nhưng thiếu dữ liệu cho phân tích. Hai là giữ dữ liệu chuẩn quá nặng nhưng không có kế hoạch triển khai.
Khi nền móng đã đúng, các bước tiếp theo sẽ trở nên rõ ràng hơn. Bạn sẽ đọc cấu trúc dữ liệu dễ hơn. Bạn cũng sẽ chọn LOD và xử lý tọa độ, độ cao đúng cách. Đồng thời, bạn có thể thiết kế pipeline chuyển đổi để vận hành ổn định.
Đọc tiếp Phần 2
Sang Phần 2, chúng ta sẽ đi vào câu hỏi mà rất nhiều đội dự án gặp phải: “CityGML bên trong trông như thế nào, và làm sao biết bộ dữ liệu mình có đang chứa đúng đối tượng, đúng thuộc tính, đúng cấu trúc để dùng cho bài toán?” Từ đó, bạn sẽ biết cách kiểm tra dữ liệu một cách hệ thống, thay vì chỉ mở phần mềm lên và hy vọng “nó chạy được”.