历史地名库怎么建?GIS数据库设计难不难?

wowwwai GIS研习社 · 工具流程与项目排障

“历史地名库怎么建?GIS数据库设计难不难?”这个问题，表面是在问数据库建表，实际是在问：如何把不同时期、不同来源、不同写法的历史地名，整理成可以查询、制图、分析和长期维护的GIS数据库。

对GIS学习者和初级GIS工程师来说，历史地名库不一定难，但不能只建一张“地名表”。它至少要处理地名、空间位置、时间范围、行政层级、来源出处、别名异名和不确定性。本文按一个可落地的工作流，讲清楚历史地名库的GIS数据库设计思路、表结构、字段设计、空间数据处理和常见坑。

引言：历史地名库不是普通地名表

普通地名表通常关心“现在叫什么、在哪里”。历史地名库更复杂，因为同一个地点可能在不同时期有不同名称，同一个地名也可能对应多个历史位置。

例如，一个古县名可能经历过以下情况：

• 名称变化：唐代叫一个名字，明清又改名。
• 治所迁移：行政名称不变，但中心位置发生变化。
• 范围变化：同一县名在不同时期管辖范围不同。
• 文献差异：不同志书、地图、论文给出的坐标或归属不同。
• 空间精度不一：有的能定位到点，有的只能定位到大致区域。

所以，历史地名库的核心不是“把地名录入数据库”，而是用GIS数据库设计方法，把地名、时间、空间和证据关系组织清楚。

背景：历史地名库通常要解决哪些GIS问题

在实际项目中，历史地名库常见于历史GIS、地方志数字化、文化遗产管理、古地图配准、历史行政区划研究和文旅数据平台。不同项目目标不同，但GIS数据库设计需要回答的基本问题比较一致。

1. 能不能按历史时期查询地名

用户可能需要查询“宋代某地叫什么”“清代某县属于哪个府”“某个古地名从什么时候开始出现”。这要求数据库不能只存一个现代名称，而要存名称的有效时间范围。

2. 能不能在地图上定位

历史地名库最终往往要进入QGIS、ArcGIS Pro、WebGIS或PostGIS空间查询环境。每条记录需要明确空间几何类型，例如点、线、面，或者至少存储一个代表点。

3. 能不能表达不确定性

历史地名定位经常不是百分百确定。有些来自文献描述，有些来自旧地图配准，有些只是学者推定。数据库应保留定位精度、置信度、来源说明，而不是把所有坐标都当成绝对正确。

4. 能不能追溯来源

历史地名库最怕“坐标从哪里来的说不清”。如果后期需要校核、发表或共享数据，必须能追溯到原始文献、地图、论文、档案或采集人员。

原理：历史地名库GIS数据库设计的核心关系

建设历史地名库，建议先把问题拆成四个核心对象：地名实体、名称记录、时空记录和来源证据。

地名实体

地名实体表示“一个被研究的历史地点或行政对象”。它不等于某一个名称，也不一定等于某一个坐标。比如“某古县”可以作为一个实体，它在不同年代有不同名称、不同治所位置和不同管辖范围。

名称记录

名称记录用于存储正名、别名、异名、繁体写法、古今对应名称等。这样可以避免把同一个地点因为不同写法重复建成多条主记录。

时空记录

时空记录用于描述某个实体在某个时间段内的空间位置或空间范围。历史地名库中的空间信息最好带有起止时间，例如开始年份、结束年份、朝代、年号或时间说明。

来源证据

来源证据用于说明这条名称、坐标或行政归属来自哪里。它可以是地方志、历史地图、数据库、论文、考古报告，也可以是人工判读结果。

实用建议：不要急着把所有字段塞进一张大表。历史地名库越是需要长期维护，越应该把“名称、位置、时间、来源”拆开设计。

步骤：从零建设历史地名库的可执行流程

步骤1：先明确历史地名库的使用场景

在GIS数据库设计之前，先写清楚这个库主要服务什么任务。不同任务会影响表结构和字段粒度。

• 如果用于WebGIS检索展示，重点是名称检索、地图定位和弹窗字段。
• 如果用于历史行政区划研究，重点是时间范围、层级关系和边界变化。
• 如果用于地方志数字化，重点是文献来源、原文摘录和地名标准化。
• 如果用于空间分析，重点是几何精度、坐标系、拓扑关系和可计算字段。

初学者常犯的错误是先建表、后想用途。结果字段越来越多，数据越来越乱，最后既不好查，也不好维护。

步骤2：确定最小可用数据模型

如果项目刚起步，可以先设计一个最小可用模型。下面是一个适合PostGIS、QGIS和ArcGIS Pro使用的基础方案。

表名	用途	关键字段
place_entity	地名实体主表	place_id、current_name、place_type、description
place_name	历史名称与别名表	name_id、place_id、name_text、name_type、start_year、end_year
place_geometry	历史空间位置表	geom_id、place_id、geom、geom_type、start_year、end_year、accuracy_level
place_source	来源证据表	source_id、source_title、source_type、author、publish_year、url
place_evidence	记录与来源关联表	evidence_id、place_id、name_id、geom_id、source_id、note

这个模型的优点是清晰：主表管对象，名称表管叫法，空间表管位置，来源表管证据。后期无论接入QGIS、ArcGIS Pro还是WebGIS，都比较容易扩展。

步骤3：设计地名实体主表

地名实体主表不要放太多变化频繁的信息。它主要保存稳定字段。

place_id            唯一编号
standard_name       标准名称或项目内推荐名称
place_type          类型，例如古县、府、州、城址、驿站、河流、关隘
modern_admin        现代行政区参考
description         简要说明
created_at          创建时间
updated_at          更新时间

其中，place_id建议使用稳定唯一编号，不建议直接使用地名作为主键。因为历史地名可能重名、改名，也可能需要后期修订。

步骤4：单独设计历史名称表

历史名称表是历史地名库的重点。它解决“同地多名”和“同名多地”的问题。

name_id             名称记录编号
place_id            关联地名实体
name_text           名称文本
name_type           正名、别名、古称、异写、简称、现代对应名
start_year          开始年份
end_year            结束年份
dynasty             朝代
source_note         名称说明

如果时间无法精确到年份，可以增加 time_text 字段保存原始时间描述，例如“唐开元年间”“明洪武初”“清中期”。同时用 start_year 和 end_year 存储便于GIS查询的大致时间范围。

步骤5：为历史空间位置单独建表

历史地名库的空间位置不应只存经纬度两个字段。对于GIS使用，最好使用空间几何字段。PostGIS中可以使用 geometry，文件型数据可以使用GeoPackage。

geom_id             空间记录编号
place_id            关联地名实体
geom                空间几何字段，点、线或面
geom_type           point、line、polygon、centroid
start_year          空间位置开始年份
end_year            空间位置结束年份
srid                坐标参考系统编号
accuracy_level      精度等级，例如精确、约略、推测
confidence          置信度，例如高、中、低
locating_method     定位方法，例如旧地图配准、文献推定、现地遗址、权威数据

如果历史行政区划边界无法准确恢复，可以先用代表点表达治所或中心位置，并在 accuracy_level 中标记为“约略”或“推测”。不要把不确定边界画成看似精确的面。

步骤6：统一坐标系与空间精度

历史地名库常见坐标系包括WGS 84经纬度、CGCS2000、高斯克吕格投影坐标以及旧地图配准后的自定义结果。建议在数据库中明确记录SRID。

如果主要用于WebGIS展示，通常会存储WGS 84或Web Mercator可用数据。如果用于面积、距离、缓冲区等空间分析，应转换到合适的投影坐标系后再计算。

• 用于检索和展示：WGS 84经纬度通常更方便。
• 用于距离分析：选择本地区合适的投影坐标系。
• 用于旧地图配准：保留配准控制点、残差和配准方法说明。
• 用于多源数据合并：先统一坐标系，再检查偏移。

步骤7：建立来源表和证据关系

来源表不只是“参考文献列表”，而是历史地名库质量控制的关键。建议至少记录来源标题、类型、年代、页码或图幅信息。

source_id           来源编号
source_title        来源名称
source_type         地方志、历史地图、论文、数据库、档案、实地调查
author              作者或机构
publish_year        出版或成图年份
page_or_sheet       页码、卷次、图幅号
url                 在线地址
citation            引用格式
reliability         可靠性等级

如果一条地名记录同时来自多种来源，不要只保留一个来源字段。可以用 place_evidence 表建立多对多关系，这样后期校核会容易很多。

步骤8：在QGIS或ArcGIS Pro中制作录入模板

对于非程序员团队，建议先用QGIS或ArcGIS Pro制作标准化录入模板，再导入PostGIS或GeoPackage。

1. 创建点图层或面图层，设置统一坐标系。
2. 按字段设计创建属性字段。
3. 给 place_type、accuracy_level、confidence 等字段设置值域。
4. 开启编辑后录入样本数据。
5. 用字段计算器检查空值、重复编号和时间范围。
6. 导出为GeoPackage或直接写入PostGIS。

如果使用ArcGIS Pro，可以通过地理数据库域和子类型控制字段取值。如果使用QGIS，可以通过字段约束、值映射和表单配置降低录入错误。

步骤9：用PostGIS建立基础空间查询

如果历史地名库需要多人维护、WebGIS服务或复杂空间查询，PostGIS是很合适的选择。下面是一个简化的建表示例。

CREATE TABLE place_entity (
  place_id SERIAL PRIMARY KEY,
  standard_name TEXT NOT NULL,
  place_type TEXT,
  modern_admin TEXT,
  description TEXT
);

CREATE TABLE place_geometry (
  geom_id SERIAL PRIMARY KEY,
  place_id INTEGER REFERENCES place_entity(place_id),
  geom geometry(Geometry, 4326),
  geom_type TEXT,
  start_year INTEGER,
  end_year INTEGER,
  accuracy_level TEXT,
  confidence TEXT,
  locating_method TEXT
);

CREATE INDEX idx_place_geometry_geom
ON place_geometry
USING GIST (geom);

建立空间索引后，可以支持范围查询、附近查询和与历史行政区划叠加查询。对于历史地名库来说，空间索引不是可有可无，数据量上来以后它会直接影响检索速度。

步骤10：做数据校验与样本测试

数据库建好后，不要立刻大批量录入。建议先选20到50条典型地名做样本测试，覆盖点、面、别名、时间变化、来源不确定等情况。

• 按名称能否查到同一个地名实体？
• 按朝代或年份能否筛选出正确记录？
• 地图上是否存在明显坐标偏移？
• 同名地名是否被错误合并？
• 来源字段是否足够支持追溯？
• QGIS、ArcGIS Pro或WebGIS是否能正常读取空间字段？

常见坑：历史地名库建设最容易出错的地方

坑1：把历史地名当成现代POI处理

现代POI通常是一点一名，而历史地名经常是一地多名、一名多地、位置变化、范围变化。如果直接用POI表结构，会很快遇到重复、冲突和无法追溯的问题。

坑2：只存经纬度，不存坐标系和定位方法

经纬度本身不能说明数据可靠。必须记录坐标系、定位方法、精度等级和置信度。尤其是从旧地图配准得到的位置，更应保留配准说明。

坑3：时间字段只写朝代名称

只写“唐代”“明代”适合阅读，但不利于数据库查询。建议同时保留文本时间和数值时间范围。比如 dynasty 存“唐”，time_text 存“开元年间”，start_year 和 end_year 存近似年份。

坑4：把不确定边界画得过于精确

历史边界常常无法完全复原。如果证据不足，可以用点、范围框、模糊区或说明字段表达不确定性。不要为了地图好看而制造虚假的精确边界。

坑5：来源记录太粗

只写“来自地方志”是不够的。至少要写清书名、卷次、页码、版本或数字化链接。历史地名库后期最耗时的工作，往往是回头查来源。

坑6：没有唯一编号规则

地名会改，名称会重复，所以不能用名称做唯一标识。建议使用稳定的 place_id，并在导入、修改、发布过程中保持不变。

方法比较：不同GIS数据库方案怎么选

方案	适合场景	优点	限制
Excel或CSV	早期整理、文献摘录、少量点位	门槛低，方便人工录入	不适合复杂空间关系和多人协作
GeoPackage	QGIS单机项目、教学练习、中小规模数据	一个文件保存空间图层和属性表，跨平台较好	多人并发和Web服务能力有限
File Geodatabase	ArcGIS Pro工作流、机构内部制图和编辑	支持域、子类型、拓扑等地理数据库能力	跨开源生态使用时需要注意兼容性
PostGIS	多人维护、WebGIS发布、空间查询、长期项目	空间索引强，查询能力强，适合服务端应用	需要数据库部署、权限管理和SQL基础

如果只是课程作业或小型研究，GeoPackage已经足够。如果要做历史地名平台、开放查询接口或长期维护项目，建议尽早使用PostGIS。GIS数据库设计并不是越复杂越好，而是要和项目规模匹配。

检查清单：开始建库前先确认这些问题

• 是否明确历史地名库的主要用途：检索、制图、分析还是发布？
• 是否区分了地名实体、名称记录、空间位置和来源证据？
• 是否为每个地名实体设计了稳定唯一编号？
• 是否记录历史名称的起止时间或时间说明？
• 是否记录空间位置的坐标系、精度等级和定位方法？
• 是否允许一个地名实体对应多个历史名称和多个空间位置？
• 是否记录来源的书名、页码、图幅、链接或引用格式？
• 是否考虑同名异地、异名同地和治所迁移？
• 是否在大规模录入前完成样本测试？
• 是否能被QGIS、ArcGIS Pro、PostGIS或WebGIS顺利读取？

FAQ：历史地名库怎么建的常见问题

1. 历史地名库一定要用PostGIS吗？

不一定。如果只是学习、论文配图或小规模整理，可以先用GeoPackage。它能在QGIS中直接编辑，也能保存空间数据和属性字段。如果项目需要多人协作、WebGIS查询、接口服务和长期维护，再使用PostGIS更合适。

2. 历史地名库的点、线、面应该怎么选？

古城、治所、遗址、驿站通常可以先用点表示。古道、河流、边界适合用线。行政区划、区域范围适合用面。但如果历史边界证据不足，不要强行画面，可以先用代表点加说明字段表达。

3. 历史地名库需要记录现代行政区吗？

建议记录，但不要把现代行政区当作历史归属。现代行政区字段主要用于检索和定位参考，比如“今属某省某市某县”。历史归属应单独设计字段或关系表，并带有时间范围。

4. 历史地名的时间不确定怎么办？

可以同时使用文本时间和数值时间。文本时间保留原始描述，数值时间用于查询和筛选。对于不确定时间，可以用较宽的 start_year 和 end_year，并在备注中说明依据和不确定性。

5. 同一个地名有多个坐标来源，应该保留哪一个？

不要简单删除其他来源。可以把不同坐标作为多条空间记录保存，并记录来源、置信度和定位方法。项目展示时可以选择一个推荐位置，但数据库中应保留校核痕迹。

6. GIS数据库设计难不难，非程序员能做吗？

不难入门，但要有结构化思维。非程序员可以先用QGIS或ArcGIS Pro制作字段模板，使用GeoPackage录入数据。等数据模型稳定后，再让数据库或WebGIS人员迁移到PostGIS。

结论：历史地名库建设的关键是结构清楚、证据可追溯

历史地名库怎么建，关键不在于软件多高级，而在于GIS数据库设计是否把“地名、时间、空间、来源”分清楚。只要从最小可用模型开始，先做样本测试，再逐步扩展字段和关系，历史地名库并不难建设。

实际工作中，建议先用QGIS或ArcGIS Pro完成样本数据整理，再根据项目规模选择GeoPackage、File Geodatabase或PostGIS。无论使用哪种工具，都要避免只存名称和坐标，而忽略时间范围、定位精度和来源证据。这样建出来的历史地名库，才真正能用于查询、制图、分析和长期维护。