企业官网建设流程全解析

简介：一份面向基础地理信息专业人员与技术管理人员的技术规程，聚焦1∶500、1∶1 000、1∶2 000比例尺基础地理信息要素数据向基础地理实体数据转换的标准化流程，可服务于新型基础测绘与实景三维中国建设，助力提升地理实体数据生产效率与成果质量。内容系统覆盖技术规程范围、引用文件、术语定义、基本要求、作业流程、源数据收集与分析、预处理、映射转换、语义化处理、质量控制及成果归档等环节，并针对时空基准、数据格式、精度与粒度要求、元数据要求等给出明确规范，为二维基础地理实体数据转换提供可操作的技术依据。压缩包内含1个PDF文档，大小约924KB，便于直接阅读与对照实施。目前已有204人学习浏览，适合承担基础地理实体生产、质检或项目管理工作的读者参考使用。

1. 规程背后的转换逻辑：为什么 1∶500 要素数据要变成“实体”

传统的大比例尺基础地理信息要素数据按图幅组织，一条路被图廓切断存在多个图幅里，一栋房子跨两幅图就被画成两个要素；而基础地理实体数据按“现实世界对象”组织，一个房子只有一个唯一标识，位置、属性、关系围绕同一个身份展开。1∶500、1∶1 000、1∶2 000基础地理信息要素数据转换生产基础地理实体数据技术规程，要解决的正是“按图幅的要素”向“现实世界的实体”重组的成套方法问题。

过去管的是图上的线、面、注记，现在管的是这座房子、这条路、这片水域本身。实体数据要求每栋房屋、每条道路具备可识别、不重复的身份编码，空间跨图幅连续，属性上统一分类并记录生命周期。这个转变不是换个字段名那么简单，源数据处理、实体归并、编码赋码、属性映射、质量检查整套流程都要重新设计。

下面按落地顺序拆开说：数据怎么预处理，跨图幅实体怎么合并，标识码按什么规则赋，属性映射表怎么建，质检哪些坑最常出，以及怎么让整套转换流程可回溯。适合手里已有大比例尺要素成果、要转实体库的数据生产人员，以及正在规划实体模型的数据平台设计人员。

2. 转换前的实体建模：先把“什么是实体”定死，再谈数据

2.1 源数据合规检查：坐标系统、图幅接边与图层完整性

开工前先花半天把“数学基础”定死。1∶500、1∶1 000、1∶2 000城镇数据常用的坐标系并不统一，有的成果是地方坐标系，有的历史更新图幅混用不同中央经线。直接用错误坐标的数据去构建实体，后续实体融合、实体编码全部白做。我一般会先汇总全部图幅的元数据，检查平面坐标系统、高程基准是否一致，再把图幅接边关系打印出来核对。

常用的检查命令是 OGR 工具，第一步只读元数据不改数据。下面给一个可复制的示例：

# 1) 查看每个图幅的坐标系统和范围，核对数学基础 ogrinfo -al -so -q 500_tile.gdb | grep -E "Layer SRS|Extent" # 2) 统一重投影到 CGCS2000，按本区中央经线选 3 度带 ogr2ogr -t_srs "EPSG:4539" -overwrite merge_2000.shp 500_tile.gdb

-al -so表示只读取图层元数据不遍历要素；-t_srs指定目标坐标系，EPSG 编码不能照抄，要按所在行政区中央经线选择，我这里用的是中央经线 117°E 的示例。所有图幅统一重投影后再拼接，而不是边拼边转，否则接边处容易出现亚米级错位，直接拉大后续实体合并误差。

坐标系统之外，更要命的是图幅接边质量。相邻图幅里同一栋房屋的围墙边线经常有几厘米到几十厘米的错位；道路边线跨图幅后会形成搭接或分离。处理办法是先做图幅边缘检查，统计图廓两侧 5 米范围内悬挂线、重复面、碎面的数量，再按分幅边界裁剪重叠部分。不要依赖人工目视，一定要出检查报告，问题数据返修完成后再进入实体转换。

常用图层的完整性检查也要提前做。建筑、道路边线、道路中心线、水系、植被、境界、管线点线等图层有缺失，或者属性字段大面积空值，都需要在转换前暴露出来。建议建一张检查表，把每个图层应有的字段、允许空值比例写清楚，转换前扫一遍。

这一步尽量做成脚本自动输出报告，每批次数据都跑一遍，不要凭感觉认为“上一批没问题这批就安全”。

2.2 实体类型的划分原则：把哪些要素归成同一实体

很多团队把实体转换理解为“给每个要素加个编码”，这是最大的误区。同一个现实世界对象在图库中可能被表达为多个要素：一栋楼有主体面、阳台面、雨棚面，跨图幅还有两半；一条道路有路面边线、中心线、分隔带，分别在不同图层。实体模型要回答的是：这些要素什么时候归并成一个实体，什么时候保持独立。

先分大类。大比例尺实体一般按建筑、道路、水系、境界、植被、地貌、管线、独立设施来划分。不同大类的空间表达方式也要定死：建筑通常采用面实体，道路可以是路面实体加中心线实体，水系按双线河还是单线河决定用面还是线，井盖、灯杆这类独立设施用点实体。

大类定了还不够，同一大类下还要定“聚合粒度”。我给一个实操判断原则：同一物理对象、空间上连续、属性上同类，则归一个实体；若中间被物理间隔断开，或者属性发生实质变化，则拆成多个实体。举例来说，同一栋楼的主体与阳台连廊相接，合并成一个建筑实体；两栋楼之间只是间距很窄，但没有任何结构连接，不能因为距离近就合并。

复合实体也要提前约定。桥梁在要素库里通常是桥面、桥墩、引道多个图层，转换时常见做法是把桥梁主体作为一个实体，护栏和桥墩作为附属关系挂接，而不是拆成几十个独立实体。这类建模决策必须写在项目方案里，统一执行，不能靠作业员各自发挥。

2.3 实体属性模型与标识码结构设计（先于生产确定）

实体编码是整个实体库的根。编码结构设计错了，后面前期建库、增量更新全要推倒重来。1∶500、1∶1 000、1∶2 000 成果通常按区县组织，实体编码一般包含行政区划代码、实体分类码和顺序号三段。顺序号必须跨全库统一分配，不能按图幅独立编号。

常用编码结构是：6 位县级行政区划代码 + 6 位实体分类码 + 6 位及以上顺序号，总长度 18 位以上，用定长字符串存储。行政区划代码标识实体所在区县，实体分类码对应前面确定的实体大类及细分类型，顺序号表示该实体在同类实体中的唯一编号。

顺序号生成的实际项目中经常翻车，后面我会专门讲。这里先说原则：先全库排重生成，每批数据续接已有最大顺序号，增量更新时借用同一发号机制。实体属性字段也要在转换前定好，至少包含实体标识码、实体分类码、名称、几何类型、长度、面积、数据来源、生产批次、生命周期状态、创建时间、变更时间。关系字段不直接落实体主表，而是单独建关系表，按需要记录包含、从属、连通、毗邻四类基础关系。

3. 核心转换流程：跨图幅清洗、实体归并与赋码

3.1 全局数据预处理：图幅拼接、接边与重叠清理

实体转换不能分图幅流水线式地干。先做整库拼接，将全部图幅合成一个无缝工作区，再统一做要素级预处理。常见做法是把源数据导入 PostgreSQL/PostGIS 或直接落到一个大型文件地理数据库，后续用 SQL 和脚本完成批量处理，效率远高于逐个图幅手工操作。

预处理顺序很关键，我一般这样排：

1. 全部图幅统一坐标系后拼接，去掉图幅边界字段。
2. 检查并修复几何错误：自相交、重复点、闭合面积小于零的面。
3. 图幅接边处重叠要素去重：保留面积较大的要素，删除重叠部分。
4. 悬挂线、孤立点清理：只清理完全多余的碎线，路网端点在路口处不要动。
5. 碎小多边形合并：对面积过小且无实际意义的面要素并入相邻同属性要素。

重叠去重这一步可以用空间相交判断批量做。实际生产中两个图幅对同一栋楼的图形表达不完全一致，直接保留一个再删除另一个，会让边界出现锯齿。更好用的方式是取两者边界的中线或保留精度较高的版本，这需要提前确认哪个图幅是现势性更近的成果。

一个参考的 SQL 思路如下：

-- 找出跨图幅重叠的房屋面 SELECT a.gid, b.gid, ST_Area(ST_Intersection(a.geom, b.geom)) AS inter_area FROM house a JOIN house b ON ST_Intersects(a.geom, b.geom) WHERE a.gid < b.gid AND ST_Area(ST_Intersection(a.geom, b.geom)) > ST_Area(a.geom) * 0.6;

这段逻辑是在判断：如果 b 覆盖了 a 的 60% 以上面积，基本可以断定是同一栋房屋的重复采集。处理后保留现势性更新的那一个，删除旧的。这里的 0.6 阈值需要试跑，不同数据重叠率不一样，建议先用小范围测试再定全局参数。

预处理得到的错误清单和修复记录必须留存。实体转换完成后如果发现某个房屋实体形状异常，能追回去查原始要素，而不是对着实体库里的结果凭空猜。这是整个工作流里最值得提前投入的一步。

3.2 实体归并与几何处理规则

预处理完成后进入实体归并阶段。归并不只是简单地把相邻要素连在一起，要按实体建模规则分批处理：先做建筑实体，再做道路实体，再处理水系和植被，最后处理管线与独立设施。

建筑实体归并的一般做法是：先按名称、楼号等属性分组，再把空间上相连的同组面合并为一个实体。同组含义要设计好，不能只靠名称。很多小区里几十栋楼名称前缀完全一样，单纯按名称 GROUP BY 会把整个小区变成一栋楼。我常用的规则是：名称相同、且面与面之间的最近距离小于 0.5 米时才合并；名称不同但空间完全相接，会进一步判断是否属于同一结构体，不能盲目合。

具体到 SQL，可以这样表达归并逻辑：

-- 按名称分组，仅合并彼此距离在 0.5 米的同名房屋面 CREATE TABLE ent_building AS SELECT name, ST_Union(geom) AS ent_geom, ST_Area(ST_Union(geom)) AS ent_area FROM house h WHERE name IS NOT NULL AND name <> '' GROUP BY name;

这段 SQL 只适合同名房屋确实为一栋楼的情况，实际数据里同名不同栋大量存在，所以必须先用空间临近关系过滤一遍，只让真正相连或近邻的面进入同一分组。0.5 米这个距离参数要按图幅精度调整，1∶500 数据可取 0.3~0.5 米，1∶2 000 数据放宽到 0.5~1 米。

道路实体归并逻辑不同。道路必须保持连通，一条道路跨图幅断成几段时，优先按中心线端点连接，而不是按名称属性合并。连接规则要考虑道路等级：城市快速路、主干道按名称连续；等级较低的小路如果断开距离超过 5 米，宁可保持线实体分段，也不要强行拉通。道路中心线缺漏是高频问题，常见做法是从路面边线提取中心线，再与已有中心线匹配拼接。

水系实体相对简单：双线河的面要素跨图幅拼接后直接合并；单线河按线实体连接。植被实体按面聚合时要注意，同一林地中间被道路穿过时，应保持分割状态，不能合并成跨道路的一个实体，因为现实世界中道路是天然边界。

3.3 实体标识码赋码：规则、顺序与稳定性

几何实体建好之后，最后统一赋码。赋码必须放到归并之后，因为归并过程中伴随面的拆分与合并，提前赋码会产生大量失效编码，浪费已经生成的顺序号，后续排重都很麻烦。

赋码脚本要保证幂等性，同一数据重新跑一遍，编码结果保持一致。常见做法是把编码分配写成一个独立模块，输入实体分类码和行政区划代码，输出下一号顺序号，并把分配记录写入编码日志表。下次生产时先读日志表获取当前最大序号，而不是在实体表中取最大值，避免删除数据后序号回退导致重码。

Python 端一个可靠的逻辑结构如下：

import psycopg2 def allocate_code(conn, district: str, ent_class: str) -> str: cur = conn.cursor() # 从编码日志表取当前分类序号的累计值，行级锁防止并发重码 cur.execute( """ SELECT seq_value FROM entity_seq_log WHERE district = %s AND ent_class = %s FOR UPDATE """, (district, ent_class), ) row = cur.fetchone() seq_next = 1 if row is None else row[0] + 1 cur.execute( """ INSERT INTO entity_seq_log(district, ent_class, seq_value) VALUES (%s, %s, %s) ON CONFLICT (district, ent_class) DO UPDATE SET seq_value = EXCLUDED.seq_value """, (district, ent_class, seq_next), ) conn.commit() return f"{district}{ent_class}{seq_next:06d}"

这段代码关键是 FOR UPDATE 和 ON CONFLICT 配合，保证两个作业员同时跑任务不会拿到同一个顺序号。实体标识码一旦分配并写入库中，后面任何图形形状修改、属性修改都不能改变编码。生命周期状态用“建成”“存在”“拆除”表示，实体拆了编码保留，新实体用新码，绝不能把老编码重新用给新物体。

4. 属性映射设计：要素分类码到实体分类码的对照与字段迁移

4.1 构建要素分类码到实体分类码的映射表

要素分类码遵循传统测绘要素分类体系，实体分类码按实体对象重建分类，两个体系不是一一对应。转换前必须建一张完整映射表，覆盖源数据里出现的全部要素分类码，不能有遗漏。

映射表的典型结构是：源要素分类码、源要素名称、目标实体分类码、目标实体名称、转换规则说明。一条源要素编码可能对应多个实体分类码，取决于要素的细分属性。比如同一编码下，有名称的独立房屋与无名附属房在实体建模中可能落入不同实体类型，这时映射规则要写成条件式。

映射表管理要落到一张可维护表中，不要写在代码里。生产过程中发现漏映射，直接补映射表记录，然后重跑转换任务。每次转换前用一条 SQL 检查源数据分类码与映射表是否完全覆盖：

SELECT DISTINCT source_class_code FROM source_layers WHERE source_class_code NOT IN ( SELECT DISTINCT source_class_code FROM entity_code_mapping );

返回空集才允许启动转换。这里最怕的是数据里出现了垃圾值、空值、历史遗留编码，映射表没覆盖到，程序默认落到 NULL。质检阶段看到一堆实体分类码为空，往往就是这一步没把关。

4.2 实体属性字段迁移与标准化

源要素属性字段命名五花八门，实体库字段必须统一。名称、地址、权属这类文本属性要做规范化处理：半角全角统一，首尾空格清理，地名中的“第”“号”“栋”等通名不能随意增减；数字属性检查单位，长度、面积按米和平方米换算后重算，不能直接沿用源字段值。

实体属性字段设置建议按以下清单建表：

CREATE TABLE base_entity ( entity_id VARCHAR(32) PRIMARY KEY, entity_class_code VARCHAR(12), entity_name VARCHAR(200), address_text VARCHAR(500), geom_type CHAR(1), -- P: 点 L: 线 A: 面 measure_length NUMERIC(15,3), -- 米 measure_area NUMERIC(15,3), -- 平方米 data_source_code VARCHAR(50), batch_no VARCHAR(20), lifecycle_status VARCHAR(10), -- 建成/存在/拆除 create_time TIMESTAMP, update_time TIMESTAMP );

属性迁移的核心是保留“来源可溯”。给实体表加 batch_no 和 source_layer_id 字段，把实体标识码与源要素的主键对应关系存到单独表里。实际项目中我用过一张很小的表完成这个目标，结构是 entity_id、source_layer 名、source_feature_id，查询时通过 source_feature_id 直接回到原始图幅，非常管用。

长度面积值要用实体归并后的新几何重新计算，直接沿用源要素属性里旧面积，会让实体面积与图形对不上。质检阶段拓扑检查可能放过，但面积统计时发现问题，返工成本反而更高。

4.3 实体间关系构建与数据落库结构

实体关系在要素数据里没有现成表达，转换后要通过空间分析生成。四类基础关系建议在建库后自动生成，再加人工抽查：

包含关系：房屋实体被宗地、行政区境界实体包含，通过面包含判断生成。从属关系：路灯、井盖、门牌等独立设施点实体落入某个建筑或道路，通过点面包含生成。连通关系：道路实体之间共端点或交叉点，通过端点匹配生成。毗邻关系：相邻房屋共边或近邻，通过缓冲区相交生成。

关系表通用结构如下：

CREATE TABLE entity_relation ( relation_id BIGSERIAL PRIMARY KEY, from_entity_id VARCHAR(32), to_entity_id VARCHAR(32), relation_type VARCHAR(10), -- CONTAINS / BELONGS / CONNECTS / ADJACENT relation_source VARCHAR(20), -- AUTO_CHECK / MANUAL create_time TIMESTAMP );

关系表生成后最值得做的是连通性检查。道路是线实体、水系是线或面实体，生成后都要做网络连通分析，标出孤立段、端点悬空、跨实体断裂的位置。孤立段不一定全错，因为实体建模中某些小路确实独立存在，但每一处都必须有明确的说明，不能是有图幅拼接遗留导致的断裂漏网。把检查结果导出成清单，人工逐条确认，确认过的记录原因，返回修改的有则重跑。

5. 转换生产常见问题排查：5 个高频翻车点

5.1 同一栋房屋跨两幅图，转换后成了两个实体

现象：建筑实体统计数量比规划预估多出一大截，实地核对发现同一边缘地带的房屋被重复计数，实体库中出现两栋完全重叠或部分重叠的房屋。

原因：预处理阶段只做了图幅拼接，没有对重叠要素做去重；实体归并时又只按属性分组，跨图幅的重复面没有进入同一分组。两幅图对同一栋房屋的边界绘制存在差异，导致空间相交面积没有达到合并阈值。

解决：在实体归并前单独跑一次全库空间重叠检查，找出两两相交面积占其中一个面积比例超过 60% 的要素对，按较低评估判断保留现势性更新的那一份。处理后在两边同时记录被删除要素的 ID，方便追踪。这个环节要在一开始跑完就检查，不要等到实体赋码之后再处理。

5.2 实体合并把邻居楼“吞”了

现象：房屋实体归并后，部分实体几何形状异常，像是两栋独立的楼被连成一体，中间原本的巷道消失。

原因：空间聚合的缓冲阈值设置过大，比如 1∶500 数据用了 0.5 米以上的缓冲来判断是否相连，两栋楼之间间距本身就小，缓冲一膨胀直接互相接触，ST_Union 就把它们合并了。

解决：调整聚合策略，先按属性分组再做空间判断。名称、结构、层数不同的房屋不应进入同一分组；只有属性相同的近邻面才允许聚合。缓冲阈值要按比例尺做参数化，1∶500 一般取 0.2 米，1∶1 000 取 0.3 米，1∶2 000 取 0.5 米，同时叠加“不得跨越道路、围墙等分隔要素”的规则。

5.3 道路中心线断头、甩尾与交叉口缺口

现象：道路线实体生成后，在路口位置出现大量断头，两条相交道路的中心线互不接触；部分中心线在路面边缘处突然停止，没有延伸到路口中心。

原因：中心线数据源于图幅边线提取，各图幅分段提取后端点不在同一位置，也没有做端点捕捉；另外部分道路面要素在路口区域本身缺边，导致提取结果先天缺一段。

解决：中心线实体生成后统一做一次端点捕捉，捕捉半径按比例尺设阈值，1∶500 一般 0.3 米以内可接受。捕捉后重新生成连通关系，再做一次路网连通性检查，把悬空端点列出来人工判断是路口断缺还是死路。对于路口区域缺口，用相邻道路面的轮廓延长线做交点点位，再修正中心线端点。

5.4 属性映射丢数据：实体分类码为空或落入默认值

现象：质检统计时发现实体分类码大量为 NULL，或者全部实体都落到了同一个默认分类码下。

原因：源数据分类码存在映射表未覆盖的编码，转换脚本遇到未知代码默认跳过或赋了一个兜底值，后续没有对空分类码做二次检查；或者在映射表的 JOIN 条件里用了全码精确匹配，而源数据分类码存在前导空格、全角字符等问题，匹配不上。

解决：转换前跑“未被映射覆盖的源编码列表”，这里不能只是看一眼，要逐条处理，该补映射表补映射表，源数据真的有垃圾值要返回修数据。编码匹配前清洗两侧文本，去掉首尾空格、统一半角。实体库提交前做一次完整性校验，分类码为空或等于兜底值的记录数量必须为零。

5.5 实体码重复：分批次顺序号从 1 重新开始

现象：两个批次数据分别独立赋码，批次一从 1 开始给房屋实体编号，批次二也从 1 开始，两批入库后出现多个实体标识码完全相同的记录。

原因：赋码脚本没有统一发号机制，作业员在各自分区跑任务，谁也没读到对方的最后顺序号。

解决：编码分配统一走中心发号服务，也就是前面写的 entity_seq_log 表，所有作业员共用同一张表，用事务锁保证并发安全。入库前跑全表唯一性检查，标识码出现重复立即中止并回滚该批次。这个检查可以作为实体库入库的硬性门槛，不管数据量多大都要跑。

6. 把转换流程做成可回溯的生产线

实体转换不是一次性的技术动作，后续日常更新都在这套流程上跑，所以整个流程的“可回溯性”比单次转换的正确性更重要。我习惯在生产开始前就把三张表准备好：批次表、编码分配日志表、实体-源要素追溯表。批次表记录每批数据的名称、起始时间、源数据版本、转换参数；编码分配日志表记录每个实体标识码由谁、在什么时间、按哪条规则生成；追溯表记录实体标识码与源要素主键的对应关系。

有了这三张表，复查某栋房屋实体为什么形状异常时，可以一键定位到原始图幅和原始要素，而不是面对实体库里的几何状态反复猜测。除了追踪，还要做对账：每批转换完成输出一张统计表，包含源要素按图层数量、实体按分类数量、图形总面积、总长度，和上一批做差值比对。差值异常说明归并规则或源数据发生了意外变化，趁早发现问题比最后质检时补救省力得多。

批量处理脚本要设计成可重复执行。生产过程中我常用的脚本框架是先清空本批次临时表，再重新导入源数据、重新跑预处理、重新归并、重新赋码，每一步都留下中间图层快照。中间快照可以占不少存储，但带来的排查便利远超成本，因为人工修改过某一小步之后，整个流程是否能复现就靠它。

增量更新时还要遵守一个硬原则：实体标识码一旦产生，永久不变。旧实体拆除，只把生命周期状态改成“拆除”，记录拆除时间；新实体使用新编码，绝不重用旧号。曾有项目为了省编码空间把已拆除实体的号重新分配给新房屋，后续历史回溯时新旧记录全部纠缠在一起，这段经历算是我在赋码设计上最深刻的一次踩坑。

数据和流程都稳定下来后，还可以给实体库做版本化输出，每个版本完整导出实体表、关系表、属性快照和质检报告。版本间对比功能排查更新影响非常实用，某块地发生变化时，能直接看到关联的道路、宗地、水系实体是否同步受到牵连。按照上面的流程把基础打好，转换生产做起后续更新维护就会顺手得多，希望这篇能帮到你少走弯路。

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