简介：这是一份公路数据库数据采集规则的专业文档，面向交通行业从事公路数据库及相关信息系统建设、维护的人员，用于规范公路工程基础信息资源的采集、处理与交换。资源包为1个doc文件，大小544KB。文档依据现行国家与行业标准，系统规定了数据指标分类原则、数据类型（数字型、字符型、日期型）、采集方法及精度要求，内容覆盖总则、里程桩系统建立、数据采集顺序与更新、起止点桩号等核心规范。针对公路概况类数据，重点说明了路线现状、晴雨通车里程、分离式路段主路与下行路段的采集规则，并给出技术等级、车道特征等各类数据采集表的实际样式，便于直接参照执行。同时明确了现场调查与档案资料核实相结合、以实地测量结果为准的工作要求，确保数据真实可靠。该文档适合国道、省道、县道及乡道的数据采集管理工作参考，目前已有152人学习下载。
1. 公路数据库数据采集规则：一份doc如何决定数据能不能用
很多单位拿到《公路数据库数据采集规则.doc》时，第一反应是把它存进档案柜，等数据真正入库那天才发现，规则没定清楚，采集回来的数据只能烂在外业硬盘里。我见过最典型的翻车现场：路线长度与年报对不上，桥梁位置偏离几百米，病害照片和桩号对不上，最后连一次养护决策都做不出来。这个标题看起来像一份普通文档，实际是整个公路数据闭环的“宪法”。它定义采什么、怎么采、按什么精度采，也决定数据能不能支撑路况评定、养护计划和资产管理。这篇内容主要面向公路数据管理者、养护工程师和第三方采集团队，帮大家把一份规则文档变成能直接执行的库表结构、外业流程和校验脚本。
2. 先把采集对象讲清楚：公路数据库到底在采什么
公路数据库听起来像一张大表，实际不是。常见做法是把数据按“路线—路段—设施”三层组织，三条链路对应完全不同的采集周期、精度和更新时机。规则文档如果没有先分层，后面定义字段时一定打架。
2.1 路线、路段、设施：三类对象对应三种采集规则
路线层最简单的理解是“整条路的档案”。比如G318这条路线，要记录路线编码、路线名称、行政等级、技术等级、设计速度、通车年份。这些字段变化频率极低，一次采集后可以用很多年，规则里不需要重复要求外业每次去现场更新。
路段层才是日常采集的重点。一条路线会被切分成若干路段，切分依据通常是行政区域、养护单位或技术等级变更。路段层必须有起止桩号、方向、路面类型、养护单位，还要能算出路段的长度。这一层的典型问题是“一条路线到底分多少段”，规则里不写清楚，不同的人会切出不同结果，最后里程汇总对不上。我的习惯是明确“一个路段内不能同时跨越两个养护单位或两种路面结构”，这是最基本的分段原则。
设施层是最耗外业精力的一层。桥、隧道、涵洞、标志标牌、护栏、防护工程等都是独立设施，每个设施既要有点位坐标，也要有桩号，还要有设施类型、结构类型、建成年份、养护状态。设施层的采集规则不能拿路段层套用，因为桥梁需要净空、跨径组合、桥面铺装类型，护栏需要长度和起终点，这些属性只能在设施表里单独定义。
2.2 采集规则的核心载体：编码体系与数据字典
有了分层，下一步是让每个对象都能被唯一找到。路线层编码用行业通用的路线标识即可，比如“G318”；路段层建议用“路线编码+行政区划+起止桩号”生成派生段号，但不要在原始字段里写下完整冗长编码，保留route_id、start_stake、end_stake三个基础字段，段号由系统拼接，这样后期维护简单。
设施编码我一般用“路线编码_方向_桩号_设施类型_序号”的结构，比如“G318_U_K12+350_桥_01”。这个编码只作展示用，数据库主键还是用自增或内部ID。规则文档里必须写清楚编码怎么拼，否则外业人员按自己理解编，内业入库时统计口径全乱。
| 字段名 | 中文名 | 类型 | 长度/精度 | 必填 | 字典项说明 |
|---|---|---|---|---|---|
| route_id | 路线编码 | VARCHAR | 16 | 是 | 按行业路线标识规则填写，如G318 |
| direction | 方向 | VARCHAR | 2 | 是 | U=上行，D=下行，O=无方向 |
| start_stake | 起点桩号 | NUMERIC | 10,3 | 是 | 单位公里，K12+350记作12.350 |
| facility_type | 设施类型 | VARCHAR | 8 | 是 | 桥、隧、涵、护栏、标志等 |
| longitude | 经度 | NUMERIC | 10,7 | 是 | CGCS2000十进制度 |
| latitude | 纬度 | NUMERIC | 10,7 | 是 | CGCS2000十进制度 |
| elevation | 高程 | NUMERIC | 8,3 | 否 | 1985国家高程基准，单位米 |
| survey_date | 采集日期 | DATE | - | 是 | 格式YYYY-MM-DD |
| remark | 备注 | VARCHAR | 200 | 否 | 补充说明，不填不影响统计 |
这张表是数据字典的浓缩形式。经度纬度用十进制度而不是度分秒，原因很简单：字符串格式的度分秒在数据库里不能参与范围查询，也不能直接做空间运算，入库前还要多一步解析。规则文档里如果写了“坐标用度分秒记录”，后面一定会多出一堆转换脚本和数据清洗工作。
2.3 一份规则文档该有的骨架：建议目录与内容清单
真正能落地的规则文档不会只有一张字段表，它至少要包含九块内容：总则、规范性引用文件、采集对象与分类、编码规则、字段字典、外业采集要求、内业入库要求、质量控制、版本与变更。每一块都要落到具体操作，而不是写“应按国家规定执行”这种空话。
| 目录 | 内容要点 | 落地产物 |
|---|---|---|
| 总则 | 目的、适用范围、各单位职责分工 | 一份职责说明 |
| 规范性引用文件 | 编码规则、公路技术状况评定等基础文件清单 | 引用清单 |
| 采集对象与分类 | 路线、路段、设施三层定义 | 对象分层表 |
| 编码规则 | 路线、路段、设施编码生成方式 | 编码示例与模板 |
| 字段字典 | 每张表的字段定义、类型、长度、字典项 | 建表SQL与采集模板 |
| 外业采集要求 | 设备、精度、桩号、照片、轨迹记录方式 | 外业操作手册 |
| 内业入库要求 | 数据清洗、坐标转换、拓扑处理流程 | 清洗与入库流程 |
| 质量控制 | 必填、唯一、长度闭合、坐标漂移等检查 | 质检脚本与抽检表 |
| 版本与变更 | 规则修订、数据字典变更、历史数据迁移 | 变更记录表与映射表 |
“doc”后缀本身不重要，重要的是内容闭环。如果采集团队已经在用手机APP采集，那规则文档还要衍生出一份“字段配置”和“APP采集模板”。外业人员真正接触的是Excel模板或APP界面，不是一堆编制说明，因此规则文档最好带上可复制的空白采集表，并在每个字段旁边标注填写样例，这会直接决定外业配合度。
3. 把规则落成可执行方案：字段、精度与采集流程
规则文档写得再完整，如果下不了地就是废纸。我评判一份规则好坏的标准很简单：外业照它走能不能顺利交差，内业照它转能不能不出错，数据库照它建能不能直接跑通。这一章就是把规则语言翻译成现场动作。
3.1 字段字典怎么定：字段名、类型、长度、字典项
字段命名建议全部用小写英文加下划线，比如surface_type、maintainer。原因不是英文比中文高端，而是跨数据库、跨GIS平台、跨APP传输时，英文小写下划线的兼容性最好，中文名只用于界面展示和规则说明。字段长度要按真正可能出现的最大值估算，不要随手写255。
| 序号 | 字段名 | 中文名 | 类型 | 长度/精度 | 必填 | 字段说明 |
|---|---|---|---|---|---|---|
| 1 | segment_id | 路段编号 | VARCHAR | 32 | 是 | 主键，由route_id+方向+起止桩号生成 |
| 2 | route_id | 路线编码 | VARCHAR | 16 | 是 | 关联路线表 |
| 3 | route_name | 路线名称 | VARCHAR | 64 | 是 | 展示用，如“国道318” |
| 4 | direction | 方向 | VARCHAR | 2 | 是 | U=上行，D=下行，O=无方向 |
| 5 | start_stake | 起点桩号 | NUMERIC | 10,3 | 是 | 单位公里，保留三位小数 |
| 6 | end_stake | 终点桩号 | NUMERIC | 10,3 | 是 | 必须大于起点桩号 |
| 7 | length_km | 路段长度 | NUMERIC | 10,3 | 是 | 单位公里，由起止桩号计算 |
| 8 | surface_type | 路面类型 | VARCHAR | 16 | 是 | 沥青、水泥、砂石、简易 |
| 9 | maintainer | 养护单位 | VARCHAR | 64 | 是 | 填写具体单位名称 |
| 10 | survey_date | 采集日期 | DATE | - | 是 | 格式YYYY-MM-DD |
| 11 | source | 数据来源 | VARCHAR | 16 | 否 | 外业采集/资料转绘/影像解译 |
桩号是这里最容易出问题的字段。规则里必须明确规定“桩号一律存公里数值，不存K12+350这种字符串”。K12+350转换后就写12.350，数据库里能排序、能求差、能画里程关联图。外业人员习惯写K字头没问题，采集APP或内业脚本负责转换，但规则要附上明确的换算样例，避免“12+350”和“12350”同时出现。这段转换逻辑如果没人规定，内业会按自己的理解处理，一小时能完成的工作最后拖三天。
3.2 三个必调参数：坐标精度、高程基准、采集频率
第一个必调参数是平面精度。路线线形采集用RTK或高分辨率影像加野外复核，平面精度控制在1米以内足够；桥梁、隧道等重要设施用RTK实测，精度要求高一些；普通标志牌和护栏用采集APP记录，定位精度2米以内可以接受。不要在规则里写“全部厘米级精度”，那是给测量控制网用的，公路数据库的日常采集没必要，也拖不起这个进度。
第二个必调参数是坐标系和高程基准。公路行业外业设备普遍输出WGS84或CGCS2000坐标，入库时统一存CGCS2000经纬度。选择CGCS2000是因为它是国家的法定大地基准，也和现行公路勘察设计数据能衔接起来。高程则统一用1985国家高程基准，桥梁净空、涵洞纵坡这类数据必须依赖统一高程，否则建出来的数据没法做结构分析。
| 采集对象 | 平面精度要求 | 坐标系 | 采集周期 | 采集方式 |
|---|---|---|---|---|
| 路线线形 | ≤1m | CGCS2000 | 竣工后3个月内 | RTK或影像+野外复核 |
| 桥梁隧道 | ≤0.5m | CGCS2000 | 竣工后3个月内 | RTK实测 |
| 路面病害 | ≤2m | CGCS2000 | 每年1次 | 巡检APP+轨迹 |
| 标志护栏 | ≤2m | CGCS2000 | 季度巡检 | 巡检APP |
| 应急灾毁 | ≤5m | CGCS2000 | 灾后24小时内 | 手持终端先采轨迹 |
第三个必调参数是采集频率。新建和改建公路在竣工后3个月内完成全要素采集；路面病害、平整度这类动态数据结合路况评定每年采一次；标志牌和护栏这类容易变化的设施按季度巡检；应急灾毁数据要有“24小时内先采现场轨迹，后续再补属性”的兜底机制。规则里最忌讳写“定期更新”，因为没有明确的周期，这项工作到年底一定被遗忘。参数写清楚后，每个季度该派谁去现场、数据哪天入库，都可以直接排进工作计划。
3.3 外业采集规则：桩号、照片、轨迹文件怎么记
外业采集不是“到现场随便拍一拍”，每一步都要有记录规范。出发前先确认路线起点和桩号递增方向，找到K0+000的位置，避免把路线方向搞反。到达每个采集对象后先打点，等定位精度稳定在2米以内再记录桩号，手持终端信号不好时停稳三秒再打点，这些细节能显著减少点位漂移。
照片是外业数据里最容易被忽视的部分。规则要写死命名格式，同时规定每个设施至少拍三张：一张整体全景、一张近景、一张关键部位细节。照片命名用“路线代码_方向_桩号_设施类型_序号”的格式，桩号里的“+”改成“_”，避免文件名非法字符。例如“G318_U_K12+350_桥_01.jpg”写成“G318_U_K12_350_桥_01.jpg”。这样整理内业时，按文件名就能直接归类，不用再打开图片猜位置。
轨迹文件同样要规范。外业人员出发时开启轨迹记录，收工后停止，轨迹点按每5秒或每10米一个记录。轨迹数据用来验证路线线形是否连续，也用来检查设施点位是否偏离路线。规则里要写明轨迹导出格式，一般用GeoJSON或Shapefile均可，但必须带时间戳。如果没有时间戳，后续把照片和轨迹对齐时只能靠人工，效率会很难看。
3.4 内业入库规则：从外业原始记录到数据库表的四步清洗
外业回来的Excel直接复制粘贴进数据库，这是最常见的翻车操作。我一般要求内业按四步走：先保留原始文件存档并改名标准化，再把外业表里的“里程桩号”“公里桩”这类自由文本解析成数值桩号，第三步统一坐标转换，第四步把几何与属性分离。每一步都有明确产物，不能混在一起做。
| 步骤 | 执行内容 | 产物 | 验证方式 |
|---|---|---|---|
| 1 原始存档 | 保留外业交付的原文件，另存一份标准命名副本 | 原文件+标准副本 | 文件数量与清单一致 |
| 2 字段标准化 | 桩号文本转数值，字段名与规则字典对齐 | 清洗后的CSV或Excel | 抽样比对桩号差异 |
| 3 坐标转换 | 将设备输出坐标统一转成CGCS2000 | 已转换坐标数据 | 与已知控制点比对 |
| 4 入库 | 生成线段几何和设施点几何，分表写入数据库 | 数据库中的路线表和设施表 | 跑SQL校验脚本 |
第四步里的“几何与属性分离”很多人不理解。简单讲，路线中心线是线几何，设施点是点几何，两者不要强行放在一张表里。路线表保存路段线形，设施表保存设施点位，通过route_id和桩号关联。如果全部合并成一张大宽表，后面做空间分析时查询会变得很慢，而且设施属性和路线属性混在一起，统计口径也很难理清。
4. 用数据库约束和脚本把住入库质量：建表、校验与版本管理
采集规则最终要落进数据库。很多规则文档只写“请认真填写”，却没有把“认真”变成数据库能自动执行的约束，结果入库数据还是千奇百怪。这一章讲怎么在建表、校验和版本管理三个环节把规则固化下来。
4.1 建表阶段就卡规则：约束、索引与默认值
字段类型只是规则的第一层约束，更关键的是主键、唯一约束、检查约束和默认值。用PostgreSQL加PostGIS写一个路段表示例，其他数据库的语法类似，思路可以照搬。
CREATE TABLE route_segment ( segment_id VARCHAR(32) PRIMARY KEY, route_id VARCHAR(16) NOT NULL, route_name VARCHAR(64) NOT NULL, direction VARCHAR(2) NOT NULL CHECK (direction IN ('U', 'D', 'O')), start_stake NUMERIC(10,3) NOT NULL CHECK (start_stake >= 0), end_stake NUMERIC(10,3) NOT NULL, length_km NUMERIC(10,3) NOT NULL, surface_type VARCHAR(16) NOT NULL DEFAULT '沥青', maintainer VARCHAR(64) NOT NULL, survey_date DATE NOT NULL, geom GEOMETRY(LINESTRING, 4326) NOT NULL, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, CONSTRAINT chk_end_gt_start CHECK (end_stake > start_stake), CONSTRAINT chk_length_positive CHECK (length_km >= 0), CONSTRAINT uq_route_segment UNIQUE (route_id, direction, start_stake) );这条建表语句里，NOT NULL把字段必填规则直接做进数据库，空值根本插不进去。CHECK约束限制了方向和桩号范围，U、D、O之外的枚举值会被数据库拒绝。UNIQUE约束防止同一条路线、同一个方向、同一个起点桩号出现两条记录。这些约束建表时多写几行，后面能省掉大量人工查重和返工。
这里有一个经常被忽略的点：direction字段用VARCHAR(2)而不是CHAR(1)，是为了后面扩展双向编码时不用改表结构，比如将来加“E双向”也能兼容。surface_type的默认值设成“沥青”，是因为公路数据库里沥青路面占比最高，外业漏填时数据库不会留下NULL值，后续统计不会把这一条丢掉。
4.2 三类必要校验：必填、唯一、空间逻辑（SQL与脚本示例）
规则文档里写的“必填”“不能重复”“坐标不能偏离路线”，都要变成能跑的校验脚本。第一类校验是必填检查，SQL直接统计空值率。
SELECT COUNT(*) AS total_rows, COUNT(surface_type) AS filled_surface, COUNT(maintainer) AS filled_maintainer, COUNT(survey_date) AS filled_date FROM route_segment WHERE route_id = 'G318';COUNT函数会跳过NULL值，所以filled_surface小于total_rows时，说明有记录漏填路面类型。这个SQL适合在每次入库后立即执行，不需要改表结构，也没有副作用。空值率持续偏高的话，要回去查外业模板，看看是不是字段名称太晦涩，外业人员根本没理解这一列要填什么。
第二类校验是重复记录。同一路段被采了两次，是外业和内业衔接中最常见的低级错误。用分组加HAVING就能找出重复项。
SELECT route_id, direction, start_stake, COUNT(*) AS dup_count FROM route_segment GROUP BY route_id, direction, start_stake HAVING COUNT(*) > 1;如果查出重复，先看是不是编码规则本身有问题，比如某条路线桩号链不连续导致同一桩号出现在两个不同路段，那要靠桩号链处理；如果编码没问题，就是外业重复采集，删除前要保留原始档案作为依据。
第三类校验是空间逻辑检查，只靠字段约束不够，还要对比线形长度和桩号长度。例如一条路段桩号长度是12.5公里，但坐标几何算下来只有11.8公里，差出来的0.7公里可能是桩号断链，也可能是坐标采错了。
SELECT segment_id, ROUND(ST_Length(geom)::numeric, 3) AS geom_length_km, length_km AS stake_length_km, ROUND(ABS(ST_Length(geom)::numeric - length_km), 3) AS diff_km FROM route_segment WHERE ABS(ST_Length(geom)::numeric - length_km) > 0.5;这里阈值设成0.5公里，意味着几何长度和桩号长度偏差超过500米就要复查。阈值不是固定值，可参考路线勘测精度和比例尺调整，但规则里必须给出一个数字，否则内业不知道“差多少算异常”。更细的检查还能做设施点到中心线的距离，判断桥梁点位是否落在路边几百米外。
如果采集数据还在Excel阶段，可以写一个简单的Python脚本提前检查枚举值。
import pandas as pd df = pd.read_excel("facility_2025.xlsx") allowed = {"U": "上行", "D": "下行", "O": "无方向"} df["direction_ok"] = df["direction"].isin(allowed) bad = df.loc[~df["direction_ok"]] print(f"非法方向记录数: {len(bad)}") if not bad.empty: print(bad[["facility_id", "route_id", "direction"]].head(20))这个脚本依赖pandas读取Excel，脚本里的allowed字典就是规则里的枚举字典。用脚本的好处是外业交付前就能拦截垃圾数据，而不是等入库后才发现，到时候再去追哪个外业小组填的已经很难说清。规则文档里附上这个脚本，比让内业人员一遍遍打开Excel筛选效率高得多。
4.3 规则版本管理：数据字典变更比代码变更更需要留痕
代码项目改个接口都要走版本管理，数据采集规则也一样，而且比代码更需要留痕，因为规则变化直接影响外业、内业和历史数据三批人。常见的翻车场景是：2019年把桥梁类型从四类扩到八类，只在Word里改了描述，没通知外业，2021年采集数据用新枚举，旧库里还是旧枚举，汇总统计直接报错。
规则文档要做版本化管理，文件名带日期和版本号，例如“公路数据库数据采集规则_V1.3_20240915.doc”。同时维护一张变更记录表：
| 版本号 | 变更日期 | 变更内容 | 受影响字段 | 数据处理要求 | 编制人 |
|---|---|---|---|---|---|
| V1.0 | 2019-03-01 | 初版发布 | 全表 | 无 | 张三 |
| V1.1 | 2019-06-18 | 扩展桥梁类型字典 | facility_type | 旧数据继续保留旧值，统计时按映射表转换 | 张三 |
| V1.2 | 2020-11-30 | 增加应急灾毁采集流程 | 新增emergency表 | 新表不影响旧表 | 李四 |
版本变更最关键的不是更新文档，而是建立“新旧字典映射表”。旧值不能直接删除，统计时通过映射表把旧值归并到新字典里，等确认历史数据全部迁移成功后再下线旧值。给原表直接改字段、直接删旧编码，都是给自己吃后悔药的机会，等发现统计对不上时再想找原始数据就晚了。
5. 公路数据采集绕不开的坑：现象、原因与解决
现场采了三个月的数，入库季度汇总时跳出来一堆异常，这种场景在我看来不是单点故障，而是规则在几个环节埋了坑。以下五个坑，我在项目里反复见过。
5.1 桩号与里程不闭合
现象：路线总里程和年报差出几公里；某路段按起止桩号算出来是12.5公里，但在地图上量测只有12.05公里；或者顺着路线一路采集，到某处发现桩号突然退回去。
原因：桩号链存在断链。公路勘测设计中为了处理路线比选，同一桩号在不同段落可能重复或跳跃，形成长链、短链。外业人员直接读里程碑，没有先确认当前路段的桩号链类型，数据采回来之后，内业又不知道这些断链位置，拿桩号差直接当里程用，自然对不上。另一类原因是路线起点方向搞反，整条路线从终点开始采，桩号全部反序。
解决：规则里明确写明路线的起点、桩号递增方向、是否按新桩号链采集。数据库保留桩号链版本字段，每次采集时记录采用哪套桩号链。质检阶段用轨迹长度和桩号长度做对比，超差路段返回现场复核。不要相信外业口头保证“从头到尾都是顺着走的”，必须用轨迹方向验证。
5.2 坐标系混用导致点位漂移
现象：桥梁、隧道的位置在电子地图上偏离实际位置几十米甚至上百米，视觉上“浮”在路边农田里。
原因：外业手持设备默认输出WGS84，内业按CGCS2000入库，中间又没有做转换，两个坐标系在纬度和经度上存在米的级偏差。更隐蔽的是某些采集APP为了适配互联网地图，直接把坐标转换成了地图加密坐标，导出时又不加说明，内业人员不知情又做了一次转换，点位越转越偏。
解决：规则第一页就写清楚“采集设备坐标系统一设为CGCS2000，导出格式必须是经纬度十进制度”。数据文件必须带上元数据说明，记录原始坐标系、目标坐标系、转换方式。内业只做一次明确的投影转换，所有处理步骤留日志。凡是外业交付文件里没有坐标系说明，一律打回重交，不能入库。
5.3 照片与地点对不上
现象：整理内业时发现几百张照片的文件名全是“IMG_20250901_123456.jpg”，完全看不出拍摄位置，只能靠拍摄顺序和轨迹猜。
原因：外业采集规则没有规定照片命名，也没有要求拍照时同步记录桩号。外业人员现场忙着打点，掏出手机就拍，拍完不重命名，回办公室后谁也说不清这张照片对应哪个桥、哪一侧、哪个部位。
解决：规则里写死照片命名格式，并规定每个设施至少拍三张，全景、近景、细节各一张。使用采集APP时，让APP自动把桩号和设施类型写进照片文件名，同时把拍摄时间写入轨迹记录。整理时按拍摄时间和轨迹点对齐，而不是靠人眼猜。这条规则看起来琐碎，但它决定了病害照片能不能在养护决策中被引用。
5.4 新旧编码冲突
现象：同一个桥梁，老系统里叫“董家沟桥”，新采集数据里叫“G318_K12+350_桥_01”，合并库时出现两条记录，工程量统计翻倍。
原因：老库用的是桥梁名称或老路线编码，新规则启用新编码体系，又没有建立映射关系。尤其是行政区划调整或路线编号调整后，旧数据没做迁移，新数据直接入库，两个体系的记录并存在一张表里。
解决：规则中必须包含新旧编码映射表，设施表保留legacy_id字段。合并库之前先跑重复检测，按路线、桩号、设施类型综合判断是否同一条记录。迁移顺序是先加列、再更新、再确认、最后清空旧编码，不要在原始表上直接改主键，历史数据永远要留一份可追溯的原始档案。
5.5 外业内业字段口径不一致
现象：外业填“沥青路面”，内业存成“沥青”，统计时“沥青”和“沥青路面”分成两类；长度单位更乱，有的表格填米，有的填公里，汇总里程直接差出一千倍。
原因：字段字典没有落到采集工具里，Excel没有下拉限制，外业靠手打；单位只在规则文字提了一句，外业人员没有看，或者看了也没当回事。
解决：规则规定长度统一用米、面积统一用平方米、桩号统一用公里且保留三位小数。外业采集表用Excel数据验证或APP下拉框限制枚举值，让外业人员只能从字典里选，不允许自由输入。进入数据库时再加一层CHECK约束，双保险。单位这类基础口径，规则里要放到显著位置，并在采集模板表头用红字或注释标注，不能只藏在正文里。
6. 让规则活起来：每季度做一次规则体检
6.1 用历史数据反推规则漏洞
规则文档发布不是终点，数据质量才是真正的裁判。我养成的习惯是每季度按5%的比例抽检历史入库数据，拿当年的年报里程、遥感影像和现场复核结果去反推规则漏洞。
| 体检项 | 方法 | 合格判据 | 异常之后的动作 |
|---|---|---|---|
| 字段字典执行率 | 统计空值率与枚举值合法率 | 空值率低于5%，枚举异常为0 | 检查外业模板，重新培训 |
| 里程闭合差 | 对比坐标几何长度与桩号长度 | 偏差不超过0.5公里 | 现场复核，修正桩号链 |
| 设施漏采率 | 与养护台账抽查比对 | 漏采率不超过2% | 安排补采 |
| 坐标漂移 | 计算设施点到路线中心线距离 | 距离不超过10米 | 核实坐标系与点位 |
| 时效性 | 检查采集日期与入库时间之差 | 滞后不超过30天 | 调整采集排期和入库流程 |
如果某个字段的空值率连续两个季度都高，问题大概率不在外业态度，而在规则本身，可能是字段定义太模糊，也可能是这个字段本来就不该由外业填。这时候要修改字段字典，而不是硬逼外业填一堆没用的数据。如果某类设施总漏采，就去细化这一类设施的采集流程，单独做一张采集说明发给外业小组。
6.2 把采集规则当成数据库基础设施
规则文档、数据库表结构和外业采集APP配置三者必须绑定发布，改规则时同步改建表脚本和APP配置。我现在接手任何公路数据项目，第一件事不是直接看库，而是先找采集规则和字典版本。没有规则，再好的数据库都是黑匣子，数据出了问题根本不知道从哪查起。每次质检发现新问题，我会第一时间更新对应章节，并在变更记录里写明原因，让下一批外业人员知道为什么这样改。把规则当基础设施维护，数据才能真正用起来，希望帮到你。
本文还有配套的精品资源，点击获取
