基于GIS拓扑分析的地址匹配区域块方法和系统与流程

本申请涉及GIS应用技术领域，特别地，涉及一种基于GIS拓扑分析的地址匹配区域块方法和系统。

背景技术：

基于GIS系统的区域划分和订单分拣技术是GIS应用之一，目前绝大多数物流配送企业多采用人工地址库自动分拣技术，其中：地址库采用人工维护的方式，需要手工录入业务区划的四至（东、南、西、北）及楼宇、大厦、街道地址，手工更新维护地址库；订单划分则通过订单地址与人工地址库进行关键词匹配实现，匹配成功的订单才被划分到对应的业务区划，并归属给对应的派件网点及派件人；因此存在操作时间长，效率低，错误率高等问题。

技术实现要素：

本申请提供一种基于GIS拓扑分析的地址匹配区域块方法和系统，用于解决现有分单系统效率低下、错误率高的问题。

本申请公开的一种基于GIS拓扑分析的地址匹配区域块方法，在服务端，所述方法包括：接收客户端提交的订单地址；利用后台地址解析算法对所述订单地址进行解析；从后台地址库查询获得解析后的订单地址对应的空间位置信息，根据所述空间位置信息将所述订单地址匹配到电子地图上；根据GIS拓扑关系确定所述订单地址对应的业务区域块，将所述业务区域块的信息返回至客户端。

优选的，所述利用后台地址解析算法对所述订单地址进行解析，具体包括：根据词库对所述订单地址进行切分，识别出其中的行政区划关键词、道路关键词、标建关键词和/或门牌号关键词；对上述识别出的关键词进行搜索匹配，并对匹配结果进行相关度计算，将相关度最高的匹配结果作为解析后的订单地址。

优选的，在通过GIS拓扑关系确定所述订单地址对应的业务区域块，将所述业务区域块的区块信息返回至客户端之前还包括：若后台地址库中不存在解析后的订单地址对应的空间位置信息，则提醒用户手工标注所述订单地址对应的业务区域块，并将所述订单地址与业务区域块的对应关系存储到地址纠错库中。

优选的，在利用后台地址解析算法对所述订单地址进行解析之前，还包括：判断所述地址纠错库中是否保存有该订单地址的纠错信息，若是，直接根据所述订单地址与业务区域块的对应关系获得所述业务区域块的信息并返回至客户端；否则执行后续流程。

优选的，所述空间位置信息为所述订单地址的经纬度。

优选的，所述业务区域块的信息包括区块名称、区块编号、配送网点名称和/或配送网点的属性。

优选的，所述方法还包括：基于GIS拓扑关系对业务区域块进行添加、修改、合并和/或拆分操作，将电子地图划分成无缝拼接的业务区域块。。

本申请公开的一种基于GIS拓扑分析的地址匹配区域块系统，包括通过网络连接的客户端和服务器，所述服务器具体包括：订单地址接收模块，用于接收客户端提交的订单地址；订单地址解析模块，用于利用后台地址解析算法对所述订单地址进行解析；地图标绘模块，用于从后台地址库查询获得解析后的订单地址对应的空间位置信息，根据所述空间位置信息将所述订单地址匹配到电子地图上；第一分单模块，用于根据GIS拓扑关系确定所述订单地址对应的业务区域块，将所述业务区域块的信息返回至客户端。

优选的，所述订单地址解析模块具体包括：分词子模块，用于根据词库对所述订单地址进行分词，识别出其中的行政区划关键词、道路关键词、标建关键词和/或门牌号关键词；评分子模块，用于对分词子模块识别出的关键词进行搜索匹配，并对匹配结果进行相关度计算，将相关度最高的匹配结果作为解析后的订单地址。

优选的，所述服务器还包括：地址纠错模块，用于判断后台地址库中是否存在解析后的订单地址对应的空间位置信息，若是，则提醒用户手工标注所述订单地址对应的业务区域块，并将所述订单地址与业务区域块的对应关系存储到地址纠错库中；第二分单模块，用于在利用后台地址解析算法对所述订单地址进行解析之前，判断所述地址纠错库中是否保存有该订单地址的纠错信息；若是，直接根据所述订单地址与业务区域块的对应关系获得所述业务区域块的信息并返回至客户端；否则转订单地址解析模块、地图标绘模块和第一分单模块进行相应的地址解析、地图标绘和分单操作。

与现有技术相比，本申请具有以下优点：

本申请优选实施例通过对订单地址进行解析生成订单地址对应的空间地理位置信息，并将空间地理位置信息基于GIS拓扑关系与业务区域块进行匹配的方式，实现了对订单的自动识别分区，并自动分派到相关的派件网点和派件人，可实现对海量订单进行批量自动分拣和连续不断的分拣，减轻了分拣人员的劳动强度，提高了派单效率，解决了物流等行业的分拣派单难题，并为企业节省了人力成本。

附图说明

附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本申请基于GIS拓扑分析的地址匹配区域块方法一实施例的流程；

图2为本申请基于GIS拓扑分析的地址匹配区域块系统一实施例的结构示意图；

图3为本申请基于GIS拓扑分析的地址匹配区域块系统具体实施例的标绘结果示意图；

图4为本申请基于GIS拓扑分析的地址匹配区域块系统具体实施例的分单结果示意图；

图5为本申请基于GIS拓扑分析的地址匹配区域块系统具体实施例的订单处理情况分时段汇总结果示意图；

图6为本申请基于GIS拓扑分析的地址匹配区域块方法具体实施例的地址匹配度评分模型。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

在本申请的描述中，需要理解的是，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。“多个”的含义是两个或两个以上，除非另有明确具体的限定。术语“包括”、“包含”及类似术语应该被理解为是开放性的术语，即“包括/包含但不限于”。术语“基于”是“至少部分地基于”。术语“一实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”。其他术语的相关定义将在下文描述中给出。

参照图1，示出了本申请基于GIS拓扑分析的地址匹配区域块方法一实施例的流程，执行所述方法的系统包括通过网络连接的客户端和服务器，在服务器端，所述方法包括：

步骤S101：接收客户端提交的订单地址；

具体实施时，可以将客户端提交的订单地址批量传入系统进行后续处理。

步骤S103：利用后台地址解析算法对所述订单地址进行解析；

具体实施时，步骤S103可以包括如下分词、评分和排序的过程：

分词

根据词库对订单地址（即中文地址）进行切分和关键词识别，包括对省、市、区、县、乡镇等行政区划关键词的识别，以及道路、地标建筑名称（简称标建）和/或门牌号等关键词的识别。

由于全国的地址样例较多，所涉及的关键词信息量太大，在对道路及门牌号的识别则采用相关正则模式进行匹配，从而实现对道路、标建的识别。

例如：上海市嘉定区马陆镇丰兆路118号上海鹏晨消防器材有限公司

分词结果之后将会变为：上海市/嘉定区/马陆镇/丰兆路/118号/上海鹏晨消防器材有限公司

“上海市/嘉定区/马陆镇”这三个关键词采用各级行政区关键词进行切分，从“丰兆路”开始则使用道路及标建正则模式进行匹配。例如：xx路/大街/大道xx号。

评分：

在对评分进行介绍之前，需要简要介绍一下地址匹配的过程。实现地址匹配需要做两部分主要工作，索引与搜索。索引就是将基础数据按照特定的方式打包。地址匹配采用的是倒排索引的方式，即将基础数据进行分词，然后将分词作为关键词进行存储，该关键词并指向原始文档。当进行搜索的时候也会对搜索目标进行分词，并使用分词的结果进行关键词搜索，从而匹配到相应的原始文档。

以上为地址匹配的简要过程，评分是对搜索结果进行相关度计算，给出得分，从而找出匹配度最高的结果。地址匹配采用的相关度算法为TF-IDF，该算法按照向量空间的方式进行相似度计算。具体模型参考如图6所示。

图6展示了地址匹配过程中，计算文档相似度的评分。箭头query表示查询目标，箭头document表示命中结果。对两者进行叉积运算从而得到一个分数，两者的夹角越小表示相似度越高。

每一个权重（weight）代表一个分词命中分数，该分数的计算采用信息检索与数据挖掘加权技术（TF-IDF，Term Frequency–Inverse Document Frequency）计算。该算法分为两个部分，tf和idf。tf表示一个分词项在一个目标文档（Document）中的频率，idf表示这个分词项在多少文档中出现。所以公式可表示为如下：

V_q*V_d = w(t₁, q)*w(t₁, d) + w(t₂, q)*w(t₂, d) + …… + w(t_n ,q)*w(t_n, d)

t_i（1≤i≤n）表示第i个分词项（如天安门、九里堤等就为一个分词项），q表示查询对象，d表示命中文档，w表示权重，*表示叉积运算。带入tf与idf之后。

V_q*V_d = tf(t₁, q)*idf(t₁, q)*tf(t₁, d)*idf(t₁, d) + tf(t₂, q)*idf(t₂, q)*tf(t₂, d)*idf(t₂, d) + …… + tf(t_n ,q)*idf(t_n, q)*tf(t_n, d)*idf(t_n, d)

以上向量空间的计算结果并不能作为最终的评分结果，同时还要考虑目标文档的长度。因为通常情况下，当出现同样词项的时候，文档长度越短则匹配度越高。同时，在实际应用中，还需要考虑词项加权的情况，因为并不是所有的词项都具有同等的低位，比如地址“丰兆路/118号”，“丰兆路”的权重就应该比“118号”重要，所以在对地址匹配的时候需要对“丰兆路”进行加权。

排序：

地址匹配的排序结果是依据各个命中结果的相关度评分进行的，将匹配度最高的搜索结果作为解析后的订单地址。

利用上述地址解析方式，对于符合标准规范的订单地址，解析率可达99%以上。将解析好的订单地址与已有区域块进行后续流程的匹配处理，即实现了自动分单。

步骤S105：从后台地址库查询获得解析后的订单地址对应的空间位置信息，根据所述空间位置信息将所述订单地址匹配到电子地图上；

具体实施时，可以基于海量地址库数据构建的地址词典，利用中文地址模糊匹配算法搜索并定位上述解析后的订单地址的空间位置信息（如经纬度），确定其在电子地图上的具体位置，并可电子地图相应位置上进行标注。

另外，后台地址库的数据可以逐渐积累，并在不断迭代中更新。

步骤S107：根据GIS拓扑关系确定所述订单地址对应的业务区域块，将所述业务区域块的信息返回至客户端。

GIS的空间对象间的拓扑关系是指在拓扑变换（旋转、平移、缩放等）时保持不变的空间关系，即拓扑不变量，包括空间对象的相邻和连通关系。拓扑关系所表达的是满足拓扑几何学原理的各空间数据间的相互关系，采用结点、弧段和多边形表示实体之间的邻接、关联、包含和连通等关系。如：点与点的邻接关系、点与面的包含关系、线与面的相离关系、面与面的重合关系等。

在另一实施例中，返回的业务区域块的信息可以包括业务区域块名称、业务区域块编号以及对应的配送网点名称、配送网点属性信息（如网点负责人、电话、网点其他情况等）。

在进一步的优选实施例中，步骤S107之前还可以包括：

步骤S106：判断后台地址库中是否存在解析后的订单地址对应的空间位置信息，若是，转步骤S107；否则，转步骤S108。

步骤S108：提醒用户手工标注所述订单地址对应的业务区域块，并将所述订单地址与业务区域块的对应关系存储到地址纠错库中。

相应的，在步骤S103之前，还包括：

步骤S102：判断所述地址纠错库中是否保存有该订单地址的纠错信息，若是，转步骤S109；否则，转步骤S103。

步骤S109：直接根据所述订单地址与业务区域块的对应关系获得所述业务区域块的信息并返回至客户端。

另外，所述方法还可以包括：

步骤S110：基于GIS拓扑关系对业务区域块进行添加、修改、合并和/或拆分操作，将电子地图划分成无缝拼接的业务区域块。

对于前述的各方法实施例，为了描述简单，故将其都表述为一系列的动作组合，但是本领域的技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为根据本申请，某些步骤可以采用其他顺序或同时执行；其次，本领域技术人员也应该知悉，上述方法实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

本申请还公开了一种在其上记录有用于执行上述方法的程序的计算机可读记录介质。所述计算机可读记录介质包括配置为以计算机（以计算机为例）可读的形式存储或传送信息的任何机制。例如，机器可读介质包括只读存储器（ROM）、随机存取存储器（RAM）、磁盘存储介质、光存储介质、闪速存储介质、电、光、声或其他形式的传播信号（例如，载波、红外信号、数字信号等）等。

参照图2，示出了本申请基于GIS拓扑分析的地址匹配区域块系统一实施例的结构框图，包括通过网络连接的客户端1和服务器2，其中的服务器2具体包括：

订单地址接收模块21，用于接收客户端提交的订单地址。

订单地址解析模块22，用于利用后台地址解析算法对所述订单地址进行解析。

地图标绘模块23，用于从后台地址库查询获得解析后的订单地址对应的空间位置信息，根据所述空间位置信息将所述订单地址匹配到电子地图上。

具体实施时，可以基于海量地址库数据构建的地址词典，利用中文地址模糊匹配算法搜索并定位上述解析后的订单地址的空间位置信息（如经纬度），确定其在电子地图上的具体位置，并可电子地图相应位置上进行标注，其形式可以如图3所示。

第一分单模块24，用于根据GIS拓扑关系确定所述订单地址对应的业务区域块，将所述业务区域块的信息返回至客户端。

具体实施时，分单结果可以采用图4所示的形式显示。

在进一步的优选实施例中，订单地址解析模块22具体可以包括：

分词子模块，用于根据词库对所述订单地址进行分词，识别出其中的行政区划关键词、道路关键词、标建关键词和/或门牌号关键词；

评分子模块，用于对分词子模块识别出的关键词进行搜索匹配，并对匹配结果进行相关度计算，将相关度最高的匹配结果作为解析后的订单地址。在另一实施例中，服务器2还可以包括：

第一地址纠错模块25，用于判断后台地址库中是否存在解析后的订单地址对应的空间位置信息，若是，则提醒用户手工标注所述订单地址对应的业务区域块，并将所述订单地址与业务区域块的对应关系存储到地址纠错库中。

第二分单模块26，用于在利用后台地址解析算法对所述订单地址进行解析之前，判断所述地址纠错库中是否保存有该订单地址的纠错信息；若是，直接根据所述订单地址与业务区域块的对应关系获得所述业务区域块的信息并返回至客户端；否则转订单地址解析模块、地图标绘模块和第一分单模块进行相应的地址解析、地图标绘和分单操作。

第二地址纠错模块27，用于为业务员在实地配送时，若发现订单地址分配有误或地址更新等情况，在地图上直接调整配送网点位置的接口。由于业务员权限有限，因此相应的配送网点负责人负责对业务员纠错后的地址进行审核，查看该地址在地图上的位置是否准确，并将审核通过的地址录入地址纠错库。下次再遇到类似订单地址，系统直接到地址纠错库中去匹配，将匹配结果返回给客户端。

网点管理模块28，用于管理配送网点，包括配送网点的增加/删除/修改/查询（含条件查询）、以及配送网点对于配送面的绑定/解绑等。其中的配送网点信息除了点坐标数据之外，还包括配送网点名称、责任人、电话、所属分组等，上述属性还可以作为配送网点的查询条件。该模块还提供配送网点的批量导入、自定义属性及各类属性的增加/删除/修改/查询、图片上传、分类显示/查询、弹窗字段自定义等功能。

区划管理模块29：用于为管理员提供业务区域块管理接口，包括业务区域块的增加/删除/修改/查询、合并拆分，业务区域块与配送网点的绑定/解绑等。业务区域块的信息除了业务区域块的矢量数据外，还包括业务区域块的名称等信息。该模块支持多人同时在线协同操作。

系统管理模块20，用于用户账号的权限划分以及系统运营支撑管理。其中，用户账号的权限划分包括用户账号信息管理、角色权限赋值、数据权限管理等。系统运营支撑管理包括记录客户每次发送任务的地址，统计月度任务地址总数，自动分单总数，分单失败总数，管理用户、限权、日志和认证，监控系统，支持系统自动还原备份等。具体实施时，订单量的统计形式可以如图5所示。

在具体实施时，可分为三层实现：数据层、服务层和用户界面（UI，User Interface）层。数据层包含基础地图数据、基础GIS数据、业务数据、文件型数据、地址数据等。服务层由Web平台组件和系统组件构成，前者提供角色管理等业务功能，后者提供区划和分单功能，两者通过HTTP、SOAP、FTP等协议交换数据。UI层可通过PC浏览器、终端APP接入，与服务层通过HTTP协议交换数据，支持Ajax异步请求。系统采用SOA架构，实现系统的复用和低耦合，以及与外部应用的无缝集成。

为提高系统的可扩展性、可维护性和高安全性，可采用标准的MVC分层开发模式，在数据层、服务层和UI层分别采用如下机制：

数据持久机制：采用开源的对象关系映射框架Hibernate对数据库进行持久化，在数据库与系统之间，建立数据库表/视图和Java类的映射关系，形成模块化关系集成管理数据库，同时为服务层提供POJO类支撑，简化服务层操作数据库的工作量，提高对数据库的访问效率、安全性、稳定性和可扩展性。

业务处理机制：采用Spring企业级集成框架，基于持久化的数据，结合用户需求和UI展现，为系统实现复杂的业务逻辑处理，返回正确的处理结果并展现给用户，系统资源开销小、配置管理灵活、集成性和可移植性高。

分发控制机制：采用SpringMVC框架，提供B/S结构通信管道，处理系统中的非法请求拦截、系统权限控制、业务请求调度分发、跳转UI视图等。

UI表现机制：采用前端开发框架Bootstrap和jQuery，提供友好、人性化的UI设计。Bootstrap和jQuery提供丰富的插件（如时间控件、表格控件、树形控件等）、图形化UI（如柱状图、饼状图、曲线图等）和安全稳定的Ajax技术，以保证UI层的实现。

需要说明的是，上述系统实施例属于优选实施例，所涉及的单元和模块并不一定是本申请所必须的。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

以上对本申请所提供的一种基于GIS拓扑分析的地址匹配区域块方法和系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。