简介本资源是一套覆盖全球及中国精细化行政区域的地理信息数据集面向地图开发、GIS系统构建、地区联动组件开发等场景的中高级开发者。数据以层级结构组织支持国家→省→市→区县逐级下钻查询并附带精确经纬度坐标可直接用于地图定位、区域筛选、LBS服务等核心功能开发。压缩包共4个文件2个JSON2个SQL总大小385KBJSON文件分别提供中国全境含特别行政区与境外各国的城市层级及坐标SQL文件则包含对应数据库表结构与初始化数据便于快速导入关系型数据库使用。目前已有375人学习下载开发者可即取即用无需自行爬取或整理显著降低地理数据接入门槛尤其适合需要高精度、结构化、开箱即用全球行政区划数据的Web/移动端项目。1. 全球省市区层级结构经纬度数据不是“拿来即用”的JSON包而是地理信息系统的地基砖你下载了一个叫全球各国省市区城市地区层级结构经纬度 json与SQL.zip的压缩包双击解压后看到world_regions.json、china_provinces_cities.json、geo_data.sql……第一反应是“终于不用手敲行政区划了”兴冲冲导入数据库或json.load()读取结果——Python 报json.decoder.JSONDecodeError: Expecting property name enclosed in double quotesSQL Server 执行.sql文件卡在第3行提示Incorrect syntax near 0ArcGIS Pro 导入 JSON 提示 “无法识别地理要素类型”连点“确定”都找不到坐标字段更玄学的是越南的“胡志明市”被标为type: province而日本的“东京都”却是type: prefecture中国“重庆市”和“北京市”同属直辖市但经纬度精度差了0.002度约220米……这不是数据错了而是你没看清它背后的三层契约第一层是地理实体定义谁算“省”谁算“市”联合国标准 vs 各国法定名称 vs 实际治理单元第二层是坐标系约定WGS84GCJ02是否含边界多边形单点中心还是质心第三层是工程接口规范JSON 字段命名是否兼容 GeoJSON RFC 7946SQL 表结构是否带索引/约束/注释。本文不讲“怎么下载这个包”而是带你亲手验证、清洗、适配、落地——把这份看似杂乱的jsonSQL数据变成你 GIS 分析、地址解析、空间聚合、前端下拉联动中真正可信赖的底层地理骨架。适合正在做跨国业务系统、LBS 应用、政企数据中台或刚被“经纬度对不上”问题卡住三天的工程师。2. 解构数据包先看懂 JSON 结构再动手否则清洗就是无头苍蝇拿到global_regions.json和countries_with_admins.sql这类文件别急着pd.read_json()或psql -f。先用命令行快速探查真实结构这是所有后续操作的前提。2.1 用jq快速诊断 JSON 层级与字段一致性Linux/macOS# 查看顶层结构是否是数组对象有无根键 jq keys world_regions.json # 检查前3个元素的 type 字段是否统一常见坑混用 province/state/prefecture jq .[:3][] | {id, name, type, lat, lng} world_regions.json # 统计各 type 出现频次暴露数据标准混乱程度 jq -r .[] | .type world_regions.json | sort | uniq -c | sort -nr逻辑说明jq是处理 JSON 的瑞士军刀。keys看顶层键名避免误判为数组实为对象如{ data: [...] }.[:3]取样检查防止全量解析大文件卡死-r输出原始字符串便于管道统计。参数关键点-rraw output必须加否则uniq会把带引号的字符串当不同值sort | uniq -c是 Unix 下统计唯一值频次的黄金组合。2.2 用headfile判断 SQL 文件编码与格式Windows/Linux 通用# 查看前10行确认是否含 BOM、注释风格、建表语句位置 head -n 10 geo_data.sql # 检测文件编码中文乱码根源 file -i geo_data.sql # 输出示例geo_data.sql: text/plain; charsetutf-8 # 若显示 charsetiso-8859-1 或 charsetus-ascii大概率含 GBK/GB2312 中文需转码 iconv -f GBK -t UTF-8 geo_data.sql geo_data_utf8.sql为什么这步不能跳很多“全球数据包”由多国贡献者拼接SQL 文件可能混合 UTF-8欧美、GBK中国、Shift-JIS日本编码。直接mysql -u root geo_data.sql会因编码错位导致ERROR 1064 (42000)—— 错误提示指向第1行实际是第1000行一个日文汉字引发的连锁解析失败。file -i是唯一能提前预警的命令。2.3 验证经纬度坐标的合法性与分布范围import json import numpy as np with open(world_regions.json, r, encodingutf-8) as f: data json.load(f) # 提取所有 lat/lng过滤 None 和异常值 lats [item.get(lat) for item in data if item.get(lat) is not None] lngs [item.get(lng) for item in data if item.get(lng) is not None] print(f有效纬度数: {len(lats)}, 范围: [{min(lats):.4f}, {max(lats):.4f}]) print(f有效经度数: {len(lngs)}, 范围: [{min(lngs):.4f}, {max(lngs):.4f}]) # 检查是否超出 WGS84 合理范围纬度 -90~90经度 -180~180 invalid_lats [lat for lat in lats if lat -90 or lat 90] invalid_lngs [lng for lng in lngs if lng -180 or lng 180] print(f非法纬度数: {len(invalid_lats)}, 非法经度数: {len(invalid_lngs)})血泪经验某次导入发现“南极洲”下辖 12 个“省”纬度全是99.9999—— 实为数据生成脚本未处理极地投影的占位符。min/max统计比肉眼扫grep更可靠尤其当数据量超 10 万行时。参数说明.get(lat)安全取值避免KeyError{:.4f}保留4位小数足够定位到百米级0.0001° ≈ 11 米过细反而暴露浮点误差。3. JSON 清洗与标准化统一 type 字段、补全缺失坐标、修复嵌套结构原始 JSON 常见三大硬伤type字段命名不一致province/state/oblast混用、中国区lng写成lon、小国数据缺失lat/lng。不清洗就入库后续写 SQL 时WHERE type IN (province,state)会漏掉 30% 数据。3.1 编写 Python 清洗脚本用映射字典统一行政级别语义import json import re # 定义全球行政级别标准化映射按联合国 M49 标准常见实践 LEVEL_MAPPING { # 一级行政区国家以下最高层 province: administrative_area_level_1, state: administrative_area_level_1, prefecture: administrative_area_level_1, oblast: administrative_area_level_1, region: administrative_area_level_1, # 注意法国region是大区但意大利regione也是大区 governorate: administrative_area_level_1, # 埃及、约旦 # 二级行政区 city: administrative_area_level_2, municipality: administrative_area_level_2, county: administrative_area_level_2, district: administrative_area_level_2, # 特殊情况中国直辖市、特别行政区单独标记便于前端高亮 municipality: administrative_area_level_1, # 北京/上海/天津/重庆 special_administrative_region: administrative_area_level_1, # 香港/澳门 } def normalize_type(raw_type: str, country_code: str None) - str: 根据国家代码微调 type 映射如日本 to metropolitan prefecture raw_lower raw_type.strip().lower() # 中国特例直辖市在 JSON 中常标为 city但逻辑上是省级 if country_code CN and raw_lower in [city, municipality]: return administrative_area_level_1 # 日本特例to (都), do (道), fu (府) 都是都道府县等同于 prefecture if country_code JP and raw_lower in [to, do, fu]: return administrative_area_level_1 return LEVEL_MAPPING.get(raw_lower, unknown) # 执行清洗 with open(world_regions.json, r, encodingutf-8) as f: raw_data json.load(f) cleaned_data [] for item in raw_data: # 修复字段名兼容 lng/lon lng item.get(lng) or item.get(lon) lat item.get(lat) # 标准化 type country_code item.get(country_code, ).upper() new_type normalize_type(item.get(type, ), country_code) # 构建标准化对象 cleaned_item { id: item.get(id), name: item.get(name, ).strip(), type: new_type, country_code: country_code, lat: float(lat) if lat is not None else None, lng: float(lng) if lng is not None else None, parent_id: item.get(parent_id), # 保留层级关系 level: int(item.get(level, 0)) # 显式标注层级深度1省2市... } cleaned_data.append(cleaned_item) # 保存清洗后 JSON with open(world_regions_clean.json, w, encodingutf-8) as f: json.dump(cleaned_data, f, ensure_asciiFalse, indent2)为什么用字典映射而非正则type字段是业务语义标签不是文本模式。region在法国是大区L1在南非是省L1但在美国是泛指区域非行政单位——必须靠人工校验的映射字典而非re.sub(rregion, L1)这种暴力替换。关键参数ensure_asciiFalse保证中文不转义为\u4f60\u597dindent2生成可读 JSON方便后续 diff 对比。3.2 为缺失经纬度的城市补全坐标用 Geopy 缓存防限流from geopy.geocoders import Nominatim import time import pickle # 初始化地理编码器设置合理 user_agent 防被封 geolocator Nominatim(user_agentgeo-admin-cleaner-v1.0) # 加载已清洗数据含缺失 lat/lng 的项 with open(world_regions_clean.json, r, encodingutf-8) as f: data json.load(f) # 尝试从缓存恢复避免重复请求 cache_file geocode_cache.pkl try: with open(cache_file, rb) as f: cache pickle.load(f) except FileNotFoundError: cache {} def get_coordinates(name: str, country_code: str None) - tuple: 获取城市坐标优先查缓存失败则调用 API cache_key f{name}|{country_code} if cache_key in cache: return cache[cache_key] try: # 构造查询字符串城市名 国家提高准确率 query name if country_code: query f, {country_code} location geolocator.geocode(query, timeout10, languageen) if location: coords (round(location.latitude, 6), round(location.longitude, 6)) cache[cache_key] coords return coords else: return (None, None) except Exception as e: print(fGeocode failed for {query}: {e}) return (None, None) # 批量补全注意Nominatim 要求 1秒/请求 for i, item in enumerate(data): if item[lat] is None or item[lng] is None: lat, lng get_coordinates(item[name], item[country_code]) if lat and lng: item[lat] lat item[lng] lng print(f[{i}] Fixed {item[name]}, {item[country_code]} - ({lat}, {lng})) # 强制休眠 1.1 秒遵守 Nominatim AUP time.sleep(1.1) # 保存缓存和更新后数据 with open(cache_file, wb) as f: pickle.dump(cache, f) with open(world_regions_complete.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2)避坑重点Nominatim 免费版严格限制 QPS每秒请求数不加time.sleep(1.1)会导致403 Forbidden或返回空结果。languageen强制英文返回避免多语言名称混淆如“San Francisco”在西班牙语 JSON 中可能写作“San Francisco”但返回墨西哥地址。缓存价值10 万条数据中约 15% 缺坐标全量请求需 40 小时用缓存后首次运行耗时后续复用只需秒级。4. SQL 结构设计与安全导入拒绝裸执行 .sql 文件必须建模再加载直接mysql -u root geo_data.sql是新手最大误区。原始 SQL 文件往往缺少主键、索引、外键约束且INSERT INTO regions VALUES (...)语句未指定字段名一旦 JSON 字段顺序变动数据就错位。4.1 逆向工程 SQL 文件提取建表语句并增强约束# 提取 CREATE TABLE 语句跳过注释和 INSERT sed -n /^CREATE TABLE/,/);/p geo_data.sql | grep -v ^-- | grep -v ^/*假设提取出CREATE TABLE regions ( id VARCHAR(32), name VARCHAR(128), type VARCHAR(32), parent_id VARCHAR(32), lat DECIMAL(10,8), lng DECIMAL(11,8) );必须增强的 4 处否则生产环境必翻车增强点原始缺陷增强后 SQL为什么必要主键无主键id VARCHAR(32) PRIMARY KEY避免重复插入作为其他表外键基础索引无索引INDEX idx_country_type (country_code, type)地址搜索高频条件WHERE country_codeCN AND typeadministrative_area_level_1非空约束lat/lng可为空lat DECIMAL(10,8) NOT NULL, lng DECIMAL(11,8) NOT NULL空坐标导致空间计算崩溃如ST_Distance报错外键无层级关联FOREIGN KEY (parent_id) REFERENCES regions(id)保证parent_id必须存在防止脏数据最终建表语句CREATE TABLE regions ( id VARCHAR(32) PRIMARY KEY, name VARCHAR(128) NOT NULL, type VARCHAR(32) NOT NULL, country_code CHAR(2) NOT NULL, parent_id VARCHAR(32), lat DECIMAL(10,8) NOT NULL, lng DECIMAL(11,8) NOT NULL, level TINYINT NOT NULL DEFAULT 0, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (parent_id) REFERENCES regions(id), INDEX idx_country_type (country_code, type), INDEX idx_lat_lng (lat, lng) );参数深挖DECIMAL(10,8)表示共10位小数占8位如39.90420000足够表示厘米级精度0.00000001° ≈ 0.001 米TINYINT存层级1~5比INT节省 3 字节/行INDEX idx_lat_lng是空间查询基础没有它WHERE ST_DWithin(point, ST_MakePoint(lng,lat), 1000)会全表扫描。4.2 用 Python 安全批量插入替代原始 INSERT 语句import mysql.connector import json # 连接数据库生产环境务必用配置文件此处简化 conn mysql.connector.connect( hostlocalhost, usergeo_app, passwordyour_secure_password, databasegeo_db, charsetutf8mb4 # 支持 emoji 和生僻汉字 ) cursor conn.cursor() # 加载清洗后 JSON with open(world_regions_complete.json, r, encodingutf-8) as f: data json.load(f) # 预编译插入语句防 SQL 注入且性能提升 3x insert_sql INSERT INTO regions (id, name, type, country_code, parent_id, lat, lng, level) VALUES (%s, %s, %s, %s, %s, %s, %s, %s) ON DUPLICATE KEY UPDATE nameVALUES(name), typeVALUES(type), latVALUES(lat), lngVALUES(lng) # 批量执行每次 1000 条防内存溢出 batch_size 1000 for i in range(0, len(data), batch_size): batch data[i:ibatch_size] values [ ( item[id], item[name], item[type], item[country_code], item[parent_id], item[lat], item[lng], item[level] ) for item in batch if item[lat] is not None and item[lng] is not None ] cursor.executemany(insert_sql, values) conn.commit() print(fInserted batch {i//batch_size 1}/{(len(data)-1)//batch_size 1}) cursor.close() conn.close()为什么不用LOAD DATA INFILELOAD DATA虽快但无法处理ON DUPLICATE KEY UPDATE需去重更新且对字段类型校验弱lat字符串会静默转 0。executemany 预编译语句兼顾安全、可控、可调试。关键防御charsetutf8mb4防止“”等四字节 Unicode 存储为?if item[lat] is not None过滤无效坐标避免NULL写入NOT NULL字段报错。5. 避坑指南JSON 与 SQL 地理数据的 5 个血泪现场注意以下问题均来自真实项目非理论推演。每个现象都对应一次线上事故或 3 天以上的排查。5.1 现象ArcGIS Pro 导入 JSON 后所有点挤在赤道上原因JSON 中lat/lng字段被交换lat: 116.404, lng: 39.915实为lng/lat顺序错误而 ArcGIS 默认按x,y解析经度,纬度导致x39.915无效经度被强制归零。解决用jq检查lat值是否普遍在0~180应为-90~90lng是否在-90~90应为-180~180。交换字段后重新导出。5.2 现象SQL 查询SELECT * FROM regions WHERE country_codeCN AND typeadministrative_area_level_1返回 33 行含台湾省但业务要求只显示 31 个省级单位原因数据包遵循联合国 M49 标准将台湾列为country_codeTW但中国区 JSON 单独提供CN下的administrative_area_level_1包含台湾省。业务系统需按政治实体过滤而非单纯country_code。解决建country_policy配置表定义country_code与display_scope如CN - mainland_only查询时JOIN过滤而非硬编码WHERE。5.3 现象前端下拉选择“日本→东京都→新宿区”后地图定位到东京湾海面原因新宿区的lat/lng是其行政中心点但该点位于东京都厅舍屋顶GPS 信号弱实际地理质心在新宿站南口。更严重的是东京都的lat/lng是35.6895,139.6917皇居而新宿区的lat/lng是35.6895,139.6917完全相同—— 数据生成时未计算子区域质心。解决用 PostGIS 计算质心UPDATE regions SET lat ST_Y(ST_Centroid(geometry)), lng ST_X(ST_Centroid(geometry)) WHERE geometry IS NOT NULL;需先导入 GeoJSON 边界。5.4 现象json.loads()报错JSONDecodeError: Invalid control character at: line 1 column 12345 (char 12345)原因JSON 文件含不可见控制字符如\x00空字节、\x08退格常见于 Windows 记事本另存为 UTF-8 时插入 BOMEF BB BF或爬虫抓取时混入响应头。解决用iconv -c -f UTF-8 -t UTF-8//IGNORE input.json clean.json-c跳过非法字符或 Python 中预处理with open(input.json, rb) as f: raw f.read() clean re.sub(b[\x00-\x08\x0b\x0c\x0e-\x1f], b, raw) # 移除控制字符 data json.loads(clean.decode(utf-8))5.5 现象SQL Server 导入后lat字段全为0.00000000原因SQL Server 的DECIMAL(10,8)要求输入值必须是xxxx.xxxxxxxx格式但 JSON 中lat为整数如39或短小数如39.9SQL Server 自动补零导致精度丢失。解决导入前用 Python 格式化lat_str f{item[lat]:.8f} if item[lat] else 0.00000000 # 确保小数位数恒为 8避免 SQL Server 隐式转换6. 进阶技巧用空间索引加速跨国地理查询以及一个反直觉的验证方法当你把数据成功导入 MySQL 或 PostGIS别急着写业务 SQL。真正的分水岭在于——能否在 1 秒内回答“离东京都 200 公里内有哪些中国的省级行政区” 这需要空间索引而非普通 B-Tree。6.1 在 MySQL 中创建空间列并构建 R-Tree 索引-- 添加空间点列WGS84 坐标系 ALTER TABLE regions ADD COLUMN geom POINT SRID 4326, ADD SPATIAL INDEX sp_index_geom (geom); -- 用 lat/lng 填充空间点注意ST_Point(longitude, latitude)顺序是 lng,lat UPDATE regions SET geom ST_Point(lng, lat) WHERE lat IS NOT NULL AND lng IS NOT NULL; -- 验证查询东京都 200km 内的中国省级单位使用地球距离函数 SELECT r1.name AS china_province, r2.name AS tokyo_city FROM regions r1, regions r2 WHERE r1.country_code CN AND r1.type administrative_area_level_1 AND r2.country_code JP AND r2.name Tokyo AND ST_DistanceSphere(r1.geom, r2.geom) 200000; -- 单位米为什么ST_DistanceSphere比ST_Distance强ST_Distance计算平面欧氏距离单位度在赤道和两极误差达 100 倍ST_DistanceSphere按球面大圆距离计算单位米误差 0.5%。SRID 4326是 WGS84 标准强制声明坐标系避免ST_Point解析错乱。6.2 一个反直觉但极有效的数据质量验证法用“逆向地理编码”交叉验证你以为坐标准试试把lat/lng丢回地理编码 API看返回的address_components是否匹配原始name和typefrom geopy.geocoders import Nominatim geolocator Nominatim(user_agentgeo-verify-v1) def verify_coordinate(lat: float, lng: float, expected_name: str, expected_type: str): try: # 逆向编码坐标 → 地址 location geolocator.reverse(f{lat},{lng}, exactly_oneTrue, languageen) if not location: return False, No reverse result # 解析返回的地址组件Google/OSM 格式 address location.raw.get(address, {}) city address.get(city) or address.get(town) or address.get(village) state address.get(state) or address.get(province) or address.get(region) # 检查是否匹配模糊匹配容忍拼写差异 name_match expected_name.lower() in (city or ).lower() or \ (city or ).lower() in expected_name.lower() type_match expected_type in [administrative_area_level_1, administrative_area_level_2] and \ (state is not None if expected_type administrative_area_level_1 else city is not None) return name_match and type_match, fGot: {city}, {state} except Exception as e: return False, fAPI error: {e} # 随机抽样 1000 条验证 import random sample random.sample(cleaned_data, 1000) errors [] for item in sample: if item[lat] and item[lng]: ok, msg verify_coordinate(item[lat], item[lng], item[name], item[type]) if not ok: errors.append(f{item[name]} ({item[country_code]}): {msg}) print(fVerification errors: {len(errors)} / {len(sample)}) # 输出示例[Beijing (CN): Got: Beijing, Beijing] # 这说明“北京市”的逆向结果是“Beijing, Beijing”符合预期市省为什么这招比人工抽查强人工看lat39.9042, lng116.404觉得没问题但逆向编码可能返回location: Forbidden City, Beijing—— 说明坐标点落在故宫而非北京市政府质心。这种偏差在旅游、物流场景中会导致路径规划失效。关键洞察地理数据质量不在于“数值精确”而在于“语义一致”。39.9042,116.404是精确的但如果它代表故宫就不能当“北京市”的坐标用。我坚持在每个新项目启动时用这个逆向验证法跑一遍核心城市数据。曾经发现某批东南亚数据中70% 的“首都”坐标实际指向机场——因为数据源用机场 IATA 代码反查坐标而机场常在城郊。这种坑只有让坐标自己“开口说话”才能暴露。希望帮到你。本文还有配套的精品资源点击获取