简介面向GIS开发、地图可视化、城市规划与空间分析人员该数据提供成都市高新区南区、高新西区、高新东区及天府新区等区域的GeoJSON边界反映较新的区域划分可用于高德地图等平台的图层叠加、区域展示和空间查询解决行政区划底图与专题制图的数据来源问题。压缩包共2个文件以1个json地理数据为核心另含1个zip归档整体约1.6MB体量轻便便于解析后接入地图应用或分析流程。已有948人学习下载说明其在成都区域地图数据使用中具有一定参考价值。文件以GeoJSON几何对象和属性字段组织区域边界可支撑地图渲染、区域裁剪、空间查询与统计汇总并服务于城市规划、交通研究、商业选址、灾害应急和区域对比等场景方便读者快速建立可复用的成都分区数据底图也为二次开发和专题分析提供便利。1. 一份 1.8 MB 的成都市 GeoJSON 边界数据足以把整张图跑偏上个月帮一个做本地生活选址的朋友排查图表问题他把成都市 GeoJSON 边界数据加载进前端后高新区南区那几个街道的落点全部压到了一条河对岸天府新区的点位更是有一半飘到了边界外面。排查后发现数据本身没有问题问题出在他把在线地图返回的 GCJ-02 坐标直接扔进了 WGS-84 的底图里算归属。成都城区这种偏移量在 400 米上下视觉上就是“明明在该区却判给了隔壁”。这份 chengdu.json 边界数据重点不在“成都”两个字而在它把高新区南区、高新西区、高新东区空港新城方向和天府新区这几块非标准行政区的范围单独切了出来。做选址、网格化运营、配送分区、区域热力图的人真正卡住的地方几乎都不是“有没有数据”而是“功能区和行政区两套口径怎么对齐、坐标系怎么统一、重叠部分算谁的”。下面按我自己跑一遍的流程拆开讲。2. 拆开 chengdu.json三个层级看懂边界数据的组织方式2.1 从 FeatureCollection 到 MultiPolygon坐标环到底怎么存GeoJSON 的顶层是一个对象type为FeatureCollection真正的内容全在features数组里。每个 feature 由properties属性和geometry几何两部分组成几何类型在区县、街道这一级基本只有Polygon和MultiPolygon两种。区别在于一个区县如果存在飞地、被河流切开的孤岛、或者像高新区东区那种和主体不相连的片区就必须用MultiPolygon因为单个Polygon只能表达一个连通的外环。先用最朴素的方式把文件结构打出来别急着上 GIS 库import json from collections import Counter with open(chengdu.json, encodingutf-8) as f: data json.load(f) # 顶层必须是 FeatureCollection否则前端 registerMap 会直接白屏 print(top-level type:, data.get(type)) print(feature count:, len(data.get(features, []))) # 统计几何类型分布MultiPolygon 的多少决定了后面处理逻辑的复杂度 types Counter() for feat in data[features]: geom feat.get(geometry) or {} types[geom.get(type)] 1 print(geometry types:, dict(types)) # 抽查前三个要素的属性和坐标点数 for feat in data[features][:3]: prop feat.get(properties, {}) geom feat.get(geometry) or {} coords geom.get(coordinates, []) # Polygon: [ring, hole...]MultiPolygon: [[ring, hole...], ...] n_poly len(coords) if geom.get(type) MultiPolygon else 1 n_ring len(coords[0]) if coords else 0 print(prop.get(name), prop.get(adcode), geom.get(type), n_poly, n_ring)这段代码有三个作用确认顶层类型、确认几何类型分布、确认每条要素的环数。n_poly大于 1 就说明这个区有飞地后面做点在多边形判断时不能只取第一个多边形否则外围片区会全部判成“不在区内”。n_ring是第一个多边形的环数正常一个外环加若干内环湖泊、挖空区域如果出现n_ring 0那这条要素就是空的渲染时会被静默跳过图上看不出报错但就是少一块。属性字段这块不同来源导出的命名差异很大常见的有下面几种写法读取时建议做一次归一化常见字段名含义缺失后的影响name/NAME/district区县或片区名ECharts 无法按名称映射图例全空adcode/code/id行政区划代码无法和统计表做 joinlevel/type层级市/区/街道混合层级数据容易重复渲染center/centroid中心点标签位置需要自己算否则标签挤在质心外parent/city上级归属无法做下钻联动我一般会在读取后立刻做一次字段归一化把name、adcode、level三个关键字段统一成固定名字后面的代码只认这三个能省掉大量“为什么这个区的名字是空的”的排查时间。还有一个容易被忽略的细节RFC 7946 规定外环逆时针、内环顺时针但国内大量从 GIS 工具导出的数据并不遵守这个约定。shapely 在大多数操作里能容忍环方向问题可一旦你把数据丢给三维渲染或者某些地图 SDK 的填充算法方向反了就会出现“该填色的区域变成镂空”的现象。后面 3.2 会讲怎么统一修掉。2.2 高新区三个片区与天府新区功能区和行政区是两套口径这份数据最有价值、也最容易出问题的部分就在这里。高新区不是一级行政区它是挂在武侯区、郫都区、双流区、简阳市等几个区市之上的功能区天府新区更特殊它的规划范围横跨成都和眉山两地其中成都直管区的边界和任何单个行政区都对不上。也就是说这份 chengdu.json 里的要素并不是一棵树而是两张互相交叉的网。具体到片区高新区南部园区主要覆盖桂溪、肖家河、石羊、芳草街一带是老建成区的核心边界和武侯区、双流区高度咬合。高新区西部园区落在郫都区、金牛区交界方向形状偏狭长和周边区县的边界有多处锯齿状交错。高新区东部园区也就是空港新城方向和主城完全不接壤属于典型的飞地型片区。天府新区成都直管区面积在公开资料里常见的口径是五百多平方公里但它的边界是一条规划边界不是民政边界所以和双流、龙泉驿、新津的接壤段会出现“同一条路两侧分属不同片区”的情况。这带来一个直接后果如果你把功能区要素和区县要素放在同一张图上按面积统计重叠部分会被计两次。成都市域总面积公开口径一万四千多平方公里把各要素面积直接相加却可能得到一万六千以上差的这部分就是重叠。正确做法是先做一次空间差集把功能区从行政区里抠出来或者反过来只保留功能区的净面积。from shapely.geometry import shape from shapely.ops import unary_union # 假设已经从 features 里按 name 取出了对应几何 admin unary_union([shape(f[geometry]) for f in admin_feats]) func unary_union([shape(f[geometry]) for f in func_feats]) overlap admin.intersection(func) # 两层口径的重叠部分 admin_net admin.difference(func) # 行政区扣除功能区后的净范围 func_net func.difference(admin) # 功能区中不属于任何行政区的部分通常很小 print(overlap area(deg^2):, overlap.area) # 注意这是度平方仅用于相对比较unary_union会把同类要素先合并成一个整体避免逐对求交带来的碎片化。这里打印的面积单位是度平方只能用来做相对比较真实面积必须投影后计算3.3 会给出投影参数。另外difference在大多边形上比较慢成都全市要素跑一次大概几秒到十几秒建议结果落盘缓存不要每次请求都算。选型上我倾向于保留两份数据一份是原始的功能区 行政区全集用于渲染和展示另一份是裁剪后的净范围只用于统计口径。两份额度分开别想着用一份数据同时满足展示和统计那样只会两头不讨好。2.3 坐标系先对上GCJ-02 与 WGS-84 在成都的偏移量级搜 chengdu.json 的人十有八九是从在线地图的开放平台拿过边界或者准备把在线地图返回的 POI 坐标往上套。国内在线地图对外输出的经纬度是经过非线性加偏的 GCJ-02 坐标系而 GeoJSON 规范默认、绝大多数开源底图和卫星影像用的是 WGS-84。这两个坐标系在成都城区的偏移量大约在经度 0.004 度、纬度 0.002 度这个量级换算成地面距离是 300 到 500 米且方向不固定随经纬度变化。判断手里这份数据属于哪一套最省事的办法是拿一个已知点位做反查找一个确定落在某个区内部、远离边界的位置用它去跑点在多边形看结果对不对。如果所有点都稳定地偏向同一个方向基本就是坐标系不一致。from shapely.geometry import shape, Point # 两个候选点分别按 WGS-84 和加偏后的坐标测试 candidates [(104.066, 30.573), (104.062, 30.575)] polys [(f[properties][name], shape(f[geometry])) for f in data[features]] for lng, lat in candidates: hit [name for name, poly in polys if poly.contains(Point(lng, lat))] print(f({lng}, {lat}) - {hit})这段代码的逻辑很直白拿同一个物理位置的两套坐标分别去命中多边形哪一套命中了预期片区数据就是哪一套坐标系。参数上要注意两点一是候选点必须离边界足够远至少 1 公里以上否则偏移量会直接把点推到隔壁二是contains和covers在边界上的行为不同边界点建议用covers避免浮点误差导致漏判。确定坐标系之后统一策略只有一条全链路只保留一种坐标。我的习惯是存储层用 WGS-84因为它是无偏的、可逆的、和大部分开源工具链兼容只在与在线地图交互的那一层做一次转换。反过来的做法——存储用 GCJ-02、需要时再转回去——会导致每次转换都产生微小误差来回几次之后点位就漂了。3. 用 Python 给边界做体检加载、校验、算面积3.1 一次遍历把所有结构问题全部暴露出来拿到一份外部来源的 GeoJSON不要直接扔进渲染先跑一遍体检。体检要覆盖四件事几何是否有效、环是否闭合、坐标是否落在合理范围内、属性是否完整。import json from shapely.geometry import shape from shapely.validation import explain_validity with open(chengdu.json, encodingutf-8) as f: data json.load(f) issues [] for feat in data[features]: name (feat.get(properties) or {}).get(name, no-name) geom feat.get(geometry) if not geom: issues.append((name, geometry 为空)) continue # 1) 几何有效性自相交、环重复点、零面积都会在这里暴露 g shape(geom) if not g.is_valid: issues.append((name, invalid: explain_validity(g))) # 2) 坐标范围粗筛成都大致在 lng 102.5~104.9, lat 30.0~31.5 minx, miny, maxx, maxy g.bounds if not (102.0 minx 105.5 and 29.5 miny 32.0): issues.append((name, f坐标越界 bounds{g.bounds})) # 3) 属性完整性缺 name 的数据在前端基本不可用 if not (feat.get(properties) or {}).get(name): issues.append((name, 缺少 name 字段)) print(问题条目:, len(issues)) for it in issues[:20]: print(it)explain_validity返回的字符串会直接告诉你是Self-intersection还是Ring Self-intersection前者通常是两个环相互穿过后者是同一个环自己打了个结两种情况修复方式不同。bounds粗筛能抓出一类很隐蔽的问题数据里混进了用投影坐标米而不是经纬度存的要素这种要素在经纬度底图上会跑到几千公里外但 JSON 本身完全合法不体检根本发现不了。体检结果建议存成一份 JSON 报告跟着数据一起走谁改动了边界、改完有没有引入新的无效几何一眼就能看出来。这算是给后续维护留的后路。3.2 自相交与环方向shapely 的修复流程体检发现问题之后修复要按顺序来顺序错了会引入新问题。我的流程是先buffer(0)做快速修复再判断是否仍然无效最后才上make_valid。from shapely.geometry import shape, mapping from shapely.validation import make_valid def repair(geom): g shape(geom) if g.is_valid: return g, ok # 方案 Abuffer(0) 对自相交类问题通常有效且保持单几何类型 fixed g.buffer(0) if fixed.is_valid and not fixed.is_empty: return fixed, buffer(0) # 方案 Bmake_valid 可能返回 GeometryCollection需要挑出多边形 fixed make_valid(g) if fixed.geom_type GeometryCollection: polys [p for p in fixed.geoms if p.geom_type in (Polygon, MultiPolygon)] from shapely.ops import unary_union fixed unary_union(polys) return fixed, make_valid for feat in data[features]: g, how repair(feat[geometry]) if how ! ok: print(feat[properties].get(name), -, how, g.geom_type) feat[geometry] mapping(g)buffer(0)的作用是把自相交的环按奇偶规则重新切分代价是可能把一条细长的飞地整个吃掉所以修复后要对比面积变化掉超过 1% 就得人工看一眼。make_valid更保守但返回值可能是GeometryCollection里面除了多边形还混着线直接塞回 GeoJSON 会让前端解析失败必须过滤。这里用unary_union把拆散的多边形重新合并是因为make_valid有时会返回多个相邻碎块不合并的话一个区会被拆成好几块渲染。环方向的问题单独处理用带符号面积判断对环的坐标序列做鞋带公式结果为正说明逆时针为负说明顺时针。外环应该逆时针内环顺时针发现反了就list(reversed(coords))翻转一下。这一步不影响 shapely 的计算但会影响一部分渲染库的填充结果属于“不做也能跑做了少一类玄学问题”的操作。3.3 投影后算面积拿公开数据对一下经纬度直接算面积得到的是度平方毫无意义。必须投影到等面积或等距坐标系。成都经度范围大概在东经 102.5 到 104.9 之间落在 3 度带的第 34 带中央经线 102°和第 35 带中央经线 105°交界附近最省事的做法是用 CGCS2000 的 3 度带投影代码里直接引 EPSG 码。from pyproj import Transformer from shapely.ops import transform from shapely.geometry import shape # CGCS2000 / 3-degree Gauss-Kruger CM 105E to_metric Transformer.from_crs(EPSG:4326, EPSG:4545, always_xyTrue).transform total 0.0 for feat in data[features]: g transform(to_metric, shape(feat[geometry])) area_km2 g.area / 1e6 total area_km2 print(feature_name : feat[properties].get(name), round(area_km2, 2)) print(合计:, round(total, 2))always_xyTrue这个参数很关键不写的话 pyproj 在某些版本里会按lat, lon的顺序解析导致整个图形旋转 90 度跑到地球另一边这种错误特别不容易第一眼看出来。EPSG:4545是中央经线 105°E 的 3 度带对成都东部精度较好如果对西部山区要求更高可以按经度分带分别投影或者改用 UTM 48NEPSG:32648代价是东西跨度大的时候面积会有千分之几的畸变。算完拿公开口径对照一下单区面积偏差在 3% 以内属于正常因为公开数据本身精度有限、边界口径也有差异偏差超过 10% 基本可以断定是重叠没扣、或者数据里混进了非当前层级的要素。这一步是整份数据质量最直观的量化指标比看几何有效性有用得多。4. 坐标转换与归属判定把业务点位准确落进片区4.1 GCJ-02 与 WGS-84 互转的迭代实现正算WGS-84 → GCJ-02是解析式一遍就能出结果反算GCJ-02 → WGS-84没有解析解得用迭代逼近。网上流传的很多反算代码只做一次粗略反推精度差几十米做区域归属判断时刚好卡在边界上就会翻车。import math PI math.pi A 6378245.0 EE 0.00669342162296594323 # 克拉索夫斯基椭球偏心率平方 def _tlat(x, y): r -100.0 2.0*x 3.0*y 0.2*y*y 0.1*x*y 0.2*math.sqrt(abs(x)) r (20.0*math.sin(6.0*x*PI) 20.0*math.sin(2.0*x*PI)) * 2.0/3.0 r (20.0*math.sin(y*PI) 40.0*math.sin(y/3.0*PI)) * 2.0/3.0 r (160.0*math.sin(y/12.0*PI) 320*math.sin(y*PI/30.0)) * 2.0/3.0 return r def _tlng(x, y): r 300.0 x 2.0*y 0.1*x*x 0.1*x*y 0.1*math.sqrt(abs(x)) r (20.0*math.sin(6.0*x*PI) 20.0*math.sin(2.0*x*PI)) * 2.0/3.0 r (20.0*math.sin(x*PI) 40.0*math.sin(x/3.0*PI)) * 2.0/3.0 r (150.0*math.sin(x/12.0*PI) 300.0*math.sin(x/30.0*PI)) * 2.0/3.0 return r def wgs2gcj(lng, lat): dlat _tlat(lng - 105.0, lat - 35.0) dlng _tlng(lng - 105.0, lat - 35.0) rad lat / 180.0 * PI magic 1 - EE * math.sin(rad) ** 2 sq math.sqrt(magic) dlat (dlat * 180.0) / ((A * (1 - EE)) / (magic * sq) * PI) dlng (dlng * 180.0) / (A / sq * math.cos(rad) * PI) return lng dlng, lat dlat def gcj2wgs(lng, lat, tol1e-9, max_iter30): # 反向迭代每轮用正算结果与目标值做差修正输入 wlng, wlat lng, lat for _ in range(max_iter): glng, glat wgs2gcj(wlng, wlat) dlng, dlat glng - lng, glat - lat if abs(dlng) tol and abs(dlat) tol: break wlng - dlng wlat - dlat return wlng, wlat_tlat和_tlng是那套多项式加三角函数的扰动项参数是固定的不要改。gcj2wgs里tol设 1e-9 度约 0.1 毫米实际上过度了1e-7 度约 1 厘米就足够一般 3 到 5 轮就收敛。max_iter设 30 是为了兜底正常情况下根本用不到。这套实现只对中国范围有效经纬度落在境外时扰动项会失效所以转换前最好加个范围判断超出 73°E–135°E、3°N–54°N 的直接原样返回。实际使用中还有个坑批量转换时逐点调用math.sin开销不小十万级点位大概要几秒。如果只是做归属判断可以先把边界转换一次、点位保持原坐标系转换成本从 N 次降到 M 次M 是边界顶点数这个思路在处理大规模点位时很划算。4.2 STRtree 批量判点一万个点也别用双层 for 循环点在多边形判断写起来最简单的是双层循环慢起来也是真要命。假设 20 个片区、每个片区 2 万个顶点、你有 5 万个点位暴力算法要做 100 万次多边形包含判断单机跑十几分钟很正常。shapely 自带的空间索引STRtree能把这个数量级打到秒级。from shapely.geometry import shape, Point from shapely.strtree import STRtree import shapely geoms, names [], [] for feat in data[features]: geoms.append(shape(feat[geometry])) names.append(feat[properties].get(name)) tree STRtree(geoms) def locate(lng, lat): p Point(lng, lat) hits tree.query(p) # shapely 2.x 返回索引数组1.x 返回几何对象 for h in hits: idx h if isinstance(h, int) else geoms.index(h) if geoms[idx].covers(p): return names[idx] return None print(locate(104.066, 30.573))tree.query只做包围盒级别的粗筛返回的是“可能相交”的候选真正的精确判断还得靠covers两步合起来才是完整逻辑。covers比contains更适合边界判断因为落在边界线上的点contains会返回 False。这段代码里那个isinstance(h, int)的判断不是多余的shapely 1.8 和 2.0 的STRtree.query返回值类型不同前者返回几何对象、后者返回整数索引混用环境时如果不做兼容会直接抛AttributeError。建索引的时机也值得说一下。大于几百个多边形时建索引才有明显收益小数据量下建索引的开销反而更大。另外索引本身不能序列化持久化每次进程启动都得重建成都这个量级几十个要素重建耗时在毫秒级完全不用考虑缓存。4.3 重叠区域怎么裁决功能区和行政区的优先级规则真正难的不是判断点在哪而是点同时落在功能区边界和行政区边界里时该报哪一个。这不是技术问题是业务口径问题必须提前定死规则否则同一批点位每次跑出来的归属都可能不一样。我常用的优先级是功能区优先于行政区小范围优先于大范围显式配置优先于几何计算。高新区南区既是功能区、又横跨武侯和双流业务上通常只关心“是不是高新区”不关心它具体在哪个区所以功能区的判定放在第一层。天府新区同理。# 三层判定功能区 - 行政区 - 兜底 PRIORITY [高新区南部园区, 高新区西部园区, 高新区东部园区, 天府新区, 武侯区, 双流区, 郫都区] def resolve(lng, lat): p Point(lng, lat) for name in PRIORITY: g geom_by_name.get(name) if g is not None and g.covers(p): return name return 未归属用显式优先级列表而不是按面积排序好处是规则可读、可审计、改起来只动一行。缺点是新片区加进来必须同步维护这个列表所以我一般会写一个单元测试遍历所有片区各自取一个内部点断言resolve返回的名字就是它自己防止优先级顺序被后续改动打乱。这个测试很便宜但拦住过我好几次手滑。还有一种情况是点位落在所有多边形之外常见于数据源坐标系没对齐、或者点位在行政区划调整后被划走了。这种点位不要静默丢掉单独落一张表按周统计数量变化能提前发现上游数据源的问题。5. 五个让图跑偏的坑从现象倒推原因5.1 现象边界整体平移三四百米点位大面积错位原因基本只有一个——坐标系混用。在线地图返回的坐标是 GCJ-02GeoJSON 边界是 WGS-84两者直接叠加就会稳定偏向某个方向。判断方法是取三五个明显在区内部的点位看偏移方向是否一致一致就是坐标系问题不一致才是数据问题。解决办法是把整条链路统一到一种坐标系只在最后一层做转换。转换代码用 4.1 的迭代版本别用网上那种单次近似的版本尤其是做边界附近判定的时候几十米的残差足够造成误判。5.2 现象某个片区渲染出来是镂空的或者中间少一块原因通常是内环方向反了或者difference操作后产生了嵌套环。某些渲染库按非零环绕规则填充环方向错误会让本该实心的区域变成空洞。解决办法是先跑 3.2 的环方向检查把所有环的绕向统一。如果已经确认方向正确还是漏就检查是不是修复几何时make_valid返回了多个碎块但只取了第一个。这种情况在带飞地的片区上特别常见取第一个等于把飞地全丢了。5.3 现象各区面积加起来比全市总面积还大原因见 2.2功能区和行政区是两套口径直接求和必然重复计算。成都市域公开面积一万四千多平方公里如果求和结果超出一万六基本可以确认重复。解决办法是统计前先做空间差集用admin.difference(func)得到行政区净范围功能区单独统计。如果业务上就是要两套数并列展示那就在表头写清楚“含功能区重叠”别让人自己去猜。这个坑我在两个项目上各踩过一次都是上线后被业务方问“为什么数对不上”。5.4 现象前端registerMap之后地图一片空白控制台无报错原因可能是三种JSON 顶层不是FeatureCollection、要素缺少name属性、文件带 BOM 头导致JSON.parse失败。前两种控制台会有提示第三种最阴某些浏览器直接静默失败。解决办法是先跑 3.1 的体检脚本确认结构和属性再用十六进制看一眼文件开头是不是EF BB BF。导出时选 UTF-8 无 BOM或者读进来之后content.replace(\ufeff, )处理一下。这个问题跟数据内容完全无关纯属编码问题但排查起来最费时间。5.5 现象页面首屏加载卡顿地图要等好几秒才出来原因是原始边界坐标保留的小数位太多动辄七八位。经纬度保留 6 位小数精度大约 0.1 米对行政区级展示完全够用多出来的位数纯属浪费体积。一份一万多顶点的边界从 8 位压到 6 位能省三成体积。解决办法是两步先把坐标精度截到 6 位再用道格拉斯-普克算法做适度简化容差取 0.0001 度左右肉眼几乎看不出差异。但简化要小心飞地和窄长条简化过度会把宽度只有几十米的片区整个抹掉简化后一定要对比面积和要素数量掉太多就调小容差重来。6. 出图验证ECharts 与 Leaflet 两条渲染路加一个抽样反查法渲染不是为了好看是为了验证。两份代码分别对应两种典型场景。ECharts 走的是registerMap注册 geo组件的路子三个参数必须改对map名字要和注册名一致roam决定能不能缩放拖动aspectScale影响长宽比成都在这个比例上如果不设 0.75 左右的默认值图会被拉扁。import * as echarts from echarts; import chengdu from ./chengdu.json; // 建议预编译为 JS 模块避免运行时 fetch echarts.registerMap(chengdu, chengdu); const chart echarts.init(document.getElementById(map)); chart.setOption({ geo: { map: chengdu, roam: true, // 允许缩放拖动便于核对边界细节 aspectScale: 0.75, // 成都纬度约 30.6余弦值约 0.86留一点余量 itemStyle: { areaColor: #eef4fb, borderColor: #7aa7d8 } }, series: [{ type: scatter, coordinateSystem: geo, data: poiList, // 已在服务端转换到与边界同一坐标系 symbolSize: 6 }] });aspectScale没调对的时候图形会被横向拉长看起来像边界变形实际上只是显示比例问题和几何数据无关别去改数据。Leaflet 那边重点是坐标系对齐检查。把 geojson 图层和栅格底图叠在一起取一个边界拐点看两个图层上是否重合偏差超过 10 像素就说明坐标不匹配。另外L.geoJSON的style回调里别做重计算每个要素都会调一次写复杂逻辑会明显拖慢首屏。最后是我每次必做的一步抽样反查。从片区内部随机取 50 个点其中 20 个取在边界向内 200 米处用 4.2 的locate跑一遍看命中率。全部命中说明坐标系和几何都没问题边界附近有零星失败属于正常因为边界数据本身精度有限如果内部点也大量失败那就得回头查坐标系了。血泪教训是有一回偷懒省了这一步直接把数据交给前端结果上线后业务方反馈“高新区的点位只有一半对”。回头一查是转换脚本里always_xy漏写了整个边界转了 90 度图上却因为形状相近没被立刻发现。从那以后我每次出图前都强制跑一遍这 50 个抽样点哪怕数据来源写着“已校对”。希望帮到你。本文还有配套的精品资源点击获取