再来给世界建模

Table of Contents

• 建模的重要性
• 模型的选取原则
• Geodatabase
  • 简介
  • 基本数据类型
  • 特点
  • 其他
    • shapefile
    • extend shape buffer
• I3S
  • 简介
  • 基本数据类型
  • 数据模型
    • 空间索引
    • LoD
    • 图层
    • 节点
    • 要素
    • 共享资源
  • 数据请求与存储
    • 请求
    • 存储
  • 特点
  • 其他
• KML
  • 简介
  • 基本数据类型
  • 特点
  • 其它
• CityGML
  • 简介
  • 对象
  • LoD
  • BIM,CityGML,GIS
• IFC
  • 简介
  • IFC与BIM
    • 数据交换格式
    • 设计和施工
    • 数据模型
  • IFC,BIM,GIS

在这里谈谈对于地理对象数据模型的理解吧。

建模的重要性

最早有为世界建模的想法是从看《Modeling Our World》一书而来。为什么要建模，先引用这本书中译本的一句话：

地理数据模型是GIS中用以对真实世界进行模拟表达，它能够应用于地图生产、交互式信息查询以及功能分析等。数据库技术和软件技术的不断发展也促进了新一代地理数据模型的产生。

微盘地址

在我看来，对事物的抽象之后，就能将各种知识泛化的应用于其他相近的场景和领域。这也是一个通过学习经验转换为知识的过程。像很多公司，团队做的小项目，为什么在一个地区或者一个场景下，可以做得很好，但换了另一个场景或者换一个地区就不能复现之前的好效果了。一部分原因也是在于对于业务数据、逻辑没有做合适层面的抽象。导致切换场景之后，很多东西不能复用。

模型的选取原则

对于不同的行业，不同的地理尺度，不同的业务需求，对于模型的要求也是不一样的。所以数据的使用方式是模型选取（或者说数据规范的选取）的关键。
在我看来，对于传统的GIS需求，使用Geodatabase中的各种模型是一个不错的选择。对于城市级别的应用，CityGML是一个不错的选择，不过据我所知，CityGML在欧洲发展和应用得不错，在中国还需要更多推广。对于建筑物BIM的信息表达和交互来说，类IFC更加广泛。对于三维场景的渲染，使用Esri的i3s或者Cesium的3d tile也是不错的选择。对于数字地球来说，使用KML作为数据交换格式也是一种选择。

下面则分别介绍这几种模型（数据标准）：

Geodatabase

简介

Esri在经历了Coverage和shapefile数据格式之后，开始使用Geodatabase：地理数据库。ArcGIS 地理数据库是存储在通用文件系统文件夹、Microsoft Access 数据库或多用户关系 DBMS（如 Oracle、Microsoft SQL Server、PostgreSQL、Informix 或 IBM DB2）中的各种类型地理数据集的集合。地理数据库大小不一且拥有不同数量的用户，可以小到只是基于文件构建的小型单用户数据库，也可以大到成为可由许多用户访问的大型工作组、部门及企业地理数据库。

基本数据类型

• 使用Feature（要素）来表示各种离散对象（各种矢量对象）。常用于有确定的形状或者边界和不连续的对象。Feature又由Geometry（点线面）和Attribute组成，有精确的形状和位置，属性和元数据。
• 使用栅格来表示影像数据。可以用来做底图和地形。常见来源是卫星影像或者航空相片。
• 使用TIN（三角格网）来表示地形数据。不过现在似乎很多系统中也用栅格来存储地形表面数据，在客户端才进行构网操作。
• 地址和定位（address and locator)

在gdb中，还可以定义和查询要素之间的关联的情况。如要素的拓扑关系（连通性等），空间位置关系（相交，相离，包含等），以及一般关联（人为定义两个要素之间有联系，如地块和业主）

特点

• 能较为完善的表达地理对象，以及对象之间的关联关系。
• 泛用性很强，大到国家，小到各种基础设置都可以用它来表示。
• 使用ArcSDE可以将gdb格式的功能和扩展了空间功能的关系型数据库有机结合。可以支持多用户编辑。

其他

对于geodatabase的各种增删改查，Esri都提供了库。
在这里还是列举下格式的表示：

shapefile

shapefile中的几何体类型还比较少：

对于一个简单的多边形，我们可以这样表述：

extend shape buffer

• 更详尽的shape buffer的描述：下载File Geodatabase API，在\doc\html\extended_{shapebufferformat}.pdf里面。

举个例子，对于三维物体的描述，也就是multipatch的组成结构，我们可以看这张表：

I3S

简介

Indexed 3D Scene Layer，是Esri新的三维数据格式标准，也是OGC新的国际三维标准。为三维数据专门设计。基于JSON，REST以及新的web标准，能友好的支持Web、移动和云。

GitHub地址

I3S作为开放的标准，可用于流式传输具有大数据量、多种类型地理数据集的三维内容。三维内容可包含离散的三维模型、密集格网(倾斜摄影测量建模成果，3D Mesh)、三维矢量点、点云以及其它内容。

I3S支持非常大的数据集的存储和传输，可大至包含数百万个具有属性对象的离散三维模型或覆盖数千平方公里的倾斜摄影测量建模成果。I3S具有为三维专门设计，为Web、移动和云专门设计，可扩展支持多种类型的三维数据的特点。

基本数据类型

目前支持的数据类型有：
- 3D Objects，即离散三维模型
- Integrated Meshes，即倾斜摄影测量建模结果
- Point，离散点
- PointCloud，激光点云数据集

数据模型

空间索引

为了支持包含海量数据的场景，I3S对场景进行了空间划分，在空间树中的各个节点中包含了要素数据或者模型数据。
如下图所示：

LoD

在I3S中，没有过多的语义上的约束或者描述，所以细节层次(LoD)完全是按照当前视口的显示尺度来完成的。每一层节点就是一层细节。但在某一个节点中，不包含多层细节。这一点和OSGB， GityGML略有不同。所以在客户端渲染时，切换层级的话，要在节点的层面上进行(node-switch)。

图层

定义了场景中的图层的各种元数据，例如空间参考，高程模式，空间索引的树的类型，几何体的组织方式，属性字段和属性类型，标签类型，符号化，渲染方式。纹理材质信息等。具体结构如下：

节点

定义的在该场景中节点的范围，层级，空间尺度信息，LoD切换方式，父节点，子节点，节点中要素、模型的id，节点中纹理材质id等。具体结构如下：

要素

定义了节点中每一个要素、模型的信息，如几何体的类型，几何体二进制存放位置，索引方式，属性二进制存放位置，索引方式。具体结构如下：

共享资源

这一部分主要是描述了纹理和材质的内容，编码方式，存储位置，结合上面要素对象的信息就可以渲染出一个完整的三维模型。

数据请求与存储

请求

I3S的特点之一是使用REST API来请求数据，和服务器没有太复杂的交互，比较适合云端架构。（客户端的发起的POST请求，云端的任何一个节点都可以提供数据资源）

服务端需要保证以下资源，客户端可以按照URL Pattern进行数据请求。

• Common Services Information

  URL Pattern: http://<hostname>/arcgis/rest/services/
  Method: GET
  Example Service: http://3dcities.maps.arcgis.com/arcgis/rest/services/
  Returns: A List of all services running on the server instance.
  返回服务信息。
  

• 3dSceneServiceInfo

  URL Pattern: <ags-base-url>/<server-name>/SceneServer
  Method: GET
  Example Service:http://3dcities.maps.arcgis.com/arcgis/rest/services/New_York_LoD2_3D_Buildings/SceneServer
  Returns: Scene Service metadata and list of available layers.
  返回服务的元数据和包含图层。JSON
  

• 3dSceneLayerInfo

  URL Pattern: /layers/
  Method: GET
  Example Service:http://3dcities.maps.arcgis.com/arcgis/rest/services/New_York_LoD2_3D_Buildings/SceneServer/layers/0
  Returns: Detailed information about single layer, including symbology, field schema, and profile/store metadata, with a link to the root 3dNodeIndexDocument
  返回图层的元数据，json格式

• 3dNodeIndexDocument

  URL Pattern: <layer-url >/nodes/<node-id>
  Method: GET
  Example Service:http://3dcities.maps.arcgis.com/arcgis/rest/services/New_York_LoD2_3D_Buildings/SceneServer/layers/0/nodes/5-1-0-0-0
  Returns: A file describing a single node in the spatial index, with links to all associated resources such as FeatureData, textures, Geometry and
  返回节点的各种信息，会包含要素数据，纹理，几何体等。JSON
  

• SharedResources

  URL Pattern: <node-url>/shared/
  Method: GET
  Example Service:http://3dcities.maps.arcgis.com/arcgis/rest/services/New_York_LoD2_3D_Buildings/SceneServer/layers/0/nodes/5-1-0-0-0/shared
  Returns: A feature data resource (bundle)
  返回要素数据的纹理材质信息描述。JSON
  

• FeatureData

  URL Pattern: <node-url>/features/<feature-data-bundle-id>
  Method: GET
  Example Service:http://3dcities.maps.arcgis.com/arcgis/rest/services/New_York_LoD2_3D_Buildings/SceneServer/layers/0/nodes/5-1-0-0-0/features/0
  Returns: A feature data resource (bundle) 
  返回要素数据的描述.JSON
  

• GeometryData

  URL Pattern: <node-url>/geometries/<geometry-data-bundle-id>
  Method: GET
  Example Service: <a href=http://3dcities.maps.arcgis.com/arcgis/rest/services/New_York_LoD2_3D_Buildings/SceneServer/layers/0/nodes/5-1-0-0-0/geometries/0
  Returns: A geometry data resource (bundle)
  返回几何体的二进制
  

• TextureData

  URL Pattern: <node-url>/textures/<texture-data-bundle-id>
  Method: GET
  Example Service:http://scene.arcgis.com/arcgis/rest/services/Hosted/Buildings_San_Francisco/SceneServer/layers/0/nodes/1-3-0-0-0-0-0-0-0/textures/0_0
  Returns: A texture data resource (bundle). Refer to the i3s format specification for details on how different encodings and resolutions are encoded.
  返回纹理的二进制
  

存储

• SLPK

  对于一般的数据交换，例如数据厂商将他们的产品转换为i3s格式发送给客户的场景需求，可以使用SLPK的方式。大概来说就是zip之后的上述i3s资源。
  具体见文档scene layer package format specification

• Database

  可以使用散文件的方式，也可以使用数据库进行存储。只要服务端能映射为上述的REST请求即可。一般来说，因为在i3s node中包含了空间索引的信息，使用NoSQL数据可以保证更快的读取效率，也方便与云端扩展。

特点

• 由于加入空间索引和LoD，并优化了存储以及访问方式。比较适合于大场景，大范围海量数据的渲染展示。
• 在客户端也可以做基本的三维分析，如日照，通视，视域分析。
• 数据按属性渲染快，但是对整个图层进行属性查询效率不高。需要和SQL数据库或者gdb，服务配合使用。
• 数据更新和编辑比较麻烦。但是用于所固定场景的底图非常合适。

其他

贴一些图吧，这是用i3s发布的公司视图的寻路功能。（Esri Campus Viewer)

旧金山建筑

KML

简介

KML严格来说不是一种模型，是一种标记语言，KML英文全称是Keyhole Markup Language，基于XML语法标准进行扩展，最早是应用于Google地球的软件中，用于显示地理数据，现在也是一种常用的地理数据交换格式。KML也是OGC标准之一，详细文档可以点击这里。 KML在developers.google中的地址，点击这里。

但就我所知，KML的确很强大。在中国KML的影响力还够，虽然基本的三维GIS软件都支持KML，但是并没有完全应用它的特性，也没有作为项目产品的主要输入输出格式。

基本数据类型

完整的结构如下图所示：

ref: https://developers.google.com/kml/documentation/kmlreference

KML为数字地球中的三维场景设计，所以除了普通的图像，要素对象之外，也包含了场景中的各种对象。下面的简介中会包含这些对象，但是不包括KML语言本身的特性，如它自身的语法，组织结构之类的。
- 从几何体上来看，它包括，点，线，面，模型。
- 从要素上来说，它支持NetWorkLink（可以联网，实时刷新，例如实时显示各航班飞机位置）， 导览（Tour，按位置播放整个序列，包括popup，声音，视频，地图要素），Placemark和叠加层（Overlay）
- 可以使用Popup/Ballon来显示要素的属性页面。
- 支持时间戳，可以按时间浏览数据。
- 加入了三维的相机（Camera）和高程模式。
- 支持星空
- 支持影像，底图

特点

• 作为三维展示来说比较全面了，如果用到全部的功能，效果会很好。
• 作为三维纯数据的交互来说，也比较好，因为格式全面且标准。
• 标准扩展性强，可以加入自定义格式。
• 没有空间索引，空间关系，拓扑关系的定义。只是单纯的文件树型组织，所以在行业应用方面不是很通用。
• Popup和Tour在Web端效果不好。

其它

列一些例子吧。

使用KML的Networklink和Esri的GeoEvent实现对出租车的位置的动态显示。

使用KML显示航线

金门大桥

CityGML

简介

CityGML是用以表达三维城市模板的通用数据模型。它定义了城市和区域中最常见的地表目标的类型及相互关系，并顾及了目标的几何、拓扑、语义、外观等方面的属性，包括专题类型之间的层次、聚合、目标间的关系以及空间属性等。这些专题信息不仅仅是一种图形交换格式，同时可以将虚拟三维城市模型用于各种应用领域中的高级分析，例如模拟、城市数据挖掘、设施管理、专题题查询等。

（以上摘自百度百科）

CityGML也是OGC标准之一，使用XML格式描述数据。文档下载点击这里。

我看来，CityGML在欧洲发展得比较好，所以很多欧洲的项目都有对CityGML的需求。虽然没有geodatabase的泛用性广。但由于主要支持城市级别的应用，对于有一定的支持能力。

对象

不同于Geodatabase，i3s，kml。CityGML对于对象的定义十分细致，所以如果有涉及到具体的领域，可以参考它的这些对象。

• DTM
• Building
• Tunnel
• Bridge
• Water bodies
• Transportation
• Vegetation
• City furniture
• Land use
• User-definable grouping

关于对象的UML图，我就列几个举个例子吧，详细的点击这里。

• 概览

• 要素的类图第一部分（主要是可以和i3s进行对比）

LoD

抛开那些详细的语义定义的模型，来说，CityGML的另一个亮点就是对于LoD的定义了。这里面会分为5层LoD。这种分级方式会在很多数据定义和数据标准里面提到，也是大家对于数据精细程度的一个标准。

LOD 0 – regional, landscape 地域模型
LOD 1 – city, region 楼块
LOD 2 – city districts, projects 粗糙的模型
LOD 3 – architectural models (outside), landmarks 详细贴图和建模
LOD 4 – architectural models (interior) 更精细的建模，包括室内

示意图如下：

目前i3s支持的数据还是集中在LoD1，LoD2, LoD3。能大规模的支持LoD4的数据的软件还是比较少。

BIM,CityGML,GIS

关于BIM和GIS结合，之前有一个CityGML GeoBIM的扩展。详情点击这里。 其中也涉及到BIMServer，主要是一些实现的细节，就不在这里展开了，详情点击BIMServer。

IFC

简介

IFC标准是建筑行业信息化过程中必定会出现的产物，具有两个非常重要的特点：1.IFC标准是完全开放的；2.IFC是数据交换标准，用于异构系统之间交换数据、共享信息。

IFC定义超过600个建筑实体以及超过300个抽象类型，共计逾900种定义 。构件种类繁多，构件与构件之间的空间关系异常复杂。要想对IFC进行模型转换，就需要对建筑构件进行归纳分类，根据转换的实际需求，保留需要转换的几何类型与语义信息，去除在3DGIS领域不需要的信息，避免为转换增加难度的同时又降低转换的效率。

IFC建筑构件主要是在共享层中定义的，共享建筑构件以及共享建筑服务构件构成主要的构件实体与相关抽象类型所属超类。

共享建筑构件定义的实体数量总共为47个，可以大致归为14种类型。表1罗列了部分实体。

共享建筑服务构件定义的实体数量为31个。不过这些实体主要用于领域层内的暖通工程领域、建筑管理领域、防火管理领域等领域。

IFC与BIM

说到IFC都会和BIM联系起来。

数据交换格式

IFC可以作为数据交换格式，里面会包含几何体和非几何数据，这些数据都可以用于显示和分析。数据定义比较详细，而且数据标准开放，文档详细，所以从软件中导出IFC格式的数据，可以被其他软件使用。
例如，IFC格式目前可以用过FME转换为Esri能支持的数据（gdb）

设计和施工

IFC目前也广泛应用于设计和施工中。在设计中，主要是可视化和碰撞检测。而且可以引用CAD文件和其他学科领域的模型。能包含几何，数据和时间表。从一个应用程序导出，导入到另一个工具中还能继续的进行设计或者分析。
以下图为例：

数据模型

IFC本身也是数据模型，在包含几何和非几何信息的同时，也有类型定义。可以让同一个项目和不同项目中的类似物体共享属性。用户可以将常用信息（例如维护说明，型号，尺寸等）附加到类型中，但将特定属性（如序列号，安装日期，条件等）附加到对象实例中。这些属性本身具有特定的结构。属性通常分组在属性集中。其中一些是在IFC标准中定义的，一些是在BIM执行计划等中定义的。还定义了建筑元素之间的关系。其中一些关系用于建立系统，类型，属性集合等。另关系描述了建筑组件如何成为建筑物。这些关系包括空间结构（如何由建筑物，建筑物楼层，房间（空间）以及空间如何分组成区域），还有一些关系将元素的位置连接到这个空间结构，这对于设施管理比较重要。关系也可以是外部地址指向任务或文件的外部指针。

IFC,BIM,GIS

目前Esri支持将Revit和IFC格式数据转为自己的格式，中间会有数据丢失，但是流程是通用的。
对于I3S来说，目前对于精细数据LoD4的BIM数据，还是有显示效率方面的问题。需要分多个图层来解决。