深圳小区AOI数据集制作全流程：SHP矢量与人口估算实战

简介：本资源为2024年深圳全市小区级AOI（Area of Interest）矢量数据集，面向城市规划师、GIS研究人员、智慧城市开发者及地理信息专业学习者，用于支撑人口空间分布分析、社区设施配置评估、交通需求预测等精细化城市研究场景。数据以标准Shapefile格式组织，共7个核心文件：.shp与.shx存储小区边界几何信息，.dbf承载小区名称、常住人口数量等关键属性，.prj定义坐标系（CGCS2000），.sbn/.sbx为空间索引提升查询效率，.shp.xml提供元数据说明，整体压缩包仅980KB，轻量易用。已有109人下载学习，数据覆盖完整、结构规范，开箱即用于QGIS或ArcGIS平台，可直接开展空间叠加、密度热力图生成、人口—设施匹配度计算等实操分析，是开展深圳本地化空间治理研究的可靠基础底图。 做社区商业分析的时候，我最头疼的一件事就是“找不到合适的小区矢量面”。POI（兴趣点）数据满大街都是，但一个点代表不了一个小区的真实边界，更承载不了楼栋数、户数、人口估算这类属性。2024年我花了不少业余时间，把深圳的小区AOI（Area of Interest，兴趣面）整理成了一套带属性表的SHP矢量数据集，里面包含小区名称、行政分区、人口估算等字段。这篇文章就把这套数据的制作思路、字段逻辑、坐标处理、常见翻车点全部摊开来讲，希望能给正在做城市分析、商业选址或者GIS数据处理的朋友一些参考。

这套数据本身是从公开数据源、开放地图影像和房产公示信息三个维度交叉整理出来的，不是官方测绘成果，精度上肯定做不到“厘米级”，但对于区级、街道级甚至社区级的研究和业务场景，已经足够用了。适合的人群也很明确：做城市研究的、搞商业智能的、做通信基站覆盖评估的、还有对GIS感兴趣想练手的同学，都能从这套数据的处理过程中获得一点启发。

1. 为什么小区AOI比POI难搞：这份数据的定位

先聊清楚一个基本概念。AOI（Area of Interest）指的是“兴趣面”，对应的是一个有边界、有面积的地理对象。POI（Point of Interest）是“兴趣点”，就是一个坐标点。你去任何一家地图平台，搜“XX花园”，返回的基本都是POI点。但这个花园到底东到哪里、西到哪里，跟隔壁小区边界怎么切分，POI完全回答不了。真正要做空间分析，比如统计小区周边500米内有多少便利店，或者算某个片区的居住密度，就必须落到面上。

深圳的情况比较特殊，小区形态极其复杂。关内（福田、罗湖、南山、盐田）有很多老商品房小区，地块小、楼栋密；关外（宝安、龙岗、龙华、光明、坪山）既有大型居住片区，也有大量城中村和工业区宿舍混杂。很多“小区”在物理上并没有围墙，边界模糊；有些小区和商业综合体共用地下车库，地上边界还交错。这就导致网上能下载到的小区数据要么是点位，要么是粗颗粒度的街道轮廓，真正好用的小区级AOI几乎没有现成的。市面上有商业公司卖这类数据，但价格不菲，而且授权条款往往限定了使用范围。

所以我当时给自己定的目标是：不追求测绘级精度，做一份“业务可用、字段丰富、时间口径统一”的深圳小区AOI数据集。精度控制在院落或地块级别，保证相邻小区面不重叠、不出现明显裂隙，属性字段至少包含小区名称、所在行政区、街道、楼栋数、建筑面积和估算人口。最终交付格式是SHP，因为SHP是通用性最好的矢量格式，ArcGIS、QGIS、FME、Python的GeoPandas都能直接读写，后续转GeoJSON、转3D Tiles也方便。

这里要提醒一句：所有数据源都来自公开渠道，包括公共地图服务的开放接口、公开的房产信息、公开的影像底图。整理过程中我做了大量的人工校对，但数据版权归属原始来源，如果要商用，请务必确认授权链条，不要直接拿去卖钱。技术方法和流程可以随便参考，数据本身要谨慎对待。

2. 数据底座：坐标系、数据源与边界处理顺序

做AOI数据集，第一步不是画边界，而是定坐标系。坐标系错了，后面所有分析都是白做。国内做地图相关数据，最常遇到的就是WGS84、GCJ02和CGCS2000这几个坐标系之间的纠葛。

2.1 坐标系选择：WGS84还是GCJ02，这是个哲学问题

WGS84是GPS使用的全球坐标系统，网络地图服务在国内实际返回的坐标通常经过加密偏移，也就是GCJ02，俗称“火星坐标”。直接把GCJ02的坐标当成WGS84用，叠加OpenStreetMap或者遥感影像会偏移几百米，在深圳这种高密度城市里，几百米足够从一个小区偏到另一个小区。

我的处理原则是：所有原始数据先统一进入WGS84地理坐标系（EPSG:4326）进行存储和编辑，分析时按需投影到Web Mercator（EPSG:3857）或深圳本地的高斯投影带。为什么不用GCJ02作为存储坐标？因为GCJ02是一种非标准的加密坐标系，很多GIS工具不原生支持，做几何运算（比如面积计算、缓冲区分析）时容易出幺蛾子。而且一旦数据要跟GPS采集的轨迹、跟OSM数据叠加，GCJ02会让你怀疑人生。

具体操作上，如果从公开地图接口拿到的坐标是GCJ02，我会先用坐标转换库转成WGS84再入库，转换时保留5位小数，大约对应1米左右的精度，对这个数据集的需求来说够了。

提示：如果你在网上下载到的SHP文件坐标偏移明显，先用QGIS加载Google卫星影像做视觉对比，确认偏移方向再决定要不要做坐标纠偏。不要一上来就无脑套转换公式。

2.2 数据源拆解：从公开数据到现状核对

数据源决定了AOI边界的下限。我最终采取了“先粗后精、多源交叉”的路线。

第一步，用公开的建筑物轮廓和小区范围数据作为底图。这个底图来源要说明清楚，很多地图开放平台提供“行政区划”或“区域范围”数据接口，但粒度多数到区县或街道，小区级需要自己拼接。深圳部分行政区在规划公示网站公开过度地块图则，这些图则带用地性质，能从里面抠出二类居住用地，再结合楼栋轮廓数据，初步生成小区边界。

第二步，结合卫星影像和街景进行人工校对。这一步虽然费时间，但必须做。光看用地红线不够，因为实际围墙、围栏、院落边界才是居民感知的“小区边界”。比如一个商品房小区和一片城中村相邻，规划图则上可能都是居住用地，但物理边界可能被一条内部道路切得清清楚楚。影像上可以很清楚看到建筑布局密度和路网，人工勾边的效率其实比想象中高，因为小区边界大多是规则的多边形，不需要精细到逐栋楼。

第三步，用公开的房产数据完善属性。包括小区名称、别名、物业公司、建筑年代、楼栋数、总户数、容积率等信息。这些数据在房产类公开网页都能查到，但需要做名称匹配。匹配是整套流程里最费头发的一步，后面专门说。

2.3 边界处理顺序：先用渔网分割做质量抽检

这里插一个我的土办法。当一个区的小区AOI画完之后，我不会立刻去做属性匹配，而是先在QGIS里生成一个500米×500米的渔网（网格），用渔网去查每个格子里面有没有“空白区域”——就是既没有小区AOI，也没有河流、绿地、道路、工业用地等其它面要素的区域。如果渔网格子里出现了大面积空白，说明这个片区要么是城中村没被划进来，要么是新建小区漏了。这个方法比人眼盯屏幕可靠得多，特别是处理面积较大的行政区时，效率翻倍。

渔网分割这个功能在QGIS里叫“Create Grid”，在ArcGIS里叫“Create Fishnet”。如果你手头有街道边界或者社区边界，也可以反过来先把深圳切成若干个街道片区，每个片区独立检查AOI覆盖率。覆盖率低于90%的片区直接标记为“数据待补”，后面集中人工复核。

3. SHP生产全流程：字段设计、编码修复与几何检查

当你把边界画好、属性填好，接下来就是把数据导出成SHP。这个过程看似简单，实际上翻车率极高。字段名被截断、中文乱码、几何自相交、面积计算出错……这些问题我全踩过，下面逐一拆解。

3.1 字段设计：别把SHP当成数据库用

SHP文件的字段名有历史包袱——DBF格式单字段名最长10个字节，中文在GBK编码下占2个字节，UTF-8下更占3个字节。很多新手辛辛苦苦在GeoPackage或者PostGIS里建好了字段，导出SHP之后发现字段名被截断成一堆字符，就是因为没提前规划好。

我最终确定的字段结构如下：

注意，字段名全部用英文，避免中文名在跨平台拷贝时出现各种编码问题；字段类型尽量用String和Integer、Double，不要用Date类型做复杂日期运算。SHP的Date字段在不同软件里读取经常不一致，我用update_date存成字符串“20241201”格式，反而更好用。

3.2 编码修复：为什么你打开的SHP字段名全是乱码

SHP属性表的编码问题跟.cpg文件直接相关。.cpg文件记录的是DBF文件的字符编码，比如UTF-8或者GBK。如果你在ArcGIS里用默认选项导出SHP，ArcGIS通常会把.cpg写成系统语言对应的编码（中文Windows下常见GBK）；如果在QGIS里导出，默认多半是UTF-8。数据一旦交换到另一个软件，乱码就来了。

这里有个常见的坑：网上很多SHP文件没有.cpg文件，因为早期工具导出时不生成这个文件。当你用ArcGIS打开一个没有.cpg的SHP，它按本地语言猜编码，中文Windows就按GBK读，如果实际是UTF-8就乱码；QGIS遇到没有.cpg的SHP，则有可能按UTF-8读，如果实际是GBK也会乱码。

解决办法分两步。第一步，尽量在导出SHP的时候主动指定编码。QGIS里导出SHP时，在“Layer Options”里把ENCODING选为“UTF-8”，同时勾选“Save styles to DB”旁边的几何选项不影响编码。第二步，如果拿到手的是已经乱码的文件，用Notepad++打开配套的DBF文件看编码太麻烦，直接推荐用QGIS重新指定编码加载：数据源管理器里选“编码”为“GBK”或“UTF-8”，哪个显示正常就用哪个，然后再另存为新的SHP并强制写成UTF-8。

注意：如果你后续要把SHP批量转成CAD，或者导入SU（SketchUp）做三维建模，建议转换前先把属性表里的中文字段全部清理一遍。CAD和SU对DBF编码的支持更差，经常出现导入后中文乱码、字段错位。我的做法是先导出成DXF，再接一个属性表做关联，而不是直接“SHP转CAD”一把梭。

3.3 几何检查：自相交、缝隙与重叠一个都不能少

SHP的几何问题不会让你导出失败，但会让后续所有空间分析结果失真。我常用的几何检查流程是：

1. 在QGIS里用“Check Geometries”插件扫描全部要素，修复自相交、环方向错误、重复节点；
2. 用“Fix Geometries”（对应ArcGIS的Repair Geometry）做批量修复；
3. 对相邻小区做拓扑检查，重点看重叠和缝隙。

重叠问题在AOI数据里最常见。深圳有很多“一地多权”的情况：一个小区底下是商业裙楼，上面是住宅塔楼，房产网站上可能登记了两个不同名字的“小区”，画AOI的时候就容易重叠。还有一些开发商宣传名和备案名不同，导致同一个实际范围被画成了两个面。这个时候需要花时间做合并和取舍，不能靠程序自动解决，只能人工判断哪个名字是居民实际使用的，哪个是规划备案名。

缝隙问题同样麻烦。两条相邻小区的边界如果都没对齐到同一条路的中线，中间会出现一条细细的空白带。这个空白带通常只有一两米宽，肉眼在屏幕上不容易发现，但在叠加分析的时候，它会导致点落在“无主区域”，影响小区覆盖率的统计。我处理缝隙的办法是：以道路中心线或围墙线作为天然边界，在勾边阶段就尽量对齐；如果后期检查发现缝隙，直接用“Eliminate Selected Polygons”把缝隙合并到相邻面中。

4. 人口数量字段：从楼栋参数到户数推算的不完美解

做这套数据集时，最费心思的不是画边界，而是人口数量这个字段。小区人口没有官方公开数据，常规做法是通过“总户数 × 户均人口”来估算。但这里每一步都有误差，而且误差会叠加，搞得不好就是从一个不精确的数字跳到一个更不精确的数字。

4.1 楼栋参数获取：公开数据的上限和下限

总户数其实是最难拿到的公开数据。房产平台上很多小区的“总户数”是开盘规划数，可能跟实际入住数差很多。更可靠的办法是用“楼栋数 × 楼层数 × 每层户数”反推。深圳的商品房小区，标准层户型通常是2到8户不等，塔楼每层4到6户比较常见，板楼每层2到3户。拿楼栋数乘以平均每栋户数，再乘以楼栋单元数修正，能得到一个粗略的总户数。

如果碰到找不到楼栋参数的小区，我还有一个下位估算方案：用建筑面积除以平均户型面积。深圳商品房的平均户型面积大约在80到90平米，建筑面积小于总户数不可得的时候，可以用“建筑面积÷85”作为总户数估计。这个方法对有明确建筑面积披露的小区比较有效。但注意，这个方法对大面积豪宅小区误差极大，别墅区一套房动辄200平米以上，直接按85平米算会把人口严重高估。

4.2 户均人口怎么定：不要照搬全国平均

户均人口是另一个误差大头。全国第七次人口普查数据显示，全国平均家庭户规模约为2.6人/户，深圳作为移民城市，户籍人口和常住人口的结构跟全国并不一样。根据深圳统计年鉴和各类公开研究，深圳的家庭户均规模大约在2.3到2.5人之间。但不同片区差异很大，福田、南山的白领社区户均人口往往偏低，可能只有2.0到2.2人；龙岗、宝安的大型居住片区家庭结构更复杂，可能有2.5到2.8人。

我的做法是给每个片区设定一个“户均人口系数”，不搞一刀切。具体操作是：先按街道拆分小区，再给每个街道赋系数，最后把估算结果跟街道公开的常住人口总量做一次对照，看偏差是否在合理范围。如果某个街道的小区估算人口总和明显偏离街道总人口，就回头检查系数设置和小区覆盖率，而不是盲目调到“看起来一致”。

4.3 估算公式与校验：宁可有误差，不可有系统性偏差

最终我采用的人口估算公式是：

估算人口 = 总户数 × 户均人口系数 × 入住率修正

入住率修正系数通常取0.85到0.95。深圳很多小区存在明显的“买而不入”现象，特别是投资客集中的片区，空置率不低。开发商宣传的“售罄”和路灯亮灯率完全不是一回事。入住率修正系数不能用一个全局固定值，建议根据小区建成年代和片区活跃度调整，新盘交付前两年入住率低，老小区入住率高。

校验的时候，我习惯把估算人口和街道层级的人口密度做对比。举个例子，南山区某街道常住人口约20万，街道内小区AOI覆盖了大约15万估算人口，加上城中村、宿舍和未覆盖的零散居住区，整体数量级对得上。如果出现某个街道的小区估算人口比街道总人口还高，那数据一定有问题，要么小区AOI重叠严重，要么户均人口系数定得太高。这种“总量守恒”的校验方法不需要精确到小数，但能帮你迅速发现系统性偏差。

还有一个容易忽略的点：人口字段建议单独存放在一个属性字段里，不要和“总户数”挤在一起。原因很简单，总户数是相对稳定的规划指标，而人口估算会随年份和算法改变。以后你更新算法，只需要重算人口字段，不需要动其它几何和属性数据。

5. 使用过程中的坑：重叠、时效和属性缺失的处理方案

数据做完之后，我又用这套数据集跑了好几个真实项目，结果发现实际使用中的坑比制作时还多。下面列几个典型案例，都是踩过之后才总结出来的。

5.1 AOI重叠：多个“小区”共用一个物理地块

深圳有个著名现象——同一个地块，商品房住宅区和底商裙楼写的是不同小区名。我数据里有个案例，某楼盘住宅部分叫“XX花园”，但底商部分在另一个平台显示为“XX商业中心”，两个AOI面重叠了整整一个街坊。做统计时，这个区域的人口被算了两次，商业设施POI却被算了两次。处理方法是建立“父子关系”字段，或者在做统计时按优先级去重。最简单的方法是先做拓扑检查，把重叠面积超过阈值的小区挑出来，手动标记“合并面”或“剔除冗余面”。

如果你用的是ArcGIS Pro，想把一个大的AOI按街道或社区边界拆分成多个小面，可以用“Split by Attributes”或者“Intersect”工具。但要注意拆分后属性表会复制，重叠部分会重复计算面积，做统计分析前要格外小心。

5.2 时效性：2024年的数据等不到2025年的新盘

数据集标注“2024”，意味着它的时间口径停留在2024年。深圳每年都有新盘交付，也有旧改拆迁，用老数据做现状分析时一定要加一个“数据截止日期”的判断。我在实际项目里遇到过：用这套AOI数据做片区商业规划，结果分析范围内有一个2024年底刚交付的超大型社区，完全不在数据里，整个片区的居住人口和商业需求被严重低估。

因此，使用这类数据前，建议先把当年的公开新房成交列表、交付预告拿来做一轮增量更新。这一步人工成本不算高，但能显著提高数据集在时效敏感型分析中的可靠性。

5.3 属性缺失：城中村和宿舍区怎么处理

深圳相当比例的人口住在城中村和园区宿舍，这两类区域严格来说不是“商品房小区”，但承载了巨量人口。如果数据集只收录正规小区，那用它估算片区人口会严重偏低。我的处理方式是：城中村按“社区”或“股份公司”地块范围单独做一个分类编码（比如把type字段设为“urban_village”），宿舍区则归入“industrial_dormitory”。这样在分析时，你可以根据业务需要选择“只看商品房小区”或“包含城中村与宿舍”。

属性缺失还体现在老小区上。很多2000年前的楼盘，在网上翻烂也找不到楼栋数和总户数。碰到这种情况，我宁可把字段设为空，也不要随手填一个“看起来合理”的数值。因为估算字段的空缺是可以说明的，但错误的数值会误导所有下游分析。src_level字段就是专门用来标记这类“低置信度”记录的，数值越低，说明数据来源越不可靠。

5.4 SHP文件的打开兼容性：从ArcGIS到QGIS再到Python

最后说一个使用层的老问题。很多刚接触GIS的人拿着SHP文件不知道该怎么打开。最简单的路径是：QGIS免费开源，打开SHP直接拖拽；ArcGIS需要用ArcMap或ArcGIS Pro的“Add Data”添加；Python环境下用GeoPandas十几行代码就能读。如果只是快速看一眼属性表，用Excel直接打开DBF文件也行，但要注意编码问题。我这里放一个用GeoPandas读取SHP的示例代码：

import geopandas as gpd # 读取SHP文件 gdf = gpd.read_file('shenzhen_aoi_2024.shp', encoding='utf-8') # 查看字段信息 print(gdf.columns.tolist()) print(gdf.head()) # 计算面积（前提：坐标系是地理坐标系，需要先投影） gdf_proj = gdf.to_crs('EPSG:3857') gdf['area_m2'] = gdf_proj.geometry.area # 按行政区统计估算人口 pop_by_district = gdf.groupby('district')['pop_est'].sum() print(pop_by_district)

这段代码很朴素，但能解决80%的日常数据查看和统计分析需求。如果要把SHP转成其他格式，GeoPandas也支持to_file输出GeoJSON、GeoPackage，转换3D Tiles则需要借助其他工具链，这里先不展开。

6. 这套数据可以怎么用：几个实际跑过的场景

数据做出来不是用来躺硬盘的。我先后拿这套深圳小区AOI数据跑过几个不同类型的分析，每个场景的侧重点都不一样，分享出来供你参考。

6.1 片区人口密度热力：从小区尺度看城市

传统的街道级人口分布图，在深圳这种街道面积差异极大的地方十分粗糙。把小区AOI人口估算值做成热力图或者按面着色的分级图，可以清楚看到人口高密度区域并不是均匀分布在“市中心”，而是集中在大型居住组团边缘。比如宝安西乡、龙华民治这些片区，小区AOI又密又大，估算人口远超传统商圈核心区。这种尺度的认知对比，对于商业选址和公共服务设施规划都很有价值。

6.2 15分钟生活圈评估：AOI+路网+POI的联动

做15分钟生活圈评估时，AOI是起点。以每个小区AOI的几何中心（或加权人口中心）为圆心，结合真实的城市路网做等时圈分析，再统计等时圈内的菜市场、学校、医院、公园等POI数量。如果没有小区AOI，这个分析只能退化成按网格做，结果会差很多。深圳部分区域的社区配套评估，用AOI做出来之后，能很直观看到哪些小区是“配套洼池”。

6.3 商业选址辅助：人口结构决定业态

给一个连锁药店品牌做深圳区域拓展分析时，我用了这套数据里的小区人口估算字段，结合小区均价和建筑年代做聚类，把小区分成“高密度刚需型”“中密度改善型”“低密度高端型”三类。不同类型的社区适合的药店类型、营业时间和SKU结构都不一样。比如“老年人占比高的小区”在属性上往往表现为建成年代早、楼栋数多、容积率高，这些信息在AOI边界里是看不出来的，但通过字段关联之后就能落地执行。

6.4 通信基站覆盖评估：AOI是用户分布的高质量先验

通信行业的覆盖评估，原本主要靠栅格化人口数据。但栅格数据的粒度是100米×100米，放到城市里往往把一个街区的人口全部摊平。如果用小区AOI叠加基站覆盖范围，能更精确地估算出某个扇区下有多少“潜在用户”。这个场景下，AOI的边界精度要求不高，但小区名称和人口估算字段特别重要，因为后续要跟运营商的话务统计做关联分析。

之前还有一个朋友问要怎么把SHP转成3D Tiles做三维可视化，我的建议是先转成GeoJSON，再通过相关工具链切片。AOI作为底层面，叠加建筑白模之后，可视化的效果很好，特别是做城市更新项目汇报的时候，能一眼看懂现状建筑密度和人口承载关系。

6.5 社会治理与应急响应：AOI数据作为“最小管理单元”

街道和社区一级的管理者最头疼的问题之一，是“底数不清”。网格化管理虽然精细，但网格边界和物理小区边界经常不一致。小区AOI可以作为“最小管理单元”的一种补充，把一个网格里的人口估算和房屋数据落到具体小区面上，发通知、做排查、组织核酸、派发物资的时候都能直接定位到具体小区，比凭经验找人靠谱得多。当然，这个场景对数据的准确性和时效性要求很高，必须配合底数摸排动态更新，不能拿一年前的数据硬用。

7. 关于进一步扩展和处理的一些个人经验

数据集做到这个程度，其实只是第一步。真正把它变成好用的工具，还需要围绕它搭一套更新和维护机制。这里分享几点我自己的体会。

第一，SHP不是唯一交付形态。虽然SHP是通用标准，但日常维护和更新时，我更推荐用GeoPackage或者PostGIS。GeoPackage支持更多的字段类型、没有字段名长度限制、也支持空间索引，一个文件搞定所有图层，省去SHP那一堆配套文件的麻烦。SHP只在对外数据交换时导出。每次导出SHP前，我都会用脚本自动检查一遍字段名长度、编码方式、几何有效性，确保交给别人的数据不出基础性问题。

第二，批量处理时尽量脚本化。比如同时要处理几百个小区的属性匹配，手动操作显然不现实。我习惯用Python写一个匹配脚本：先用小区名称做模糊匹配，再用坐标距离做二次校验。比如某个小区在房产平台上叫“XX家园”，在地图服务里叫“XX家园东区”，名称相似度很高但坐标有几十米偏差。程序会把这些“疑似匹配”的候选对列出来，人工确认一次后，剩下的还是全自动处理。这个流程里面，最怕的是把两个位置上接近但完全不同的“同名小区”合并，所以坐标校验这步不能省。

第三，数据质量分级很重要。不管怎么样画AOI、填属性，都不可避免地存在个别位置的边界不是特别准确、个别小区的人口估算偏差偏大。我在交付数据的时候，一定要附一个README文件，里面写清楚每个字段的来源和精度说明，把“不确定”这个事摆在台面上。这比让用户自己去猜哪些能用哪些不能用要负责任得多。

第四，以后再做类似数据集，我会优先考虑“众包审核+定期更新”的模式。单个个人或小团队想把整个深圳的小区AOI做成测绘级精度，投入产出比很低。但如果你愿意把数据作为一个开放性项目，让更多人参与校对和更新，数据质量反而会越滚越好。深圳的小区还在不断新建和更新，这份数据2024年能用，2025年就需要做一轮大更新。数据治理本来就是长期投入，不是一次性交付。

最后再讲一个小技巧，也是我踩过几次坑之后总结出来的：不管数据做得多完善，使用前一定要做一次“空间连接自检”。把AOI面层和点位层做一个空间连接，检查每一个小区面里面是否至少有一个对应的POI点。如果一个小区面里连一个POI点都没有，极有可能是边界画错了、坐标偏移了，或者属性匹配出了问题。这个自检方法不需要高级算法，一个最简单的Intersect操作就能跑完，成本极低，但能帮你拦住80%的低级错误。

做数据这件事，没有绝对的完美，只有持续的迭代和校准。希望这篇文章能给正在跟SHP、AOI较劲的你一点参考。

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