矢量数据
矢量数据是地理信息系统的核心,用点、线、多边形等几何类型表示空间要素。遵循OGC国际标准(如Simple Features),确保数据跨平台互操作。主流格式包括GeoPackage(轻量单文件)、PostGIS(企业级数据库)、KML(网络交换),支持坐标系定义与高效存储(如WKB编码)。适用于地图制作、空间分析及移动端应用,提升数据共享与可视化效率。
矢量数据基础
矢量数据用点、线和多边形这三种基本的几何类型来表示空间数据。这些几何类型可以模拟现实世界中的各种地理要素。
矢量数据具备一些重要的区别于其它类似文件的特征,我们能具体感知的特征如下:
- 几何(Geometry):只能存在规定的几何类型,主要包括点、线、多边形
- 坐标系(SpatialReference):矢量数据具备空间参考系统,使用地理坐标系和投影坐标系进行定义
- 要素(Feature):封装了几何图形和属性的单个地理要素,包括点、线、多边形等,我们称之为要素
矢量数据中的几何类型
几何类型2D
Simple Features,中文一般称为几何图形或者简单要素。
| 类型 | 示意图 | 说明 |
|---|---|---|
| 点、多点(Point, MultiPoint ) | ![]() | 用于表示具体的位置,如地标、城市或其他感兴趣的点 |
| 线、 多线(LineString,MultiLineString) | ![]() | 由多个点按顺序连接而成,用以表示路径、河流、交通线路等线状要素 |
| 多边形、多多边形、三角形(Polygon, MultiPolygon, Triangle) | ![]() | 由闭合的线组成,表示具有一定面积的地理要素,如湖泊、岛屿或行政区域等 |
备注:另外包括多面体表面 | PolyhedralSurface、三角化不规则网络 | TIN,现在的软件还不支持,暂不叙述。
几何图形的坐标
几何图形的坐标可以是 2D (x, y)、3D (x, y, z)、4D (x, y, z, m),其 m 值是线性参考系统的一部分,也可以是 2D 具有 m 值 (x, y, m) 的坐标。三维几何图形在几何类型后用“Z”表示,具有线性参考系统的几何图形在几何类型后用“M”表示。不包含坐标的空几何可以通过在类型名称后使用符号来指定。
在XinGeo中要想使用Z值和M值需要在创建矢量数据时进行指定。

几何对象表示格式
WKB(Well-Known Binary)和 WKT(Well-Known Text)是两种常用的几何对象表示格式,广泛应用于 GIS(地理信息系统)、数据库(如 PostGIS)、空间数据传输和标准化交换中。
- WKT(Well-Known Text)是一种基于文本的格式,用来描述几何对象的空间结构,易于人类阅读。
- Well-Known Binary(WKB)是一种用于表示几何对象的二进制编码格式。它是Well-Known Text(WKT)的二进制等价物,旨在促进几何数据在不同系统间的快速交换和存储。WKB格式定义了点、线、多边形等基本几何形状的存储方式,与shpfile完美兼容,支持空间数据库和GIS系统之间的有效数据传输。
XinGeo为了在服务器和用户浏览器之间快速传输数据,采用WKB格式,这样可以压缩数据大小,从而可以使数据更快的在用户浏览器中展示。
比如对于下述点要素:
POINT (10 20)
WKB格式表述为:
010100000000000000000024400000000000003440
矢量数据中的坐标系
空间参考系(Spatial Reference System, SRS)或坐标参考系(Coordinate Reference System, CRS)为地理信息系统(GIS)中定位地球表面特定位置提供了一种标准框架。这些系统是坐标系和解析几何在地理空间数据管理中应用的结果。
几何图形坐标在表示时,必需声明其所用的空间参考系统,这样要素才能被正确的表达。
- 大地/地理坐标系(Geographic Coordinate System, GCS):使用纬度(赤道以北或以南的度数)和经度(本初子午线以西或以东的度数)直接测量地球上的位置(建模为球体或椭球体)的球面坐标系。
- 平面/格网/投影坐标系(Projected Coordinate System, PCS):一种标准化的笛卡尔坐标系,将地球(或更常见的是其中的一大片区域)建模为一个平面。地图投影有多大几千种,每种地图投影都基于特定的数学模型,旨在平衡区域特征的准确展示和地图的实用性。常见示例如:
- 通用横轴墨卡托 (UTM):世界被分成60个或者120个纵向区域,每个区域使用一个横轴墨卡托投影,适合中等尺度地图的精确测量。
- web墨卡托(WGS 84 / Pseudo-Mercator:主要用于网络地图服务,如天地图和OpenStreetMap,优化了全球尺度的视觉展示,但在高纬度区域有较大失真。
虽然天地图、高德地图、百度地图等在线地图的影像图以web墨卡托进行标识,但由于web墨卡托存在较大的距离变形,因此我们在使用测距功能时,距离并不以web墨卡托进行计算,而是以Vincenty公式进行计算,这个距离与我们在实际生活中测量的距离是一致的。
OGC 简单要素规范概述
昕图中,矢量数据中的要素,遵循OGC Simple Features Access (SFA)设计规范。下面简述:
SFA设计思路
OGC 简单要素规范(SFA)的设计理念可以概括为:“用最通用的数学模型,解决最广泛的地理空间表达问题。”
它的出现将地理信息从早期的封闭式、专有格式,推向了现代的开放式、数据库化时代。以下是其核心设计理念与思路的深度解析:
- 核心设计理念:最小公分母原则 (Least Common Denominator)
SFA 的核心理念是定义一套所有系统都能理解的最小几何子集。
- 跨平台一致性:无论是 Oracle、PostgreSQL 等数据库,还是 ArcGIS、QGIS 等软件,都能识别相同的
POINT或POLYGON。 - 牺牲复杂性换取普适性:它舍弃了难以统一计算的参数化曲线(如圆弧、样条曲线),强制要求所有几何体都由直线段组成。这虽然在精度上有所妥协,但极大地降低了空间分析(如求交、合并)的算法难度。
- 空间对象模型:基于组件的层次结构
SFA 采用面向对象的设计思路,构建了一个严谨的几何对象继承体系。
- 基类 (Geometry):所有对象的祖先,定义了通用的空间属性(如 SRID、维度)。
- 原子类型:点(Point)、线(LineString)、面(Polygon)。
- 集合类型 (GeometryCollection):为了处理复杂地理实体,设计了多点、多线、多面等容器,允许一个“要素”由多个物理碎块组成。
- 核心思路:几何与属性的“解耦”与“关联”
SFA 将地理信息拆分为两个核心部分,并定义了它们的交互方式:
- 几何 (Geometry):纯粹的数学描述(坐标、拓扑)。
- 要素 (Feature):现实世界的实体。一个要素 = 几何 + 业务属性。
- 关联机制:在数据库中,这表现为一行为一个 Feature,其中一列(Geometry Column)存储几何形状,其他列存储名称、人口、类型等属性。这种设计使得 SQL 语言能够直接处理地理数据。
- 拓扑与空间关系的数学定义 (DE-9IM)
SFA 不仅仅定义了“形状”,还定义了“形状之间如何交互”。
它引入了 DE-9IM(九交模型) 的设计思路,通过判断两个几何对象的内部(Interior)、边界(Boundary)和外部(Exterior)的交集情况,定义了 8 种标准的空间关系运算:
- Equals, Disjoint, Intersects, Touches, Crosses, Within, Contains, Overlaps。
意义:这套设计让“查询某条河流穿过哪些省份”这种问题,转化为了标准的数学布尔运算。
- 标准的序列化表达 (WKT & WKB)
为了让不同的系统能够交换这些“简单要素”,SFA 设计了两套极其成功的表达方式:
- WKT (Well-Known Text):
- 思路:人类可读。
- 例子:
POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))。这使得开发人员可以直接在代码或命令行中写出几何体。
- WKB (Well-Known Binary):
- 思路:机器高效。
- 用途:以二进制流的形式在数据库与应用程序之间快速传输,减少解析开销。
- 注:昕图中为了压缩从服务器到浏览器之间的数据传输量,昕图的要素使用WKB表示几何。
如何理解Simple
在地理信息系统(GIS)领域,OGC 的 Simple Features Access (SFA) 规范是基石。这里的 "Simple"(简单) 并不代表它的功能“简陋”,而是一个严谨的几何学与计算科学术语。
我们可以从以下三个维度来理解这个“简单”:
- 几何学定义:无自相交 (Non-self-intersecting)
在数学和拓扑学中,简单几何对象(Simple Geometry) 指的是那些不与自身相交的对象。
- 简单曲线 (Simple Curve):比如一条从 A 到 B 的线,中间不会像麻花一样交叉。
- 简单多边形 (Simple Polygon):边界不自交,且没有“洞”(或者洞的边界也不与外边界相交)。
核心逻辑: 如果一个多边形的边穿过了自己,它就不再是“Simple”的,处理起来的算法复杂度会呈几何倍数增加。规范要求几何图形必须是“简单”的,是为了保证拓扑关系的明确性。
- 维度限制:二维平面的线性插值
"Simple" 还体现在它对形状描述方式的约束:
- 线性插值:所有的曲线都由直线段(Straight line segments)连接而成。即使是一个圆,在 SFA 规范下也要表达为一个拥有很多顶点的多边形。它不支持复杂的数学曲线(如圆弧、贝塞尔曲线或样条曲线)。
- 维度限制:主要针对 0维(点)、1维(线)、2维(面) 的几何体。虽然现在支持 Z 轴(高度),但其核心计算逻辑仍基于二维平面的拓扑关系。
- 数据模型:对象模型的简化
从软件工程的角度看,“简单要素”意味着它将复杂的现实世界抽象为一套标准的、可预测的对象结构。
- 标准定义:它定义了我们熟知的
Point,LineString,Polygon以及它们的集合体(MultiPoint等)。 - 易于存储:因为定义简单,这些要素可以很方便地存储在关系型数据库的表格中(如 PostGIS、MySQL),或者通过 WKT (Well-Known Text) 这种人类可读的字符串来表达。
| 要素类型 | 描述 | 示例 (WKT) |
|---|---|---|
| Point | 单个坐标点 | POINT(1 1) |
| LineString | 由直线段连接的点序列 | LINESTRING(0 0, 1 1, 2 1) |
| Polygon | 封闭的环(包含外环和可选的内环) | POLYGON((0 0, 4 0, 4 4, 0 4, 0 0)) |
总结
"Simple" 的真正含义是:基于欧几里得平面的、边界不自交的、由直线段构成的几何对象。
这种“简单化”是一种极其成功的策略,它抛弃了极其复杂的非线性数学模型,换取了计算的高效性和跨系统(数据库、Web、桌面软件)的通用性。
SFA的后续扩展
副标题:从“直线”到“圆弧”:地理信息规范的进化。
在地理信息系统(GIS)的数字化进程中,OGC SFA (Simple Features Access) 曾像一位严厉的老师,规定世界只能由“点、线、面”组成,且线必须是直的。这种“简单化”让数据库处理变得飞快,但也留下了一个遗憾:真实的地球,其实充满了曲线。
为了填补这个鸿沟,OGC 通过后续的扩展(主要是吸纳了 ISO SQL/MM 标准),让“简单要素”变得不再简单。
- 突破“直线”的限制:非线性几何
早期的 SFA 规定,任何曲线都必须由无数个小直线段连接而成(线性插值)。但在后续扩展中,规范引入了数学函数来描述形状。
核心新成员:
- CircularString(圆弧线):它不再是由成百上千个点凑成的“近似圆”,而是由起点、弧中点、终点三个点精确定义的数学圆弧。
- CompoundCurve(复合曲线):这是一种“混血儿”。想象一段高速公路,它在直道时使用
LineString,在弯道时无缝切换为CircularString。 - CurvePolygon(曲面多边形):它的边界可以是圆弧。比如一个完美的圆形喷泉,在数据库里只需要一个中心和半径逻辑(或三个边界点)就能精准表达。
- 增加“深度”与“刻度”:Z 轴与 M 值
原本的 SFA 主要是二三维混合的模糊处理,扩展规范则正式确立了 XYZM 四维模型。
- Z(高度/深度):让地理要素从平面的“纸上谈兵”变成了立体的“数字孪生”。
- M(测量值/Measure):这是一个天才的设计。它不代表空间位置,而是一个逻辑刻度。
- 应用场景:在一条铁路线上,即便火车的经纬度坐标 在变,它的“里程数” 是固定的业务参考。这让我们可以直接查询:“在京沪高铁 105 公里处有一个信号灯”,而不需要精确的经纬度。
- 标准化的“拓扑实验室”:DE-9IM
为了让不同软件对“相交”、“包含”的判断逻辑一致,规范强化了 DE-9IM(九交模型)。
它像是一套几何体之间的 DNA 检测。通过分析两个物体内部、边界、外部的交叉情况,用一个 9 位字符的矩阵(如 T*****FF*)来定义空间关系。这保证了你在 PostGIS 里算的“重叠”,在 ArcGIS 或 QGIS 里得到的结果完全一致。
- 为什么要费力搞这些扩展?
你可能会问:既然把圆弧打碎成线段也能用,为什么要搞这么复杂?
- 存储效率:存储一个 3 个点的圆弧,比存储一个 1000 个点的“近似圆折线”节省 90% 以上的空间。
- 计算精度:在精密测绘中,线段模拟带来的误差会随着空间叠加不断累积。
- 行业语义:交通、水利、建筑(BIM)行业原生就是基于曲线设计的,直接支持曲线能让 GIS 与这些行业无缝对接。
- 现状:理想与现实的平衡
虽然规范(SQL/MM)很完美,但现实中存在“性能鸿沟”:
- 数据库(如 PostGIS):已经完全支持这些扩展,能存、能读。
- 前端渲染(如 OpenLayers/Leaflet):由于浏览器绘图性能限制,它们往往还是会将圆弧“线性化”后再显示。
- 数据交换(如 GeoJSON):很遗憾,目前最流行的 GeoJSON 依然只支持“简单要素”的线性路径,不支持原生圆弧。
从 SFA 到 SQL/MM 扩展,是 GIS 从“画地图”向“模拟现实”的跨越。现在的规范既保留了简单要素的高效,又给了复杂世界精确表达的机会。
矢量数据存储
矢量数据可以存储和交换为多种格式,每种格式都有其特定的用途、优点和局限性。在XinGeo的设计中,我们尽量不需要关注格式本身,而是尽可能抛弃格式之间的区别,专属于矢量数据本身,但理解格式之间不同的区别可以帮助我们更好的理解矢量数据,下面对一些常用的数据格式做出介绍。
ESRI Shapefile
ESRI Shapefile(shp),或简称shapefile 由美国环境系统研究所公司(ESRI)开发,是一种用于存储地理要素的几何位置和属性信息的非拓扑、空间数据开放格式。 shapefile 中的地理要素可表示为点、线或面(区域)。 包含 shapefile 的工作空间还可以包含 dBASE 表,它们用于存储可连接到 shapefile 的要素的附加属性。
Shapefile文件组成
Shapefile文件指的是一种文件存储的方法,实际上该种文件格式是由多个文件组成的。其中,要组成一个Shapefile,有三个文件是必不可少的,它们分别是:
- .shp - 图形格式,用于保存元素的几何实体。
- .shx - 图形索引格式,几何体位置索引,记录每一个几何体在SHP文件之中的位置,能够加快向前或向后搜索一个几何体的效率。
- .dbf - 属性数据格式,以dBase IV的数据表格式存储每个几何形状的属性数据。
表示同一数据的一组文件其文件名前缀应该相同。例如,存储一个关于湖的几何与属性数据,就必须有lake.shp,lake.shx与lake.dbf三个文件。而其中“真正”的Shapefile的后缀为.shp,然而仅有这个文件数据是不完整的,必须要把其他两个附带上才能构成一组完整的地理数据。除了这三个必须的文件以外,还有一些可选的文件,使用它们可以增强空间数据的表达能力。 下面的是可选文件,需要注意的是,一般情况下,.prj为必须完整的,否则矢量数据的空间位置会发生错误:
- .prj是坐标系参数。
- .sbn是用于优化查询的空间索引。
- .sbx优化了加载时间。
- .xml是关联的元数据。
在XinGeo中Shapefile的元数据信息存储于数据库中,并不存储和读取关联的xml文件,因此xml文件在CRGIS数据管理中并不识别为数据,仅识别为普通文件。
Shapefile文件的限制
shapefile 具有以下限制:
- Shapefile 大小限制:2 GB。
- 最大字段名称长度:10 个字符。
- 最大字段数:1024。
- 空值仅适用于 Date 字段数据类型,而不适用于 shapefile 中数值和文本字段数据类型。
- shapefile 无法存储拓扑信息或关系。
- Shapefile 和 dBASE 文件默认无法存储非英文字符
- 在字段视图中,可添加、删除或复制字段,但字段保存后,无法修改字段属性
由于这些限制,我们不建议将shapefile 文件作为您的首选文件格式,建议使用PostGIS存储的矢量数据,以使用软件的完整功能。
Geopackage矢量数据
GeoPackage 是一个开放、标准化、平台无关且自描述的数据库格式,用于存储和传输地理空间信息。它基于 SQLite 数据库格式,由开放地理空间联盟(OGC)制定并维护。GeoPackage 的主要目标是让用户能够在不同的地理信息系统(GIS)软件、设备和平台之间轻松共享和发布地理空间数据。
主要特性如下:
- 多种数据类型支持:GeoPackage 支持各种类型的地理空间数据,包括矢量数据(如点、线、多边形)、栅格数据(如卫星图像、地图瓦片)以及其他地理信息(如特征属性表)。
- 单一文件存储:所有的地理空间数据和相关信息都存储在一个单一的 SQLite 数据库文件中。这使得数据管理、共享和传输变得非常简便。
- 开放标准:作为一个开放的国际标准,GeoPackage 旨在促进地理空间数据的互操作性和共享。它被设计来避免专有格式的限制,确保长期的数据可访问性和可用性。
- 广泛的应用支持:由于其开放性和标准化,许多GIS软件和工具都支持GeoPackage格式,包括但不限于ArcGIS、QGIS、Google Earth等。
- 移动设备友好:GeoPackage 特别适合于移动应用场景,因为它基于轻量级的SQLite数据库,易于在移动设备上处理和使用。
GeoPackage 在保存矢量数据时,可以实现超越ESRI Shapefile的功能,但保存栅格数据,只能以“瓦片切片(Tile Pyramid)”机制保存为png/jpg,比较适合WEB浏览,不能实现OGC定义的栅格数据功能,因此,在软件中,使用GeoPackage 保存为数据时,仅能保存矢量数据,在云资源管理器中显示为GeoPackage 矢量(*gpv)。
矢量数据存储(Vector Data)
-
存储方式:
-
每个矢量图层是一个独立的 SQLite 表
-
表中的一列保存几何对象,使用 WKB(二进制形式)
-
其余列为属性字段
-
-
✅关键表
gpkg_contents:记录所有图层的元数据(包括名称、类型、空间范围等)gpkg_geometry_columns:记录每个矢量图层的几何列名、类型(如 POINT、LINESTRING)和空间参考系(SRS)
-
✅示例结构:
CREATE TABLE roads (
id INTEGER PRIMARY KEY,
name TEXT,
geom BLOB -- 存放WKB格式的几何
);
- ✅注册元数据:
INSERT INTO gpkg_contents (
table_name, data_type, identifier, srs_id, min_x, min_y, max_x, max_y
) VALUES (
'roads', 'features', 'roads', 4326, 120.1, 30.1, 120.9, 30.9
);
INSERT INTO gpkg_geometry_columns (
table_name, column_name, geometry_type_name, srs_id, z, m
) VALUES (
'roads', 'geom', 'LINESTRING', 4326, 0, 0
);
栅格数据存储(Raster / Tile Data)
GeoPackage 存储栅格数据采用“瓦片切片(Tile Pyramid)”机制,特别适合地图平铺服务(如 Web Map Tile)。
-
✅存储方式:
-
栅格图层由若干张瓦片图像组成(如 PNG/JPEG)
-
按缩放等级、瓦片行列进行组织
-
图像数据存在
BLOB类型字段中 -
✅ 关键表:
-
gpkg_tile_matrix_set:记录瓦片图层的空间参考和边界框 -
gpkg_tile_matrix:记录不同缩放级别下的分辨率、行列数等 -
瓦片图像表:通常以图层名命名,包含 zoom_level、tile_column、tile_row 和 tile_data
-
-
✅ 示例瓦片表结构:
CREATE TABLE maptiles (
id INTEGER PRIMARY KEY,
zoom_level INTEGER NOT NULL,
tile_column INTEGER NOT NULL,
tile_row INTEGER NOT NULL,
tile_data BLOB NOT NULL -- 图像二进制数据
);
PostGIS矢量数据
PostGIS 是 PostgreSQL 的空间扩展,能够让数据库支持地理空间数据类型、索引和函数。 其中,“矢量数据”是最常用的数据形式,用于表示点、线、面等空间要素。
什么是PostGIS
PostGIS 最初是位于加拿大维多利亚州的地理空间咨询公司 Refractions Research (http://refractions.net) 的一个项目,此后已被政府、大学、公共组织和其他公司采用和改进。
PostGIS 的基础是 PostgreSQL 对象-关系数据库管理系统 (ORDBMS),它提供事务支持、空间对象的 gist 索引支持以及现成的查询管理程序。
为什么是PostGIS
PostGIS支持OGC SFS,OGC(Open Geospatial Consortium)是全球地理信息标准的权威组织。 Simple Features Specification (SFS) 是 OGC 发布的最早也是最核心的标准之一,最初在1999年发布。目标是: ✅ 定义**“几何对象(Geometries)”的通用数据模型 ✅ 标准化存储、操作、交换**矢量数据的方式 ✅ 让不同厂商软件(Oracle Spatial, ESRI, PostGIS等)互相兼容
支持OGC SFS带来的优势如下:
✅ 标准化: 不同数据库(Oracle Spatial, SQL Server, PostGIS、SpatiaLite )之间可以互导数据。
✅ 可扩展: GIS客户端(QGIS、ArcGIS)都能直接连PostGIS读取标准几何。
✅ 功能完备: 数百个函数覆盖OGC定义的绝大部分操作。
✅ 兼容未来: 随着OGC/ISO标准演进,PostGIS也不断扩展。
SFS对几何数据的核心定义
A. 支持的几何类型,简单几何由以下七种基础类型组成:
| 几何类型 | 英文名称 | 描述 |
|---|---|---|
Point | 点 | 一个位置(X, Y) |
LineString | 线 | 一个有序点集,不自交 |
Polygon | 面 | 一个闭合线环(外环 + 可选内环) |
MultiPoint | 多点 | 点的集合 |
MultiLineString | 多线 | 多个 LineString |
MultiPolygon | 多面 | 多个 Polygon |
GeometryCollection | 几何集合 | 任意几何的组合 |
这些几何类型都能用WKT(Well-Known Text)或WKB(Well-Known Binary)表示。
B. 几何属性
OGC SFS要求几何对象满足:
-
**简单性(Simple):**如 LineString 不自交,Polygon 不重叠
-
**有效性(Valid):**几何是闭合的、正确的
-
**维数:**点(0D)、线(1D)、面(2D)
PostGIS是第一个完全通过OGC SFS一致性测试的开源空间数据库扩展。 它的目标就是:
“让用户能放心地把PostGIS当作一个标准的、可靠的、可互操作的空间数据库。”
在PostGIS中: ✅ 所有几何类型都符合SFS标准 ✅ 所有空间谓词、函数都尽量遵循OGC规范 ✅ 支持WKT/WKB输入输出 ✅ 可通过SQL/MM标准接口
支持的几何类型
PostGIS 中矢量数据基于 OGC Simple Features 标准,核心数据类型如下:
| 数据类型 | 含义 | 示例 |
|---|---|---|
POINT | 单个点 | 城市坐标、取样点 |
LINESTRING | 折线(有序点集) | 河流、道路中心线 |
POLYGON | 多边形(闭合区域) | 行政区、湖泊 |
MULTIPOINT | 多个点 | 传感器组位置 |
MULTILINESTRING | 多条折线 | 公路网络 |
MULTIPOLYGON | 多个多边形(通常带洞) | 分布式保护区 |
GEOMETRYCOLLECTION | 混合几何(不常用) | 多种几何的组合 |
另外,PostGIS 还吃多面体、曲面和TIN,可以Esri geodatabase 相媲美。
KML格式
Keyhole Markup Language (KML) (.kml)是一种基于 XML 的格式,用于存储地理数据和相关内容,是一种开放地理空间联盟 (OGC) 标准。KML 格式便于在 Internet 上发布并可通过 Google 地球和 ArcGIS Explorer 等许多免费应用程序进行查看,因此常用于与非 GIS 用户共享地理数据。国内GIS软件很多也支持将用户标记导出为KML文件。
KML 文件要么以 .kml 为扩展名,要么以 .kmz(表示压缩的 KML 文件)为扩展名。
CRGIS无法直接编辑KML文件,但支持读取和导出,用户可直接在CRGIS中上传并导入KML文件,也可以将矢量数据导出为KML文件。
XML文件可以使用文本编辑器直接打开,一个简单的kml文件内容示例如下:
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Placemark>
<name>A Place</name>
<description>This is a description of the place.</description>
<Point>
<coordinates>-122.0822035425683,37.42228990140251,0</coordinates>
</Point>
</Placemark>
</kml>
GeoJSON
GeoJSON 是一种基于 JSON(JavaScript Object Notation) 的开放标准格式,用于表示地理空间数据。 它既是一种数据交换格式,也是Web GIS 可视化的事实标准
GeoJSON 被广泛用于:浏览器地图(Leaflet、OpenLayers)、Web API(RESTful 服务)、空间数据库(PostGIS、MongoDB)和移动GIS应用。
GeoJSON 的特点
🔹 纯文本格式,易读易编辑 🔹 直接支持 UTF-8 编码 🔹 与JavaScript、Python、PostGIS、NoSQL完美兼容 🔹 支持矢量要素与属性一体化 🔹 可用于前端直接渲染
GeoJSON 文件结构
GeoJSON 文件是一个JSON对象,必须包含一个 type 字段,表示数据类型。
最常见的四种结构:
| 类型 | 描述 |
|---|---|
Point | 单个点 |
LineString | 折线 |
Polygon | 多边形 |
Feature | 带属性的单个要素 |
FeatureCollection | 多个要素的集合(最常用) |
GML
GML (Geography Markup Language) 是一种基于 XML (eXtensible Markup Language) 的开放标准,用于表示、存储和交换地理空间信息。它由 OGC (Open Geospatial Consortium) 制定,目标是成为跨平台、跨系统的空间数据通用语言。
GML是OGC WFS(Web Feature Service)的默认交换格式,客户端(QGIS/ArcGIS)可以直接解析。。
GML 的主要特点
✅ 基于XML,结构清晰、可扩展 ✅ 可描述几何、属性、坐标参考系、拓扑关系 ✅ 支持丰富的地理要素模型 ✅ 具备Schema(模式约束),保证数据一致性 ✅ 与 OGC 标准(WFS、WMS等)紧密集成
GML 是许多政府、国土资源、测绘部门和国际数据交换的首选标准。
GML 核心组成部分
GML 的基本单位是要素(Feature),每个要素包括:
1️⃣ 属性(Property)
- 如名称、类别、编号
2️⃣ 几何(Geometry)
- 点、线、面(支持 OGC Simple Features)
- 复杂几何(如复合曲线、曲面)
3️⃣ 坐标参考系(CRS)
- 可定义 EPSG 编码或自定义 CRS
4️⃣ 标识与元数据
- Feature ID、Schema定义
示例:一个简单的 GML Point
<gml:Point srsName="EPSG:4326">
<gml:coordinates>116.4,39.9</gml:coordinates>
</gml:Point>
🗺️ 示例:Feature + 属性 + 几何
<gml:featureMember>
<myNS:CityFeature gml:id="city.1">
<myNS:name>Beijing</myNS:name>
<myNS:population>21540000</myNS:population>
<myNS:location>
<gml:Point srsName="EPSG:4326">
<gml:coordinates>116.4,39.9</gml:coordinates>
</gml:Point>
</myNS:location>
</myNS:CityFeature>
</gml:featureMember>
GML 支持的几何类型
GML遵循OGC Simple Features模型,支持:
PointLineStringPolygonMultiPointMultiLineStringMultiPolygonGeometryCollection- 以及拓扑几何 (TopoGeometry)


