返回 BIM 与 IFC 博客
当数字孪生从一栋建筑扩展到一个街区时，每次讨论都会提到三种格式：CityGML、IFC 和 3D Tiles。人们常把它们并排比较，好像必须分出胜负。其实它们并不竞争：每一种回答的是不同的问题，而城市孪生通常三种都需要。
要点
- CityGML（及其 JSON 编码 CityJSON）把城市描述为对象：建筑、道路、地形、植被，并按细节层次（LOD）划分。
- IFC 逐个构件地描述单个资产，带有运维所需的类型、属性和关系。
- 3D Tiles 用于传输：它把任何 3D 内容切分成瓦片，让浏览器由粗到细地流式加载。
- 在它们之间转换，总会丢失一些东西。让每种源数据保持各自的格式，只在传输时才转换。
三种分工，而不是三个对手：城市、资产，以及把两者送进浏览器。
CityGML：以对象描述城市
CityGML 是开放地理空间信息联盟（OGC）制定的 3D 城市模型标准[citygml]。它把城市描述为带类型的对象：建筑、桥梁、道路、水体、植被、地形，每个对象都有属性，几何则按细节层次表达，从底面轮廓（LOD0）到带门窗洞口的立面（LOD3）。许多国家级和城市级数据集都以它发布；CityJSON[cityjson] 则用 JSON 编码同一个数据模型，在浏览器中处理起来要容易得多。
它的优势在于广度：整个街区，分类一致。它的局限在于深度：CityGML 中的一栋建筑并不知道自己地下室里有一台水泵。它的细节层次与 BIM 的 LOD 如何对比，见 BIM 与 CityGML 中的 LOD。
IFC：逐个构件描述资产
IFC 是 buildingSMART 制定的建筑和基础设施模型开放模式（Schema），以 ISO 16739-1 发布[ifc]。每一面墙、每一扇门、每一台水泵、每一根停车桩都是一个构件，带有类型、属性、工程量，以及与周围构件的关系。这正是孪生对其跟踪的资产所需要的：可供绑定实时数据的标识，以及维护所依赖的数据。要把 IFC 模型放到地图上，需要它的地理配准信息，即 IfcMapConversion，详见 IFC 坐标与地理配准。
3D Tiles：为流式传输而生
3D Tiles 是 OGC 的社区标准[3dtiles]，解决的是另一个问题：把海量 3D 内容送进浏览器。一个瓦片集（tileset）是一棵瓦片树，每个瓦片都有自己的细节层次；查看器先加载粗略的瓦片，再在相机所看的位置逐步细化。摄影测量网格、点云和整个城市模型都是这样传输的。至于瓦片表达什么含义，仅限于它们携带的元数据。
并排对比
| CityGML / CityJSON | IFC | 3D Tiles |
|---|
| 描述对象 | 城市对象 | 单个资产，逐个构件 | 任意 3D 内容，以瓦片形式 |
| 典型尺度 | 从街区到国家 | 建筑、桥梁、车站 | 最大可达全球 |
| 语义 | 每个对象的类和属性 | 类型、属性、关系、系统 | 每个瓦片或要素的元数据 |
| 几何 | LOD0–3 的表面 | 每个构件一个实体 | 网格（glTF）、点云 |
| 真实世界中的位置 | 内置 | 可选（IfcMapConversion） | 内置 |
| 最擅长 | 全市范围内一致的数据 | 资产标识和数据 | 把大模型送进浏览器 |
城市孪生如何组合使用它们
常见的做法是：城市模型用 CityGML 或 CityJSON，提供周边环境并支持全市范围的分析；承载实时数据或需要维护的资产用 IFC；两者中哪一个大到无法一次性传送，就用 3D Tiles 流式传输。把 IFC 转成 CityGML，保留的是外壳，丢掉的是大部分语义；把任何一种转成 3D Tiles，保留的是外观，其余所剩无几。所以，让每种源数据保持各自的格式，只在传输时才转换。
在本博客的实时案例中，周边环境是以拉伸体块绘制的 OpenStreetMap 建筑，大致相当于 LOD1；资产则是 IFC 模型，因为实时数据绑定的正是它们。这个查看器读取 IFC，目前不读取 CityGML，也不读取外部的 3D Tiles。这些案例及其展示的内容，见什么是城市数字孪生。
CityGML、IFC 与 3D Tiles 的区别：数字孪生该用哪种格式？
