1.2.3场景数据存储管理方法：

常见GIS数据存储管理系统：

1.基于关系数据库，包括基于关系数据库空间扩展和基于关系数据库的空间引擎；

2.基于非关系数据库（NoSQL数据库），包括文档、键值、列、图四类典型的NoSQL数据库；

3.基于文件系统的，基于HDFS分布式文件系统的数据仓库。

关系数据库支持ACID事务，处理多模态场景数据存储需求时写入效率低，难以扩展存储容量。

NoSQL数据库设计遵循CAP理论（即一致性、可用性、网络分割），提供了比关系数据库ACID事务更为松散BASE(即基本可用、软状态、最终一致性)并发事务模型。

键值存储适合分布时数据，但不合适需要表达关系、或者复杂数据结构的场景。因为模型结构简单，数据查询速度远高于传统关系数据库。但是其查询和修改操作只支持基于键的点对点查询和字符串级别的范围查询，不支持地理空间范围查询，无法直接存储空间数据。

列模型中由于每一列的数据类型相同，可以获得较大的数据压缩比率，节省存储空间。

文档模型与键值模型类似，通过键定位存储在磁盘中的值。

图模型源于图论，通过节点以及节点内键值对形式的属性表达数据对象，边及其键值对形式的属性表示节点对象之间的连接和语义，此外对象模型可以拥有标签从而实现对节点的分类，关系边可以拥有方向表示关系的起点和终点。

NoSQL数据库处于发展初期，对空间数据的支持弱，需要开发独立的空间数据索引层或者引擎，因此基于关系数据库的GIS数据存储管理方式不会被淘汰，将与NoSQL数据库一同组成混合持久化方案。

1.3.2：研究内容

研究内容1：多模态场景数据时空索引机制

研究内容2：基于时空关系图的多层次混合时空索引方法

研究内容3：基于微服务架构的场景数据组织管理引擎

研究内容4：场景数据组织管理原型系统及实验分析

2.1多模态场景数据

2.1.1场景数据多模态特点

多模态：场景数据来源广泛和类型多样。

场景数据：不同于传统GIS数据库或者云数据中心基于外存储管理的数据，更靠近应用端。

特点：多元、多维、多尺度、动态变化、复杂关联、全生命周期管理需求。

数据分类：

1.基础框架数据：是场景构建的背景数据，其空间位置和几何形状相对稳定，具有规模大、变化小、跟新慢等特点。

2.智能感知数据：具有时空信息的动态数据，其空间位置或状态值随时间显著变化，具有时空序列性强、数据量大、更新快等特点。

3.关联关系数据：场景中广泛存在的，在社会空间、物理空间和信息空间三元世界交叉融合、相互作用中产生，表示时空对象、过程和事件在空间、时间和语义等方面的关联关系，具有典型的高维、动态和复杂交织特点，如社交网络、物联网、道路网等关系数据。

2.2多层次可视化任务需求

三个层次：

展示性可视化：这一类可视化以数据为驱动力，属于数据I/O密集型应用。与基础框架数据对应。

分析性可视化：这一类可视化任务以数据+模型为驱动力，属于数据I/O密集型和计算密集型应用。与智能感知数据对应。

探索性可视化：这一类可视化任务以数据+模型+交互为驱动力，属于计算密集型和交互探索密集型应用。与关联关系数据对应。

索引算法选择：对于属性字段可采用B树及其变种索引，对于DEM(数字地形数据)和DOM（正射影像数据）这一类呈现多分辨率平面分布特点的数据可以采用四叉树进行索引组织，对于建筑和单体模型可采用LOD-R树空间索引计算其包围盒范围并进行索引组织。

查询则需要提供面向需求的点查询、范围查询、拓扑关系查询和属性字段查询等。

2.2全局-局部协同的时空索引机制

全局索引位于是整个索引框架的最上层，位于内存，作用是对进入系统的多模态场景数据在全局层面快速建立时间、空间、语义和关联关系索引。常见分为4类：空间划分、数据划分、时间划分和降维。图模型具有和树索引相似的结构组成，相较于树索引它将空间拓扑关系、时间关系扩展为了场景中更为广泛存在的关联关系。局部索引是指对全局索引处理后的数据单元进行进一步索引组织的过程，存在于外存磁盘，用作处理框架数据和备份的历史智能感知数据。

3.1基于稀疏矩阵的时空关系图索引

构建时空关系图：

使用LPG（Labeled Property Graphs,标签属性图）对场景数据进行抽象表达，主要包含四种表达方式：节点（数据实体）、关系（节点之间的联系）、属性（键值形式存在于节点和关系之间）、标签（表示节点的角色和类型）。

基于平面四叉树生成地理字符编码。

3.1.3基于系数矩阵的内存存储和操作

将时空关系图索引存储在内存环境中，避免索引节点访问时因内外存交换产生I/O时延。每一个节点和关系都与内存中唯一键值类型的内存对象通过ID唯一绑定。不同于以节点分裂、合并为核心的树形结构空间索引不同，时空关系图索引操作主要涉及到对内存对象的更新和稀疏矩阵运算。

3.2多层次混合时空索引方法结构及原理

3.2.1总体架构

全局索引模块除了时空关系图索引之外，在内存处理部分还采用了基于HashMap和SkipList的数据缓存结构，HashMap是用来缓存进入系统的待处理多模态场景数据，而SkipList则在HashMap的基础上提供数据记录的排序功能。

3.2.3典型多模态场景数据局部索引组织方法

（1）基础框架数据的索引组织

一维的示意性对象符号及其属性描述。

二维的栅格瓦片数据。

三维的建筑物和管线模型。

（2)智能感知数据的索引组织

实时产生的智能感知数据有人流、物流、信息流等。这些属于时序数据，可以采用时序数据模型。

Key值对应时空关系图中相应数据节点ID。将近一段时间内的数据全部存储在内存缓存之中。对于历史数据，可以设定存储时间粒度（如30分钟），将这段时间的数据进行打包存储。

3.3内外存索引更新与优化

3.3.1内外存索引更新机制

预先设置同步跟新规则，批量处理缓存在内存中的各类基础框架数据、智能感知数据和关联关系数据，避免对全局索引和局部索引的频繁写入和更新操作。智能感知数据实时接入导致全局索引中对应实体对象节点产生大量的数据节点，所以为了维持内存中时空关系图索引节点和关系数目规模在一个合理的范围内，需要设置淘汰机制。本文设计一种基于时间的节点更新机制。

3.3.2时空关系图索引优化

当单个节点的连接数目超过一定阈值时，对单个关系的查询和修改开销会急剧增加，产生超级节点。解决方法时在内存中通过HashMap和SkipList这两种数据结构实现一个有序集合，对时间节点和空间节点的连接数目进行排序，当连接数目超过阈值，会额外在内存中记录该节点的连接情况。

4.1场景数据引擎设计

4.1.1概述

分为三层，存储层、索引层、查询层。

4.1.2引擎机制

该机制由三部分组成：以内存为中心的场景数据存储机制、全局-局部协同的时空索引机制、面向任务的时空关系查询和调度机制。 

内存为中心的场景数据存储机制：如图所示，前文已有介绍，这里主要提及内存集群。

全局-局部协同的时空索引机制：上一章详细介绍。

面向任务的时空关系图查询与调度机制：本文主要针对3种可视化，在钢铁物流场景中可以扩展延伸到各个应用场景中。

4.2.2多模型数据存储与多模式数据视图

实现支持多种数据模型的数据存储管理系统常见方法有2种：1.通过选择多种模型的数据库系统进行一体化集成，缺点时引擎开发与维护困难，需要深入研究多种模型ide数据库促成农户优化方案。2.基于单一原生的基础模型构建并实现其他数据模型，这样做法的优点是分层数据模型更能展现底层基本模型的特性，但系统设计更为复杂，性能上也会降低。论文实现对表、文档、键值、图四种数据模型的支持。表模型选择关系型数据库PostgreSQL;文档模型选取文档类型NoSQL数据库MongoDB;键值模型采用键值类型NoSQL数据库Redis实现；图模型是在键值模型基础上实现。

4.3多样化场景数据查询

4.3.1时空查询

考虑先对时间维度还是空间维度进行筛选。

4.3.1模糊时空关系查询

5.原型系统与实验分析

原型系统

6.总结与展望

进一步工作：

1.多模态场景数据时空索引机制有待进一步完善。

2.基于时空关系图的多层次混合时空索引方法性能有待进一步提升。

3.场景数据多模型存储微服务有待进一步改进。