简介这是一份北京市十六个区县级行政区划矢量数据包覆盖全部市辖区属性信息完整面向GIS数据分析、地理教学、地图制图、城乡规划与可视化报表等场景的使用者。数据以标准shp格式组织可直接导入ArcGIS、QGIS、SuperMap等主流平台访问属性表包含各行政区名称、区域面积等字段便于进行区域面积对比、人口经济数据挂接、专题图制作、空间查询与基础统计分析免去手工整理底图的环节。压缩包共7个文件包含shp、dbf、prj、shx等必要组件其中shp记录几何边界dbf承载名称与面积等属性prj提供坐标参考信息结构简洁整体仅53KB轻量易用。目前已有1562人学习下载适合需要快速获取北京区划底图、做区县尺度空间可视化或开展区域对比分析的读者也可与在线底图、统计年鉴数据叠加进一步承载人口密度、经济总量等分析。1. 北京行政区划shp属性清晰为什么比边界本身更值钱做地图可视化和行政区统计的人大概率都经历过找底图的折腾。网上的北京行政区划shp版本不少真正能直接用的很少多数版本要么坐标对不上底图要么字段叫FID、SHAPE_Leng这种系统默认名拿到手得花半天猜每个字段是什么。所以“属性清晰”这四个字才是关键边界多边形只是外衣属性表才是能与业务数据对话的桥梁。一份属性清晰的北京行政区划shp通常意味着字段名规范adcode、name、level、parent、区划代码是更新后的官方版本、中文不乱码、层级能对得上。它能直接用来做行政区聚合统计、按区配色的地图、地址与区划代码的匹配。我早期给某市级大数据可视化项目做底图时拿到的数据几何没问题但属性表里区划代码新旧混杂光清洗就花了两天。后来才意识到这类基础数据属性清晰比边界精确更值钱。适合读这篇笔记的是做数据可视化、GIS空间分析、地址落区匹配的从业者目标就一个拿到北京行政区划shp后能用最短时间确认它能不能用、怎么用、坑在哪。2. 先摸清北京行政区划shp的底细组成文件、坐标系与属性字段2.1 一个shp不是单个文件.shp、.shx、.dbf、.prj各管什么第一次接触shp的人常踩同一个坑把“北京行政区划.shp”单独拷走到另一台电脑上打不开或者打开后只剩几何没有属性。这不是数据坏了而是Shapefile天生就是一组文件不是一个文件。一个完整的Shapefile至少包含三个文件再加上可选的投影和编码文件实际使用中最好整体管理。扩展名作用如果丢了会怎样.shp要素几何坐标打不开.shx几何索引负责要素顺序部分软件能打开但很卡.dbf属性表存adcode、name等字段只剩几何没有任何属性.prj坐标系与投影定义软件按默认坐标系猜容易错位.cpg属性表字符编码声明中文可能乱码需要猜测编码.dbf就是属性清晰问题的根源。它用dBase格式存储字段名长度上限是10个字符早期数据用拼音缩写做字段名就是这么来的。属性清晰的北京行政区划shp字段名一般不会是X1、X2这种简写而是adcode、name、level、parent、lng、lat、childrenNum这一组约定俗成的命名。拿到数据先看字段名是否可读就能判断这份数据是被人认真整理过还是直接从某个系统倒出来的。另一个容易被忽略的是.cpg文件它记录.dbf的字符编码。Shapefile格式本身没有强制规定属性表编码中文数据出现乱码是常态。很多“属性清晰”的版本会附带.cpg注明UTF-8或GBK这决定了后面用代码读取时该传什么encoding参数。如果你做的是工程而不只是在GIS软件里点两下一定要把这几个文件当成一个整体来管理放在同一个目录下统一打包不要单独复制其中某一个。2.2 坐标系先统一再谈属性CGCS2000、WGS84与投影坐标的选择属性清晰可以和坐标系割裂开看吗不能。如果prj信息丢失或写错再清晰的属性表也会在地图上错位。北京地区的行政边界数据最常见的坐标系有三类。第一类是CGCS2000高斯投影具体到北京往往是“CGCS2000 / 3-degree Gauss-Kruger CM 117E”中央经线取117°E单位是米适合做面积计算和精度要求较高的工程分析。第二类是WGS84经纬度单位是度适合直接输出给Web地图、GeoJSON和空间数据库。第三类是GCJ-02加密经纬度很多从在线服务取来的边界坐标属于这一类它相对WGS84做了偏移和卫星底图对不上。数据样式坐标值量级常见用途是否需要处理CGCS2000投影X约几十万到几百万Y约几百万本土工程分析、面积统计输出给前端时转经纬度WGS84经纬度经度115~117纬度39~41Web地图、GeoJSON可直接用GCJ-02经纬度经度115~117纬度39~41在线地图来源的边界与WGS84混用会偏移几百米用GIS软件打开一份没有.prj的shp时软件会默认拿WGS84去套。如果这份数据本来是米制投影坐标地图上的要素就会跑到海里去反过来如果经纬度数据被赋予了投影坐标系要素位置会挤压变形。这类问题在刚拿到数据时很难发现通常要叠加在线底图后才意识到错位看起来有点“玄学”。判断方法其实很直接看坐标值量级。经纬度坐标的范围应该在东经115到117度、北纬39到41度之间米制投影坐标的范围则是X从几十万到几百万、Y在几百万左右。如果几何范围不符合说明坐标系定义有问题需要重设prj再做转换。选数据时优先选带.prj且声明CGCS2000或WGS84的版本能省掉后面一大半排查时间。2.3 属性清晰到底怎么检查用ogrinfo五分钟巡视字段结构拿到一份北京行政区划shp后我建议先别急着扔进GIS里看先做一次字段结构体检。最省事的工具是GDAL自带的ogrinfo命令行一行命令就能输出图层要素数量、几何类型、坐标范围、字段列表。# 只读方式打开并输出概要信息-so表示不逐要素打印-al处理所有图层 ogrinfo -ro -so -al 北京行政区划.shp参数说明-ro是只读模式避免误操作改写数据-so是summary only只输出概要信息不会把几千个要素的几何全部打出来-al表示遍历所有图层。如果GDAL没有安装可以通过Python的gdal包获得命令行工具或者直接进入下一步的geopandas读取。一份典型的清晰属性表长这样字段名类型含义典型用途adcode字符串行政区划代码6位区县/9位街道/12位村居与业务表joinname字符串行政区名称地图标注level整数层级省、市、区县、街道按层级过滤parent字符串上级区划代码生成级联关系lng, lat双精度几何中心点坐标标签避让childrenNum整数下级要素数量校验数据是否完整用这张表去对照你的数据如果adcode缺失后面做行政区聚合就无从谈起如果level字段靠猜层级统计也不可信。“属性清晰”并不是字段多多益善而是字段语义明确、层级完整、代码版本一致。字段名就像一本字典决定了你后续写代码时是直接写gdf[adcode]还是得反复确认X1字段到底是什么。体检完字段如果字段合格再进入下一步的工程处理。3. 把“属性清晰”投入生产编码修复、新旧adcode对齐与join实操3.1 中文乱码并不等于文件损坏两种编码读取路径前面提到Shapefile的.dbf没有统一的编码元数据中文数据读取乱码几乎每个人都遇到过。处理乱码的第一原则不要认为文件坏了先检查读取端在用哪种编码解码。第一种路径是用GDAL的OGR_ENC环境变量让GDAL统一按指定编码读取dbf字段。import os import sys from osgeo import ogr # 指示GDAL用GBK解码dbf很多国产工具导出的shp都是这个编码 os.environ[OGR_ENC] GBK ogr.UseExceptions() ds ogr.Open(北京行政区划.shp, 0) if ds is None: sys.exit(打开失败确认路径与文件名) layer ds.GetLayer(0) defn layer.GetLayerDefn() for i in range(defn.GetFieldCount()): fld defn.GetFieldDefn(i) print(fld.GetName(), fld.GetType())这段代码的逻辑是先设置环境变量再打开数据循环打印字段名和类型。ogr.UseExceptions()的作用是把GDAL底层错误转换成Python异常方便定位路径问题。GetLayerDefn()获取图层结构定义不会读取全部要素速度很快。如果这里打印出的字段名仍然乱码再试把OGR_ENC改成UTF-8——有些数据源用UTF-8写入但.cpg缺失GDAL默认按GBK处理了。第二种路径是geopandas路线读取时显式指定encoding参数。import geopandas as gpd # 先按UTF-8尝试报UnicodeDecodeError就换gbk try: gdf gpd.read_file(北京行政区划.shp, encodingutf-8) except UnicodeDecodeError: gdf gpd.read_file(北京行政区划.shp, encodinggbk) # 验证关键字段是否可读 print(gdf[[adcode, name]].head())read_file会同时读取几何和.dbf属性参数encoding只影响属性表。这里用try/except做两级尝试比先用某个编码打开再确认乱码更省事。需要注意geopandas内部用的是Fiona读取环境变量的优先级高于read_file参数如果你同时在脚本里设置了OGR_ENCread_file的encoding可能不生效。建议在脚本开头统一管理编码策略要么全走环境变量要么全走参数。3.2 adcode对不上行政区划版本旧代码映射与再校验北京行政区划经历过多次调整不同年份导出的shpadcode可能相差一代。比如老代码里有已经撤销的区级代码新区划里已经没有它们了。拿业务表直接和最新shp做join这些老代码的记录会全部匹配不上留下一大堆name为空的坏数据。常见做法是维护一张新旧代码映射字典在join之前先把业务代码归一化。# 旧区划代码 - 现行区划代码示例映射实际以最新标准代码表为准 adcode_map { 110103: 110101, 110104: 110102, 110226: 110228, # 占位示例 } def normalize(code): code str(code).split(.)[0] # 去掉浮点尾巴 code (000000 code)[-6:] # 补齐6位区县代码 return adcode_map.get(code, code) # 命中映射则转换否则原样返回 # 应用到业务数据 orders[adcode_norm] orders[adcode].map(normalize)代码里的细节值得说明先把数值型代码转字符串去掉可能出现的“.0”后缀再右补零保证6位。区县代码是6位街道级是9位如果你处理的是街道级数据补齐逻辑要改成9位。字典映射只是兜底手段更可靠的是用标准行政区划代码表做全量映射而不是自己手写几条。手写字典适合快速验证长期维护不现实。映射完成后还要做一次双向校验一是统计映射后仍然匹配不上的adcode有多少二是查看这些未匹配代码是不是园区、开发区等功能区代码这类代码往往不纳入标准行政区划编码。用shp里的adcode集合反向筛查业务数据能很快定位脏数据来源。生产环境里我一般会把这份映射表独立成csv文件维护业务代码里只引路径不写死字典。3.3 join到行政区边界重复、类型、空值三个关卡把业务数据join到北京行政区划shp上听起来只是一次merge真正动手时要过三个关卡重复、类型、空值。关卡一是重复。如果shp里同一个adcode出现了两次比如某个区由多个多面子要素拼成直接merge会把业务数据按同一条代码复制多份统计结果被成倍放大。所以join前先确认adcode有没有重复。import pandas as pd import geopandas as gpd # 业务表读取时直接按字符串读adcode避免浮点数 orders pd.read_csv(订单表.csv, dtype{adcode: str}) shp gpd.read_file(北京行政区划.shp, encodinggbk) shp[adcode] shp[adcode].astype(str) # 关卡1检查shp里adcode是否重复 duplicated shp[adcode].duplicated().sum() print(重复adcode数量:, duplicated) assert duplicated 0, 存在重复区划代码先按level去重 # 关卡2类型统一后再merge merged orders.merge( shp[[adcode, name, geometry]], onadcode, howleft ) # 关卡3检查匹配率 print(merged[name].isna().mean())代码里两个关键点一是astype(str)统一类型如果shp的adcode是int64而orders里是stringmerge会匹配不上二是howleft保留订单全量再用name.isna()检查哪些代码没匹配上。如果shp本身通过了重复检查但匹配率仍然低就要回查业务表是不是混入了老代码回到3.2的映射步骤处理。空值的处理也有技巧。join完成后不能只看匹配率还要看匹配到的行政区名称个数是否符合预期。北京区级shp应该匹配出16个区如果匹配出18个不同name说明有代码版本混杂或功能区代码混进来了。这一层校验很多人不做结果地图上多出几个不存在的“区”统计口径全都对不上。属性清晰的shp在这里的价值会显现字段语义明确你才能一眼看出哪里多了、哪里少了。4. 北京行政区划shp使用避坑五类高频现象与修复套路4.1 中文乱码name字段全是乱字符图能画但没法标现象在GIS里打开边界形状正常但name字段显示成“???”或“æµ·æ·”等乱码地图无法标注导出图表时名称全是问号。原因dbf属性表实际以GBK编码写入读取端按UTF-8解码或者反过来。还有一种情况是.cpg文件存在但内容与实际编码不一致数据导出工具写错了编码声明。解决先看有没有.cpg文件有则按它的值读取没有则依次尝试UTF-8、GBK、GB18030。用geopandas的encoding参数或GDAL的OGR_ENC环境变量都行如果只是在GIS里看一眼也可以在软件里手动切换字符编码。不要直接去改dbf文件改错会丢属性。这条的经验是编码问题不影响几何所以最容易忽略但恰是“属性清晰”最容易翻车的点——几何是准的属性是乱的。4.2 adcode版本不一致业务表大量匹配不上现象join之后业务数据里有相当一部分adcode在shp中不存在匹配率只有六七成地图上一片空白。原因业务表里的区划代码是几年前的版本shp是新区划版本或者业务表包含开发区、功能区代码这些代码不在行政编码里。解决先建新旧代码映射再join。这里强调一个小习惯拿到业务表后先orders[adcode].nunique()看有多少不重复代码再对比shp里的adcode集合两个集合的差异才是真正要手工处理的量。如果差异占了一半不要手工映射直接用标准行政区划代码表做全量匹配。不要因为匹配率低就怀疑数据源很多时候只是版本问题。4.3 几何自相交与缝隙属性没问题空间分析却对不上现象做相邻区合并、面积统计、栅格叠加时结果比预期大或出现异常值几何检查提示自相交。原因shp在数字化或裁剪拼接过程中产生了自相交、重叠、缝隙。属性表再干净几何拓扑有问题空间操作就会基于错误的边界。自相交要素在视觉上往往看不出来因为折返点很小。解决先备份原始几何再统一修复。from shapely.validation import make_valid import geopandas as gpd gdf gpd.read_file(北京行政区划.shp, encodinggbk) gdf[geometry] gdf[geometry].map(make_valid)make_valid会对每个几何做拓扑修复处理自相交和小缺口。修复后检查要素数量和面积范围是否符合北京实际情况如果面积数值很离谱说明投影坐标系单位有问题。之后再做任何空间操作都建议先做一次拓扑检查。这个坑踩一次就知道修复方法基本就是这一条但能提前发现的人不多。4.4 level字段与adcode自相矛盾层级统计不可信现象shp里level字段标记为“区县”但adcode长度是9位其实是街道级或者childrenNum统计的下级数量与实际要素数对不上。原因多个来源的数据拼接后底层字段没有同步更新。单独看每个字段都有值放在一起就矛盾。解决不要信任level字段以adcode长度为准重新推断层级。adcode长度6位是区县9位是街道乡镇12位是村居。def infer_level(code: str) - str: n len(code) if n 6: return 区县 if n 9: return 街道乡镇 if n 12: return 村居 return 未知 gdf[level_ok] gdf[adcode].map(infer_level) print(gdf[level_ok].value_counts())这个检查通常能暴露数据集的真实范围。很多网上标着“北京行政区划”的shp其实是16个区级边界但level字段可能标得五花八门。重新推断后再决定要不要保留原level字段。层级是后续做下钻地图的基础这里错了整张图层都不可用。属性清晰的数据在这一点上很有优势adcode和level能互相印证而不是互相打架。4.5 坐标系错位差几百米的“看起来没毛病”最坑现象把shp叠加到在线地图上边界整体偏移或者完全不在北京区域。原因最常见两种情况——shp缺少.prj读取工具默认按WGS84套数据是GCJ-02加密坐标被当成WGS84使用后整体偏移几百米。前者的错位往往几百到上千公里一眼能看见后者只有几百米小比例尺下不明显叠加道路或POI时就会露馅。解决先确认坐标系看坐标量级然后重设正确的crs再转成目标坐标。import geopandas as gpd gdf gpd.read_file(北京行政区划.shp) # 坐标值量级为米制时先声明正确的投影坐标系 gdf gdf.set_crs(EPSG:4547) # CGCS2000 3度带中央经线117E gdf_wgs84 gdf.to_crs(EPSG:4326) # 转成Web常用的经纬度这里set_crs只是声明当前坐标系不改变坐标值to_crs才做真正的投影转换。如果不确定原始坐标系先用图层范围反推米制投影的X坐标通常有几十万到几百万的量级经纬度则只有两位整数。不要直接做四参数或七参数变换那需要已知控制点对一般使用场景来说选用CGCS2000版本的shp比做参数转换靠谱得多。5. 在属性清晰的基础上再进一步层级校验与按区切片导出5.1 用属性字段拼出层级链并校验完整性数据进入生产环境之前我习惯做一次层级链校验。所谓层级链就是从adcode长度和parent字段还原出“省-市-区-街道”的上下级关系再和字段声明对比。代码很短import geopandas as gpd gdf gpd.read_file(北京行政区划.shp, encodingutf-8) gdf[adcode] gdf[adcode].astype(str) gdf[level_inferred] gdf[adcode].str.len().map( {6: 区级, 9: 街道级, 12: 村居级} ) # 按层级统计要素数区级应为16个北京市辖区数量 print(gdf[level_inferred].value_counts())这个校验的价值在于拿到任何shp都能在三十秒内知道它到底覆盖到哪一层。很多所谓“北京行政区划shp”下载下来发现只有区级但业务需要街道级早点发现就不用浪费时间整理。如果childrenNum字段也在可以顺带做个交叉验证每个区下面的街道数量通常稳定在几位到二十位之间出现过大的值说明层级判定有问题。5.2 按区导出GeoJSON切片前端地图不再卡顿最后一个常用技巧是把区级要素切片输出。前端加载全量shp或一次性转出的综合GeoJSON时数据量一大交互就卡把每个区单独导出为一个GeoJSON加载体验会好很多。import geopandas as gpd import os os.makedirs(slices, exist_okTrue) gdf gpd.read_file(北京行政区划.shp, encodingutf-8) county gdf[gdf[adcode].str.len() 6].copy() for _, row in county.iterrows(): one gpd.GeoDataFrame([row], crsEPSG:4326) one.to_file( fslices/{row[adcode]}.geojson, driverGeoJSON, encodingutf-8 )代码逻辑先按adcode长度过滤出6位区级要素然后逐条构造单要素GeoDataFrame并导出。注意to_file里driver必须写成GeoJSON否则geopandas可能按shapefile处理crs建议统一成EPSG:4326省得前端还要做投影转换。切出来后每个区一个文件单个文件通常只有几百KB地图加载速度会明显改善。做下钻地图时这就是一份属性清晰的数据在工程端的“最后一公里”。我早期做行政区下钻地图时为了让“属性清晰”名副其实把原始shp里用不到的字段全部删掉只留adcode、name和geometry。结果后来要做行政区联查没有parent字段不得不重新回去找原始数据走了不少弯路。那之后我养成了一个习惯属性清晰不等于字段越少越好层级代码和上级代码这类关键字段必须保留它们才是让一份shp从“能画图”变成“能分析”的分水岭。希望帮到你。本文还有配套的精品资源点击获取