超图三维数据格式解析

之前有讲过Cesium的三维数据格式：3dtiles。。。https://www.cnblogs.com/2008nmj/p/14395128.html

超图的三维数据格式和它有什么不同呢？它比3dtiles好在哪里？

https://github.com/SuperMap/s3m-spec/tree/master/S3M_SDK/S3M_Parser_JS

空间三维模型数据格式规定了三维地理空间数据格式的逻辑结构及存储格式要求。

该标准适用于网络环境和离线环境下海量、多源三维地理空间数据的数据传输、交换和高性能可视化，以及满足不同终端(移动设备、浏览器、桌面电脑)上的三维地理信息系统相关应用。

该标准定义的S3M数据格式具备以下技术特点和优势：

1、支持表达多源地理空间数据：倾斜摄影模型、BIM、人工建模、激光点云、矢量、地下管线等多源数据。
2、具备海量数据高效绘制的能力：支持LOD、批次绘制、实例化等，提升渲染性能。
3、具备单体化选择和查询能力：支持高效选择、支持批量修改对象颜色、批量修改对象可见性。
4、简洁易读：格式简洁，易解析，适用于WebGL等轻量级客户端。
5、高效传输：数据紧凑，以二进制形式保存，占用空间小，传输性能高。
6、快速载入显卡：数据结构尽可能跟OpenGL接口保持一致，减少加载时间，高性能，低消耗。
7、跨终端：独立于任何终端，适用于PC端、Web端、移动端，具有较好的兼容性。
8、扩展性好：支持扩展，允许增加一些多用途扩展或特定厂商的扩展。
9、完善的工具支撑：提供开源免费的S3M数据解析和转换工具，支持3D-Tiles、OSGB等格式与S3M格式相互转换。(开源地址：https://github.com/SuperMap/s3m-spec。)
10、完善的配套设施：完整的解决方案，成熟的可行性，强大的实用性。基于S3M形成了完整的B/S及C/S架构的三维GIS应用解决方案，从数据生成、服务器端发布到多种客户端加载应用等多个环节解决用户实际问题。

目录

前言 Ⅲ …………………………………………………………………………………………………………

引言 Ⅳ …………………………………………………………………………………………………………

１ 范围 １ ………………………………………………………………………………………………………

２ 规范性引用文件 １ …………………………………………………………………………………………

３ 术语和定义 １ ………………………………………………………………………………………………

４ 符号和缩略语 ２ ……………………………………………………………………………………………

４．１ 缩略语 ２ ………………………………………………………………………………………………

４．２ ＵＭＬ图示符号 ２ ………………………………………………………………………………………

４．３ ＵＭＬ多样性描述 ３ ……………………………………………………………………………………

５ 基本规定 ３ …………………………………………………………………………………………………

５．１ 基本数据类型 ３ ………………………………………………………………………………………

５．２ 字符串类型 ４ …………………………………………………………………………………………

５．３ ｊｓｏｎ格式存储 ４ ………………………………………………………………………………………

６ 组织结构 ４ …………………………………………………………………………………………………

６．１ 文件组织 ４ ……………………………………………………………………………………………

６．２ 树形结构描述 ５ ………………………………………………………………………………………

７ 存储格式 ５ …………………………………………………………………………………………………

７．１ 描述文件 ５ ……………………………………………………………………………………………

７．２ 数据文件 ８ ……………………………………………………………………………………………

７．３ 索引树文件 ２１ …………………………………………………………………………………………

７．４ 属性文件 ２２ ……………………………………………………………………………………………

附录 Ａ （资料性附录） 数据示例 ２５ …………………………………………………………………………

参考文献 ３２ ……………………………………………………………………………………………………

前言

我们现在还需要多一种三维数据格式吗？似乎数据格式已经够多了够用了。但是很多的数据格式是不公开的，保密的，只能导入不能导出。而且多源三维数据格式无法统一。

近年来，倾斜摄影建模、激光扫描等数据采集技术的发展，有效降低了三维空间数据的获取成本和 时间周期，提高了数据精度。伴随大规模三维空间数据的不断积累，三维空间数据的高效发布、数据共享和数据交换，成为三维GIS研究重要内容。

本标准定义了一种开放式可扩展的空间三维模型数据格式———Spatial 3D Model（S3M），适用于空间三维模型数据的传输、交换与共享，有助于解决多源空间三维模型数据在不同终端（移动设备、浏览器、桌面电脑）地理信息平台中的存储、高效可视化、共享与互操作等难题，对于推动我国三维地理空间 数据的共享及深入应用具有重要作用。

目前，S3M 涵盖的数据类型包括：

ａ） 传统模型：人工建模三维模型数据；

ｂ） 实景三维：包括倾斜摄影建模数据和点云数据；

ｃ） 建筑信息模型（Building Information Modeling，BIM）数据：采用BIM设计软件制作的三维模型数据；

ｄ） 矢量数据：包括二维点／线／面数据、三维点／线／面数据、三维管线数据。

 

１ 范围

本标准规定了一种空间三维模型数据格式的文件组织结构及存储格式要求。 本标准适用于网络环境和离线环境下三维空间数据的传输、交换与共享，也适用于三维空间数据在 不同终端（移动设备、浏览器、桌面电脑）上的三维地理信息系统相关应用。

２ 规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文 件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

ＧＢ／Ｔ７４０８—２００５ 数据元和交换格式 信息交换 日期和时间表示法

ＧＢ／Ｔ１６８３１—２０１３ 基于坐标的地理点位置标准表示法

ＧＢ／Ｔ３０３２０—２０１３ 地理空间数据库访问接口

ＧＢ／Ｔ３３１８７．１—２０１６ 地理信息 简单要素访问 第１部分：通用架构

３ 术语和定义

下列术语和定义适用于本文件。

３.１ 瓦片 tile 对应一个二维矩形或三维长方体空间，邻接瓦片之间空间范围可重叠。

３.２ 根节点 root node Tile Tree的根节点。 注：一个Tile Tree只有一个根节点，其空间范围是所有子节点的并集。

３.３ 瓦片树 tile tree 由唯一的根节点自上而下逐级划分的、多细节层次的树形空间数据结构，树形结构的每个节点表示 一个Tile。 注：父节点Tile的空间范围是所有子节点Tile的并集。

３.４ 瓦片树集合 tiletreeset 由一个或多个tiletree构成的集合。

３.５ LOD分片 patchLOD 表示TileTree中指定LOD层的一个数据分片。 注：一个LOD可包含一个或多个PatchLOD。

３.６ 数据片 patch PatchLOD的一个数据分片。 注：一个PatchLOD可包含一个或多个Patch，每个Patch有零个或一个父Patch，有零个或多个子Patch；父Patch 的空间范围是各子Patch空间范围的并集；Patch的父子关系构成树状结构。

３.７ 数据包 geode 表示一个Patch对应的数据包。 注：每个Patch可包含零个或多个Geode。Geode包含了骨架、材质、纹理三种实体对象。

３.８ 实体对象 model entity Geode的基本数据构成，包含骨架、材质、纹理三种实体类型。

３.９ 骨架 skeleton 几何数据信息，包括顶点、顶点索引、纹理坐标、纹理坐标索引等。 注：骨架附带材质信息。

３.10 材质 material 模型对象表面各可视化属性的集合，包括模型对象表面的色彩、纹理、光滑度、透明度、反射率、折射 率、发光度等。

３.11 纹理 texture 纹理贴图信息，包含宽、高、压缩方式及纹理二进制数据等。

４ 符号和缩略语

４.１ 缩略语

下列缩略语适用于本文件。

EPSG：欧洲石油测绘组织（The European Petroleum Survey Group）

LOD：细节层次（Level of Detail）

ＵＭＬ：统一建模语言（Unified Modelling Language）

WKT：常用文本表示（Well Known Text Reperesentation）

４.２ UML图示符号

本标准出现的图用 ＵＭＬ静态结构表示。

所有数据模型 ＵＭＬ图示中符号表示的规定见表１。

表１ UML图符号对照表

４.３ UML多样性描述

本标准涉及的 ＵＭＬ图中多样性描述含义见表２。

表２ UML图多样性描述

５ 基本规定

５.１ 基本数据类型

本标准涉及的基本数据类型规定见表３。

表３ 数值数据类型规定

５.２ 字符串类型

本标准涉及的字符串数据类型用String对象描述，采用 Unicode编码，字符集规定为 UTF８。

String｛
 int32 length； ／／字节数 
 byte str[length]；／／数据内容
｝

５.３ json格式存储

本标准涉及的json格式存储，规定 UTF８编码，不带BOM 头。

６ 组织结构

６.１ 文件组织

本标准规定的数据的组成文件主要包括：描述文件、数据文件、索引树文件、属性文件。

描述文件和数据文件是基础组成部分。描述文件中包含一个或多个 TileTree的根节点路径；数据 文件通过TileTree组织，TileTree中每个Tile对应一个．s3mb文件；索引树文件是对 Tiletree中各 Tile的描述，可以在不加载实际数据的情况下，获取LOD层的各Tile的包围盒、LOD切换信息、挂接 的子节点文件路径等，主要作用是加速 Tile文件检索的效率；属性文件包括属性描述文件和属性数据 文件。各类文件的组织形式见表４。

表４ 文件组织形式

 

６.２ 树形结构描述

树形结构相关对象的UML图见图１。

           图１ 树形结构UML图

７存储格式

７.１ 描述文件

７.１.１ 描述文件概述

描述文件（TileTreeSetInfo对象），用于描述数据的基本信息，关联对象的 UML图见图２。

                              图２ 描述文件的UML图

７.１.２ 描述文件标签信息

描述文件各标签含义见表５。

表５ 描述文件各标签含义

 

 表６Rect对象各标签含义

表７ Range对象各标签含义

表８ WDescript对象各标签含义

 表９ Position对象各标签含义

 表10 Point3D对象各标签含义

 表11 TileTreeInfo对象各标签含义

 表12 BoundingboxInfo对象各标签含义