GeoJSON数据处理与ZIP压缩包实操：从解压校验到避坑指南

简介本资源是一套面向GIS开发者、Web地图工程师及地理信息初学者的GeoJSON地理数据集解决实际项目中基础行政区划数据获取难、格式不统一、解析成本高等问题。压缩包共1102个文件主体为1100个标准GeoJSON文件含全球多国各级行政区边界如印尼、巴西、菲律宾、加拿大、德国等国的1–4级行政单元辅以1个说明文档md和1个结构化CSV含全国县级以上地名代码及经纬度总大小156.12MB开箱即用适配Leaflet、Mapbox、OpenLayers等主流前端地图库。已有574人学习下载资源覆盖完整层级体系与跨区域数据可直接用于地图可视化、空间查询、行政边界渲染、坐标匹配等典型场景CSV文件还支持属性关联分析GeoJSON文件均符合RFC 7946规范具备良好兼容性与可扩展性。 看到“搜集来的geojson数据_GeoJSON_data.zip”这个文件名时我大概已经能猜到里面装的是什么了不同渠道下载的行政区划边界、路网、POI点数据命名风格各异坐标系可能还混着WGS-84和GCJ-02属性字段更是各写各的。更麻烦的是这类zip包十个里有三四个在传输过程中已经受损解压时报错、导入软件时报错、打开后乱码……我电脑里至今还躺着好几个类似命名的压缩包每次打开都像在拆盲盒。今天不聊高大上的GIS理论就讲我拿到这类GeoJSON数据包之后的完整处理流程先怎么验证zip包能不能用再怎么看GeoJSON内容、检查坐标系和字段最后怎么转成路网、导入到UE这类工具里以及这一路上踩过的各种报错。你要是也经常跟地理数据打交道或者刚接触这些格式可以参考我这套流程少走点弯路。1. 拿到zip之后先别急着解压把思路理清楚1.1 GeoJSON到底是什么为什么大家都用这个格式GeoJSON是一种基于JSON的矢量数据编码标准一个FeatureCollection里放若干Feature每个Feature有geometry和properties两部分。相比shapefile这种一个文件还要拆成shp、shx、dbf、prj好几个附件的格式GeoJSON用单个文件就能表达完整的要素集合浏览器里直接就能当JSON解析。这也是为什么在Web地图、数据可视化项目里GeoJSON几乎是默认的输入格式。不过这种便利是有代价的。JSON文本格式没有“分图层”概念一个文件通常只适合放一种类型的要素另外GeoJSON不保存拓扑关系路网数据如果要做最短路径之类的网络分析得先自己构建拓扑。换句话说GeoJSON适合“表达”和“交换”但不一定适合“分析”。拿到一批GeoJSON数据时我通常先问自己一个问题这批数据最终是要展示、分析还是作为中间格式转给别的工具想清楚用途后面才知道该花多少力气去清理数据。1.2 行政区划边界这类数据坐标系是第一个坑西咸新区、东莞市镇街边界、四川矢量地图这些关键词一出来基本可以判断手头是行政区划边界或地图底图类数据。这类数据来源很杂高德、百度、天地图、OSM、GADM、各种统计年鉴配套数据。来源一杂坐标系就乱套了。常见的有WGS-84GPS原始坐标、GCJ-02高德/腾讯用的火星坐标、BD-09百度坐标。同一份镇街边界用GCJ-02的版本和用WGS-84的版本叠在一起偏移量可能达到几百米。这个偏移在城市尺度下意味着建筑物直接压到了马路对面做720度全景标注、做车道级路网完全是不可用的。所以我拿到数据的第一件事不是看内容而是查坐标系。快速判断方法是用QGIS加载一份已知的WGS-84底图比如OpenStreetMap把待检查数据叠上去看边界线是否和底图吻合。如果整体偏向东南方向、偏移量在几十到几百米范围内大概率是GCJ-02如果在此基础上再偏出几百米可能是BD-09。确认之后再用QGIS的矢量重投影功能统一到目标坐标系。这个步骤不能省我已经不止一次见到项目里因为坐标系不一致最后地图上数据错位到完全没法用的例子。1.3 动手前先给数据做一次快速“体检”解压之前先做三个快速检查。第一用ls -l看一下zip文件大小。如果文件只有几十KB而名字里写着“全国”或者“全省”基本可以判断内容不完整。第二用unzip -l列出压缩包里的文件列表不看内容只看有没有文件、文件后缀是否符合预期特别留意有没有.DS_Store、.tmp之类的垃圾文件混在里面。第三随机挑一两个GeoJSON文件用文本编辑器或者jq简单看一下结构确认是不是合法JSON。这轮体检能挡掉大部分后续问题。很多人拿到zip直接双击解压解压失败才反应过来文件是坏的浪费时间。我先用命令行做基础校验五分钟能筛掉一半问题包。体检之后再做正式的数据整理流程效率会高很多。2. zip压缩包操作全解从解压到重新打包的完整姿势2.1 Linux下解压和压缩zip文件的基本命令如果你在服务器上处理这批数据Linux命令是绕不开的。解压最常用的是unzip基础用法是unzip GeoJSON_data.zip -d output_dir。注意这个-d参数我见过太多人解压完发现文件全散在当前目录就是因为没指定输出目录。压缩则用zip -r 目标.zip 源目录/-r表示递归。还有一个容易忽视的参数是-9代表最大压缩比。GeoJSON是纯文本压缩率其实非常高-9能明显减小体积压缩时间也会长一点但文件不大时无脑用-9就行。另外在Linux上打包发给别人之前建议用zip -UNUTF8参数指定UTF-8文件名或者确保你的工具默认使用UTF-8否则在macOS和Windows上很容易出现解压乱码这个坑后面会详细说。2.2 常见zip包类型MySQL免安装包、GitHub源码包、字体包解压后的动作不一样热词里出现了mysql-8.0.46-winx64.zip、sourcehansanssc otf.zip、github下载的zip这类说明很多人不只是处理GeoJSON还会碰到各种用途的zip。这里给个通用判断框架拿到zip先看它是哪种类型再决定解压后做什么。免安装软件包如MySQL winx64 zip解压只是第一步。MySQL 8.x的zip解压后没有data目录需要手动执行mysqld --initialize-insecure初始化再配置my.ini、启动服务。直接解压双击mysqld.exe是没有用的。源码包如GitHub下载的zip这不是conda包不能直接conda install。通常解压后先看有没有environment.yml有就conda env create -f environment.yml如果是Python包往往要pip install -e .或python setup.py install装到当前环境再谈使用。字体包如思源黑体otf.zip解压后把.otf或.ttf文件复制到系统字体目录即可。Windows是C:\Windows\FontsmacOS是~/Library/FontsLinux是/usr/share/fonts复制完执行fc-cache -f刷新缓存。再比如android aarch64 jre17.zip这种包解压后要设置JAVA_HOME环境变量、把bin目录加进PATH才能用。每个zip后面的动作都不一样。GeoJSON数据zip也一样解压不是终点后面还有校验、坐标系整理、重新打包这一长串事情。2.3 分卷zip(z01)与多文件合并解压的方法有时候对方发来的是一个分卷压缩包文件名类似name.z01、name.z02再加一个name.zip。这种包在聊天工具传大文件时很常见。很多人只看到name.zip双击解压却提示缺少分卷。如果手头有全套分卷文件最简单的办法是把所有分卷放进同一个目录然后用7-Zip打开name.zip它会自动识别相邻的z01、z02直接解压。WinRAR也可以同样要保证分卷齐全再操作。总的原则是分卷文件一个都不能少且文件名前缀和后缀都不能改动序号改了也会失败。有时会遇到z01能打开、主zip打不开的情况那个主zip里装着中心目录和最后一部分数据。这种时候7-Zip有强制打开选项但能不能完整恢复就看运气了。2.4 zip密码、加密标志位和“移除密码”的真实边界热词里出现了“zip密码移除”“zip密码恢复”“超人zip解密助手”这类工具。我说点实在的zip加密分两种传统ZipCrypto和AES加密。ZipCrypto算法本身有弱点密码是纯小写字母加数字且长度较短时解密工具暴力破解速度非常快AES加密则基本只能靠穷举密码一长那已经不是“移除密码”能搞定的事了。还要提醒一个概念zip文件头里有个“全局方式位标记”general purpose bit flag第0位表示文件是否加密。网上某些“移除密码”工具原理就是篡改这个bit让解压软件跳过密码校验。这在ZipCrypto下对部分文件有效对AES加密文件完全无效而且强行改bit后可能解压出乱码文件。所谓“zip格式文件夹加密”本质也是压缩包内文件逐个加密并不会真的把一个文件夹加锁。正规做法是能想起密码最好想不起来短密码可以试解码字典长密码就真当它没救了。别下载来路不明的破解工具压缩算法本身没有后门的前提下密码学上没有捷径。3. GeoJSON数据查看、校验与转换从“能打开”到“能直接用”3.1 GeoJSON用什么打开最方便“geojson怎么打开”是高频问题。如果只是想快速看一眼直接把文件拖进geojson.io网页端就能渲染地图和属性表。QGIS则更适合做专业校验和坐标系转换注意QGIS导入GeoJSON时会自动识别坐标参考如果文件里带了crs字段就按crs识别否则默认按WGS-84处理。这个特性也解释了为什么坐标系不对的数据在QGIS里一显示就偏移。开发者可以考虑VS Code加GeoJSON扩展边看边改如果只是想让同事在浏览器里看效果在线工具拖进去就能出地图。但“能打开”和“能用”之间差距很大。你打开看到一条线不代表这条线的坐标在合理范围内。我曾经遇到过一份GeoJSON加载后地图上什么都没有把坐标打出来发现全是NaN。这种数据在浏览器端渲染时直接报错在QGIS里则显示成空图层。所以下一步必须做校验。3.2 批量校验几何类型、坐标范围、属性字段一个都不能少GeoJSON有严格的规范。校验时我关注四件事。第一JSON结构是否合法。用Python的json模块或者jq直接解析报错就说明文件损坏或根本不是GeoJSON。第二每个Feature必须要有geometry和properties字段。geometry.type必须是Point、MultiPoint、LineString、MultiLineString、Polygon、MultiPolygon这几种之一如果出现GeometryCollection很多下游工具不支持要提前拆开处理。第三坐标范围是否合理。还是以东莞为例经纬度应该在北纬22.8到23.4、东经113.5到114.2附近。如果你看到coordinates里的数是(500, 400)这种量级就很可能是投影坐标没经过转换就写进了GeoJSON。这种数据在WGS-84下会被渲染到非洲西海岸附近特别诡异。第四属性字段类型是否一致。同一个字段有些要素是字符串有些是数字后续做图层样式或空间查询时会出现各种奇怪问题。我习惯用Python脚本做批量校验核心逻辑就几十行遍历Feature逐个检查输出一份JSON报告。下面是一个很精简的Python校验脚本能覆盖上面大部分问题import json import sys VALID_TYPES { Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, GeometryCollection } def check_geometry(geom, errors, pathroot): if geom is None: errors.append(f{path}: geometry is null) return if geom.get(type) not in VALID_TYPES: errors.append(f{path}: invalid type {geom.get(type)}) coords geom.get(coordinates) if geom[type] Polygon: if not coords or not all(isinstance(r[0], (int, float)) for r in coords[0]): errors.append(f{path}: invalid coordinate type) def main(path): with open(path, encodingutf-8) as f: data json.load(f) errors [] if data.get(type) ! FeatureCollection: errors.append(root type is not FeatureCollection) for i, feature in enumerate(data.get(features, [])): check_geometry(feature.get(geometry), errors, ffeature[{i}].geometry) if errors: print(\n.join(errors[:20])) sys.exit(1) print(OK) if __name__ __main__: main(sys.argv[1])实际使用中我还会加坐标范围检查、字段类型一致性检查。跑完之后如果报大量错误那就不是单个文件的问题很可能是转换导出环节出了bug得回到源头去查。3.3 转换成GeoJSON路网数据可行吗UE线段标注怎么接“转换为geojson路网数据可行么”这个问题在游戏和数字孪生项目里特别常见。答案是完全可行但中间有不少坑。路网数据转换的思路有两种。一种是从OSM这类开放数据源导出道路数据OSM原始格式是XML通过osm2geojson或QGIS转换就能得到GeoJSON。另一种是把CAD图纸、shapefile里的道路中线转成GeoJSON。这里核心点在于路网数据要求的是LineString或MultiLineString而很多矢量源里道路是Polygon道路面必须先提取中心线而不是简单改类型。至于UE线段标注我理解的是在Unreal Engine里用Spline组件做道路标注或规划线路。常见做法是把GeoJSON解析成坐标序列再在UE里用Spline或SplineMesh逐段生成。如果只是做可视化几千个点的路网直接生成Spline问题不大但要做物理碰撞或车辆寻路数据量大了必须做抽稀和拓扑整理不然性能会崩。还要注意UE默认单位是厘米GeoJSON里是经纬度导入时必须做坐标映射否则道路会跑到场景原点附近缩成一个点。3.4 从Shapefile、Excel、数据库导出GeoJSON的转换实操很多时候手头不是GeoJSON而是需要转换成GeoJSON。最实用的工具还是QGIS加载数据右键图层导出保存要素为格式选GeoJSON坐标系选WGS-84。这个操作背后有个关键点QGIS导出时会把属性表里的中文字段名做处理但字段名里带空格或点号时Turf.js等库解析起来很容易出问题导出前最好先改字段名。如果是从Excel导出经纬度生成点数据可以用Python的geopandasread_excel之后转GeoDataFrame再to_file成GeoJSON。Excel数据的坑主要在经纬度列搞反、缺失值没处理、度分秒格式没转成十进制度。这些在数据量小的时候肉眼看不出来但一做成地图点位全部跑到海里甚至非洲就慌了。所以无论用哪种方式转换最后我都会再跑一遍3.2节的校验脚本把坐标范围检查加上。4. 实操过程中的经典报错与排查实录4.1 “file is not a zip file”的完整排查思路这个报错通常出现在你试图用unzip或编程语言的zip库打开文件时但文件头不是PK开头。常见原因有四类。第一类是文件传输过程中被截断或损坏尤其是聊天工具传文件微信、QQ常有文件被改名或加后缀的情况。收到压缩包后我习惯先执行file 文件名.zip如果输出是Zip archive data说明文件头正常如果输出是HTML document、gzip compressed data甚至data那基本可以判定这个文件根本不是zip。第二类是文件后缀被改了。比如对方发来的是.tar.gz但名字叫xxx.zip或者反过来。用unzip解压就会报not a zip file。我见过有人从网上下载“GeoJSON数据资源包”点下去实际是个HTML跳转页用file命令一看就清楚了。第三类是下载不完整。curl或wget下载中断但工具没报错最常见于网络不稳定。判定的方法是比较Content-Length和本地文件大小或者直接unzip -t测试。第四类是文件名编码问题比较隐蔽文件确实是zip但工具因为文件名乱码找不到正确条目。总之遇到所有zip相关报错都建议先跑file命令判断真实格式再决定下一步处理方向。4.2 “could not find EOCD”和“invalid zip archive”是怎么回事导入资源包失败报错invalid zip archive: could not find EOCD这在UE、Maven、Java程序里都很常见。EOCD全称是End Of Central Directory recordzip格式要求在文件末尾有一个中心目录结束记录。解压工具打开zip文件时会先跳到文件末尾找这个标记。如果文件不完整比如传输被截断末尾那段被切掉了就会报could not find EOCD。修复思路分三步。第一步重新下载或找对方重新传输这是最靠谱的办法。第二步如果文件实在只有一份用zip -FF 损坏的.zip --out 修复的.zip尝试修复。zip -FF会扫描文件中的本地文件头来重建中心目录能救回多少算多少修复完记得用unzip -t再测一遍。第三步如果原始文件是分卷压缩缺少最后一个分卷也会报EOCD找不到这种情况要把分卷找齐再解压。在UE里导入资源包失败也同理先确认zip本身没坏再去查UE的资源包规范。顺便说一下Java和IDE环境下还有个类似的报错error opening zip file or jar manifest missing。Jar文件本质上也是zip如果jar本身不完整启动服务时就会报这个。很多人把精力放在找manifest文件上其实优先检查jar文件是否完整、路径里是否有中文或空格尤其是Windows上从聊天工具下载的jar经常被改动。4.3 “锟斤拷”乱码和路径问题的根源热词里有个经典场景d:\tools\idea锟斤拷锟斤拷\。一看就是中文路径在终端或IDE里显示乱码。锟斤拷是GBK编码被当成UTF-8解码时产生的替换字符本质是编码不一致。zip文件名乱码也是类似问题zip格式标准里文件名用CP437编码但国内很多工具写文件名时用GBKLinux和macOS的unzip默认按UTF-8解释结果就是中文文件名全部变成乱码。解决办法有三个层次。第一打包时就用UTF-8Linux下用zip -UNUTF8Windows下用7-Zip的“使用UTF-8文件名”选项。第二解压时用兼容工具Windows上优先用Bandizip、7-Zip它们在解压时会尝试GBK和UTF-8两种编码Linux下可以装unarThe Unarchiver的命令行版替代unzip。第三如果已经解压出乱码文件名用convmv或Python脚本批量改名。从源头解决最省心我建议所有要发给别人的zip统一用7-Zip以UTF-8文件名打包。4.4 “failed to copy spatial iop zip”这类软件导入失败的通用排查法热词里有一条failed to copy spatial iop zip后面还跟着“与技术支持部联系”。这种报错看名字像是某个GIS或遥感软件在导入zip时复制临时文件失败。虽然具体软件我不能确定但这类“导入zip失败”的排查逻辑是通用的。第一步先把zip解压到本地如果解压本身就报错说明文件已损坏和软件无关。第二步把文件放到纯英文路径下重试中文路径和空格经常导致底层复制函数失败。第三步看压缩方式。有些老旧软件只支持传统ZIP格式不支持LZMA压缩或分卷zip如果你用7-Zip压缩时选了LZMA导入就会失败改成传统Deflate或“存储”方式重新打包。第四步看权限和杀毒软件。压缩包里有exe或脚本时部分安全软件会在临时目录拦截复制尝试关掉实时防护或把文件加入白名单。这四步下来九成导入失败都能解决。剩下的才是真需要技术支持部门介入的但你把前三步的结果告诉他们他们也能更快定位问题。4.5 报错速查表我把常见问题整理成一张表方便对照症状大概率原因优先尝试unzip提示not a zip file文件不是zip或后缀错误file命令确认真实格式could not find EOCD文件截断/分卷缺失重新下载或用zip -FF修复解压后文件名乱码zip文件名编码不是UTF-8用7-Zip或Bandizip解压jar manifest missingjar文件不完整或路径乱码检查jar完整性、换纯英文路径GeoJSON加载后偏移坐标系不统一QGIS重投影到WGS-84GeoJSON浏览空白坐标缺失或NaN跑Python校验脚本导入软件失败压缩方式兼容性问题改用Deflate存储重新打包这张表是我踩过无数坑之后沉淀出来的每次遇到新数据包都会先对照一遍能省很多时间。5. 数据整理完到最后打包交付一份检查清单5.1 统一坐标系、字段和命名数据整理到这一步最核心的动作就是把所有文件统一标准。坐标系统一到WGS-84还是GCJ-02取决于最终使用场景Web地图在国内用高德底图就统一到GCJ-02做国际项目或离线应用用WGS-84。这个决策要在项目开始时定下来中途改坐标系会牵扯所有图层改一次就重新对一遍边界非常耗时间。字段同样要统一。以行政区划数据为例建议至少保留adcode行政区代码、name、area字段其余冗余字段可以删掉。字段名统一用小写字母加下划线避免中文、空格、点号不然在大多数GIS库和前端工具里都会遇到麻烦。文件命名也值得花两分钟统一用拼音或英文包含区域和时间比如dongguan_town_boundary_2024.geojson。不要出现带空格、括号、中文、特殊字符的文件名。在命令行和服务器上处理这种文件时转义和编码问题会让你怀疑人生。我拿到的数据包里经常有类似“【课堂作业】.zip”“新地铁—强锁...枪(3).zip”这种名字明明数据是好的光文件名就够折腾半天。5.2 哪怕只写三行README强烈建议在数据包内放一个README.md。就写三行数据来源哪个网站、哪年数据、谁处理的、坐标系说明WGS-84还是GCJ-02、属性字段说明每个字段是什么意思。这三行字看起来无关紧要但能解决未来三个月的扯皮问题。我吃过亏辛辛苦苦整理的数据随手发给同事三个月后对方问“这个数据坐标系是什么来着”我完全不记得了。有README至少有个交代。README还有另一个作用把自己的处理过程记录下来。你用了什么工具转换、做了什么清洗、改了哪些字段这些操作细节是最容易被遗忘的本文还有配套的精品资源点击获取