地理信息系统

地理信息系统处理的是带有位置含义的信息。这里的“位置”不只是经纬度，还包括地物之间的邻接、包含、连通、距离、方向和尺度。把一张表加上坐标列，可以得到空间数据，却不一定形成有用的 GIS。真正的工作从问题开始：对象位于哪里，彼此有什么空间关系，某种现象怎样随时间和区域变化，数据精度是否足以支持判断。

GIS 同时是一套概念、一组分析方法和一类软件系统。概念层决定怎样描述现实世界，方法层负责测量、转换和推断，系统层负责采集、存储、计算、表达与共享。如果只熟悉软件按钮，很容易忽略坐标参考和误差；如果只学习空间理论，又难以面对数据格式、数据库、服务接口和性能限制。

从现实对象到空间数据

道路、河流和行政区在现实中连续存在，计算机必须选择一种可以存储和计算的表达。矢量模型用点、线、面及其属性描述离散对象，栅格模型把空间划成规则像元，更适合连续表面和影像。两者不是互相替代的阵营。道路中心线适合用矢量表示，地表温度通常更适合栅格；同一项目往往需要在两种模型之间转换。

OGC Simple Features 建立了常用几何类型和空间关系的基础。点、线串、多边形及其集合看似简单，实际应用还要处理空几何、自相交、环方向、维度、测量值和无效拓扑。几何有效不等于业务正确：一块合法多边形仍可能落在错误行政区，一条连通的道路也可能不允许车辆通行。

坐标参考系统决定数字坐标如何对应地球。经纬度不是天然统一的平面坐标，不同大地基准、轴顺序、单位和投影会产生不同结果。距离、面积和缓冲计算前必须确认数据使用的 CRS 以及算法的计算空间。WKT 可以表达坐标参考系统及坐标操作，但仅有一段 WKT 还不够；工程中仍需记录数据来源、适用区域、转换方法和精度。

空间分析不是普通查询加一个地图

普通数据库擅长按属性筛选记录，空间数据库还要回答相交、包含、最近、可达和可视等问题。PostGIS 把几何、地理坐标、空间索引和分析函数放进 PostgreSQL，使空间条件可以与事务、权限和普通属性查询一起工作。空间索引能够缩小候选范围，但精确关系判断通常还需要几何计算。看到查询使用了索引，不代表整个分析已经正确或高效。

缓冲、叠加、插值和网络分析都隐含假设。缓冲距离取决于坐标单位和测量方式；叠加结果受数据精度与边界一致性影响；插值要求理解采样分布和空间相关；最短路径也必须先定义“最短”对应时间、距离、费用还是其他成本。GIS 的专业性往往体现在这些假设被明确写出，而不是工具执行得多快。

从文件走向服务

地理数据常在 Shapefile、GeoPackage、GeoJSON、GeoTIFF、Cloud Optimized GeoTIFF 和数据库之间流动。格式选择关系到字段类型、坐标信息、文件规模、随机访问和协作方式。GDAL 提供统一的栅格和矢量数据模型及转换工具，但转换前后仍应检查坐标参考、NoData、编码、字段精度和几何有效性。

Web GIS 把数据访问、地图表达和分析能力放到网络环境。传统 WMS、WFS、WMTS 与新的 OGC API 系列解决的对象和交互方式并不相同。OGC API - Features 以 Web 资源方式访问要素，核心部分先规定发现和查询能力，其他部分再扩展坐标参考、过滤和更复杂操作。选择接口时应从数据类型、客户端需求、缓存策略和更新方式出发，而不是把所有空间数据都做成同一种服务。

后续知识体系将依次展开坐标参考、空间数据模型、质量、数据库、分析、制图、Web GIS、三维场景和工程实践。遥感影像在栅格与分析部分和 GIS 交汇，GeoAI 则在空间抽样、特征、评估和部署环节与人工智能相连。

资料依据

OGC Standards，地理信息模型、编码和接口标准的权威入口。
OGC API - Features，要素资源发现、查询和扩展能力的标准说明。
PostGIS Official Manual，空间类型、索引、查询和数据库管理的官方资料。
GDAL Documentation，栅格与矢量数据模型、驱动和处理工具的官方文档。