CN112699640A - 基于PostgreSQL的地理编码方法和系统 - Google Patents

Abstract

本申请涉及基于PostgreSQL的地理编码方法和系统，其中方法包括：获取城市管理所需的基础地理数据、城市部件数据和地址类数据；当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述地址类数据生成一对应的地址类地址串，对每个所述地址类地址串进行分词得到地址词向量集合；根据所述基础地理数据为每个所述城市部件数据生成一对应的部件类地址串，对每个所述部件类地址串进行分词得到部件词向量集合；为所述部件数据表创建部件物化视图；为所述地址类数据表创建地址物化视图。本方案解决数字化城市管理中，现有地理编码实现途径的不足的问题。

Description

基于PostgreSQL的地理编码方法和系统

技术领域

本申请涉及数字化城市管理领域，特别是涉及基于PostgreSQL的地理编码方法和系统。

背景技术

在当下流行的智慧城市、数字城管等城市信息化管理平台中，地理编码系统是其中核心的基础支撑系统之一。地理编码技术的关键在于：在拥有地理空间位置属性的数据与实际对应的地理坐标之间，通过标准地址串建立映射关系。具体应用在数字化城市管理中，就是将所关注的城市内部对象（如兴趣点、城市部件、商店/住户地址等）在数字化的基础上，进行空间化与地址标准化，从而便于用户与下游业务系统通过地址信息来访问或调用对应空间位置上的城市数据资源，实现各种空间范围（行政区划、单元网格等）的信息整合。

现有的地理编码技术在城市管理信息化平台中的实现主要分为以下几种途径：

1.利用在线地图服务商的地理编码API实现（廖薇薇, 柳林, 周素红, 宋广文,李秋萍, & 刘凯. (2018). 多源在线地理编码服务分类优化模型. 热带地理, 38(2),255-263.）。

2.利用成熟的商用GIS（地理信息系统）研发框架（专利号：CN 105022770 B，国别：中国，公开日期：2019/01/25）或数据库产品（夏兰芳, 毛炜青, & 郭功举. (2012). 上海城市地理编码系统应用与研究. 测绘通报, 1, 78-80.）实现。

3.利用基于Lucene搜索引擎技术实现（张敏. (2014). 地理编码服务体系在智慧城市公共信息整合中的应用与研究 (Master's thesis, 中国地质大学 (北京))）。

对于实现途径1，目前，天地图、腾讯地图、百度地图、高德地图等大型在线地图服务提供商旗下的地图产品，都提供地理编码 API用作二次开发，极大降低了开发难度。但是，以上地图产品存在以下问题：a. 用户在使用相关地理编码服务时，必须通过互联网维持与地图服务提供商的服务器连通和访问。但城市管理信息化平台的相关用户，常常出于安全的考虑，对网络访问进行了限制，用户只能连接内部的局域网，无法访问公网。如果处于局域网的环境，相关地图服务提供商的地理编码API则难以直接调用。b. 相关在线地图服务商的地理编码服务API往往只能针对一些通用地址对象（小区、街道、公共建筑、地标等），无法直接对用户的定制化业务数据（如城市部件）进行地理编码。而且不同的地图服务商的数据采集来源与更新频率存在差异，因此在不同地区的地理编码服务质量也不尽相同，未必能满足部分地区用户的需求。c.虽然在线地图服务提供商可能通过私有云部署服务的方式解决内网访问限制与业务数据接入的问题，但是部分服务商对其下所有的地图相关服务使用了特殊的坐标系统，这就导致用户在正确使用这些服务商的地理编码服务之前，往往需要对自身的业务数据进行额外的转换/迁移工作，增加了使用成本。

对于实现途径2，虽然成熟的商业GIS研发框架/数据库产品的功能强大，稳定可靠。但往往价格高昂，对于预算有限的用户，这将成为选择该实现途径的主要障碍。

对于实现途径3，虽然使用开源搜索引擎框架Lucene不存在商用产品的授权使用费问题，而且该框架在解决地理编码核心任务之一的中文分词匹配问题上，拥有强大的性能。但是由于该框架技术较新，并且采用的是非关系型数据库的数据组织与存储形式。对于那些拥有大量需要进行地理编码的历史数据，却将这些数据存储在传统关系型数据库的用户而言，采用该实现途径会产生额外的数据转换/迁移成本。此外，该实现途径对于管理地区范围较小、地理编码数据量较小的用户而言，也会额外增加运维成本。

此外，在数字化城市管理系统中，若采用传统的关系型数据库的存储架构，则往往需要将地理编码查询的数据按照对象类型、所属地区、采集时间等区分标识，进行分表存储（比如，城市部件数据按部件类型分表存储），以方便相关维护工作。但地理编码查询往往需要基于全量数据进行搜索，而这种分表的数据存储方式，为相关查询任务带来挑战。虽然可以通过元数据表与传统数据库视图的方式，将分表数据先聚合然后再查询，但是当分表数量较多时，这种基于多表连接的聚合查询方式会产生严重的效率问题。

最后，数字化城市管理中，如何将用户搜索的地址串匹配地理编码库中对应的标准地址串，是地理编码查询的核心任务之一，而利用基于分词相似的全文搜索是解决该问题的主流方法，但是该方法会在搜索地址串与标准地址串的字符长度差异过大时（通常是字符长度：搜索地址串<<标准地址串时），会降低搜索的召回率。

发明内容

为解决数字化城市管理中，现有地理编码实现途径的不足，本发明提出了一种基于PostgreSQL的地理编码方法和系统，具体方案如下：

第一方面，本申请实施例提供了基于PostgreSQL的地理编码方法，所述方法包括：获取城市管理所需的基础地理数据、城市部件数据和地址类数据；当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述地址类数据生成一对应的地址类地址串，对每个所述地址类地址串进行分词得到至少一个地址词，生成每个所述地址词的地址词向量，将所述地址词、所述地址词向量作为所述地址类地址串的地址词向量集合；当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述城市部件数据生成一对应的部件类地址串，对每个所述部件类地址串进行分词得到至少一个部件词，生成每个所述部件词的部件词向量，将所述部件词、所述部件词向量作为所述部件类地址串的部件词向量集合；至少以所述城市部件类数据、所述部件类地址串、所述部件词向量生成部件数据表，为所述部件数据表创建部件物化视图；至少以所述地址类数据、所述地址类地址串、所述地址词向量生成地址类数据表，为所述地址类数据表创建地址物化视图。

第二方面，本申请实施例提供了一种基于PostgreSQL的地理编码系统，包括数据源模块，用于获取城市管理所需的基础地理数据、城市部件数据和地址类数据；地址类数据处理子模块，用于当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述地址类数据生成一对应的地址类地址串，对每个所述地址类地址串进行分词得到至少一个地址词，生成每个所述地址词的地址词向量，将所述地址词、所述地址词向量作为所述地址类地址串的地址词向量集合；部件类数据处理子模块，用于当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述城市部件数据生成一对应的部件类地址串，对每个所述部件类地址串进行分词得到至少一个部件词，生成每个所述部件词的部件词向量，将所述部件词、所述部件词向量作为所述部件类地址串的部件词向量集合；物化视图创建子模块，用于至少以所述城市部件类数据、所述部件类地址串、所述部件词向量生成部件数据表，为所述部件数据表创建部件物化视图；至少以所述地址类数据、所述地址类地址串、所述地址词向量生成地址类数据表，为所述地址类数据表创建地址物化视图。

第三方面，本申请实施例提供了一种电子装置，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的基于PostgreSQL的地理编码方法。

第四方面，本申请实施例提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的基于PostgreSQL的地理编码方法。

相比于相关技术，本申请实施例提供的基于PostgreSQL的地理编码方法，解决数字化城市管理中，现有地理编码实现途径的不足的问题。通过为部件数据生成部件类地址串以及对应的部件词向量，能够对用户的定制化业务数据（如城市部件）进行地理编码。

通过建立物化视图将传统数据库视图查询出的结果在磁盘中存成数据快照，在地理编码查询时相当于对特殊的实体表进行查询，而不直接涉及多表连接问题，因此提高了地理编码查询效率。

此外，针对背景技术中提出的搜索地址串与标准地址串的字符长度差异过大时（通常是字符长度：搜索地址串<<标准地址串时），会降低搜索的召回率的问题，本申请还使用字符相似作为全文检索的补充，创建了归一化的结合字符相似与分词相似的地址串相似匹配的判断方法，提高了地理编码查询的召回率。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的基于PostgreSQL的地理编码方法的流程图；

图2是根据本申请实施例的一种地理编码数据组织管理方法的流程图；

图3是根据本申请实施例的一种地理编码查询方法的流程图；

图4是根据本申请实施例的一种城市地理编码数据维护方法的流程图；

图5是根据本申请实施例的基于PostgreSQL的地理编码系统的功能架构图；

图6是根据本申请实施例的电子装置的硬件结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

实施例一

请参阅图1，所示为本发明实施例一中的基于PostgreSQL的地理编码方法，该方法包括步骤101至步骤105：

步骤S101，获取城市管理所需的基础地理数据、城市部件数据和地址类数据；

步骤S102，当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述地址类数据生成一对应的地址类地址串，对每个所述地址类地址串进行分词得到至少一个地址词，生成每个所述地址词的地址词向量，将所述地址词、所述地址词向量作为所述地址类地址串的地址词向量集合；

步骤S103，根据所述基础地理数据为每个所述城市部件数据生成一对应的部件类地址串，对每个所述部件类地址串进行分词得到至少一个部件词，生成每个所述部件词的部件词向量，将所述部件词、所述部件词向量作为所述部件类地址串的部件词向量集合；

步骤S104，以每个所述城市部件类数据、每个所述部件类地址串、每个所述部件词向量集合生成部件数据表，为所述部件数据表创建部件物化视图；

步骤S105，以每个所述地址类数据、每个所述地址类地址串、每个所述地址词向量集合生成地址类数据表，为所述地址类数据表创建地址物化视图。

在本实施例中，部件数据表被存储在PostgreSQL数据库中，部件数据表中的部件类地址串可以通过PostgreSQL数据库自带的函数处理为部件词向量，至少以城市部件类数据、部件类地址串、部件词向量集合的数据为基础，创建地理编码的查询对象——部件物化视图。同理，地址类数据表中的地址类地址串也可以通过PostgreSQL数据库自带的函数处理为地址词向量，至少以地址类数据、地址类地址串、地址词向量集合的数据为基础，创建地理编码的查询对象——地址物化视图。通过建立部件物化视图和地址物化视图将传统数据库视图查询出的结果在磁盘中存成数据快照，在地理编码查询时相当于对特殊的实体表进行查询。

在本方案中，每个部件类地址串可能包括十几个部件词，例如浙江、杭州、井盖等，每个部件词对应有一个部件词向量，如'杭州':7是杭州的部件词向量。将所有的部件词、部件词向量组合在一起生成部件词向量集合，并存储在数据表中。同理，地址类词向量集合可以理解为对地址类地址串进行分词后得到的集合。

在本例中，既可以对通用地址对象（表示为地址类地址串）进行查询，还可以对定制化业务数据（表示为部件类地址串）进行查询，也就是说，本方案通过满足对城市部件进行地理编码的需求，从而提高了地理编码服务质量。

在其中一个实施例中，所述方法还包括：接收所述数据更新请求；根据所述数据更新请求对所述城市部件数据和/或所述地址类数据进行更新；基于更新后的城市部件数据和/或地址类数据更新所述部件物化视图、所述地址物化视图。

在其中一个实施例中，所述方法还包括：定时监控所述城市部件数据和所述地址类数据，若检测到所述城市部件数据和/或所述地址类数据更新，生成所述数据更新请求。

在其中一个实施例中，基于所述城市部件数据在所述基础地理数据中的空间从属关系生成所述部件类地址串；基于所述地址类数据在所述基础地理数据中的空间从属关系生成所述地址类地址串。

在本例中，基础地理数据指各级行政区划、单元网格、街巷，地址类数据指地区/片区、门（楼）牌、兴趣点等等，城市部件数据指电力井盖、雨水井盖、路灯等等。上述数据被存储在PostgreSQL数据库中。再根据空间从属关系生成部件类地址串和地址类地址串。其中，空间从属关系指的是地址类数据或城市部件数据在空间上属于的具体的基础地理数据，例如，根据电力井盖在空间上属于的街巷、单元网格、行政区划，为该电力井盖生成一部件类地址串。在实际操作中空间从属关系可以通过空间拓扑关系函数获得。

步骤S101至S103可被具体描述为：

步骤A1：在系统初始化或收到数据库更新请求时，将地址类数据、基础地理数据聚合至地址类数据处理子模块进行下一步处理；将城市部件数据、基础地理数据聚合至城市部件类数据处理子模块进行下一步处理。

在地址类数据处理子模块中执行以下步骤：

步骤A2.a1：针对地址类数据（地片/区片、门（楼）牌、兴趣点…）, 利用空间拓扑关系函数，获得各地址类数据在街巷、单元网格、各级行政区划的空间从属关系。

步骤A2.a2: 根据步骤A2.a1获得的空间从属关系，生成地址类数据的标准地址串作为地址类地址串。

步骤A2.a3: 将步骤A2.a2获得的地址类地址串，处理为地址类词向量，并将该地址类词向量保存为数据表中的新字段。

步骤A2.a4: 将上述地址类相关的数据通过多表连接汇总。

在城市部件类数据处理子模块中执行以下步骤：

步骤A2.b1: 针对城市部件数据（电力井盖、雨水井盖、路灯…）, 利用空间拓扑关系函数，获得各城市部件数据在街巷、单元网格、各级行政区划的空间从属关系。

步骤A2.b2: 根据步骤A2.b1获得的空间从属关系，生成城市部件数据的标准地址串作为部件类地址串。

步骤A2.b3: 将步骤A2.b2获得的部件类地址串，处理为部件词向量，并将该部件词向量保存为数据表中的新字段。

步骤A2.b4: 将上述城市部件相关数据通过多表连接汇总。

在其中一个实施例中，分别为所述部件物化视图中的所述部件词向量集合、所述地址物化视图中的所述地址词向量集合添加索引。

传统的地理编码数据大多存在传统关系型数据库中，若迁移到开源搜索引擎框架Lucene，会产生额外的数据转移/迁移成本，在本例中，采用开源的关系型数据库产品PostgreSQL，避免了数据迁移成本。且通过为相关视图添加索引来优化关系型数据库的查询效率。

在其中一个实施例中，所述方法还包括：

步骤S106，获取待查询对象的搜索地址串，对所述搜索地址串进行分词得到至少一个搜索词，生成每个所述搜索词的搜索词向量，将所述搜索词、所述搜索词向量作为所述搜索地址串的搜索词向量集合；

步骤S107，判断所述搜索词向量是否存在所述部件词向量集合中的关键词，若存在，导向到所述部件物化视图；

步骤S108，计算所述搜索词向量集合与所述部件物化视图中的每个所述部件词向量集合的匹配度；

步骤S109，获取与所述搜索词向量集合匹配度最高的所述部件词向量集合所对应的所述部件类地址串。

在本例中提出了一种基于分词相似与字符相似的归一化地址串匹配度的判断方法，该方法将搜索词向量集合与地理编码的查询对象中的每个部件词向量集合或者地址词向量集合进行相似度匹配，得到匹配度最高的部件词向量集合或者地址词向量集合并输出给地理编码的查询对象的调用方。

在本例中，当获取到待查询对象的搜索地址串后，通过判断搜索词向量是否有部件词向量集合的部件关键字，导向到所述部件物化视图或地址物化视图中；在物化视图中对地理编码数据进行查询，避免了多表连接的聚合查询带来的效率低的问题。

该方法与现有技术的区别之处在于，通过对地理编码的查询对象进行查询不直接涉及多表连接问题，提高地理编码查询效率。而开源的关系型数据库产品中，PostgreSQL对物化视图有着完善的支持，因此本发明将数据存储在PostgreSQL数据库，针对聚合了地理编码数据的物化视图进行查询。利用该方法一方面摆脱商业产品授权的制约。另一方面，既维持了依照数据的指定特征进行分表带来的方便运维的优点，同时确保了地理编码数据聚合查询得高效。

值得注意的是，在相关技术中，如何将用户搜索的搜索地址串匹配到地理编码库中对应的标准地址串上，一直是地理编码查询的核心任务之一。而传统上基于分词相似的全文搜索是解决该问题的主流方法，但是该方法会在搜索地址串与标准地址串的字符长度差异过大时（通常是字符长度：搜索地址串<<标准地址串时），会导致搜索召回率低。

因此，在其中一个实施例中，“计算所述搜索词向量与所述部件物化视图中的每个所述部件词向量的匹配度”包括：计算所述搜索地址串与所述部件物化视图中的每个所述部件类地址串的字符相似，以及所述搜索词向量集合与所述部件物化视图中的每个所述部件词向量集合的分词相似，将结合所述字符相似和所述分词相似的归一化地址串相似匹配计算的结果作为匹配度。

同样的，计算所述搜索地址串与所述地址物化视图中的每个所述地址类地址串的字符相似，以及所述搜索词向量集合与所述地址物化视图中的每个所述地址词向量集合的分词相似，确定所述匹配度为结合所述字符相似和所述分词相似的归一化地址串相似匹配计算的结果。

在本例中，该方案可以被描述为以下公式：

其中，R(x,y)代表归一化的地址串匹配度的判断指标，其值域为0.5到2.0。

0.5 代表搜索的地址串与地理编码查询对象上某条标准地址串进行匹配，在简单字符对比与分词向量对比上完全不相似。

2.0 代表搜索的地址串与地理编码查询对象上某条标准地址串进行匹配，在简单字符对比与分词向量对比上完全相同。

公式中：

x指的是搜索地址串，y指的是查询对象的标准地址串（本例中指的是地址类地址串或部件类地址串）。

t(x)与t(y)指的是字符串分词向量化函数。

α指的是搜索地址串对应的搜索词向量集合。

β指的是查询对象的标准地址串对应的部件词向量集合或地址词向量集合。

f(x,y)指的是字符相似度计算函数。

g(α,β)指的是词向量相似性计算函数。

该方法使用字符相似作为全文检索的补充，运用logistic函数进行数据归一化的思想，消除字符相似与分词相似在量纲上的差异，通过归一化的结合字符相似与分词相似的匹配方法对地址串匹配度进行判断，提高了地理编码查询的召回率。

实施例二

请参阅图5，本实施例还提供了一种基于PostgreSQL的地理编码系统，该系统用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

具体地，系统包括数据源模块M1、数据组织管理模块M2、查询模块M3、数据维护模块M4，其中，

数据源模块M1，用于获取城市管理所需的基础地理数据、城市部件数据和地址类数据；

地址类数据处理子模块M201，用于当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述地址类数据生成一对应的地址类地址串，对每个所述地址类地址串进行分词得到至少一个地址词，生成每个所述地址词的地址词向量，将所述地址词、所述地址词向量作为所述地址类地址串的地址词向量集合；

部件类数据处理子模块M202，用于当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述城市部件数据生成一对应的部件类地址串，对每个所述部件类地址串进行分词得到至少一个部件词，生成每个所述部件词的部件词向量，将所述部件词、所述部件词向量作为所述部件类地址串的部件词向量集合；

物化视图创建子模块M203，用于至少以所述城市部件类数据、所述部件类地址串、所述部件词向量生成部件数据表，为所述部件数据表创建部件物化视图；至少以所述地址类数据、所述地址类地址串、所述地址词向量生成地址类数据表，为所述地址类数据表创建地址物化视图。

在其中一个实施例中，该系统还包括数据维护模块M4，其中，所述数据维护模块M4包括：

数据监控子模块M402，用于定时监控所述城市部件数据和所述地址类数据，若检测到所述城市部件数据和/或所述地址类数据更新，生成所述数据更新请求；

数据更新子模块M401，用于获取所述数据更新请求；根据所述数据更新请求对所述城市部件数据和/或所述地址类数据进行更新；基于更新后的城市部件数据和/或地址类数据更新所述部件物化视图、所述地址物化视图。

在其中一个实施例中，该系统还包括：查询模块M3，其中，所述查询模块包括：

查询任务分发子模块M301，用于获取待查询对象的搜索地址串，对所述搜索地址串进行分词得到至少一个搜索词，生成每个所述搜索词的搜索词向量，将所述搜索词、所述搜索词向量作为所述搜索地址串的搜索词向量集合；判断所述搜索词向量是否存在所述部件词向量集合中的关键词，若存在，导向到所述部件物化视图；若不存在，导向到所述地址物化视图；

地址串匹配子模块M302，用于计算所述搜索词向量集合与所述部件物化视图中的每个所述部件词向量集合的匹配度；获取与所述搜索词向量集合匹配度最高的所述部件词向量集合所对应的所述部件类地址串；和/或计算所述搜索地址串与所述地址物化视图中的每个所述地址类地址串的字符相似，以及所述搜索词向量集合与所述地址物化视图中的每个所述地址词向量集合的分词相似，确定所述匹配度为结合所述字符相似和所述分词相似的归一化地址串相似匹配计算的结果。

下面结合表格对实施例二中的数据管理模块和查询模块的实施作详细说明。应该强调的是，下述说明仅仅是示例性的，而不是为了限制本发明的范围及其应用。

如表1-1至表1-2所示，城市管理所需的数据源包括基础地理数据，其中基础地理数据至少由两张表组成，包括用来存储各级行政区划与单元网格信息的区划表以及存储区划下的街巷信息的街巷表。

表1-1基础地理数据（区划表gis_geocode_dist）

字段名称	字段类型	字段含义
			id	serial4	主键
name	varchar(50)	名称
			code	varchar(15)	标识码
alias	varchar(100)	别名
			old_name	varchar(100)	曾用名
data_source	varchar(50)	数据来源
			or_date	date	初始日期
ch_date	date	变更日期
			note	varchar(255)	备注
geom	geometry	空间坐标（区域中心点）
			type_code	int2	区域类型 1：单元网格，2：社区，3：街道，4：区县，5：市
province	varchar(50)	所在省名

表1-2基础地理数据（街巷表gis_geocode_street）

字段名称	字段类型	字段含义
			id	serial4	主键
str_name	varchar(50)	名称（街巷的标准名称，如东长安街、北四环东路）
			str_code	varchar(15)	标识码（街巷代码，值唯一）
alias	varchar(50)	别名 （标准名称以外的其他名称，{别名1/.../别名n}）
			old_name	varchar(50)	曾用名（以往所用的名称，{曾用名1/.../曾用名n}）
s_house_num	varchar(25)	最小门（楼)牌号
			l_house_num	varchar(25)	最大门（楼)牌号
begining	varchar(50)	起点名称
			ending	varchar(50)	止点名称
direction	varchar(50)	走向（街巷胡同方向，如：东-西向，东北-西南向等）
			route_name	varchar(50)	所属道路名称（包括该街巷的复合道路总称，如长安街、四环路）
data_source	varchar(60)	数据来源（包括实测/地形图/基础地理数据/其他）
			or_date	date	初始日期（格式：YYYY-MM-DD）
ch_date	date	变更日期（格式：YYYY-MM-DD）
			note	varchar(255)	备注
geom	geometry	空间字段(街巷中心线)

如表1-3至表1-5所示，城市管理所述的数据源还包括地址类数据，其中地址类数据至少由三张表组成，包括地区/片区表、门（楼）牌表以及兴趣点表。

表1-3地址类数据（地片/区片表 gis_geocode_zone）

字段名称	字段类型	字段含义
			id	serial4	主键
zone_name	varchar(50)	地片或区片的标准名称
			zone_code	varchar(15)	地片或区片代码
alias	varchar(50)	别名
			old_name	varchar(50)	曾用名
boundary	varchar(256)	四至范围（文字描述地片或区片的四至范围，如：东至：xxx,西至：xxx,南至：xxx,北至：xxx）
			sub_dis_name	varchar(50)	所在街道（镇、乡）名称
sub_dis_code	varchar(9)	所在街道（镇、乡）代码
			commu_name	varchar(50)	所在社区（村）名称
commu_code	varchar(12)	所在社区（村）代码
			data_source	varchar(60)	数据来源
or_date	date	初始日期
			ch_date	date	变更日期
note	varchar(255)	备注
			geom	geometry	空间坐标（地片与区片标识点的几何中心）

表1-4地址类数据（门（楼）牌表 gis_geocode_building）

字段名称	字段类型	备注
			id	serial4	主键
door_name	varchar(50)	名称（门楼盘上完整的内容，如：东40条甲34号院1号楼、小黄庄6号楼）
			door_code	varchar(15)	标识码（门(楼)牌代码，值唯一）
road_name	varchar(100)	所在街巷（门(楼)牌所在街巷的名称，如东四十条）
			zone_name	varchar(100)	所在地片区域（门(楼)牌所在地片、区片的名称，如小黄庄）
house_num	varchar(16)	门（楼）牌号
			sub_dis_name	varchar(50)	所在街道（镇、乡）名称
sub_dis_code	varchar(9)	所在街道（镇、乡）代码
			commu_name	varchar(50)	所在社区（村）名称
commu_code	varchar(12)	所在社区（村）代码
			data_source	varchar(60)	数据来源（包括实测/地形图/基础地理数据/其他）
or_date	date	初始日期（格式：YYYY-MM-DD）
			ch_date	date	变更日期（格式：YYYY-MM-DD）
note	varchar(255)	备注
			geom	geometry	空间坐标（门牌位置点平面坐标）

表1-5地址类数据（兴趣点表 gis_geocode_poi）

字段名称	字段类型	备注
			id	serial4	主键
poi_name	varchar(50)	兴趣点名称（地铁3号线津湾广场站C口、国子监街东牌楼、雍和大厦等）
			poi_code	varchar(15)	兴趣点代码（唯一）
alias	varchar(100)	别名 （{别名1/.../别名n}）
			old_name	varchar(100)	曾用名 （{曾用名1/.../曾用名n}）
floor	char(6)	所在层（所在构（建）筑物的层数{-n..-1}{1..n}）
			data_source	varchar(50)	数据来源（包括实测/地形图/基础地理数据/其他）
or_date	date	初始日期（格式：YYYY-MM-DD）
			ch_date	date	变更日期（格式：YYYY-MM-DD）
note	varchar(255)	备注
			geom	geometry	空间坐标（兴趣点的空间位置）

如表1-6所示，城市管理所述的数据源还包括城市部件数据，其中城市部件数据至少由一张表组成，包括部件信息表，其中gis_unit_xx的xx代表部件类型名称/唯一类型标识。

表1-6城市部件数据（部件信息表 gis_unit_xx）

字段名称	字段类型	备注
			id	serial4	主键
code	varchar(32)	编码
			unit_code	varchar(32)	部件编码
unit_name	varchar(32)	部件名称
			status	varchar(32)	状态: 1完好，2损坏，3维护中，4丢失，5占用，6作废，99其他
supv_code	varchar(64)	主管单位代码
			supv_name	varchar(64)	主管单位名称
owner_code	varchar(64)	权属单位代码
			owner_name	varchar(64)	权属单位名称
maintain_code	varchar(64)	养护单位代码
			maintain_name	varchar(64)	养护单位名称
address	varchar(255)	地址
			pic_urls	text	部件图片相对路径
grid_code	varchar(32)	网格标识
			or_date	date	初始日期（格式：YYYY-MM-DD）
ch_date	date	变更日期（格式：YYYY-MM-DD）
			property	text	具体属性
geom	geometry	空间字段

需要注意的是，以上表结构中涉及的空间字段（geom），描述表记录对应的实体在地理空间中的几何轮廓与位置，在数据源导入前需安装PostgreSQL的空间处理插件——PostGIS。

图2是根据本申请实施例的一种地理编码数据组织管理方法的流程图，参考图2，该方法包括以下步骤：

步骤p201，当系统初始化或收到数据库更新请求时，从表1-1至表1-6中获取地址类数据、城市部件数据在在街巷、单元网格、各级行政区划的空间从属关系。在具体实施过程中，空间从属关系由PostGIS的ST_within函数决定。

步骤p202，根据空间从属关系生成部件类地址串或地址类地址串，上述地址串由标准地址串表示。

具体实施例中，标准地址串的格式为：

[省名],[市名],[区/县名],[社区名],[街道名],[所在路名],[地片名/单元网格名],[门(楼)牌号/兴趣点名称/城市部件名称]

其中若有缺失部分，则将其余部分遵从以上规则用英文逗号隔开。

举例：“浙江省,杭州市,滨江区,浦沿街道,东信大道,单元网格xxxx号,雨水井盖yyyy号”。

步骤p203，将标准地址串字段处理为词向量集合，并存为新字段（字段名：fullname_vector）。

在具体实施过程中，步骤p202中的标准地址串将通过PostgreSQL的to_tsvector函数处理为如下词向量集合：

“'xxxx':31 'yyyy':39 '东信':21 '井':37 '井盖':36 '信':22 '区':17 '单':27 '单元':26 '号':32,40 '大':24 '大道':23 '州':10 '州市':8 '市':11 '杭':9'杭州':7 '杭州市':6 '格':60 '水':35 '江':4,16 '江区':14 '江省':3 '浙江':2 '浙江省':1 '浦':18 '滨':15 '滨江':13 '滨江区':12 '盖':38 '省':5 '网':29 '网格':28 '街':19 '道':20,25 '雨':34 '雨水':33”。

步骤p204: 汇总数据。

在具体实施过程中通过LEFT JOIN与UNION等SQL关键字进行多表连接，以聚合在数据源模块中分表存储的数据。

步骤p205: 以步骤p204中汇总的数据为基础，创建/刷新地理编码的查询对象——物化视图。

在具体实施过程中，使用CREATE MATERIALIZED VIEW句柄创建物化视图；使用REFRESH MATERIALIZED VIEW CONCURRENTLY句柄对已创建的物化视图进行更新，以提高并发环境下的地理编码查询性能。

步骤p206: 为步骤205中创建的物化视图部件词向量集合、地址词向量集合添加索引。

在具体实施过程中，对物化视图中的标准地址串字段使用Gin索引；对标准地址串的词向量集合字段使用Rum索引。需要注意的是Rum索引不是PostgreSQL自带的索引类型，需要以插件形式另行安装。

步骤p201至步骤p206提出了一种地理编码数据组织管理方法，在步骤p201至步骤p206中，数据管理模块根据基础地理数据，负责将地址类数据、城市部件数据分别聚合为存有标准地址串信息的物化视图（地理编码查询对象），并为创建的物化视图添加索引从而优化查询效率。

图3是根据本申请实施例的一种地理编码查询方法的流程图，参考图3，该方法包括以下步骤：

步骤p301，接受查询调用方输入的搜索地址串，例如：“兰州拉面馆”。

步骤p302，将步骤p601中的搜索地址串将通过PostgreSQL的plainto_tsquery函数处理为词向量——α。

步骤p303，判断α中是否存在城市部件类型的关键词，若存在，则将查询对象设置为城市部件类地理编码数据的聚合物化视图V1；若不在，则将查询对象设置为地址类地理编码数据的聚合物化视图V2。

在具体实施过程中，若α中出现“井盖”、“路灯”之类的城市部件类型的名称，则会将查询对象指定为城市部件类的物化视图V1, 否则指定为V2；

步骤p304: 获取查询对象的标准地址串的词向量β。

步骤p305: 利用基于分词相似与字符相似相结合的归一化地址串匹配法计算α与β的匹配程度。

在实施例中，f(x,y)可以由类似以下SQL语句实现：

“‘[标准地址串]’<-> '[搜索地址串]'”

g(x,y)可以由类似以下的SQL语句实现：

“‘[标准地址串的词向量]’<=> '[搜索地址串的词向量]'”

步骤p306: 对匹配程度最高的n个查询结果，进行降序排序，并获得与之对应的标准地址串列表。

步骤p307: 将步骤p306中的标准地址串列表输出给查询模块的调用方。

步骤p301至p307提出了一种地理编码查询方法，在步骤p301至步骤p307中，查询模块根据搜索地址串来查询与搜索地址串匹配度最高的地址类信息或城市部件信息，并将结果返回给调用方，需要注意的是，该实施例的正常执行，需要PostgreSQL中安装zhparser中文全文分词插件作为前提条件。

在其中一个实施例中，系统还包括：

数据源模块，用于获取城市管理所需的基础地理数据、城市部件数据和地址类数据，其中，所述基础地理数据、所述城市部件数据和所述地址类数据按类型分表存储于PostgreSQL数据库中。

在其中一个实施例中，系统还包括数据维护模块，其中，所述数据维护模块包括：

数据更新子模块，用于接收数据库更新请求；根据所述数据库更新请求对所述城市部件数据和/或所述地址类数据进行更新。

在其中一个实施例中，数据维护模块还包括：

数据监控子模块M，用于定时监控所述城市部件数据和所述地址类数据，若检测到所述城市部件数据和/或所述地址类数据更新，发送所述数据库更新请求给所述数据更新子模块。

在本例中，维护模块用于执行城市地理编码数据维护方法，参考图4，其流程如下：

步骤p401: 数据维护模块调用方输入数据更新内容。

例如：调用方需要删除名为“雨水井盖”的所有部件。

步骤p402: 将输入的更新内容按照数据类型，更新至数据源相应的数据库中。

例如：删除雨水井盖对应的数据表: gis_unit_ysjg。

步骤p403: 数据监控子模块定时监控数据源的变化，若检测到数据更新，则通知地理编码数据组织管理模块M2，令其重新进行数据处理。

具体实施过程中，该子模块会以定时程序实现，具体地，该程序会每隔5分钟，检测数据源模块M1中的数据表个数、每张表的记录个数是否出现变化；检测每张表的变更日期字段是否出现了落在最近5分钟检测周期内的值。若检测到上述变化的任意一种情况，则令M2重新进行数据处理。

步骤p404: 通知地理编码数据维护模块的调用方，数据是否更新成功的信息, 例如：返回调用方消息如下：“雨水井盖表gis_unit_ysjg删除成功，物化视图已更新！”。

在其他实施例中，可以通过将数据监控子模块与数据更新子模块功能归并对维护模块进行简化，当维护模块的调用方输入的数据库更新请求更新至数据源模块后，维护模块会立即向数据组织模块发送重新进行数据处理的信号，并向调用方返回更新是否成功的信息。

综上，针对上述实施例一至实施例二，本发明提出了一种基于PostgreSQL的地理编码方法和系统，可以解决现有地理编码实现途径的不足的问题。本方案通过为部件数据生成部件类地址串以及对应的部件词向量集合，能够对用户的定制化业务数据（如城市部件）进行地理编码。并且为数据表建立物化视图，对部件物化视图和地址物化视图进行查询，不直接涉及多表连接问题，提高地理编码查询效率。此外，本申请为解决基于分词相似的全文搜索方式在遇到搜索地址串与标准地址串的字符长度差异过大时，会降低搜索召回率的问题，还使用归一化的结合字符相似和分词相似的地址串相似匹配的判断方法进行匹配度判断，提高了地理编码查询的召回率。

本实施例还提供了一种电子装置，参考图6，包括存储器604和处理器602，该存储器604中存储有计算机程序，该处理器602被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

具体地，上述处理器602可以包括中央处理器（CPU），或者特定集成电路（ApplicationSpecificIntegratedCircuit，简称为ASIC），或者可以被配置成实施本申请实施例的一个或多个集成电路。

其中，存储器604可以包括用于数据或指令的大容量存储器604。举例来说而非限制，存储器604可包括硬盘驱动器（HardDiskDrive，简称为HDD）、软盘驱动器、固态驱动器（SolidStateDrive，简称为SSD）、闪存、光盘、磁光盘、磁带或通用串行总线（UniversalSerialBus，简称为USB）驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器604可包括可移除或不可移除（或固定）的介质。在合适的情况下，存储器604可在数据处理装置的内部或外部。在特定实施例中，存储器604是非易失性（Non-Volatile）存储器。在特定实施例中，存储器604包括只读存储器（Read-OnlyMemory，简称为ROM）和随机存取存储器（RandomAccessMemory，简称为RAM）。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM（ProgrammableRead-OnlyMemory，简称为PROM）、可擦除PROM（ErasableProgrammableRead-OnlyMemory，简称为EPROM）、电可擦除PROM（ElectricallyErasableProgrammableRead-OnlyMemory，简称为EEPROM）、电可改写ROM（ElectricallyAlterableRead-OnlyMemory，简称为EAROM）或闪存（FLASH）或者两个或更多个以上这些的组合。在合适的情况下，该RAM可以是静态随机存取存储器（StaticRandom-AccessMemory，简称为SRAM）或动态随机存取存储器（DynamicRandomAccessMemory，简称为DRAM），其中，DRAM可以是快速页模式动态随机存取存储器604（FastPageModeDynamicRandomAccessMemory，简称为FPMDRAM）、扩展数据输出动态随机存取存储器（ExtendedDateOutDynamicRandomAccessMemory，简称为EDODRAM）、同步动态随机存取内存（SynchronousDynamicRandom-AccessMemory，简称SDRAM）等。

存储器604可以用来存储或者缓存需要处理和/或通信使用的各种数据文件，以及处理器602所执行的可能的计算机程序指令。

处理器602通过读取并执行存储器604中存储的计算机程序指令，以实现上述实施例中的任意基于PostgreSQL的地理编码方法。

可选地，上述电子装置还可以包括传输设备606以及输入输出设备608，其中，该传输设备606和上述处理器602连接，该输入输出设备608和上述处理器602连接。

传输设备606可以用来经由一个网络接收或者发送数据。上述的网络具体实例可包括电子装置的通信供应商提供的有线或无线网络。在一个实例中，传输设备包括一个网络适配器（Network Interface Controller，简称为NIC），其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备606可以为射频（Radio Frequency，简称为RF）模块，其用于通过无线方式与互联网进行通讯。

输入输出设备608用于输入或输出信息。例如，上述输入输出设备可以是显示屏、音箱、麦克、鼠标、键盘或其他设备。在本实施例中，输入的信息可以是数据、表格、图像、实时视频，输入的信息可以是查询结果的文本、图表等等。

可选地，在本实施例中，上述处理器602可以被设置为通过计算机程序执行以下步骤：

步骤S101，获取城市管理所需的基础地理数据、城市部件数据和地址类数据；

步骤S102，当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述地址类数据生成一对应的地址类地址串，对每个所述地址类地址串进行分词得到至少一个地址词，生成每个所述地址词的地址词向量，将所述地址词、所述地址词向量作为所述地址类地址串的地址词向量集合；

步骤S103，当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述城市部件数据生成一对应的部件类地址串，对每个所述部件类地址串进行分词得到至少一个部件词，生成每个所述部件词的部件词向量，将所述部件词、所述部件词向量作为所述部件类地址串的部件词向量集合；

步骤S104，以每个所述城市部件类数据、每个所述部件类地址串、每个所述部件词向量集合生成部件数据表，为所述部件数据表创建部件物化视图；

步骤S105，以每个所述地址类数据、每个所述地址类地址串、每个所述地址词向量集合生成地址类数据表，为所述地址类数据表创建地址物化视图。

需要说明的是，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

另外，结合上述实施例中的基于PostgreSQL的地理编码方法，本申请实施例可提供一种存储介质来实现。该存储介质上存储有计算机程序；该计算机程序被处理器执行时实现上述实施例中的任意基于PostgreSQL的地理编码方法。

本领域的技术人员应该明白，以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (13)

1.一种基于PostgreSQL的地理编码方法，其特征在于，所述方法包括：

获取城市管理所需的基础地理数据、城市部件数据和地址类数据；

根据所述基础地理数据为每个所述地址类数据生成一对应的地址类地址串，对每个所述地址类地址串进行分词得到至少一个地址词，生成每个所述地址词的地址词向量，将所述地址词、所述地址词向量作为所述地址类地址串的地址词向量集合；

根据所述基础地理数据为每个所述城市部件数据生成一对应的部件类地址串，对每个所述部件类地址串进行分词得到至少一个部件词，生成每个所述部件词的部件词向量，将所述部件词、所述部件词向量作为所述部件类地址串的部件词向量集合；

以每个所述城市部件类数据、每个所述部件类地址串、每个所述部件词向量集合生成部件数据表，为所述部件数据表创建部件物化视图；

以每个所述地址类数据、每个所述地址类地址串、每个所述地址词向量集合生成地址类数据表，为所述地址类数据表创建地址物化视图。

2.根据权利要求1所述的基于PostgreSQL的地理编码方法，其特征在于，

基于所述城市部件数据在所述基础地理数据中的空间从属关系生成所述部件类地址串；

基于所述地址类数据在所述基础地理数据中的空间从属关系生成所述地址类地址串。

3.根据权利要求1所述的基于PostgreSQL的地理编码方法，其特征在于，分别为所述部件物化视图中的所述部件词向量集合、所述地址物化视图中的所述地址词向量集合添加索引。

4.根据权利要求3所述的基于PostgreSQL的地理编码方法，其特征在于，所述方法还包括：

获取待查询对象的搜索地址串，对所述搜索地址串进行分词得到至少一搜索词，生成每个所述搜索词的搜索词向量，将所述搜索词、所述搜索词向量作为所述搜索地址串的搜索词向量集合；

判断所述搜索词向量是否存在所述部件词向量集合中的关键词，若存在，导向到所述部件物化视图；

计算所述搜索词向量集合与所述部件物化视图中的每个所述部件词向量集合的匹配度；

获取与所述搜索词向量集合匹配度最高的所述部件词向量集合所对应的所述部件类地址串。

5.根据权利要求4所述的基于PostgreSQL的地理编码方法，其特征在于，“计算所述搜索词向量集合与所述部件物化视图中的每个所述部件词向量集合的匹配度”包括：

计算所述搜索地址串与所述部件物化视图中的每个所述部件类地址串的字符相似，以及所述搜索词向量集合与所述部件物化视图中的每个所述部件词向量集合的分词相似，将结合所述字符相似和所述分词相似的归一化地址串相似匹配计算的结果作为匹配度。

6.根据权利要求4所述的基于PostgreSQL的地理编码方法，其特征在于，所述方法还包括：

判断所述搜索词向量是否存在所述部件词向量集合中的关键词，若不存在，导向到所述地址物化视图；

计算所述搜索地址串与所述地址物化视图中的每个所述地址类地址串的字符相似，以及所述搜索词向量集合与所述地址物化视图中的每个所述地址词向量集合的分词相似，确定所述匹配度为结合所述字符相似和所述分词相似的归一化地址串相似匹配计算的结果。

7.根据权利要求1所述的基于PostgreSQL的地理编码方法，其特征在于，所述方法还包括：

定时监控所述城市部件数据和所述地址类数据，若检测到所述城市部件数据和/或所述地址类数据更新，生成数据更新请求。

8.根据权利要求7所述的基于PostgreSQL的地理编码方法，其特征在于，所述方法还包括：

接收所述数据更新请求；

根据所述数据更新请求对所述城市部件数据和/或所述地址类数据进行更新；

基于更新后的城市部件数据和/或地址类数据更新所述部件物化视图、所述地址物化视图。

9.一种基于PostgreSQL的地理编码系统，其特征在于，包括：

数据源模块，用于获取城市管理所需的基础地理数据、城市部件数据和地址类数据；

地址类数据处理子模块，用于当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述地址类数据生成一对应的地址类地址串，对每个所述地址类地址串进行分词得到至少一地址词，生成每个所述地址词的地址词向量，将所述地址词、所述地址词向量作为所述地址类地址串的地址词向量集合；

部件类数据处理子模块，用于当系统初始化或接收到数据更新请求后，根据所述基础地理数据为每个所述城市部件数据生成一个对应的部件类地址串，对每个所述部件类地址串进行分词得到至少一个部件词，生成每个所述部件词的部件词向量，将所述部件词、所述部件词向量作为所述部件类地址串的部件词向量集合；

物化视图创建子模块，用于至少以所述城市部件类数据、所述部件类地址串、所述部件词向量生成部件数据表，为所述部件数据表创建部件物化视图；至少以所述地址类数据、所述地址类地址串、所述地址词向量生成地址类数据表，为所述地址类数据表创建地址物化视图。

10.根据权利要求9所述的基于PostgreSQL的地理编码系统，其特征在于，包括数据维护模块，其中，所述数据维护模块包括：

数据监控子模块，用于定时监控所述城市部件数据和所述地址类数据，若检测到所述城市部件数据和/或所述地址类数据更新，生成所述数据更新请求；

数据更新子模块，用于获取所述数据更新请求；根据所述数据更新请求对所述城市部件数据和/或所述地址类数据进行更新；基于更新后的城市部件数据和/或地址类数据更新所述部件物化视图、所述地址物化视图。

11.根据权利要求9所述的基于PostgreSQL的地理编码系统，其特征在于，

查询模块，其中，所述查询模块包括：

查询任务分发子模块，用于获取待查询对象的搜索地址串，对所述搜索地址串进行分词得到至少一个搜索词，生成每个所述搜索词的搜索词向量；判断所述搜索词向量是否存在所述部件词向量中的关键词，若存在，导向到所述部件物化视图；若不存在，导向到所述地址物化视图；

地址串匹配子模块，用于计算所述搜索词向量与所述部件物化视图中的每个所述部件词向量的匹配度；获取与所述搜索词向量匹配度最高的所述部件词向量所对应的所述部件类地址串；和/或计算所述搜索地址串与所述地址物化视图中的每个所述地址类地址串的字符相似，以及所述搜索词向量与所述地址物化视图中的每个所述地址词向量的分词相似，确定所述匹配度为结合所述字符相似和所述分词相似的归一化地址串相似匹配计算的结果。

12.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行权利要求1至8中任一项所述的基于PostgreSQL的地理编码方法。

13.一种存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行权利要求1至8中任一项所述的基于PostgreSQL的地理编码方法。

Images