i3s，esri主推到ogc的一种三维开源GIS数据标准。
版权声明：原创。博客园/B站/小专栏/知乎/CSDN @秋意正寒
转载请标注原地址并声明转载: https://www.cnblogs.com/onsummer/p/12082584.html
1. i3s及其实现i3s是一种用树结构来组织大体积量三维数据的数据格式标准，比如在位图界的jpg格式一样，只不过i3s是“标准”，具体实现的文件格式另有一说。
i3s采用json文件来描述数据，采用二进制文件（格式为.bin）来存储三维地理数据。
i3s是OGC规范，目前OGC版本是1.0，但是在Esri维护的社区项目中，i3s已经演进到1.7了。可以说是“一般”与“特殊”的区别。
OGC标准一旦制定就不应该频繁更改，但是社区维护版本可以根据实际生产需要，基于OGC标准做结构优化等。
i3s标准将三维地理数据切分，用“节点”的概念组织起来，然后这些节点被有序地写在“节点页”中。说白了就是树形结构。
i3s将三维地理数据组织起来后，可以放在服务器上通过REST接口访问。
i3s目前由slpk格式的文件实现。
附：i3s对三维地理数据的分类3d模型——传统3d建模的精模转换数据
表面模型——倾斜摄影数据
三维点
三维点云
建筑——BIM数据
为什么不用bim文件、为什么不用现有的三维数据格式呢？
首先，商业软件的三维数据格式并不开源，而i3s格式是开源的，只要熟读标准可以自己编程创建（难度比较大就是了）。
其次，开源的三维数据格式不具备地理信息。
最后，bim数据不面向地理信息系统。
所以，在三维GIS萌芽的今天（指这个年代），一种开源的三维地理数据规范就显得十分重要。
1.1. i3s标准的数据组织和结构在前文提到i3s使用的是树结构组织数据，同时支持规则四叉树或者R树组织。每个树节点代表的地理数据的范围，由外包围球（mbs）或外包围（obb）盒表示。
官方推荐使用外包围盒表示范围（和二维的外包矩形，类似），点云数据仅支持外包围盒。
1.1.1. 节点和节点页一份三维地理数据应该合理的切分，i3s使用树结构切分，以适应大量数据的快速分发、显示。
切分的结果就是“节点（Node）”，组织这些节点的结构叫做“节点页（NodePage）”。
在1.6及早期版本中，节点信息是写在一个叫3DNodeIndexDocument.json.gz文件中的，即3DNodeIndexDocument文档，节点一多，遍历小文件频率增加，对IO性能有不小的影响。
所以在1.7版本中，将这个3DNodeIndexDocument文档聚合到“节点页”中去了，类似于索引的功能（i3s的i就是index嘛）。
官方给出的树状结构示意图。
1.1.2. 节点构成节点由两个部分构成：要素和节点资源。
即 Node = Feature + NodeResources
要素的概念和二维上的要素是一样的，都表示一个地理实体，比如一栋建筑。
节点资源，包括要素的几何数据、属性数据（这两个数据见我的博客《聊聊GIS数据的四个分层》），以及三维数据中的材质纹理信息。
即 NodeResources = Geometry + Attributes + Textures
注意：并不是所有的节点都包括这三大资源的。3d模型类型的地理数据和建筑数据均包括这三大资源。
① Geometry
几何数据在不同版本的i3s（社区版本）有不同的表达。在1.7版本中，3d模型和表面模型几何数据用draco压缩格式的二进制文件存储。
在构造三角面时，顺序为逆时针方向（这点我不太清楚，图形学的朋友可以深入一下）。
所有几何顶点的坐标均相对于1.1中提及的obb或者mbs的中心的。obb或者mbs的中心若为零点原点，则还需要加上顶点偏移，使其偏移到正确的坐标系上，这个偏移量在json文件中是有的。
应指定坐标轴的正方向，默认是x-东，y-北，z-高程。
② Attribute
同一个要素的几何数据和属性数据分别存在两个不同的二进制文件中。属性数据的顺序和几何数据的顺序一样。
③ Texture
纹理就是指纹理图像文件，被存储为二进制文件。
=============
为了确保与1.6版本的兼容性，1.7的i3s标准还需要包括3dNodeIndexDocument.json描述文件，以及可用于任何节点的sharedResources目录。
1.2. i3s中的统计数据