2020全国行政边界CGCS2000数据处理：坐标转换与Python标准化

简介：一份面向地理信息系统从业者、规划研究者及地理数据分析人员的全国行政边界矢量数据包，数据覆盖省、市、县三级行政单元，采用国家2000坐标系，保存为常用的矢量文件格式，适用于行政区划可视化、人口密度分析、区域规划与专题制图等场景。压缩包共二十五个文件，以shp、shx、dbf为核心矢量文件，其中shp存储几何边界、dbf保存行政属性、shx提供索引，另含坐标投影、空间索引及元数据等配套文件，整体体积六十二点二三兆字节，解压后可直接加载至主流地理信息平台使用。目前已有两千二百五十七人学习下载。借助这些数据，使用者可快速获取全国各级行政边界轮廓，省去手动采集与配准流程，专注于缓冲区分析、叠置分析等空间操作，并为政府规划、市场调研、资源管理等提供可靠的地理底图支撑。

1. 打开这份 RAR 之前，先弄明白「国家2000坐标系」在说什么

做区域统计分析、专题制图，或者任何和省市区有关的可视化项目，永远绕不开一个基础图层：行政边界。标题里的「2020全国省、市、县行政边界-国家2000坐标系.rar」，解压后就是省、市、县三套矢量面数据，坐标系标的是国家2000坐标系，也就是业内常说的 CGCS2000（2000 国家大地坐标系）。这套坐标系是当前国家大地基准的主流标准，国内自然资源、国土空间相关的数据基本都是按它生产，你的业务数据、统计口径能不能跟它对齐，决定了后面要不要花大力气做坐标转换。

我见过太多人拿到这类压缩包后直接解压、拖进软件、开始画图，结果要么边界和在线底图偏差几公里，要么属性表全是乱码。问题通常不在数据本身，而是坐标系、编码、投影这些前置信息没有被确认，才在后续环节连环翻车。这篇按我自己处理这套数据的顺序走：先验证文件与坐标系，再批量转换坐标、修正编码，把三个典型坑提前讲清楚，最后落到一套可复用的 Python 处理脚本。新手按步骤能跑通，熟手可以直接看参数和踩坑记录。

2. 解压后先做三件套验证：文件结构、字段含义、坐标系定义

很多人拿到 .rar 的第一个动作是全选解压，然后也不看解出来什么，直接在 GIS 软件里拖 .shp。等拖进去发现缺字段、缺坐标，才回头找问题。我的习惯是先花三分钟做一次「文件体检」，确认三件事：Shapefile 组件是否齐全、坐标系到底是什么、属性表里有哪些字段。这一步做扎实，后面所有处理都顺。

2.1 解压与文件体检：Shapefile 一整套文件，一个都不能少

先说一个容易被忽略的事实：Shapefile 不是单文件，而是一整套文件的组合。你在资源管理器里看到的「省界.shp」只是主文件，真正能用的图层必须同时具备至少四个文件。缺了任何一个，轻则软件提示出错，重则坐标系和属性表直接丢失。解压后第一件事，是核对每个图层是否都带齐四件套。

Linux 或 macOS 下我习惯用 unar 解压，它对中文文件名的兼容比 unrar 好，解出来不会出现文件名乱码。Windows 下直接图形化解压即可，重点看解压结果。

mkdir -p ./admin_boundary unar "2020全国省、市、县行政边界-国家2000坐标系.rar" -o ./admin_boundary find ./admin_boundary -type f | sort

代码说明：mkdir -p先建输出目录，避免解压器问到一半不知道该写哪；unar的-o指定输出目录；最后用find列出全部解压文件，按路径排序后一眼就能看出每个图层缺不缺 .prj 或 .dbf。如果解出来是三个目录或三组文件（省界、市界、县界各一套），那结构很清楚；如果是一个 shp 里带 LEVEL 字段区分三级，后面用按字段过滤的方式拆分即可，处理逻辑是相通的。

2.2 用 ogrinfo 确认坐标系：CGCS2000 地理坐标还是高斯投影

标题只写了「国家2000坐标系」，但这句话没有说全。CGCS2000 作为基准，既可以表达为地理坐标系（经纬度单位），也可以套上高斯-克吕格投影变成米制坐标。同样是这份边界，两种形式都可能在市面上流传，而它们的处理方式完全不同。判断依据只有一个：.prj 文件里到底写了什么。

ogrinfo -ro -so -al ./admin_boundary/省界.shp

命令参数说明：-ro表示只读打开，避免误改数据；-so是 summary only，只输出图层概要；-al表示列出该文件的所有图层，无论它内部装了几层。输出结果里两段最关键：一段是Layer SRS WKT，直接描述坐标系；另一段是Extent，显示要素的坐标范围。

判断口诀：如果 WKT 里出现GEOGCS["China Geodetic Coordinate System 2000"]，这是 CGCS2000 地理坐标系，行业内对应 EPSG:4490，坐标值是十进制度数；如果出现PROJCS[...Gauss-Kruger...]，这是投影坐标系，坐标值是米。再用 Extent 交叉验证：经纬度的范围大致在 73 到 135、3 到 54 之间；投影坐标的数值则是六位到七位的米制值。既看 WKT 又看坐标范围，基本不会认错。用 QGIS 的话不需要记命令，右键图层看「属性—信息」里的 CRS 描述，看到的内容一样。

这一步很关键。数据是地理坐标还是投影坐标，决定了后面叠加底图和算面积的方案完全不同，在这里花一分钟确认，比之后折腾一小时排错省力得多。

2.3 属性表字段解析：行政区划代码、名称、级别怎么用

边界数据的价值一半在几何，另一半在属性表。行政边界不像 POI 数据那么多字段，但行政区划代码、名称、级别这三个字段几乎必然出现，不同来源的命名略有差异，常见的叫法是 PAC、NAME、CLASS 或 LVL。解压后先看一眼字段结构，再讨论怎么用。

ogrinfo -ro -so -al ./admin_boundary/县界.shp | tail -20

说明：tail -20是把输出截到最后 20 行，因为-so模式下前面的信息是坐标系和范围，属性字段列表在最后。看到字段名后，注意每个字段的类型：名称和代码最好都是字符串型（String），尤其行政区划代码，如果是数值型，打开后前导零会被吃掉，比如 110101 变成 110101 没问题，但某些代码如 110100 这类补零场景会让你统计时抓狂。

行政区划代码有个通用规则：6 位代码里，前 2 位表示省级，前 4 位表示地级市，完整 6 位表示县级；有些数据给的是 12 位代码，那前 6 位同样是县级代码，后 6 位是乡镇统计扩展。做「每个省下面有多少市」「每个市下面有多少县」这类统计时，按代码前缀分组就能实现，但要注意直辖市、省直辖县级市和自治州的代码规则不完全一样，不能无脑按前缀切。此外，名称字段经常带尾随空格，之后做属性连接前一定要先strip()，这是我踩过的常见细节。

3. 让三级边界真正落入项目：QGIS 加载、坐标转换与导出

验证完数据，第二阶段就是转换。这里要解决一个核心矛盾：原始数据是 CGCS2000 基准，但很多可视化项目、在线地图工具和前后端框架默认的是 WGS84 或 Web 墨卡托。直接拿原始 shp 上项目，大概率错位。转换的思路很简单，关键是选对目标坐标系，以及搞清楚每种转换引入了什么变形。

3.1 为什么不能拿原始 SHP 直接做 Web 地图叠加

在线底图服务普遍使用 Web 墨卡托投影（WGS84 基准，对应 EPSG:3857），前端地图库也默认按 3857 的瓦片机制工作。原始数据如果停留在 CGCS2000 地理坐标（4490），直接叠加 Web 底图会发生基准差异和投影变换缺失的双重错位。基准层面，CGCS2000 与 WGS84 在椭球定义上存在细微差别，反映到平面位置通常是亚米级到米级的偏差，城市尺度下足够肉眼可见；投影变换缺失则是更大的问题，一套经纬度数据不经过投影直接丢进 Web 墨卡托的坐标系框架里，在跨图幅拼接时会出现系统性的偏移和缩放异常。

还有个容易被忽略的隐患：如果 .prj 缺失或软件没有读到坐标系定义，QGIS 在拖入图层时会弹出「选择 CRS」对话框。此时手一抖选错成 WGS84，整个图层会被按 4326 去解释，边界位置直接偏出一大截。转换前先按第 2 章的方法确认源坐标系，再根据用途选目标。

我的选择习惯是：存档用 4490，出图用 3857，接口交换用 4326。不要只导出一份「能用」的数据，最好把原始坐标版本也留着，方便日后重新投影。

3.2 用 ogr2ogr 批量坐标转换与编码修复

QGIS 里有「重投影图层」工具，单文件处理很直观。但省、市、县三个图层每次更新都要在菜单里点好几下，我一般直接用 ogr2ogr 写脚本跑，参数固定，换数据源时重跑一遍就行。下面这段脚本的处理逻辑是：把三个 shp 从 CGCS2000 地理坐标（4490）转换成 Web 墨卡托（3857），同时把属性表编码声明改成 UTF-8。

mkdir -p ./out_3857 for f in ./admin_boundary/省界.shp ./admin_boundary/市界.shp ./admin_boundary/县界.shp; do ogr2ogr -overwrite \ -s_srs EPSG:4490 \ -t_srs EPSG:3857 \ -lco ENCODING=UTF-8 \ "./out_3857/$(basename "$f")" \ "$f" done

参数说明：-s_srs声明输入坐标系，-t_srs指定输出坐标系，两者都写明确了，ogrinfo 就不至于在缺少 .prj 时猜错；-overwrite允许重复运行脚本时覆盖旧输出；-lco ENCODING=UTF-8是最容易被漏掉的一项——它不改变属性内容，只是把 dbf 的编码声明写成 UTF-8，这一步能解决后面 QGIS 里打开中文属性表乱码的问题。$(basename "$f")取原文件名作为输出名，保持三个图层命名不变。

如果解压出来的数据是投影坐标系（例如 3 度带 CGCS2000），把-s_srs EPSG:4490改成对应的 CRS 定义再跑，不必先转回地理坐标再转 3857，直接一次投影更省事。Windows 下没有 bash 的 for 循环语法，把命令逐条执行即可，但输出和输入路径不要带中文，Windows 的代码页经常会在这里制造玄学报错，第 4 章专门讲。

3.3 转换后怎么验证：位置套合、面积量级、层级统计

转换完成不等于正确。我的习惯是三层验证：位置套合、面积量级、层级统计。先打开 QGIS，加载一份在线 XYZ 瓦片底图，把转换后的省界叠上去，缩放县级尺度看行政边界是否和道路、河流、地名注记对齐。如果整体偏移但方向一致，通常是-s_srs写错；如果局部形变明显，多半是原始数据本身用了投影带，被当成地理坐标处理了。

面积量级是判断坐标系是否混乱的快速手段。在 QGIS 字段计算器里新建一个字段，表达式写area($geometry) / 1000000，得到面积单位是平方公里。省界总量级应该和全国陆地面积同一数量级，某个省的边界算出来如果是几平方公里，那不是数据错了，是坐标还是经纬度单位，面积公式在投影坐标系下才有意义。还要提醒一句：Web 墨卡托（3857）下算面积是失真的，纬度越高虚增越明显，真要算面积，把数据转到 Albers 等积投影（中央经线 105°E、标准纬线 25°N 和 47°N）再做，结果才可入报表。

层级统计最简单也最容易被跳过：分别打开三个图层，看省界要素数量是否对应当年官方省级行政区数量，市界对应地级行政区数量，县界对应县级行政区数量。任何一个数量级差出几十个，先别急着用，回去核对数据版本和字段过滤条件。

4. 行政边界数据避坑手册：从坐标系错乱到属性乱码

这一类「全国边界包」在网上流传很广，但流传过程中经常被二次处理，坐标系、编码、字段都可能被改过。我把这几年处理类似数据遇到的高频问题整理成几条，每条都是「现象 → 原因 → 解决」的结构。这些问题单个看起来都不大，凑在一起足够让一个项目卡两三天。

4.1 坐标系混用导致的全图偏移

现象：A 同学把边界拖进项目后，发现所有面整体往西北方向平移了几公里，县级边界在市区边缘错出明显的一段；切换底图后偏移方向还不一样。

原因：数据实际是 CGCS2000 地理坐标，但 QGIS 在图层缺少 .prj 时弹窗让选坐标系，A 同学随手选了 WGS84（4326）。两个坐标系虽然基准接近，但数据一旦被按错误的基准解释，投影转换的起点就错了。更隐蔽的情况是数据本身是高斯-克吕格投影，却被当作地理坐标直接叠加，这时偏移往往在数百公里量级。

解决：先回到源头，用第 2.2 节的 ogrinfo 确认每个图层的真实坐标系，逐个看，不要只看一个文件就假设三套数据来源一致。确认后用 ogr2ogr 加-s_srs和-t_srs重新投影，命令格式和 3.2 节的脚本完全一样。如果 .prj 真的丢了，那就通过坐标值范围反推：经纬度在 73/135、3/54 上下，投影坐标是五六位数的米制值，二选一基本不会错。

4.2 属性表中文乱码与行政区划代码统计出错

现象：属性表里名称字段显示成「锟斤拷」或者一长串单字，统计一个市下辖多少个县时数字明显不对，查某个县怎么都匹配不上。

原因：旧版 shp 的 dbf 属性表常用 GBK 编码，而 QGIS 和 Python 的 geopandas 默认按 UTF-8 解析，读出来自然是乱码。统计出错多半不是编码问题，而是代码字段的层级取错：拿地级市代码的后两位去匹配县级代码，或者 6 位代码被当成 12 位代码截取，县域归属天然就对不上。

解决：QGIS 里右键图层进入数据源设置，把编码切到 GBK（如果默认是 UTF-8）或反过来试一次，显示正常就锁定这个编码。命令行场景更省事，在 ogr2ogr 转换时加-lco ENCODING=UTF-8，一次性把属性表转成 UTF-8。Python 读取时显式指定编码，并统一处理代码字段：

import geopandas as gpd gdf = gpd.read_file("县界.shp", encoding="gbk") gdf["code6"] = gdf["PAC"].astype(str).str.zfill(12).str[:6] count_by_city = gdf.groupby(gdf["code6"].str[:4]).size() print(count_by_city)

代码逻辑说明：zfill(12)先把字符串补足到 12 位，防止数字型代码前导零丢失；str[:6]取前 6 位得到县级代码；再按前 4 位分组，就是地级市维度的下辖县数量统计。要注意，省直辖县级市和直辖市辖区的父级代码不在市级表里，统计结果里出现这类特殊代码是正常的，不要当成数据错误直接删掉。

4.3 拓扑小缝隙与重叠区域

现象：用县级边界和市级边界做空间连接，部分县匹配不到；或者统计人口落到县里，所有县的面积加起来比实际国土面积多出一截。把县界放大到邻接处看，相邻两个县之间有细条状重叠或空隙。

原因：不同来源的边界在相邻行政单位的公共边上，点位坐标不完全一致。这套 2020 年数据如果分省生产再拼接，省与省之间、县与县之间共享边的精度很可能不同；还有一种情况是数据包里混入了前后两个版本的区划，某两个县当年合并了，旧版数据没删干净。

解决：纯制图场景下，细小的拓扑瑕疵不影响视觉，不必强行修复，强行修反而可能引入新变形。但要做空间计算，就得先处理。QGIS 菜单里有「修复几何」工具，能自动处理重复点、自相交等结构错误，适合快速过一遍。更严格的做法是在 PostGIS 里对齐公共边：

UPDATE county_boundary c SET geom = ST_Snap(c.geom, u.geom, 0.001) FROM (SELECT geom FROM city_boundary) u WHERE ST_Intersects(c.geom, u.geom);

这段 SQL 的语义是：把每个县级面的几何捕捉到相邻市级面的几何上，容差 0.001。注意容差单位取决于当前数据坐标系，投影坐标系下是米，地理坐标系下是度，跑之前确认清楚，并且一定要先备份原表。实用层面还有个更稳的策略：统计和空间计算尽量用县级数据，但需要市级口径时，用县级面按代码字段聚合，而不是把县级边界和市级边界做面面叠置。这样可以绕开公共边不一致的大部分坑。

4.4 中文路径与命令行工具的编码报错

现象：Windows 下运行 ogr2ogr，路径里明明有文件，命令却报「无法打开数据源」；或者脚本里遍历文件时，文件名显示成乱码；QGIS 里一切正常，一上命令行就翻车。

原因：GDAL 在 Windows 上处理中文路径时，要经历系统代码页与内部 UTF-8 的转码，不同版本表现还不一样。这不是数据问题，是运行环境的字符集问题，属于典型的靠经验才能定位的坑。

解决：我的固定做法是让数据全程走英文路径。把整个工作目录放在纯英文路径下，文件名在入库前统一改成 adm0.shp、adm1.shp、adm2.shp 这类英文名，字段名也尽量保持 PAC、NAME 这类英文。路径、文件名、字段名三个维度全部英文化之后，Windows 和 Linux 上的命令行行为就完全一致了。数据转换完再改回需要的中文显示名，那是展示层的事，和数据文件本身无关。这套「英文路径 + 英文字段 + UTF-8 编码」的组合，是我处理国内 shp 数据的基本默认配置，凡是按这个配置跑的，基本没再遇过莫名其妙的编码报错。

5. 进阶：用 Python 把这套边界变成可复用基础设施

走到这一步，省、市、县边界已经能正确显示和使用了。但如果每个项目都重新解压、重新转换一次，迟早会在某个版本上栽跟头。我习惯把边界处理固化成一段 Python 脚本，跑一次就生成一套标准化的基础图层：统一字段名、统一坐标系、同时输出 SHP 和 GeoJSON 两种格式。

5.1 固化脚本：统一字段、双格式输出

import geopandas as gpd sources = [ ("adm0", "省界.shp"), ("adm1", "市界.shp"), ("adm2", "县界.shp"), ] for key, path in sources: gdf = gpd.read_file(path, encoding="gbk") # 乱码时改 utf-8 gdf = gdf.to_crs("EPSG:4490") # 统一存档坐标系 gdf = gdf.rename(columns={ "PAC": "code", "NAME": "name", "CLASS": "level", }) gdf["level"] = key gdf.to_file(f"out/{key}.shp", encoding="utf-8") gdf.to_file(f"out/{key}.geojson", driver="GeoJSON", encoding="utf-8")

说明：读入时先按 GBK 解码，乱码就换成 UTF-8 再试；三个图层全部统一到 4490 作为存档坐标系；字段重命名成 code、name、level，之后所有脚本都按这套字段名写，不用再迁就不同来源的命名差异；最终同时输出 SHP（兼容桌面 GIS）和 GeoJSON（给前端或接口用）。这里有个取舍：不要为了追求小体积去简化几何，边界数据做 Web 端可视化时简化很重要，但应该保留一份未简化的原始精度版本，简化版在使用侧再单独生成。

5.2 验证三板斧：层级数量、父级代码、面积量级

固化脚本跑完，还要自动做三层校验。第一板斧，检查每个层级的要素数量是否与官方口径一致；第二板斧，核对县级代码的父级代码是否都能在市级代码里找到；第三板斧，用等积投影算面积，确认没有重叠或漏面。

import geopandas as gpd adm1 = gpd.read_file("out/adm1.shp", encoding="utf-8") adm2 = gpd.read_file("out/adm2.shp", encoding="utf-8") parent_codes = set(adm1["code"].astype(str).str[:4]) bad = adm2[~adm2["code"].astype(str).str[:4].isin(parent_codes)] print(bad[["code", "name"]]) adm0_albers = gpd.read_file("out/adm0.shp", encoding="utf-8").to_crs( "+proj=aea +lat_1=25 +lat_2=47 +lat_0=0 +lon_0=105 +x_0=0 +y_0=0 +datum=CGCS2000" ) total_area_km2 = adm0_albers.geometry.area.sum() / 1_000_000 print(total_area_km2)

这段代码里，bad输出的那些代码就是父级不在市级列表里的特殊区域，多半是直辖市辖区或省直辖县级市，单独看一遍确认合理即可，别当错误直接删。面积校验用 Albers 等积投影算省界总面积，数值应该在 960 万平方公里这个量级附近，如果偏差很大，说明图层的坐标系定义或者要素本身有问题。这套流程我用了几轮数据更新，基本没再为边界数据翻过车，希望帮到你。

本文还有配套的精品资源，点击获取