企业官网建设流程全解析

做GIS项目这些年，我越来越觉得空间数据格式是“被低估最多的一环”。很多时候项目前期没人关心数据用什么格式存，等做到一半才发现字段名被截断、中文乱码、图层错位，甚至几十GB的数据打不开，所有锅最后都甩给“数据有问题”。其实很多问题从选格式那一刻就已经注定了。空间数据格式说白了就是地理信息在计算机里的“存在方式”，选对了，后面跑分析、做发布、搞可视化都顺；选错了，每一步都在还债。

这篇东西我打算从格式的底层逻辑讲起，把矢量、栅格两大类里最常见的格式全部过一遍，包括它们的设计初衷、优势和硬伤，再直接给出我在实际项目里用的选型思路、转换工具和踩坑记录。不管你是刚入行的GISer，还是被数据格式折磨过的老手，这篇内容应该都能帮上忙——至少下次再有人甩一个格式不明的数据过来，你能一眼判断该用什么路子处理。

1. 空间数据的两种“活法”：矢量与栅格

1.1 矢量模型：用点线面描述世界

矢量数据用几何对象来表达地理要素，点、线、面是它的三种基本形态。一个路灯是点，一条河流是线，一个小区边界是面。每个几何对象背后还可以挂一堆属性，比如路灯的编号、河流的名称、小区的占地面积。

矢量格式最大的优势是精度高、体积相对小。存一条国界线，我只需要记录一串坐标点，而不是像照片一样把整条线“画”出来。这意味着任意比例尺下缩放都清晰，也方便做空间计算，比如求两条线是否相交、某个点落在哪个面里。ArcGIS、QGIS这类桌面软件处理矢量数据最顺手，PostGIS这类空间数据库也是建立在矢量模型之上。

1.2 栅格模型：用像素格子铺满空间

栅格数据则是把连续空间切分成规则网格，每个格子存一个值。卫星影像、高程模型、气温分布图，本质上都是栅格。一个格子代表地面上一个矩形范围，格子的值可能是光谱反射率、海拔高度或者温度数值。

栅格格式的优势在于表达连续现象，它没有“边界”概念，每个位置都有一个值，适合做遥感分类、地形分析、插值分析这类活儿。代价就是体积大，一个区域的高分辨率影像动辄几百MB甚至几个GB，而且缩放到一定程度就会出现锯齿。栅格数据没法直接“查询某条路的属性”，它只有一层层的数值。

1.3 两个模型的边界正在模糊

现在不少格式已经模糊了矢量和栅格的界限。比如GeoPackage里可以同时放矢量图层和栅格影像，云端瓦片格式也把矢量和栅格混合处理。做选型的时候不用死守“矢量项目用矢量格式、影像项目用栅格格式”的老规矩，关键看数据怎么来、要往哪去。

我见过不少新人问我“GeoTIFF是不是只能存影像”，其实从模型层面想就明白——它只是带地理坐标的TIFF图片，当然只能表达栅格。反过来也有人问我“能不能用Shapefile存高程”，这等于问“能不能用Word存视频”，模型根本对不上。

2. 得摸透每种格式的“脾气”：主流矢量格式逐个讲透

2.1 Shapefile：老当益壮还是该被淘汰？

聊矢量格式绕不开Shapefile，这玩意儿从90年代ESRI搞出来到现在，依然是行业默认交换格式。一个完整的Shapefile其实是一个文件集合，至少包含三个文件：.shp存几何、.dbf存属性、.shx存索引，平常见到的一堆同名文件其实都是同一个数据集的一部分。

Shapefile能活这么久就一个原因——兼容性无敌。你手里的ArcGIS能读，QGIS能读，各种开源库能读，政府数据交换平台也能读。可以说它是GIS界的“PDF”，几乎所有软件都认。但它的缺点同样致命，字段名最长10个字符，中文属性经常乱码，文件大小不能超过2GB，几何类型单一，不支持拓扑关系。做复杂数据模型或者大数据量存储，Shapefile根本扛不住。

我不建议在新项目里主动选Shapefile作为存储格式，只把它当“交换格式”来用就好。给别人发数据、上传到政务平台、和老系统对接数据，这些场景用Shapefile最稳妥；自己内部做项目，老老实实用数据库或GeoPackage，后面会细说。

2.2 GeoJSON：Web开发者的心头好

GeoJSON基于JSON标准，把几何信息用坐标数组表示。它的走红跟WebGIS的爆发高度绑定，JavaScript天生就能解析JSON，Leaflet、Mapbox、OpenLayers这些前端库全都原生支持GeoJSON。

GeoJSON最大的特点就是“人眼可读”。用文本编辑器打开一个GeoJSON文件，你能直接看到一串坐标和一个要素的属性，调试极其方便，这也让它成了前后端数据交换的默认格式。后端从PostGIS查出来的空间数据转成GeoJSON丢给前端渲染，是WebGIS项目最常见的链路。

但人眼可读的另一面就是体积膨胀。一个明明用Shapefile存只要10MB的图层，转成GeoJSON可能变成30MB起步，因为坐标要写成文本、属性键值要反复出现。数据量一大，前端解析和渲染都会卡顿。所以我不建议把GeoJSON当成存储格式，它更适合做“数据中转”和“轻量交互”。

GeoJSON里还有个细节特别容易踩坑——坐标顺序是经度在前、纬度在后，也就是[114.05, 22.55]这样，但很多其他地方使用的格式是纬度在前。我见过不少人在写代码时把这两个值调换，结果点位全部跑到海里去了，排查半天才发现是这个事。

2.3 KML/KMZ：给Google Earth准备的格式

KML基于XML语法，2008年成为OGC标准，核心场景是Google Earth以及Google Maps的早期版本。它描述的不只是几何信息，还包括样式、气泡提示、视角高度这些展示类信息，所以非常适合做“带演示效果”的地理数据。

KMZ是KML的压缩包版本，一个文件里可以同时包含主KML文件和引用到的图标、纹理图片，发给别人打开就能完整显示。做野外调查、项目汇报、给非GIS专业的人分享数据位置，KML/KMZ特别好用——对方电脑上装个Google Earth就能看，不需要装ArcGIS或QGIS。

KML的尴尬在于复杂分析能力太弱。它本质上是个“展示格式”，几何精度、属性结构、拓扑处理都比专业GIS格式差一截。我自己拿KML通常只做两件事：一是给客户发点位数据方便他们看图，二是从Google Earth里导出一些简单地理信息。真到了做空间分析或者数据入库的时候，我还是会把KML先转成GeoJSON或者Shapefile再继续。

2.4 File Geodatabase：ArcGIS的“内功心法”

File Geodatabase（文件地理数据库）是ESRI推出的面向文件系统的数据库格式，用文件夹存储一组数据。相比Shapefile，它的进步是“代际”的：字段名可以到64字符，支持子类型、拓扑、网络数据集、属性域这些高级对象，单个数据集体积上限高达TB级别，查询和编辑性能也远强于Shapefile。

做ArcGIS项目，尤其是ArcGIS Pro的项目，File GDB就是最顺手的存储格式。它有完整的GIS数据管理能力，你在ArcGIS里做的很多模型、拓扑规则、注记、关系类，只有存成File GDB才能完整保留。按要素类分层的组织方式也方便管理大量数据，不用像Shapefile那样堆一堆散落的同名文件。

核心问题在于它是个“半封闭”体系。QGIS虽然能读File GDB，但支持的版本和要素类类型有限；开源生态里读写File GDB的库也不够成熟；到了Linux服务器上处理它就更是麻烦。因此File GDB适合“ArcGIS环境内部使用”，需要跨平台、跨软件流转数据时，别指望它能当通用格式。以前做项目经常要跟测绘院对接，他们统一交付File GDB，而我这边处理工具大多是开源的，每次都要专门写转换脚本，折腾几次之后我就学乖了——先问清楚对方能不能同时出Shapefile或GeoPackage。

2.5 GeoPackage和PostGIS：现代存储的两把利器

GeoPackage是OGC在2014年推出的开放标准，基于SQLite，一个文件就是一个完整的空间数据库。它同时支持矢量和栅格，支持空间索引，文件体积上限基本不用考虑，而且不依赖任何商业软件。用QGIS创建、编辑、分析，在开源工具链里跑得很顺，很多移动端GIS应用也直接拿GeoPackage当本地存储格式。

PostGIS则更进一步，它是PostgreSQL数据库的空间扩展，直接把空间数据和业务数据放在同一个数据库里管理，支持完整的事务、并发控制和复杂的空间查询。做WebGIS项目，只要数据量到了百万级，我都会优先考虑PostGIS——不为了花哨，就为了多用户同时写数据不会锁死，也为了能直接写SQL做空间分析，清洗和处理效率比桌面软件高一个量级。

这两者其实常搭配使用。项目开发调试用GeoPackage随手编辑，正式服务接PostGIS保证稳定，需要给外部交付数据的时候再从库里导出对应格式。这种组合兼顾了灵活和稳定，我在很多项目里都是这么落地的。

2.6 矢量格式哪家强：一张表看明白

表格能看出一件事：没有任何一种格式是“全能的”。选格式本质上是在选“你当前最看重什么”和“你愿意放弃什么”。重兼容就选Shapefile，重开发体验就选GeoJSON，重分析重管理就选PostGIS或GeoPackage——把场景想清楚，答案自己会浮出来。

3. 影像世界的主角：主流栅格格式逐个拆解

3.1 GeoTIFF和COG：影像格式的基石

GeoTIFF就是在标准TIFF基础上嵌入了地理参考信息，把坐标系统、仿射变换参数、可能有的高程信息写进文件头。只要是带坐标的影像，几乎都能用GeoTIFF存，遥感影像、扫描地形图、DEM数据，覆盖面极广。它支持多波段、多种压缩方式、多种位深，是影像处理领域的“老大哥”。

但传统GeoTIFF有个问题：数据必须从开头顺序读取，想随机看中间某个区域，得把前面的数据全部解码，效率很低。于是几家公司联合推动了一类新的格式，通常被叫做COG（Cloud Optimized GeoTIFF，云优化GeoTIFF）——本质上仍是GeoTIFF，但在内部做了金字塔结构重排，允许HTTP Range请求只读取需要的部分。在云端浏览或切片的场景下，COG比传统GeoTIFF快好几倍。

我去年做过一个省级影像发布项目，源数据是传统GeoTIFF。一开始直接拿来做动态切片，服务端卡到不行。后来把所有GeoTIFF转成COG并构建了概览金字塔，同样一组数据、同样的服务器配置，前端加载时间从十几秒降到了两秒左右，体感差异跟换了台机器一样明显。所以新接触影像数据时不妨先确认它是不是COG，如果是就省掉一大截预切片的时间。

3.2 ECW与MrSID：为“能看”而生的压缩格式

ECW和MrSID这两类格式本质上是一类“视感压缩”技术：专门用于遥感影像的极致压缩，解压速度快、对超大影像的浏览友好。ECW可以压缩到原数据的5%~10%还能保持影像看起来很清晰，一个1GB的影像压缩完可能只有80MB上下，打开浏览却依然流畅。

这类格式最大的局限在于“专”。解码依赖商业SDK，开源生态支持也一般，QGIS里读ECW通常要额外装插件或驱动，更麻烦的是很多在线影像服务根本不认这类格式。它们适合做本地浏览和交付展示，不适合放进需要进一步裁剪、分析、发布的工作流。

我不建议把ECW当成影像存档的“唯一格式”，最好是原始GeoTIFF存档、ECW浏览、COG发布，多副本各司其职——这也是不少测绘单位的通行做法。

3.3 IMG、HFA与其他“一亩三分地”格式

IMG格式是ERDAS公司（后为Hexagon）推出的遥感影像格式，其底层本质常被称为HFA（Hierarchical File Format，层次文件格式），支持多波段、金字塔、统计信息，在ERDAS等专业遥感软件里流转历史悠久。国内很多早期遥感项目的数据交付都是IMG格式，存量数据相当大。

IMG的兼容性其实不错，GDAL能直接读取和转换，QGIS也能正常打开。真正让它麻烦的是后续写入、编辑操作需要配套软件，开源工具对新版功能的写支持也不够完整。比如我想在QGIS里对IMG数据集做波段计算，通常还是先转成GeoTIFF再处理，因为这样更稳。做遥感方向的人遇到旧版IMG不用担心，GDAL命令批量转换一下就行，没必要强行保留原始格式。

3.4 NetCDF与HDF：科学计算世界的“大块头”

NetCDF和HDF都是面向科学数据设计的自描述格式，它们所存储的不仅仅是数值阵列，还会把变量名、单位、维度、坐标轴这些元数据一并保存。气象、海洋、气候模拟这些领域，这种格式几乎是标配。NetCDF常用于存储气象站点观测、再分析资料、数值预报产品；HDF则广泛用于卫星对地观测数据，很多中分辨率成像光谱仪产品都基于HDF封装发布。

这两类格式的学习曲线比较陡，普通GIS软件打开它们只能看到“一层壳”，真正有价值的子数据集藏在复杂的组结构里，你得懂一点科学数据结构的组织逻辑才找得到。做专业气象和遥感数据分析时，建议直接用xarray这类科学计算生态来处理，比桌面GIS更顺手。

3.5 栅格格式选型速览

4. 实战选型：不同场景用什么格式最省心

4.1 桌面分析场景

ArcGIS生态里，数据管理直接上File GDB，尤其涉及拓扑、关系类、版本管理时，这是唯一稳妥的选项。QGIS为主的场景则首选GeoPackage，一个文件管理一个项目的所有图层，还能建空间索引，编辑和查询体验明显好于Shapefile。纯粹做单图层小数据的处理，Shapefile也不是不能用，但建议只做到“临时交换”这个层级。

4.2 WebGIS与在线发布场景

在线发布场景要看数据的“消费方式”。要素类数据，无论来源是什么，到了服务端通常都会进入PostGIS做统一管理，再通过后端接口把查询结果转成GeoJSON送往前端，这套链路我基本没换过。前端展示海量点位时，GeoJSON直接给几万个要素会卡，需要用矢量瓦片（例如Mapbox Vector Tile格式）做分层加载。

影像类数据在线发布，现在的标准答案基本是COG，配合对象存储直接发布。传统做法是先切瓦片再发布，流程繁琐，比较适合数据形态相对固定的场景；当数据需要频繁更新时，直接用COG发布能省下非常多繁琐的预切片工作。

4.3 数据交换与长期归档场景

对外交付数据，先搞清楚对方用什么软件。遇到“我们要ArcGIS格式的”，优先交付File GDB；遇到“发个能打开的文件”，Shapefile是安全的默认选项，但要注意字段名、编码这些细节容易出问题；如果对方用QGIS或对格式要求比较现代，直接交付GeoPackage会省掉很多麻烦。长期归档场景我建议原始数据保持无损，比如GeoTIFF LZW压缩，不要为了省空间用有损压缩——归档的意义就是未来某个时刻能完整恢复原始信息，有损格式会让这一步变得不可靠。

4.4 选型时最容易忽略的三个问题

忽略空间参考系是选型时最常见的错误。格式能存什么和坐标系是两个维度的事，但很多人把它们混在一起。GeoJSON默认要WGS84经纬度，而Shapefile或GeoPackage可能存的是投影坐标系；如果应用交付时坐标系不一致，坐标偏移、测距错误都会跑出来。

忽略元数据保留是第二类坑。Shapefile、GeoJSON这类格式几乎不存储数据来源、处理历史、字段含义等元数据信息。一个数据集今天能用，三年后接手的人根本不知道每个字段代表什么。稍微规范一点的项目，都应该同步交付一份元数据文档，或者选择能内嵌元数据的存储形式，比如GeoTIFF里的元数据标签或GeoPackage里的扩展表。

忽略字符编码是第三类坑，主要出现在Shapefile上。它老旧的dBase属性表本身不明确声明编码，中国数据用GBK或UTF-8都有可能，而读取方默认的编码设置一旦不一致，就会出现中文乱码。我自己处理Shapefile交换数据的习惯是：拿到手先检查属性表中文是否正常，不正常就用工具强制指定编码重转一次，确保流通环节只有一种编码，绝不混用。

5. 格式转换实操：最常用的一招一式

5.1 GDAL：格式转换的“万能钥匙”

GDAL（Geospatial Data Abstraction Library，地理空间数据抽象库）是整个开源GIS生态的地基，QGIS底层的栅格和矢量读写就是靠它完成的。装了QGIS，或者直接用conda安装gdal，就能用命令行完成几乎所有格式转换工作。

举个例子，把Shapefile转成GeoPackage：

ogr2ogr -f GPKG output.gpkg input.shp

把GeoPackage转成GeoJSON并指定坐标系：

ogr2ogr -f GeoJSON output.geojson input.gpkg -t_srs EPSG:4326

目录里批量转栅格，把一堆GeoTIFF转成COG并构建金字塔：

gdal_translate -of COG -co COMPRESS=DEFLATE input.tif output_cog.tif

加上通配符就可以批量执行：

for i in *.tif; do gdal_translate -of COG -co COMPRESS=DEFLATE "$i" "${i%.tif}_cog.tif"; done

5.2 QGIS的另类“另存为”思路

很多人用QGIS只会“图层右键另存为”，对小数据量这么干没问题，但图层一多就低效。QGIS的批量处理工具可以一次性把多个图层统一转换，参数里还能批量指定目标坐标系和输出字段，效率提升非常明显。

5.3 转换过程中的“暗坑”整理

转换时坐标系经常被忽略，看到“图层没有CRS”这类提示就顺手跳过，等数据叠加到一起才发现位置对不上。正确的做法是每一步转换都明确指定源坐标系和目标坐标系，宁可多写几行参数，也不要一路默认下去。

字段类型丢失也很常见。比如源数据里的整型字段转到PostGIS后变成了浮点，长短整型直接变宽字段，遇到有严格字段定义要求的系统，前端直接报错。转换完记得生成一份字段映射检查表，必要时手动指定字段类型。

6. 我处理过的那些“格式血泪史”与最终建议

6.1 一个多源数据整合项目的复盘

两年前我接手过一个交通态势项目，数据来源五花八门：GPS轨迹收集到的散点不少是CSV文本，路网是测绘院给的File GDB，区域边界是网上扒下来的GeoJSON，背景影像来自公开影像服务的瓦片。刚开始各用各的格式，后面做叠加分析时出了各种问题——CSV没有坐标系参考，GeoJSON的坐标系和业务系统不一致，File GDB又需要单独处理读取权限和字段编码。

当时我的处理思路是：先定一个“主存储格式”，把所有数据先归拢到一个PostGIS库里，矢量数据统一用SQL做坐标转换和字段标准化，CSV先用ogr2ogr分批导入并显式指定坐标系，GeoJSON只做一次中间导入、之后全部从库里出数据。外部交换用GeoPackage打包成不同图层，影像单独走COG发布。整套流程稳定下来之后，项目的多源数据问题基本归零。

6.2 关于格式选择的几条“心法”

越开放越好，越标准越好。非特殊需求不要选私有格式，私有格式的读写能力始终受制于人。

内部分工明确：存储分析以PostGIS为主，交换以GeoPackage和Shapefile为主，展示以GeoJSON和COG为主。这几种角色各司其职，不互相替代。

文档和元数据比格式本身更重要。无论选什么格式，一份完备的元数据记录都能把未来的维护成本降一大半。

我这些年总结下来，选格式最怕的不是不懂技术，而是不清楚自己的数据将来会被谁用、以什么方式用。搞清楚这个问题，格式选型就成功了一大半。数据上云越来越多、在线协作越来越频繁的今天，开放和标准一定是大方向，新项目里尽量别再造私有格式的地基了。