CN106991103A

CN106991103A - 一种导航数据文件的检查方法及引擎系统

Info

Publication number: CN106991103A
Application number: CN201610042208.9A
Authority: CN
Inventors: 熊涛
Original assignee: Navinfo Co Ltd
Current assignee: Navinfo Co Ltd
Priority date: 2016-01-21
Filing date: 2016-01-21
Publication date: 2017-07-28
Anticipated expiration: 2036-01-21
Also published as: CN106991103B

Abstract

本发明公开了一种导航数据文件检查方法及引擎系统，所述方法包括：读取数据文件，对所述数据文件进行解析，得到所述数据文件中记录的导航信息；根据所述数据文件，匹配与之相对应的预设的数据表格，并将所述导航信息写入对应的数据表格之中，生成待检查文件并存储；加载与所述待检查文件相对应的预设标准模板，所述标准模板配置有相应的检查工具，并利用所述检查工具对所述待检查文件进行检查，生成并存储检查结果。

Description

一种导航数据文件的检查方法及引擎系统

技术领域

本发明涉及数据处理领域，具体地说，涉及一种导航数据文件的检查方法及引擎系统。

背景技术

导航是一项当前常用的生活功能。无论是专用的导航仪，还是手机等移动终端，都能够提供导航功能。导航功能的广泛使用，为用户的出行带来了极大的方便。

在导航过程中，需要向用户表达的信息很多。例如导航路线上途经的道路、建筑、场所等标识，都需要明显的呈现。上述各种信息往往被分类记录到各个数据文件当中，以便保存和管理。如果需要对该信息进行调用和呈现，则必须读取所述的数据文件进行数据层面上的相关检查。所述的检查包括值域、主键、外键、为空、非空、通用性和结构等诸多具体的检查项。

当前阶段，对于数据文件的检查，往往是在读取数据文件之后，直接使用检查工具对数据文件本身进行检查。但是由于每一类的数据文件在数据结构方面都有区别，所以针对数据文件的检查工具往往都是专用的，彼此不能够通用。这导致整个系统中，检查工具存在大量冗余，致使数据量庞大且重复；占用大量资源，不够精简。同时，现有的检查模式，也使得检查的流程缺乏规范性和统一性，复杂而且低效。

发明内容

有鉴于此，本发明提供了一种导航数据文件的检查方法及系统，能够实现检查工具的通用和检查流程的统一。

为了解决上述技术问题，本发明有如下技术方案：

一种导航数据文件检查方法，所述方法包括：

读取数据文件，对所述数据文件进行解析，得到所述数据文件中记录的导航信息；

根据所述数据文件，匹配与之相对应的预设的数据表格，并将所述导航信息写入对应的数据表格之中，生成待检查文件并存储；

加载与所述待检查文件相对应的预设标准模板，所述标准模板配置有相应的检查工具，并利用所述检查工具对所述待检查文件进行检查，生成并存储检查结果。

还包括：

根据所述数据文件的规格和/或内容的变化，更新数据库中存储的分别与各所述数据文件对应的数据表格；和/或，

根据对所述数据文件的检查需要，更新标准模板中配置的检查工具。

所述检查工具用于完成一个检查项，所述检查项采用配置文件的形式，通过修改配置文件中的名称和/或字段修改检查项；其中，所述检查项包括以下项目中的至少一种：值域、主键、外键、为空、非空、通用性和结构；和/或，

所述数据文件包括以下至少一种：

R_LINK文件，用于记录道路信息；

NAMES文件，用于记录显示名称；

B_CART文件，用于记录面组成；

POI文件，用于记录兴趣点；

R_CONDITION文件，用于记录导航路线。

该方法还包括：

当所述数据文件为多个时，针对每个数据文件生成对应的待检查文件；

将多个所述待检查文件进行排序，并按照排序，调用对应的标准模板对所述待检查文件进行检查。

所述对待检查文件进行排序包括：

对所述待检查文件进行数据量分析，根据分析得到的结果确定各所述待检查文件的大小，并根据所述待检查文件的大小进行排序。

所述利用所述检查工具对所述待检查文件进行检查包括：

解析所述标准模板，获取所述标准模板配置的相关检查工具、以及所述检查工具对应的检查项；

读取所述待检查文件，并根据所述检查工具预设的顺序依次调用相应的检查工具，对所述待检查文件中的导航数据进行检查。

一种导航数据文件的检查引擎系统，所述系统包括：

读取模块，用于读取数据文件，并对所述数据文件进行解析，得到所述数据文件中记录的导航信息；

生成模块，用于匹配与所述数据文件相对应的预设的数据表格，并将所述导航信息写入对应的数据表格生成待检查文件；

加载模块，用于加载与所述待检查文件相对应的标准模板，所述标准模板配置有相应检查工具；

检查模块，用于利用所述检查工具对所述待检查文件进行检查，生成并存储检查结果；

数据库，用于分配各类相关文件的存储空间和位置，对应存储所述待检查文件和所述标准模板。

还包括：

排序模块，用于对所述待检查文件进行数据量分析，根据分析得到的结果对所述待检查文件进行排序；

其中，检查模块还用于按照所述待检查文件的排序，调用与所述待检查文件相对应的标准模板对所述待检查文件进行检查。

所述检查工具用于完成一个检查项，所述检查项采用配置文件的形式，所述配置文件采用脚本形式运行。

所述数据表格写入有结构定义文件和数据文件，所述结构定义文件采用.mif格式，所述数据文件采用.mid格式。

与现有技术相比，本发明所述的方法和系统，达到了如下效果：

读取各类规格的数据文件，并进行解析获取导航信息的结构定义和数据，并将解析得到的导航信息填写到预设的对应数据表格中，生成待检查文件，根据待检查文件加载配置有对应检查工具的标准模板，对待检查文件进行检查，实现了检查工具的通用，减少了系统冗余，节约系统资源；同时，通过修改标准模板中检查工具对应的配置文件，修改、更新检查项，实现了检查流程的规范化，避免了重复的磁盘读写，提高检查效率。

当然，实施本发明的任一产品必不一定需要同时达到以上所述的所有技术效果。

附图说明

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

图1为本发明实施例导航数据文件检查方法的流程示意图；

图2为本发明实施例导航数据文件检查系统的结构示意图。

具体实施方式

如在说明书及权利要求当中使用了某些词汇来指称特定组件。本领域技术人员应可理解，硬件制造商可能会用不同名词来称呼同一个组件。本说明书及权利要求并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求当中所提及的“包含”为一开放式用语，故应解释成“包含但不限定于”。“大致”是指在可接收的误差范围内，本领域技术人员能够在一定误差范围内解决所述技术问题，基本达到所述技术效果。说明书后续描述为实施本发明的较佳实施方式，然所述描述乃以说明本发明的一般原则为目的，并非用以限定本发明的范围。本发明的保护范围当视所附权利要求所界定者为准。

目前，在导航信息数据的处理过程中，记录各种导航信息的数据文件，以及用于对所述数据文件进行检查的检查工具，其类型都是多样化的。

例如，所述数据文件中常见有如下种类：记录道路信息的R_LINK文件，记录显示名称的NAMES文件，记录面组成的B_CART文件，记录兴趣点的POI文件，记录导航路线的R_CONDITION文件等。类似的数据文件都记录了导航中要为用户呈现的重要信息。数据文件的每种检查工具，一般专用于执行一个特定的检查项。常见的检查项主要包括：值域、主键、外键、为空、非空、通用性和结构等。

在现有技术中，往往是直接使用检查工具对数据文件本身进行检查。但是由于每一类的数据文件在数据结构方面都有区别，所以针对数据文件的检查工具都是专用的，彼此不能够通用。

就是说，假使R_LINK文件和NAMES文件均需要进行主键的检查；但是R_LINK文件必须使用其专用的主键检查工具执行检查，NAMES文件亦然。而无法实现同一个主键检查工具完成R_LINK文件和NAMES文件的主键检查。

同理可以想象，在检查流程中几乎每个检查工具都是不能够通用的。这导致整个系统中，检查工具存在大量冗余，致使数据量庞大且重复；占用大量资源，不够精简。而且在上述的检查模式之下，各类数据文件的检查过程彼此没有关联，流程上一般也不具有统一性，使得检查过程规范性差，复杂而且低效。

为解决上述技术问题，本发明公开一种导航数据文件的检查方法实施例。本实施例的方法可实现检查工具的通用，以及检查流程的标准化。本实施例的方法先解析数据文件，将数据文件中的信息填写到标准化的模板中，再利用特定的检查工具执行检查，实现检查工具的通用和检查流程的统一。参见图1所示，为本发明实施例的方法流程示意图。本实施例中所述方法包括以下步骤：

步骤101、读取数据文件，并对所述数据文件进行解析，得到所述数据文件中记录的导航信息。

本实施例中，不再直接针对数据文件进行检查；而是在读取数据文件之后，首先将数据文件中的导航信息解析出来。

其中，所述数据文件的类型可以包括但不限于以下的至少一种规格：

1)R_LINK文件，用于记录道路信息，如道路的坐标，等级(高速公路、国道等)。

2)NAMES文件，用于记录显示名称；如建筑、场所、道路的名称。

3)B_CART文件，用于记录面组成。

4)POI文件，用于记录兴趣点；如银行、学校、医院、商场等场所的坐标及相关属性等。

5)R_CONDITION文件，用于记录导航路线。

上述各种类型的数据文件，均记录了不同种类的导航信息。在本实施例中均可通过所述的解析过程解析出导航信息。

步骤102、根据所述数据文件，匹配与之相对应的预设的数据表格，并将所述导航信息写入对应的数据表格之中，生成待检查文件并存储。

前述已知，各种不同规格的数据文件，文件结构和检查方式都存在差别，所以一般的检查工具无法通用。为此，本实施例中改变了直接针对数据文件进行检查的过程，而是在从数据文件中解析出导航信息之后，将导航信息填写到预设的数据表格中。数据表格是根据实现统一检查的需求预先创建，为各类导航信息的写入均预留了写入的位置。所述数据表格与所述数据文件可根据彼此的名称相对应。

将从数据文件中解析出的导航信息填写至对应的数据表格中，即生成待检查文件。并且，所述数据表格针对不同的数据文件规格进行制定，每种数据文件对应一种数据表格。另外根据所述数据文件的规格和/或内容的变化，可以更新数据库中存储的分别与各所述数据文件对应的数据表格。所以通过填写数据表格得到的待检查文件，同样也具备与该类数据表格的数据结构。所述待检查文件与所述数据表格可根据彼此的名称相对应。这就使得理论上各个待检查文件虽然具体内容各异，但数据结构都是一致的，进而在检查过程中同样可以使用同一的检查工具进行检查。

还需要说明的是，在实际的应用场景下，需要读取的数据文件往往是多个。在所读取的数据文件为多个的情况下，则针对每个数据文件对应的生成一个待检查文件。

步骤103、加载与所述待检查文件相对应的预设标准模板，所述标准模板配置有相应的检查工具，并利用所述检查工具对所述待检查文件进行检查，生成并存储检查结果。

标准模板用于配置各检查工具，一个检查工具用于完成一个检查项。或者可以认为，所述标准模板实质上等于一个配置相应检查工具的容器。在实际的检查过程当中，可以针对具体的需求，而根据对所述数据文件的检查需要，更新标准模板中配置的检查工具。本实施例中所述检查项包括：值域、主键、外键、为空、非空、通用性和/或结构等。所述检查项采用配置文件的形式，通过修改配置文件中的名称和/或字段修改检查项。

本实施例中由于检查工具具有通用性，所以一般来说一个检查项只需要配置一个检查工具，即可对所有待检查文件进行该检查项的检查。这样可大大减少了冗余，使得系统更加精简。

针对一个待检查文件来说，所述利用所述检查工具对所述待检查文件进行检查的方式具体如下：解析所述标准模板，获取所述标准模板配置的相关检查工具、以及所述检查工具对应的检查项。然后读取所述待检查文件，并根据所述检查工具预设的顺序依次调用相应的检查工具，对所述待检查文件中的导航数据进行检查。所述检查工具依次调用的顺序，将取决于所述标准模板中配置文件的顺序。

还需要说明的是，在存在多个待检查文件的情况下，还需要对所述待检查文件进行排序，以确保检查过程的有序性，使得检查流程更加高效和规范。所述排序的方式具体如下：

对所述待检查文件进行数据量分析，根据分析得到的结果确定各所述待检查文件的大小，并根据所述待检查文件的大小进行排序。排序之后，即可以调用对应的标准模板对所述待检查文件进行检查。

综上可见，待检查文件和检查工具都制定了明确的顺序后，便可以按照顺序有序的执行检查。当执行完成一个待检查文件的所有检查之后，则按照待检查文件的排序调取下一个待检查文件，重新执行检查流程。由此，本实施例中的检查流程执行顺序清晰，避免了重复低效的情况。

通过以上技术方案可知，本实施例存在的有益效果是：读取各类规格的数据文件，并进行解析获取导航信息的结构定义和数据，并将解析得到的导航信息填写到预设的对应数据表格中，生成待检查文件，根据待检查文件加载配置有对应检查工具的标准模板，对待检查文件进行检查，实现了检查工具的通用，减少了系统冗余，节约系统资源；同时，通过修改标准模板中检查工具对应的配置文件，修改、更新检查项，实现了检查流程的规范化，避免了重复的磁盘读写，提高检查效率。

为便于理解上述实施例，下面结合以下的具体应用场景和实例，对所述方法进行更加详细的描述和解读。

例如，在某次的检查中，读取一个POI文件。所述POI文件的结构定义文件如下，解析后采用.mif格式记入数据表格：

基于上述的文件结构进行解析，获得所述POI文件中包括的数据文件如下，数据文件采用.mid文件写入数据表格中：

数据表格中记录一组.mif文件和.mid文件，形成POI文件对应的待检查文件。POI文件对应的待检查文件需检查的检查项包括值域、主键、外键、为空、非空、结构、通用性等。

将POI文件对应的待检查文件缓存至关系型数据库中，加载标准模板，对待检查文件的检查。根据标准模板配置的检查项，对待检查文件进行检查，生成并存储检查结果。

参见图2所示，为本发明导航数据文件检查的引擎系统实施例的组成示意图。本实施例中所述引擎系统用于实现图1所示实施例中所述的方法。其技术特征本质上与图1所示实施例一致。前述实施例中的相应描述，同样适用于本实施例中。本实施例所述引擎系统包括：

读取模块201，用于读取数据文件，并对所述数据文件进行解析，得到所述数据文件中记录的导航信息。

生成模块202，用于匹配与所述数据文件相对应的预设的数据表格，并将所述导航信息写入对应的数据表格生成待检查文件。

加载模块203，用于加载与所述待检查文件相对应的标准模板，所述标准模板配置有相应检查工具。

检查模块204，用于利用所述检查工具对所述待检查文件进行检查，生成并存储检查结果。

数据库205，用于分配各类相关文件的存储空间和位置，对应存储所述待检查文件和所述标准模板。

优选的，所述引擎系统还可包括：排序模块206(图2中未示出)，用于对所述待检查文件进行数据量分析，根据分析得到的结果对所述待检查文件进行排序。其中，检查模块204还用于按照所述待检查文件的排序，调用与所述待检查文件相对应的标准模板对所述待检查文件进行检查。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

上述说明示出并描述了本发明的若干优选实施例，但如前所述，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述发明构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。

Claims

1.一种导航数据文件检查方法，其特征在于，所述方法包括：

2.根据权利要求1所述方法，其特征在于，还包括：

3.根据权利要求1所述方法，其特征在于：

所述数据文件包括以下至少一种：

R_LINK文件，用于记录道路信息；

NAMES文件，用于记录显示名称；

B_CART文件，用于记录面组成；

POI文件，用于记录兴趣点；

R_CONDITION文件，用于记录导航路线。

4.根据权利要求1～3任意一项所述方法，其特征在于，该方法还包括：

5.根据权利要求4所述方法，其特征在于，所述对待检查文件进行排序包括：

6.根据权利要求1～3任意一项所述方法，其特征在于，所述利用所述检查工具对所述待检查文件进行检查包括：

7.一种导航数据文件的检查引擎系统，其特征在于，所述系统包括：

8.根据权利要求7所述引擎系统，其特征在于，还包括：

9.根据权利要求8所述引擎系统，其特征在于，所述检查工具用于完成一个检查项，所述检查项采用配置文件的形式，所述配置文件采用脚本形式运行。

10.根据权利要求7～9任意一项所述引擎系统，其特征在于，所述数据表格写入有结构定义文件和数据文件，所述结构定义文件采用.mif格式，所述数据文件采用.mid格式。