EN中文

地球信息科学学报 >

2025 , Vol. 27 >Issue 6: 1289 - 1304

DOI: https://doi.org/10.12082/dqxxkx.2025.240715

第十九届中国地理信息科学理论与方法学术年会优秀论文

集成空间数据引擎和图数据库的复杂地理时空语义建模研究

  • 岳梓晨 , 1 ,
  • 钟少波 , 2, * ,
  • 梅新 1
展开
  • 1.湖北大学资源环境学院，武汉 430062
  • 2.北京市科学技术研究院城市系统工程研究所，北京 100035
*钟少波（1978—），男，湖北天门人，博士，研究员，主要研究方向为应急地理信息系统、城市安全协同感知。 E-mail:

作者贡献：Author Contributions

岳梓晨、钟少波、梅新参与实验设计；岳梓晨完成实验操作；岳梓晨、钟少波参与论文的写作和修改。所有作者均阅读并同意最终稿件的提交。

The study was designed by YUE Zichen, ZHONG Shaobo, and MEI Xin. The experimental operation was completed by YUE Zichen. The manuscript was drafted and revised by YUE Zichen and ZHONG Shaobo. All the authors have read the last version of paper and consented for submission.

岳梓晨（1998—），男，安徽阜阳人，硕士生，主要研究方向为地理知识图谱和时空语义建模。E-mail:

收稿日期: 2024-12-30

  修回日期: 2025-04-08

  网络出版日期: 2025-06-06

基金资助

国家自然科学基金项目(72174031)

收起

Research on Complex Spatiotemporal Semantic Modeling Integrating Spatial Data Engines and Graph Databases

  • YUE Zichen , 1 ,
  • ZHONG Shaobo , 2, * ,
  • MEI Xin 1
Expand
  • 1. School of Resources and Environmental Science, Hubei University, Wuhan 430062, China
  • 2. Institute of Urban Systems Engineering, Beijing Academy of Science and Technology, Beijing 100035, China
*ZHONG Shaobo, E-mail:

Received date: 2024-12-30

  Revised date: 2025-04-08

  Online published: 2025-06-06

Supported by

National Natural Science Foundation of China(72174031)

Fold

摘要

【目的】知识图谱作为一种融合多模态数据源的前沿技术，在GIS领域获得广泛关注。知识图谱主要通过图数据库构建。然而，目前主流的图数据库对地理时空数据的组织和分析仍面临挑战。【方法】为了解决这一问题，本文提出了一种桥接图数据库和空间数据引擎的时空语义建模与查询优化方法。该方法在图数据库中将地理实体存储为占位符节点（仅保留映射ID），并与时空索引节点（时间树、Geohash编码）建立关联，以增强时空聚合能力。同时，在关系数据库中存储完整的地理时空对象，并采用表分区策略优化检索效率。该方法通过统一标识符和JDBC实现跨数据库地理实体的路由映射，当用户调用图数据库中预注册的时空函数时，查询重写器基于实体标识符将图查询转换为SQL语句，并下推至关系数据库处理，随后将结果反馈至图查询流程。此外，引入两阶段提交协议保障异构数据库的数据同步性。【结果】本文通过集成Neo4j和PostGIS实现了该方法的原型系统，并基于深圳市多源时空数据集（包含出租车轨迹、共享单车轨迹、路网、POI及遥感影像），对不同规模数据进行查询和存储效率实验。结果表明：相较于主流图数据库系统（Neo4j、GraphDB），本方法在地理时空查询中显著提升性能，尤其在复杂计算场景下响应时间可缩短1~2个数量级，并支持原生图数据库无法实现的栅格计算；通过轻量化图节点和PostGIS数据压缩，存储空间减少约3~5倍。相较于虚拟知识图系统（Ontop），本方法在空间查询和存储消耗上差异较小，但在大规模时空查询中响应时间显著缩短。【结论】相较于现有方法，本文方法可直接利用现有图数据库构建实体化时空知识图，提升了地理时空知识图的建模灵活性和查询效率，且支持用户自定义扩展地理时空函数库，为知识图谱中地理时空数据的高效管理和分析提供了新的思路。

关键词： 图数据库; 关系数据库; 时空语义; 空间数据引擎; 查询优化; 知识图谱; 时空索引

本文引用格式

岳梓晨 , 钟少波 , 梅新 . 集成空间数据引擎和图数据库的复杂地理时空语义建模研究[J]. 地球信息科学学报, 2025 , 27(6) : 1289 -1304 . DOI: 10.12082/dqxxkx.2025.240715

Abstract

[Objectives] Knowledge graphs, as a cutting-edge technology for integrating multimodal data sources, have garnered significant attention in the GIS domain. These graphs are typically constructed using graph databases. However, mainstream graph databases still face challenges in effectively organizing and analyzing geospatial-temporal data. [Methods] To address this issue, this paper proposes an approach to modeling spatiotemporal semantics and query optimization that bridges graph and spatial data engine implemented within relational databases. In the graph database, geographic entities are stored as lightweight placeholder nodes (storing only mapping IDs) and linked to spatiotemporal index nodes (such as time trees and Geohash encodings) to enhance aggregation capabilities. Meanwhile, complete geospatial-temporal objects are stored in a relational database, while table partitioning strategies are employed to improve retrieval efficiency. This approach uses unified identifiers and JDBC for routing geographic entities across the databases. When users invoke pre-registered spatiotemporal functions in the graph database, a query rewriter transforms the graph queries into SQL statements based on entity identifiers, pushes them to the relational database for processing, and returns the results to the graph query pipeline. Additionally, a two-phase commit protocol ensures data consistency across the heterogeneous databases. [Results] We implemented a prototype system integrating Neo4j and PostGIS and conducted experiments on query and storage efficiency using a multisource spatiotemporal dataset from Shenzhen (including taxi trajectories, bike-sharing trajectories, road networks, POIs, and remote sensing imagery). Compared to mainstream graph database systems (e.g., Neo4j and GraphDB), our approach significantly improves performance for geospatial-temporal queries, reducing response times by 1~2 orders of magnitude in complex computational scenarios and enabling raster computations unsupported by native graph databases. By leveraging lightweight graph nodes and PostGIS data compression, storage space is reduced by approximately 3~5 times. Compared to virtual knowledge graph systems (e.g., Ontop), our method shows minimal differences in spatial query performance and storage overhead, while achieving notably faster response times for large-scale spatiotemporal queries. [Conclusions] Compared to existing methods, our approach leverages existing graph databases to construct materialized spatiotemporal knowledge graphs, enhancing modeling flexibility and query efficiency for geospatial-temporal data. It also supports user-defined extensions to the geospatial-temporal function library, offering a novel framework for efficiently managing and analyzing such data within knowledge graphs.

Key words： graph database; relational database; spatiotemporal semantics; spatial data engine; query optimization; knowledge graph; spatiotemporal index

1 引言

随着移动互联网、地理信息系统、卫星遥感等技术的高速发展，诸如位置服务、智慧城市、环境监测等领域产生了海量的地理时空数据。丰富的时空数据，以其复杂多维的结构、异构多样的类型和动态演变的特性，从不同的粒度和维度记录人类社会和自然环境的运行状态[1-2]。知识图谱作为融合多模态数据源的关键技术，在GIS领域获得广泛应用。然而，由于地理时空数据的特殊性与复杂性，尤其在空间数据组织、空间几何和拓扑计算上的高要求，使得知识图谱中时空数据的精确表达和推理面临显著挑战。如何在知识库高效地存储和管理地理时空数据，并支持复杂查询优化，成为当前亟待解决的关键问题[3-4]。
目前，关系数据库和图数据库是2种主流的时空数据组织和管理方式。关系数据库作为传统的结构化数据管理系统，在时空数据管理方面已经积累了丰富的理论和实践经验。通过集成内置的地理空间数据类型和操作符，或扩展空间数据引擎（如ArcSDE、PostGIS等），主流关系型数据库实现了对时空对象的原生支持，并依托成熟的索引机制和查询优化技术，在时空查询性能上具有显著优势[5]。然而，当面对大规模、高度关联的语义查询时，其需依赖多表连接等计算密集型操作，导致性能明显下降[6]。相比之下，图数据库基于有向无环图结构，能更直观高效地刻画数据间的复杂关联，通过模式匹配算法实现恒定时间复杂度O（1）的关联分析[7-8]。图数据库的语义数据存储主要包括三元组（RDF）存储、标签属性图（LPG）数据库和基于本体的数据访问（OBDA） 3种方式[9-10]。在RDF存储方面，已有大量研究探索使用RDF图管理时空数据，例如OGC制定的GeoSPARQL标准[11-12]，但在处理大规模时空RDF图时，查询性能难以满足实时交互需求[13]。LPG数据库为时空语义建模提供了更灵活的数据模型[14]，但目前主流的图数据库缺乏对时空数据类型和操作的原生支持，学者们提出了引入混合索引、GeoExpand运算符等改进方案[15-16]，但由于LPG图数据库在设计之初未将时空信息作为首要考虑，查询引擎和执行优化的适配还不够充分。OBDA系统在关系数据库之上构建虚拟知识图，通过映射将SPARQL查询转换为SQL查询，代表系统如Ontop进一步支持GeoSPARQL到SQL的转换[17]。这一思路允许复用关系数据库的时空索引和查询优化技术，能够提供知识图级别的数据访问接口，具有重要的借鉴意义，但本质上仍基于关系数据库构建虚拟知识图，对通用图数据库的支持有限。
综上所述，关系数据库在时空查询性能方面表现出色，但在处理关联数据时缺乏灵活性和效率；图数据库在灵活表达复杂语义方面具有天然优势，但在涉及地理数据管理和查询优化方面不足。为了兼顾语义表达能力和时空查询效率，本文提出一种融合图数据库和关系数据库的时空语义查询优化方法。该方法在图数据库中仅存储地理实体的映射ID和语义属性，而将几何等信息委托给关系型数据库管理。同时，在图数据库中引入了时空索引图，将每个实体节点与相应的时间树和空间编码节点相连，以优化图遍历过程中的时空聚合和匹配效率。当用户提交的图查询中包含预定义的地理空间函数时，计算任务会被下推到关系型数据库执行，并返回满足空间约束的目标实体ID和计算结果。随后，重启图端查询算子，继续执行直至生成最终结果。该方法适配主流图数据库与关系数据库，易于轻量化地集成至现有系统，为知识库赋予地理时空数据管理和查询能力。基于大规模真实数据测试显示，该方法在查询效率与语义表达能力上表现优异。

2 研究方法

本文方法采用了混合存储、跨数据库映射和查询转换等机制，其工作流程如图1所示。在GDBMS中，地理实体被视为占位符（仅存储标识符），并与时空索引节点相关联。RDBMS存储地理实体的完整时空属性。为了实现GDBMS与RDBMS之间的无缝集成和高效查询处理，本文方法集成了3个关键引擎（实体映射引擎、查询转换引擎和数据同步引擎）。其中，实体映射引擎在两个数据库之间建立桥梁，通过使用实体标识符合JDBC（Java Database Connectivity，Java数据库连接）将GDBMS地理实体（ ）与RDBMS地理实体（ ）链接，并提供外部接口供其他引擎调用。查询转换引擎负责将图数据库中预注册的时空查询函数转换为SQL语句并下推至RDBMS中执行。数据同步器引擎则基于2PC（Two-Phase Commit，两阶段提交）协议确保GDBMS与RDBMS之间的数据一致性。本节将重点讨论上述关键技术。
图1 地理时空语义查询的技术流程

Fig. 1 Overall workflow of geospatial-temporal semantic query

2.1 时空数据的存储优化

采用图数据库和关系型数据库的混合存储方式来管理地理时空数据。在图数据库中，地理实体节点采用轻量级存储策略。在关系型数据库中，关系表相应地存储地理实体对象的时空信息。

2.1.1 图数据库存储优化

为提升图查询和遍历的效率，在图数据库中仅存储必要的信息，包括：
（1）实体ID：全局唯一标识符，它将节点与关系型数据库中的相应实体关联。
（2）属性集：它以键值对的形式存储时空对象的其他语义属性。
此外，该方法为每个地理节点分配一个EntityClass标签，该标签映射到关系型数据库中的相应表名。EntityClass标签也可用于语义查询和类型过滤。图2显示了该方法在图数据库中组织地理空间数据的方案。地理节点（ ）可以与上下文节点（ ）关联，允许用户采用灵活的语义建模模式。此外，这些地理空间节点不直接在其属性中存储时空信息，而是通过“链接边”连接到专用的索引图。在该方法中，图数据库额外维护两种特殊类型的索引图：时间索引图和空间索引图。时间索引图使用时间树来组织和检索时间数据[18]。空间索引图使用Geohash编码对二维地理空间进行基于网格的划分和编码[19]。
图2 图数据库中组织地理空间数据的方案

Fig. 2 Scheme for organizing geospatial data in graph databases

2.1.2 关系型数据库存储优化

在关系型数据库中，定义与属性图中地理空间节点的图数据库标签（EntityClass）对应的关系表名，作为跨数据库节点-表映射和关联的基础。存储过程如图3所示。在字段组织方面，该方法采用“宽列”模型[20]，为每个实体定义时空和索引列，包括：
（1） EntityID：作为表的主键，它与图数据库中的EntityID相对应，用于跨数据库关联。
（2）空间属性：对于矢量数据，几何信息存储在Geom列中。对于栅格数据，图像二进制可以作为BLOB（二进制大对象）数据类型存储在Rast列中。
（3）时间属性：包括地理空间实体的时间戳，以标准时间戳格式存储。
（4） Geohash：表示地理空间实体所在矩形的Geohash编码，用于空间分区和索引。
图3 关系数据库中组织地理空间数据的方案

Fig. 3 Scheme for organizing geospatial data in relational databases

本文对矢量和栅格数据采用不同的策略：对于矢量类型的时空对象，关系表直接以Well-Known Text （WKT）格式存储其几何信息并计算矢量数据所在矩形的Geohash编码，将其存储在Geohash列中。其中，对于点对象，根据预设的Geohash编码长度（如长度=8，对应约38 m×19 m网格）生成相应编码；对线、面对象，首先提取其MBR左下顶点坐标（x1, y1）和右上定点坐标（x2, y2）。随后，生成完全覆盖该MBR的所有Geohash网格编码集合。对于栅格类型的时空对象，采用基于Geohash分区的图像分块方法。原始栅格被划分为规则的图块，每个图块转换为Well-Known Binary （WKB）格式进行存储。此外，矢量和栅格数据在Geohash列上针对集合对象构建索引：利用关系型数据库的GIN或GIST索引机制，支持对Geohash编码集合的高效存储与检索，并结合包含操作符（如PostgreSQL的 "@>"）实现空间分区数据的快速查询。关于时间属性，在关系型数据库中只存储时间戳，为了支持高效的时空查询，利用关系型数据库通常支持的分区特性（如Oracle的分区表或PostgreSQL的TimescaleDB扩展）。通过对Time列进行分区，相应地构建时间分区表，这些时间分区表基于预定义的时间分区范围（如每周或每月分区）进行划分。

2.2 时空实体的关联映射

为了在混合存储架构中实现图数据库和关系型数据库之间的无缝关联，引入了基于对象映射的实体关联机制。通过定义统一的对象标识规范和跨数据库映射元数据（表1），有效地为地理空间实体建立了异构数据库之间的语义链接。
表1 地理时空对象的属性映射表

Tab. 1 Attribute mapping table for geospatial-temporal objects

标识属性 图数据库 关系数据库
EntityID 地理节点的唯一标识符 实体表的主键
（关联地理节点的ID）
EntityClass 地理节点的标签 实体表名
（关联地理节点的标签）
Time 地理节点关联的时间索引 实体表的时间列
Geohash 地理节点关联的Geohash索引 实体表的Geohash列
图4说明了时空实体跨数据库映射的整个过程。在关系型数据库中包含一个专用的映射表，用于存储图数据库节点类型与关系型数据库表名之间的对应关系。在查询过程中，该方法根据节点实体标签（EntityClass）自动路由到关系型数据库中的相应实体表，并根据节点EntityID检索相应的时空对象记录，利用时空节点的多维属性来实现高效的时空剪枝，提高查询检索效率。使用JDBC进行跨数据库通信，确保了系统的兼容性和可移植性。
图4 地理实体的图数据库和关系数据库映射

Fig. 4 Mapping between graph and relational databases for geographic entities

2.3 时空查询的解析转换

本文引入查询重写机制，将用户在图数据库中提交的地理时空查询转换为关系数据库可执行的SQL语句，如图5所示。该机制由预定义函数库、参数解析器、SQL转换器和查询执行器组成。其工作流程如下：
图5 地理时空查询解析和转换过程

Fig. 5 Process of parsing and converting geospatial-temporal queries

（1）预定义函数库：在图数据库中预先注册一组常用的时空分析函数，如空间拓扑（Intersects、Within等）、空间度量（Distance、Area等）、时间拓扑（Before、After等）、时空判断（时空相交、时空包含等）。这类函数的注册和调用依托于图数据库的扩展机制实现，例如Neo4j通过用户自定义过程、JanusGraph采用Groovy语法等支持函数的扩展。
（2）参数解析器：当用户在图数据库中提交包含时空函数的查询时，参数解析器负责提取和解析函数调用中的参数信息。由于图数据库和关系数据库的数据组织方式不同，需要基于统一的跨数据库时空实体映射表（表1）将图数据库端的实体参数映射到关系数据库端对应的表名和主键。此外，还要识别用户指定的其他查询参数，如空间范围、时间段等，用于构造SQL语句的过滤条件。
（3）SQL转换器：根据解析出的函数名，SQL转换器从预定义的SQL模板库中匹配对应的SQL模板。其中，每一个图查询函数都对应配置了一个独立的SQL语句模板。SQL模板是参数化的SQL片段，包含表名占位符<EntityClass>、实体ID集合占位符<EntityIDSet>、时间范围占位符<TimeRange>、Geohash集合占位符<GeohashSet>以及空间几何占位符<wktGEOM>等参数。转换器将具体的表名、实体ID集合、时间范围、Geohash编码集合以及WKT格式的几何信息填充到占位符所在位置，形成完整可执行的SQL语句。
其中，图3的SQL转换器部分展示了一个对实体集进行“时空范围（withinST）查询”的参数化SQL模板示例，该模板采用PostgreSQL语法。其中<EntityClass>占位符表示要查询的实体表，<EntityIDSet>表示图数据库传入的实体ID集合。空间谓词ST_Within用于判断实体对象的几何是否在几何范围<wktGEOM>内。同时，模板引入<TimeRange>和<GeohashSet>占位符，利用PostgreSQL内置的表分区和包含操作符缩小数据时空搜索范围，提升查询性能。

2.4 跨数据库的数据同步

本文基于统一的实体映射机制和两阶段提交协议，实现了关系型数据库和图数据库中异构时空数据的实时同步（图6）。该方法首先通过REST API接口接收数据库连接配置、索引配置、实体标识符（EntityClass和EntityID）、时间元数据和地理文件（用于新数据）等参数，然后执行相应的操作。在用户发起数据库同步请求后，调用预处理服务模块实现异构数据的统一视图转换，具体如下：
图6 跨数据库协调器的数据同步流程

Fig. 6 Data synchronization workflow of the cross-database coordinator

（1）建立数据库连接参数和时空索引配置（如Geohash编码长度、时间树粒度、关系表分区粒度）。
（2）对输入的地理时空数据进行结构化解析：对于新增操作，预处理服务将原始数据进行结构化转换，其中矢量数据提取几何对象的WKT表示并计算外包矩形Geohash编码集合；栅格数据按预设Geohash网格分块并转换为WKB格式；时间属性则提取实体时间属性并按标准时间戳格式（ISO 8601）记录。对于删除操作，预处理服务根据EntityClass和EntityID生成待删除实体标识集合。
（3）生成统一对象视图，包含实体ID（EntityID）、实体标签/关系表名（EntityClass）、空间编码（Geohash）、时间戳（time）、几何（Geom）、栅格（Rast）等核心字段。该视图作为中间数据层，生成对应数据库操作命令：随后，调用底层数据库接口执行实际的数据操作。为确保跨数据库操作的原子性，采用两阶段提交协议，从而确保异构数据库的最终一致性。

3 实验分析

为了评估本文提出的地理时空语义查询优化方法的性能，本文选取了几个有代表性的语义存储系统作为基准，并在真实数据集实际应用场景进行了对比分析。

3.1 系统实现

本文基于Neo4j图数据库和PostgreSQL关系型数据库开发了原型系统GraST，通过混合架构设计集成两者的优势，支持跨数据库的时空数据管理与查询优化。
GraST系统架构如图7所示，主要由以下组件组成：
图7 原型系统架构

Fig. 7 Architecture of prototype system (GraST)

（1）图数据库：基于Neo4j图数据库，并使用APOC工具库和自定义的Geohash与TimeTree索引结构增强时空节点管理和聚合能力。
（2）关系数据库：基于PostgreSQL关系数据库，集成PostGIS和TimescaleDB扩展，通过原生计算函数管理和分析时空数据。
（3）实体映射器：利用JDBC建立和维护Neo4j与PostgreSQL之间的实体映射关系。实体映射器为其他组件提供统一的数据访问接口，屏蔽了底层数据库的异构性。
（4）查询转换器：利用Neo4j的Java API封装预定义的时空函数，将其加载到Neo4j的过程库中。它将这些函数映射到等效的PostGIS和TimescaleDB函数。
（5）数据同步器：基于Java Spring框架开发REST API，支持数据库事务管理，并集成GDAL库预处理地理数据。通过两阶段提交协议确保跨数据库操作的一致性。数据同步器的工作界面及矢量、栅格数据的跨数据库存储模式如图8所示。
图8 数据同步器组件界面及跨数据库存储示意

Fig. 8 Data synchronizer component interface and cross-database storage diagram

3.2 实验方案

本文选取了3个有代表性的语义存储方案作为对比，包括RDF存储GraphDB、图数据库Neo4j和虚拟知识图Ontop，如表2所示。本文采用混合存储方式导入原始数据：矢量数据的几何信息以WKT格式存储在PostgreSQL关系表的geometry类型字段中，同时计算矢量对象的外包矩形MBR，并生成完全覆盖该MBR的所有Geohash网格编码集合存储于Geohash列（构建GisT索引）；时间信息以时间戳格式存储在timestamp类型字段中。栅格数据方面，首先根据预设的Geohash分辨率对栅格进行分块，每个栅格块转换为WKB格式存储在PostgreSQL的raster对象中。Neo4j端仅存储地理实体的ID、标签等元数据信息，并关联到时间树节点和Geohash编码节点。此外，基于PostgreSQL的表分区特性，GraST根据时间戳对关系表进行按小时的时间粒度分区，优化基于时间窗口的查询性能。
表2 社区活动数据(截至2024年12月)

Tab. 2 Overview of experimental datasets

对比维度 Neo4j GraphDB Ontop
数据模型 Graph Graph、RDF RDB、RDF
数据支持 点、线、面 点、线、面 点、线、面、栅格
扩展方案 Neo4j spatial GeoSPARQL Ontop-spatial
类别 开源 商业 开源
Github Stars 13.6 k - 675
实验数据集包括深圳市4类真实地理数据： ① 2014年10月22日664辆电动出租车1 155 654条GPS轨迹点； ② 2021年8月29日905 095条共享单车轨迹； ③ 2021年OpenStreetMap提取的26 376条路网、907 633个兴趣点（POI）、31 145个兴趣面（AOI）；④ 2021年250mMOD13Q1 NDVI及30mSRTM DEM栅格数据。
查询工作负载基于Apache Sedona基准[21]调整，设计10个查询（表3）。“矩形窗口”以深圳市火车站（114.124° E, 22.537°N）为中心，生成不同边长矩形的预设尺度；“时间窗口”以10:00—14:00为中心，按前后2 h梯度扩展。每个查询执行预热后重复20次，去除极值后取平均响应时间。Q1—Q3查找“位于”指定矩形窗口内的对象， Q4—Q5查找与指定矩形窗口“相交”的对象， Q6查找与路网“相交”的轨迹， Q7—Q8查找“覆盖”特定时空范围的GPS轨迹点和单车轨迹线，Q9计算“位于”指定区域内的栅格像元平均值，Q10计算满足多重空间/属性约束的栅格像元区域，Q11测试系统跨数据库通信和处理的基础耗时。对每个查询场景，先执行预热查询以填充数据库缓存，然后连续执行20次查询，记录查询响应时间。去除最高最低值后取平均值作为衡量查询性能指标。所有实验在同一台Ubuntu Server 20.04机器上进行，配置为Intel Core i7- 13 700 K CPU（8核16线程）、64 GB内存和4 TB NVMe SSD。
表3 查询用例

Tab. 3 Query cases

类别 查询设置
Q1 Points within Polygon 查询位于深圳市火车站不同矩形窗口内的兴趣点，其中查询窗口的边长序列为1、5、10 km
Q2 Lines within Polygon 查询位于深圳市火车站不同矩形窗口内的道路，其中查询窗口的边长序列为1、5、10 km
Q3 Polygons within Polygon 查询位于深圳市火车站不同矩形窗口内的兴趣面，其中查询窗口的边长序列为1、5、10 km
Q4 Polygon intersects with points 查询与深圳市火车站不同矩形窗口相交的兴趣点，其中查询窗口的边长序列为1、5、10 km
Q5 Polygon intersects with lines 查询与深圳市火车站不同矩形窗口相交的道路，其中查询窗口的边长序列为1、5、10 km
Q6 Line intersection 查询与不同规模道路网络数据子集相交的单车轨迹，其中道路网络数据子集序列为30、40、50、60条
Q7 时空查询（Point） 查询位于深圳市火车站30 km矩形窗口内的出租车GPS点，其中时间窗口序列为10:00—14:00、 08:00—16:00、06:00—18:00、04:00—20:00、02:00—22:00和00:00—24:00
Q8 时空查询（Line） 查询位于深圳市火车站30 km矩形窗口内的单车轨迹，其中时间窗口序列为10:00—13:00、08:00—16:00、06:00—18:00、04:00—20:00、02:00—22:00和00:00—24:00
Q9 栅格值提取 查询在深圳市莲花山公园内部栅格单元的平均植被覆盖度NDVI和海拔高度
Q10 栅格代数运算 查询在深圳市莲花山公园海拔>500 m、坡度>30°且植被指数>0.6的区域
Q11 空查询测试 查询系统跨数据库通信和处理的基础耗时，不涉及数据检索和计算

3.3 性能评估

3.3.1 空间查询性能

首先，评估本文方法和对比系统在点、线、面在within操作中的性能。图9展示不同系统在不同查询窗口下的平均响应时间。结果表明，对于点查询（Q1），当查询窗口较小（10 km）时，本文方法与其他系统响应时间差异不大，都在1 s以内。然而随着查询范围扩大，本文方法性能优势逐渐显现。当查询窗口达30 km时，Neo4j响应时间已达3.056s，而本文方法仍能在0.3 s内返回结果。对线查询（Q2）和面查询（Q3），在不同查询窗口下响应时间出现类似趋势，尤其处理复杂几何对象时，本文方法与GraphDB、Neo4j在查询响应时间上存在数量级差异。
图9 不同数据规模下within查询(Q1—Q3)的响应时间

Fig. 9 Response time of within queries (Q1—Q3) under different data scales

为进一步评估本文方法在intersects关系中的表现，Q4和Q5通过不同大小矩形窗口，Q6通过不同规模路网数据，分别与POI、路网和单车轨迹线相交查询。图10展示这3个查询的平均响应时间。结果表明，本文方法能很好应对数据规模增长。以Q4为例，当查询矩形窗口从10 km增大到40 km时，本文方法响应时间从0.255 s增长到0.283 s，而Neo4j从1.049 s增到4.879 s，GraphDB从0.749 s增长到1.308 s。在最大查询窗口下，本文方法速度优势达17.2倍（与Neo4j相比）、4.6倍（与GraphDB相比）。类似地，在Q6中，随着被检查道路数量从10条增加到200条，原生图存储系统响应时间呈现明显指数级增长。
图10 不同数据规模下intersects查询（Q4—Q6）的响应时间

Fig. 10 Response time of intersects queries （Q4—Q6） under different data scales

本文方法在空间查询上的表现与采用虚拟图的Ontop系统十分接近，主要因为两者执行空间查询时，底层都基于PostGIS计算，得益于其高效GiST（通用搜索树）空间索引[20]。此外，本文方法在GDBMS侧构建Geohash编码空间索引图，可在跨库节点匹配时完成空间剪枝优化，能更好支持海量、高维、不规则形状等GIS数据高效检索。本文方法混合存储架构会带来一定跨库通信开销。在小规模数据下，本文方法查询性能与采用原生图存储的Neo4j和GraphDB相比并无明显优势。但随着查询范围和数据规模扩大，本文方法采用的时空索引和跨库协同优化机制能有效抵消通信开销带来的负面影响。

3.3.2 时间查询性能

在Q7—Q8中，本文评估本文方法和对比系统在时态数据查询中的性能。Q7查询不同时间窗口下的出租车GPS点，Q8查询不同时间窗口下的共享单车轨迹。图11展示不同系统在不同时间窗口下的响应时间。
图11 不同时间窗口下Q7和Q8的响应时间

Fig. 11 Response time of Q7 and Q8 under different time windows

结果表明，本文方法在各时间窗口下查询响应时间都优于其他3个系统。在最小时间窗口（10:00——14:00）下，本文方法检索出租车GPS点响应时间为0.382 s，而Neo4j、GraphDB和Ontop分别为5.591、6.025和1.898 s。随时间窗口增大，本文方法时间索引效果逐渐显现。在最大时间窗口下，本文方法响应时间为0.476 s，而Neo4j、GraphDB和Ontop分别达12.304、8.082、3.040 s，是本文方法的25.9倍、17倍和6.4倍。对共享单车轨迹查询，本文方法在最大时间窗口下响应时间比Neo4j、GraphDB和Ontop分别快了近35.0倍、17.6倍和3.3倍。各系统在轨迹查询上响应时间均有所上升，主要因轨迹数据包含更多坐标点，数据量和复杂度更高。尤其对缺乏高效时空索引支持的原生图存储系统如Neo4j和GraphDB，其性能下降更明显。而本文方法采用的时态索引在数据时间过滤中有效避免全时空记录扫描。

3.3.3 栅格查询性能

在Q9和Q10中，评估本文方法在栅格数据查询和分析方面的能力。本文将原始栅格文件根据Geohash索引切分成规则块并转换为二进制对象存储，以优化栅格块提取和查询。栅格数据的存储示意、查询结果和效率如图12所示。
图12 栅格代数运算(Q9、Q10)的查询响应时间

Fig. 12 Query response time of raster algebra operations (Q9, Q10)

在Q9中，以深圳市莲花山公园为目标区域，分别统计其内部栅格单元平均NDVI指数和海拔高度。本文方法利用Geohash索引快速锁定相关栅格块，并将感兴趣区矢量边界下推至PostGIS。然后，使用栅格裁剪函数提取位于公园内的栅格子集，通过聚合函数计算NDVI和DEM均值。如图12（c）所示，本文方法在该查询上响应时间分别为1.13 s，略高于直接在PostGIS（0.66 s）中查询，而Ontop-spatial为1.19 s。造成这一差异的主要原因是，本文方法和Ontop-spatial都需在异构数据库间进行跨库通信和中间传输，而PostGIS能直接访问本地栅格对象。在Q10中，进一步测试本文方法在多栅格联合分析中的表现。该查询选取莲花山公园内高程>500 m、坡度>30°且NDVI >0.6的区域。通过Geohash索引和矢量裁剪得到目标区域3个栅格子集，利用PostGIS栅格代数运算，提取满足约束条件的像元。从图12（c）可见，由于栅格分块存储和空间索引，本文方法在复杂栅格分析中查询时间（2.63 s）仍控制在可接受范围内。

3.3.4 空查询测试

为了评估系统在处理查询请求时的基本开销，Q11查询用例执行了不涉及实际数据检索的空查询。空查询旨在测量查询请求在系统间传输和处理的时间开销，为其他查询的性能分析提供基准参考。通过比较空查询与实际查询的响应时间，可更清晰地识别数据检索和处理对系统性能的影响。
实验结果中GraST系统的空查询响应时间为0.035 s，高于Neo4j的0.004 s、GraphDB的0.007 s和Ontop的0.024 s。这表明GraST系统本身的基础开销较大，主要源于其混合架构设计带来的跨数据库通信和查询转换成本。相比之下，Neo4j和GraphDB作为原生图数据库，在处理简单查询时无需跨库协调，因此基本开销较低。与实际查询的性能对比进一步凸显了GraST的系统开销占比。例如，在Q1（点within查询，查询窗口边长10 km）中，GraST的响应时间为0.262 s，其中空查询开销（0.035 s）占比较高；而Neo4j的响应时间为1.04 s，空查询开销（0.004 s）仅占0.38%，显示其系统开销对整体性能影响较小。类似地，在Q7（时空查询，最小时间窗口10:00—14:00）中，GraST的响应时间为0.382 s，空查询开销占比约9.16%，高于Neo4j（9.866 s，占比0.07%）和GraphDB（7.294 s，占比0.12%）。然而，GraST的通信开销总体可控，在大规模复杂时空查询中，此开销被高效计算所抵消。

3.3.5 查询性能分解

为深入剖析GraST系统的查询性能构成，测量了查询过程中的关键阶段耗时。本文选取Q1（点within查询，查询窗口边长40 km）、Q6（线相交，60条道路相交的单车轨迹）、Q8（时空查询，时间窗口 00:00—24:00）、Q9（栅格值提取，NDVI均值）和Q10（栅格代数运算，海拔>500 m等条件） 5个典型查询用例，将GraST的查询响应时间分解为以下 4个阶段：
（1）参数解析：提取和解析用户查询中的参数信息；
（2） SQL转换：将图查询转换为关系数据库可执行的SQL语句；
（3）查询执行：在关系数据库中执行查询并检索数据；
（4）结果映射：将查询结果从关系数据库映射回图数据库或返回给图查询过程。
实验通过在GraST系统中嵌入计时监视器，以毫秒级精度记录各阶段的耗时，结果如表4所示。
表4 GraST系统中多个查询的阶段耗时

Tab. 4 Stage-wise response time of multiple queries in GraST system (s)

查询 参数解析 SQL转换 查询执行 结果映射 总时间
Q1 0.002 0.029 0.069 0.194 0.294
Q6 0.004 0.031 19.396 0.021 19.452
Q8 0.003 0.027 0.604 0.491 1.125
Q9 0.002 0.033 1.094 0.004 1.133
Q10 0.003 0.032 2.595 0.004 2.634
从表4的数据可以看出，GraST系统中各查询阶段的耗时呈现显著差异。参数解析的耗时在 0.002~0.004 s之间，SQL转换的耗时在0.027~0.033 s之间，这2个阶段在不同查询中保持稳定，且耗时均为较低状态。查询执行是整个过程的核心耗时阶段，耗时从0.069 s（Q1）到19.396 s（Q6）不等，其中Q1涉及简单的点查询，数据量和计算复杂度较小；Q6因路网与单车轨迹相关计算涉及大量拓扑操作；Q8、Q9和Q10耗时依次增加，分别反映了时空轨迹检索、栅格数据提取和多条件栅格运算的计算需求。需要注意的是，结果映射的耗时差异较大，与返回数据量大小呈线性相关，Q8耗时最高，因查询返回数据量最大，需将结果重新匹配至图数据库节点；而Q9和Q10耗时均为0.004 s，因返回数据量较小，映射开销几乎可忽略。综上所述，GraST系统中查询执行阶段对总耗时的影响最大，而参数解析和SQL转换的相对开销在简单查询中更为明显。这种性能分布表明，GraST的设计更适用于在图数据库中执行大范围时空数据查询和复杂地理计算。

3.3.6 存储空间效率

为了评估GraST系统在存储效率方面的性能，基于3.2节所述的深圳市多源时空数据集，对GraST及其对比系统的数据存储空间消耗进行了测量。数据集包括出租车GPS点（115.6万）、共享单车轨迹线（90.5万）、路网（2.6万）、POI（90.7万）和AOI（3.1万）矢量数据，以及2021年逐月250mMOD13Q1 NDVI和30mSRTM DEM栅格数据。实验结果如表5所示。
表5 GraST 及对比系统的存储空间消耗

Tab. 5 Storage space consumption of GraST and comparison systems

系统 矢量数据
/MB		 相对增减
/%		 栅格数据
/MB		 相对增减
/%
GraST 1 065.4 - 35.4 -
Neo4j 6 105.5 473.1 - -
GraphDB 3 975.3 273.2 - -
Ontop 592.5 -44.4 24.3 -31.4
结果表明，GraST系统的矢量数据占用1 065.4 MB（Neo4j 421.8 MB，PostGIS 643.6 MB），栅格数据占用35.4 MB（Neo4j 7.8 MB，PostGIS 27.6 MB）。在GraST的混合存储架构中，Neo4j负责存储地理实体的ID、语义属性以及时间树和Geohash索引节点，占用421.8 MB； PostGIS存储矢量数据的几何信息（WKT格式）和栅格数据（WKB格式），利用其内置压缩机制，分别占用643.6 MB和27.6 MB，显示出较高的存储效率。
与GraST相比，Neo4j原生库的矢量数据占用 6 105.5 MB，因其将所有几何信息直接存储为节点属性且缺乏压缩机制，空间消耗较GraST高473.1%。GraphDB的矢量数据占用3 975.3 MB，基于RDF三元组模型存储，未实施压缩，较GraST增加273.2%，但因数据表示较紧凑，低于Neo4j。Ontop的矢量数据和栅格数据分别占用592.5 MB和24.3 MB，作为虚拟知识图系统，仅维护映射层，所有数据存储于底层PostGIS，利用其压缩机制，矢量数据较GraST低44.4%，栅格数据低31.4%，但差异未达数量级。由于实验数据集规模较大（如百万级轨迹点），时间树和Geohash索引增加了GraST在Neo4j中的节点和边数量，导致存储占用受索引开销影响较大，但显著提升了查询性能。PostGIS的高效压缩则减轻了存储负担，体现了 2种存储方式的互补性。

3.4 实验讨论

3.4.1 性能分析

实验结果表明，GraST在复杂时空语义查询中性能优异，相较于Neo4j和GraphDB具有显著优势。GraST的混合架构：图数据库负责语义关联，关系数据库处理时空计算，利用PostGIS等引擎的高效索引（如GiST）和几何运算能力，避免了传统图数据库在地理时空查询中的低效遍历。性能分解显示，查询执行占主要耗时，但得益于RDBMS的优化，整体效率在大规模地理时空查询任务中响应时间相较于原生图数据库显著缩短。此外，GraST引入的时空索引（MTT、Geohash、时间分区表、Geohash编码）进一步提升了查询性能优化。其中，MTT和时间分区表优化时间过滤，Geohash实现空间剪枝，显著降低计算开销。此外，GraST的轻量化图节点和RDBMS压缩存储减少了3~5倍空间占用。与Ontop相比，GraST在复杂时空查询和空间存储消耗中性能相近，均受益于PostGIS的空间索引和计算能力。但Ontop通过虚拟中间件将SPARQL查询映射至关系数据库，需额外模式转换，而GraST则在物理层同时维护图结构和关系表，直接利用属性图建模地理实体的语义关联，使地理实体能无缝集成至知识图谱并与语义上下文关联，支持更复杂的语义表达。

3.4.2 可扩展性

GraST的可扩展性得益于其自定义函数映射机制及主流图数据库的扩展支持。在原型实现中，GraST利用Neo4j的存储过程机制扩展时空分析功能。开发者可按规范定义高级图查询函数，通过映射将其转化为RDBMS可执行的时空算子并下推执行，降低了时空语义分析的开发难度和集成成本。同时，主流关系数据库及其GIS引擎为地理时空数据管理提供了丰富生态。尽管原型系统基于Neo4j和PostGIS构建，GraST的查询优化方法并不局限于特定数据库产品。其核心思想具有通用性，仅需调整适配层的数据库驱动、连接配置和功能映射，即可集成至其他主流数据库系统或GIS平台，为时空数据管理和查询提供高效支持。同时，该方法可融入多源数据，如CityGML三维城市模型、IFC建筑信息建模标准等，通过适配这些格式，能够扩展至城市规划、建筑信息管理等应用场景，进一步提升其多领域应用的潜力。

3.4.3 局限性

尽管GraST在优化时空语义查询方面成效显著，仍存在以下局限性需进一步完善：① 通信开销：小规模或窄范围查询中，跨库通信可能抵消性能优势。未来可压缩中间结果、缓存查询结果优化流程，降低成本； ② 索引局限：MTT对不规则时间序列适应性不足，Geohash表达复杂地理特征时精度有限。未来可引入自适应索引提升灵活性； ③ 本体集成：GraST局限于实例级属性图，未充分利用知识本体推理能力。未来计划构建概念级知识图谱，增强语义表达与推理； ④ 分布式支持：单机系统在可扩展性和容错性上存瓶颈。研究GraST分布式实现，支持多数据中心协同，提升处理海量时空数据鲁棒性； ⑤ 扩展查询支持：GraST虽支持可扩展计算，功能仍有限。未来基于主流图和关系数据库，扩展适配组件，探索多领域地理时空分析集成，满足更广需求。

4 结论与展望

4.1 结论

本文提出了一种地理时空语义查询优化方法，通过轻量级混合存储架构桥接图数据库与关系数据库，融合图数据库的模式匹配和关系数据库的地理计算能力，实现地理时空数据的灵活建模与高效查询。该方法支持复杂语义与时空约束的协同处理，为知识图谱中地理时空数据管理提供解决方案。实验表明，本文方法在大规模复杂时空查询中表现优异，相较于Neo4j和GraphDB，响应时间缩短1~2个数量级，存储空间减少3~5倍；与Ontop相比，在大规模查询中更具优势。借助主流数据库扩展机制，用户可通过自定义函数映射调用底层计算能力，灵活扩展时空分析算子。其松耦合设计易于集成至现有平台，仅需配置适配层即可赋予系统时空语义管理能力，降低开发成本，为知识图谱提供高效、可扩展的地理时空计算支持，具有重要理论与应用价值。

4.2 展望

随着空间显式知识图研究的深入，多源异构时空数据的语义融合成为关键挑战[22]。本方法平衡数据一致性与多样性，保留地理数据原生格式，利用知识图谱技术实现异构数据统一管理和语义查询，为时空数据融合提供可行路径。未来可优化跨库通信效率，降低小规模查询开销；改进时空索引，支持复杂动态地理对象；扩展多领域数据集成（如 CityGML），增强复杂地理时空数据的知识图管理和语义推理能力。同时，结合知识本体、大语言模型及自然语言处理技术，可实现人机交互的图查询转换，为GeoAI应用的智能问答和时空分析提供高效支持[23]。
AI使用说明：本文在撰写过程中使用了AI工具对语言进行润色，具体包括引言背景部分（第1、2段落）、方法部分（2.1节）和实验设计（3.1节）部分内容。
■ 本文图文责任编辑：黄光玉 蒋树芳

利益冲突：Conflicts of Interest 所有作者声明不存在利益冲突。

All authors disclose no relevant conflicts of interest.

参考文献

原文顺序 | 文献年度倒序 | 文中引用次数倒序
[1]
李德仁. 论时空大数据的智能处理与服务[J]. 地球信息科学学报, 2019, 21(12):1825-1831.

DOI

[Li D R. The intelligent processing and service of spatiotemporal big data[J]. Journal of Geo-Information Science, 2019, 21(12):1825-1831.] DOI:10.12082/dqxxkx.2019.190694

[2]
姚迪, 张超, 黄建辉, 等. 时空数据语义理解:技术与应用[J]. 软件学报, 2018, 29(7):2018-2045.

[Yao D, Zhang C, Huang J H, et al. Semantic understanding of spatio-temporal data: Technology & application[J]. Journal of Software, 2018, 29(7):2018-2045.] DOI:10.13328/j.cnki.jos.005576

[3]
陆锋, 诸云强, 张雪英. 时空知识图谱研究进展与展望[J]. 地球信息科学学报, 2023, 25(6):1091-1105.

DOI

[Lu F, Zhu Y Q, Zhang X Y. Spatiotemporal knowledge graph: Advances and perspectives[J]. Journal of Geo-Information Science, 2023, 25(6):1091-1105.] DOI:10.12082/dqxxkx.2023.230154

[4]
张雪英, 张春菊, 吴明光, 等. 顾及时空特征的地理知识图谱构建方法[J]. 中国科学:信息科学, 2020, 50(7):1019-1032.

[Zhang X Y, Zhang C J, Wu M G, et al. Spatiotemporal features based geographical knowledge graph construction[J]. Scientia Sinica (Informationis), 2020, 50(7):1019-1032.] DOI:10.1360/SSI-2019-0269

[5]
Alam M M, Torgo L, Bifet A. A survey on spatio-temporal data analytics systems[J]. ACM Computing Surveys, 2022, 54(10s):1-38. DOI:10.1145/3507904

[6]
Kotiranta P, Junkkari M, Nummenmaa J. Performance of graph and relational databases in complex queries[J]. Applied Sciences, 2022, 12(13): 6490. DOI:10.3390/app12136490

[7]
Di Pierro D, Ferilli S, Redavid D. LPG-based knowledge graphs: A survey, a proposal and current trends[J]. Information, 2023, 14(3):154. DOI:10.3390/info14030154

[8]
Cheng Y J, Ding P J, Wang T T, et al. Which category is better: Benchmarking relational and graph database management systems[J]. Data Science and Engineering, 2019, 4(4):309-322. DOI:10.1007/s41019-019-00110-3

[9]
Baralis E, Dalla Valle A, Garza P, et al. SQL versus NoSQL databases for geospatial applications[C]//2017 IEEE International Conference on Big Data (Big Data). IEEE, 2017:3388-3397. DOI:10.1109/BigData.2017.8258324

[10]
Li W W, Wang S Z, Wu S, et al. Performance benchmark on semantic web repositories for spatially explicit knowledge graph applications[J]. Computers, Environment and Urban Systems, 2022,98:101884. DOI:10.1016/j.compenvurbsys.2022.101884

[11]
李悦, 孙坦, 赵瑞雪, 等. 大规模RDF三元组转换及存储工具比较研究[J]. 数字图书馆论坛, 2020(11):2-12.

[Li Y, Sun T, Zhao R X, et al. A comparative study of large-scale RDF triple conversion and storage tools[J]. Digital Library Forum, 2020(11):2-12.] DOI:10.3772/j.issn.1673-2286.2020.11.001

[12]
卢海川, 符海东, 刘宇. 基于CAN的地理语义数据存储与检索机制[J]. 计算机科学, 2019, 46(2):171-177.

DOI

[Lu H C, Fu H D, Liu Y. Geo-semantic data storage and retrieval mechanism based on CAN[J]. Computer Science, 2019, 46(2):171-177.] DOI:10.11896/j.issn.1002-137X.2019.02.027

[13]
Patroumpas K, Giannopoulos G, Athanasiou S. Towards GeoSpatial semantic data management: Strengths, weaknesses, and challenges ahead[C]// Proceedings of the 22nd ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems. ACM, 2014:10.1145/2666310.2666410. DOI:10.1145/2666310.2666410

[14]
Alocci D, Mariethoz J, Horlacher O, et al. Property graph vs RDF triple store: A comparison on glycan substructure search[J]. PLoS One, 2015, 10(12):e0144578. DOI:10.1371/journal.pone.0144578

[15]
Gryllakis F, Pelekis N, Doulkeridis C, et al. Spatio-temporal-keyword pattern queries over semantic trajectories with Hermes@Neo4j[C]// Proceedings of the 21st International Conference on Extending Database Technology. Vienna: ACM, 2018:708-711. DOI:10.5441/002/edbt.2018.83

[16]
Sun Y H, Sarwat M. A spatially-pruned vertex expansion operator in the Neo4j graph database system[J]. GeoInformatica, 2019, 23(3):397-423. DOI:10.1007/s10707-019-00361-2

[17]
Bereta K, Xiao G H, Koubarakis M. Ontop-spatial: Ontop of geospatial databases[J]. Journal of Web Semantics, 2019,58:100514. DOI:10.1016/j.websem.2019.100514

[18]
Bakkal F, Eken S, Savaş N S, et al. Modeling and querying trajectories using Neo4j spatial and TimeTree for carpool matching[C]//2017 IEEE International Conference on INnovations in Intelligent SysTems and Applications (INISTA). IEEE, 2017:219-222. DOI:10.1109/INISTA.2017.8001160

[19]
向隆刚, 高萌, 王德浩, 等. Geohash-Trees:一种用于组织大规模轨迹的自适应索引[J]. 武汉大学学报(信息科学版), 2019, 44(3):436-442.

[Xiang L G, Gao M, Wang D H, et al. Geohash-trees: An adaptive index which can organize large-scale trajectories[J]. Geomatics and Information Science of Wuhan University, 2019, 44(3):436-442.] DOI:10.13203/j.whugis20160523

[20]
Yue P, Tan Z Y. GIS databases and NoSQL databases[M]//Comprehensive Geographic Information Systems. Amsterdam: Elsevier, 2018:50-79. DOI:10.1016/b978-0-12-409548-9.09596-8

[21]
Pandey V, Kipf A, Neumann T, et al. How good are modern spatial analytics systems?[J]. Proceedings of the VLDB Endowment, 2018, 11(11):1661-1673. DOI:10.14778/323 6187.3236213

[22]
陆锋, 余丽, 仇培元. 论地理知识图谱[J]. 地球信息科学学报, 2017, 19(6):723-734.

DOI

[Lu F, Yu L, Qiu P Y. On geographic knowledge graph[J]. Journal of Geo-information Science, 2017, 19(6):723-734.] DOI:10.3969/j.issn.1560-8999.2017.06.001

[23]
仲腾, 张雪英, 许沛, 等. 基于云原生的地理空间知识库管理关键技术与服务方法研究[J]. 地球信息科学学报, 2024, 26(9):2013-2025.

DOI

[Zhong T, Zhang X Y, Xu P, et al. Critical technologies and service approaches for cloud-native geospatial knowledge base management[J]. Journal of Geo-Information Science, 2024, 26(9):2013-2025.] DOI:10.12082/dqxxkx.2024.240184

Options
文章导航

/

〈 〉