1. 为什么我劝你学会在线制作 GeoJSON 文件手头有一批坐标点想做成地图可视化结果卡在第一步——数据格式不对。这种场景我遇到过太多次了。无论是做区域配送范围划分、门店选址热力图还是给前端同事准备一张能直接渲染的行政区划底图GeoJSON 都是绕不开的中间格式。它本质上就是一个遵循特定结构的 JSON 文本用经纬度把点、线、面这些几何对象描述出来同时允许你往 properties 里塞任意业务属性。浏览器认识它主流地图引擎认识它各种开源可视化库也认识它这种通用性是它最大的价值。所谓“在线制作 GeoJSON”指的是不装桌面 GIS 软件、不写后端脚本直接在浏览器里完成坐标拾取、几何绘制、属性编辑、格式校验和文件导出这一整套流程。它解决的问题很具体临时要一份边界数据或者要把一堆散乱的经纬度整理成规范文件没必要为这个去啃一套重型工具的安装和授权。适合看这篇内容的人大致是三类——做前端可视化但对地理数据不熟的同学、需要快速出原型图的运营和产品、以及偶尔要处理空间数据的开发人员。我先说一个容易踩的坑很多人以为 GeoJSON 就是“带经纬度的 JSON”随手写个{lat: 31.2, lng: 121.4}就去调用地图接口结果自然是坐标错乱或者直接不渲染。问题出在坐标系和结构上。GeoJSON 规范里坐标顺序固定是[经度, 纬度]也就是常说的[lng, lat]跟日常口语里“纬度多少、经度多少”的顺序正好相反。这一点我在第一次做地图标注时就栽过点位整体偏移到了另一个半球排查了半小时才发现是自己把顺序写反了。下面的内容我会把在线制作这套流程拆开从结构认知、工具思路、实操步骤一直讲到排错技巧尽量让你少走弯路。2. GeoJSON 到底长什么样结构拆解与核心概念2.1 三种基础几何类型与它们的用途在动手做文件之前得先搞清楚 GeoJSON 支持哪些几何类型这决定了你的数据最终能表达什么。最常用的三种是 Point、LineString、Polygon分别对应点、线、面。Point 就是一个坐标对适合标注门店、设备、事故点这类独立位置。它的 coordinates 字段直接放一个数组比如[116.397, 39.908]。LineString 是一串有序坐标用来表示路线、管道、河流这类线性要素coordinates 是一个嵌套数组外层是点序列。Polygon 用来表示封闭区域比如行政区划、配送片区、电子围栏它的 coordinates 外面还要再包一层因为一个面可以带多个环——第一个环是外边界后面的环是挖洞。这里有个细节值得单独说多边形的首尾坐标必须相同否则闭合失败很多引擎直接不渲染。我早期手写过一个矩形四个点写完了以为就闭合了结果边界线看起来是断开的补上第一个点作为第五个点之后才正常。这是纯文本编写时最容易忽略的一点在线工具里通常会自动帮你闭合但你要是手动改数据就得盯紧。还有 MultiPoint、MultiLineString、MultiPolygon 这些复合类型用于一个要素包含多个离散几何体的情况比如一个连锁品牌在同城有多个门店点。新手阶段不用急着全用上先从 Point 和 Polygon 练手理解清楚结构再说。2.2 Feature、FeatureCollection 和 properties 的组织逻辑单独的几何对象只是形状真正让数据有业务意义的是外面包的 Feature。一个 Feature 由 geometry 和 properties 两部分组成geometry 放形状properties 放属性。properties 是个自由对象你可以往里塞名称、编号、类别、颜色、权重任何后续渲染或交互要用到的字段都放这里。多个 Feature 按顺序组合起来就是一个 FeatureCollection它的 type 是FeatureCollectionfeatures 字段是个数组。实际业务里我们导出的文件百分之九十五以上都是 FeatureCollection因为地图渲染通常是批量给要素而不是一个个传。我把一个最简可用的 FeatureCollection 骨架贴出来你可以对着记结构{ type: FeatureCollection, features: [ { type: Feature, properties: { name: 示例门店, category: retail }, geometry: { type: Point, coordinates: [116.397, 39.908] } } ] }注意properties 里不要放坐标信息坐标只属于 geometry。我见过有人在 properties 里也写一份 lat、lng结果两处数据不一致排查起来非常费劲。2.3 坐标系选择的现实考量这是绕不过去的一环。GeoJSON 规范建议使用 WGS84 坐标系也就是 GPS 原始坐标。但国内很多地图底图使用的加密坐标系跟 WGS84 之间有几个街区的偏差。这意味着如果你的数据来源和底图来源不一致叠加出来的位置可能是错的。在线制作时的通用做法是先确认底图用的是什么坐标系再决定要不要做转换。如果你在某个在线工具的底图上绘制工具通常会按底图坐标系输出问题不大。但如果是把外部数据导进来就要留个心眼先在底图上点几个已知位置比对一下偏差明显就要走转换流程。这个步骤不要跳我吃过亏——一批门店数据看着都对叠到底图上整体往东偏了将近一公里最后发现是来源坐标和底图坐标系不匹配。3. 在线制作工具的选型思路与关键评估维度3.1 免费在线工具和桌面软件的取舍很多人一上来就问用什么软件打开 GeoJSON其实这个问题要分场景回答。如果只是看一眼数据长什么样浏览器里搜一个在线查看器就够了拖进去就能出图。如果要编辑那就要区分是轻量调整还是重度加工。轻量调整比如改几个属性、挪几个点、删几条要素在线工具的体验通常比桌面软件更快省去了安装和启动的时间。重度加工比如复杂的空间运算、批量拓扑检查、大规模数据裁剪还是得靠桌面 GIS 工具。我的习惯是数据量在一万条要素以内、操作以绘制和属性编辑为主就用在线工具搞定超过这个量级或者涉及空间分析就把数据导到桌面工具里处理两者配合着用。在线工具还有个隐性优势——协作方便。你把链接或者导出文件发给同事对方不用装任何东西就能打开看这在跨部门沟通时特别省事。而桌面软件的项目文件换个环境可能就打不开了。3.2 判断一个在线工具好不好用的三个标准我用过不少在线 GeoJSON 工具能用和好用差别很大。总结下来评估维度主要是三条。第一条是坐标拾取精度和底图质量。好的工具应该支持缩放到底图建筑级别鼠标移动时实时显示当前经纬度点击即可落点。底图清晰度不够的话你在郊区或者新区根本对不准位置画出来的面惨不忍睹。第二条是属性表编辑能力。理想的工具应该允许你添加自定义字段、批量修改属性、按字段排序筛选。如果只能改改几何形状属性全靠手动改 JSON那效率会非常低。我处理过一批两百多家门店的标注工具支持表格编辑的话十分钟能做完的事纯手改 JSON 要两个小时。第三条是导出的规范性和校验提示。靠谱的工具在导出前会检查几何是否闭合、坐标是否合法、结构是否完整有问题会给出明确提示而不是导出一个坏文件让你到下游去发现错误。这一点能帮你省下大量返工时间。3.3 结合具体搜索需求的工具使用路径网上关于“geojson用什么软件打开”和“阿里geojson”的搜索热度一直不低背后其实是两类真实需求。前者的典型场景是同事发来一个 .geojson 文件你想快速看看内容又不想装软件。这种情况直接找在线查看器把文件拖进去地图和属性表一般都能同时看到。后者的场景则偏向于获取现成的行政区划边界数据比如某些数据平台会提供按行政区划代码组织好的 GeoJSON 边界文件你拿到之后需要做裁剪、合并或者属性补全。对这两类需求我的建议路径是一致的先用在线查看器确认数据内容和坐标系再进在线编辑器做需要的修改最后导出并做一次校验。不要拿到文件就直接用先看一眼它的坐标范围和几何类型心里有个数。我见过有人拿到的边界文件其实包含了整片区域只想要其中一小块结果直接叠上去发现范围大得离谱白忙活一场。4. 从零到一在线制作完整实操流程4.1 绘制前的准备工作与底图对齐正式开始画之前准备工作有三件。第一件是明确你要产出什么几何类型是标点、画线还是圈面这决定你接下来的操作路径。第二件是确定坐标系跟使用方对齐清楚。第三件是准备好业务属性字段的清单比如名称、编号、类型、权属先在脑子里或者纸上列出来画的时候顺手就填了比事后补要高效得多。底图对齐这一步很关键。打开在线工具后先缩放到你的目标区域找到几个明显的参照物比如路口、地标建筑对照实际位置校准一下视觉。如果工具支持切换底图图层可以切到卫星图对照判断缩放级别是否够用。我一般会先找一个肯定知道的点点一下看工具给出的坐标跟预期是否接近偏差在合理范围内再开始正式绘制。这一步花两分钟能避免后面整批数据一起偏。4.2 点要素的拾取与批量属性录入画点最简单缩放到目标位置在正确的位置点击一下要素就生成了。这里有个精度技巧尽量放大到能看清建筑轮廓的级别再点别在缩得很小的视图上随手点那样误差可能有几十米。批量标点时我习惯的做法是先把所有点快速点完然后再统一到属性表里补字段。原因是绘制和录入是两种不同的注意力模式混在一起做容易出错。点完一层之后在属性表里新增字段比如 name、code、type然后一行一行填。如果字段值有大量重复比如所有点都属于同一个片区用批量填充功能一次性搞定别一个个改。提示在属性表里录入中文时确认工具的文件编码是 UTF-8避免导出后出现乱码。这个坑不常见但一旦踩到很难受有些老工具默认编码不是 UTF-8。还有一个实用技巧如果点是从已有表格里来的很多在线工具支持粘贴带坐标的表格数据直接生成点图层比起一个个手点这种方式在有现成数据时快得多。粘贴前确认列的顺序是经度在前还是在后跟工具的输入要求对齐。4.3 多边形绘制的顺时针规则与闭合处理画多边形比画点复杂有几个规则必须遵守。首先是顶点顺序GeoJSON 规范建议外环按逆时针方向、内环按顺时针方向虽然很多引擎对方向不敏感但严格遵守能避免部分工具渲染异常。在线工具一般会自动处理方向你只需要关注点的位置是否准确。绘制时沿着边界逐个顶点点击最后回到起点双击或者点击第一个点完成闭合。我强烈建议放大到足够级别再画尤其是边界曲折的地方多打几个顶点让线条贴合实际。但也不要过度加密顶点太密会导致文件体积膨胀而且后续编辑很痛苦。一个经验值是直线段中间不要加点转折处必须有顶点曲线地段根据曲率适度加密。如果需要挖洞比如一个配送区域中间有个公园不送就先画外环再画内环工具通常会有单独的挖洞模式。挖洞环的顶点顺序跟规范要求相反在线工具里一般不用你手动操心。几何类型坐标嵌套层级常见用途易错点Point单层数组门店、设备标注经纬度顺序写反LineString两层数组路线、管道顶点顺序混乱Polygon三层数组片区、围栏忘记闭合MultiPolygon四层数组多片区合并环顺序错误4.4 属性字段的规范化命名与数据类型字段命名看着是小事其实很影响后续使用。我给自己定的几条规矩字段名统一用英文小写多个单词用下划线连接比如 store_name、area_code避免用中文做字段名虽然 JSON 支持但跨系统传递时容易出问题同一批数据里字段类型保持一致编号是字符串就全都是字符串别一会儿数字一会儿字符串。数据类型这块有个隐蔽的坑。GeoJSON 本身对 properties 的值类型没有强约束但下游读取时往往有预期。比如你的编号是001如果被当成数字处理前导零就丢了变成 1。所以编号、电话、邮编这类字段务必用字符串类型并加引号。这个细节我在对接第三方系统时被坑过对方的 ID 明明是数字我这边存成数字结果跟对方的字符串 ID 对不上联调了半天。4.5 导出前的校验清单与文件优化导出前过一遍校验清单能挡掉大部分低级错误。我自己的清单是这样的坐标系是否与使用方一致所有多边形是否闭合首尾坐标相同经纬度顺序是否正确经度在前properties 里是否有空值或类型混乱的字段文件是否包含多余的临时要素属性字段命名是否规范文件优化方面如果数据量很大可以考虑精简属性字段只保留必要的去掉冗余的展示性字段这样能显著减小体积。另外坐标精度也没必要保留太多位小数一般保留到小数点后六位已经足够大约十厘米级精度再多的位数只是徒增体积。我处理过一个文件坐标保留了十几位小数精简到六位之后体积小了一大半渲染速度也明显提升。5. 常见问题排查与避坑经验实录5.1 打开后一片空白或不显示的排查思路这是最高频的问题。文件导入后地图上什么都没有通常有几个原因按概率排序。第一坐标系不匹配。数据本身没问题但它的坐标范围跟当前底图不在一个位置可能落到地球另一端。排查方法很简单看数据的坐标数值范围正常的经纬度经度在 -180 到 180、纬度在 -90 到 90 之间。如果数值是几十万甚至上百万那八成是投影坐标没转成经纬度。第二几何结构错误。多边形没闭合、coordinates 层级不对、少了 type 字段都会导致引擎无法解析。这种情况工具的开发者控制台通常会有报错打开控制台看错误信息能快速定位。第三坐标顺序写反。经度纬度颠倒后数据很可能落在南极或者太平洋某个角落视觉上就是空的。把第一个要素的 coordinates 拿出来看一眼跟预期位置比对。第四样式问题。数据其实渲染了但颜色跟底图接近或者透明度太低看不见。这种情况排查方法是在工具里切换成纯色高对比样式或者缩小视图看是否有异常轮廓。5.2 坐标偏移与坐标系不匹配的处理坐标偏移比空白更隐蔽因为数据看得见但位置是错的。典型表现是整体规律性地偏移一段距离。遇到这种情况先确认数据来源和底图的坐标系。如果确实不匹配就需要做坐标转换把数据从一个坐标系转到另一个。在线工具里有的支持在线转换有的需要先导出再处理。判断是否偏移的方法找一个你百分百确定的点比如自己的办公位置或者明显的地标看它在图上的位置对不对。对了就说明坐标系没问题错了再看偏移量有多大规律性偏移基本就是坐标系差异。5.3 文件体积过大导致的加载卡顿数据量上来之后卡顿是必然的。优化方向有几个。一是精简坐标精度前面说过保留六位足够。二是合并相邻的几何要素减少 Feature 数量。三是删除冗余属性字段。四是如果只是展示考虑做要素简化在不影响视觉效果的前提下减少顶点数。还有一个容易被忽视的点有些在线工具在绘制时会把每个顶点的信息都塞进 properties导致文件急剧膨胀。导出前检查一下 properties把工具生成的临时字段删掉只留业务字段。5.4 常见问题速查表现象可能原因排查动作空白不显示坐标系不匹配检查坐标数值范围空白不显示几何未闭合检查多边形首尾点位置偏移坐标系差异用地标点比对偏移量位置颠倒经纬度顺序反核对 coordinates 顺序加载卡顿体积过大精简精度与字段中文乱码编码问题确认导出 UTF-8编号丢零类型当数字编号改字符串存储5.5 一些只有踩过才知道的实操心得说几条我在实际项目里攒下的经验文档里一般不会写。绘制大批量要素时养成阶段性导出的习惯。在线工具遇到网络波动或者页面刷新未保存的内容可能就没了。我习惯每完成一个批次就导出一次虽然麻烦但比丢了重画强得多。属性字段能少则少但关键的标识字段一定要留。缺少唯一标识的要素集合后续做数据更新、去重、合并时会非常痛苦因为没办法精确匹配到具体是哪个要素。拿到别人给的 GeoJSON先别急着用用在线查看器打开看一眼属性表和坐标范围。这一步能帮你发现很多问题比如数据范围比预期大、属性字段名对不上、坐标系不一致。我现在的习惯是任何外部数据进来第一件事就是打开看确认无误再进后续流程。最后分享一个小技巧如果你需要经常做同一类区域的 GeoJSON可以先把一个标准模板做出来包括固定的属性字段结构和命名规范之后每次制作都从这个模板起步只改坐标和值。这样能保证同项目内所有文件的结构一致性下游处理时省心很多。这套做法我一直在用尤其是在多人协作的项目里统一模板比口头约定规范靠谱得多。