CN105320664B - 一种电子地图关系数据的修改方法及装置 - Google Patents

Abstract

本发明提供了一种电子地图关系数据修改方法及装置，其中，修改方法包括：获取待删除数据的关系属性信息；根据所述待删除数据的关系属性信息在中间数据格式的数据库进行数据查询和提取；根据查询和提取得到的数据构建关系数据修改表，所述关系数据修改表包括：用于表示待删除数据的标识的关系ID和用于表示待删除数据的类型的关系类别；根据所述关系数据修改表中的标识的关系ID从用于进行最终数据格式的编译的原始数据附表中删除与所述关系ID对应的数据，形成用于进行最终数据格式的编译的当前数据附表。本发明提供的方案根据客户需求修改导航电子地图数据时难度较小、品质风险低、实现成本较小。

Description

一种电子地图关系数据的修改方法及装置

技术领域

本发明涉及导航技术领域，特别是涉及一种电子地图关系数据的修改方法及装置。

背景技术

随着科技日新月异的进步，导航系统在汽车产业中的应用越来越广泛。对于导航系统而言，导航使用的导航电子地图数据是其重要的组成部分。传统导航电子地图数据的生产周期至少包括产品设计、生产计划资源组织、外业实地采集数据、内业制作导航数据库、数据逻辑综合检查、转换中间数据格式、编译最终数据格式、产品测试验证等主要流程。传统导航电子地图产品生产流程多、更新周期较长，而且，对于特定的导航数据生产公司而言，一般在进行产品设计的时候，数据规格标准已经制定，在一定的空间和时间范围内是相对稳定的，外业实地采集和内业制作都会遵照已制定的数据规格标准进行。这样标准化的数据规格标准，可能无法同时满足不同导航终端客户的存在细微差别的应用需求，如某导航数据生产公司制定的导航数据规格标准中规定，高速上连续两单分歧距离在600米内时应制作为普通连续分歧，但导航终端A客户认为高速上连续两单分歧距离在300-600米范围时不应制作普通连续分歧。

目前，解决这种客户需求与导航数据生产公司产品规格不一致的情况的方法可能包括(1)导航终端A客户勉强接受某导航数据生产公司已经制定的成熟数据规格标准，最终的终端应用与A客户的原始设计存在差别；(2)导航终端A客户无法接受某导航数据生产公司已经制定的成熟数据规格标准，A客户在终端应用时利用导航软件对数据进行显示屏蔽；(3)导航终端A客户无法接受某导航数据生产公司已经制定的成熟数据规格标准，由某公司在编译后进行数据修改。

这三种解决方法，方法(1)无疑与导航终端A客户的设计理念存在差别，会降低终端A客户的应用体验，也会造成A客户对某公司的数据规格标准不满，甚至可能影响双方的合作关系；方法(2)会增加导航终端A客户导航软件开发成本，且数据屏蔽难度较大；方法(3)则会增加某导航数据生产公司的生产成本，且编译后期数据修改难度和风险较大，都存在或多或少的弊端。

在市场细分和客户体验至上的时代，客户的需求日益多样，与标准化的导航数据产品或多或少存在一些差别，而现有的技术无法很好的满足客户的需求，根据客户特定条件进行数据的修改，提供定制化的导航电子地图数据。

发明内容

本发明要解决的技术问题是提供一种电子地图关系数据的修改方法及装置，解决现有技术中根据客户需求修改导航电子地图数据时难度大、品质风险高、实现成本较大的问题。

为了解决上述技术问题，本发明实施例提供一种电子地图关系数据的修改方法，包括：

获取待删除数据的关系属性信息；

根据所述待删除数据的关系属性信息在中间数据格式的数据库进行数据查询和提取；

根据查询和提取得到的数据构建关系数据修改表，所述关系数据修改表包括：用于表示待删除数据的标识的关系ID和用于表示待删除数据的类型的关系类别；

根据所述关系数据修改表中的标识的关系ID从用于进行最终数据格式的编译的原始数据附表中删除与所述关系ID对应的数据，形成用于进行最终数据格式的编译的当前数据附表。

上述的修改方法，其中，还包括：

对所述当前数据附表进行最终数据格式的编译。

上述的修改方法，其中，所述关系数据修改表还包括：用于表示待删除数据的标识的子关系ID和用于表示待删除数据的类型的子关系类别。

上述的修改方法，其中，根据查询和提取后的数据构建关系数据修改表的步骤包括：

根据提取得到的数据，确定所述关系ID的值以及所述子关系ID的值；

将所述关系类别赋予一预设值；

根据所述原始数据附表确定所述子关系类别的值；

根据得到的所述关系ID的值、所述子关系ID的值、所述关系类别的值以及所述子关系类别的值构建所述关系数据修改表。

上述的修改方法，其中，还包括：

将数据转化为中间数据格式，形成所述中间数据格式的数据库。

本发明还提供了一种电子地图关系数据的修改装置，包括：

获取模块，用于获取待删除数据的关系属性信息；

查询提取模块，用于根据所述待删除数据的关系属性信息在中间数据格式的数据库进行数据查询和提取；

构建模块，用于根据查询和提取得到的数据构建关系数据修改表，所述关系数据修改表包括：用于表示待删除数据的标识的关系ID和用于表示待删除数据的类型的关系类别；

删除模块，用于根据所述关系数据修改表中的标识的关系ID从用于进行最终数据格式的编译的原始数据附表中删除与所述关系ID对应的数据，形成用于进行最终数据格式的编译的当前数据附表。

上述的修改装置，其中，还包括：

编译模块，用于对所述当前数据附表进行最终数据格式的编译。

上述的修改装置，其中，所述关系数据修改表还包括：用于表示待删除数据的标识的子关系ID和用于表示待删除数据的类型的子关系类别。

上述的修改装置，其中，所述构建模块包括：

第一确定单元，用于根据提取得到的数据，确定所述关系ID的值以及所述子关系ID的值；

赋予单元，用于将所述关系类别赋予一预设值；

第二确定单元，用于根据所述原始数据附表确定所述子关系类别的值；

构建单元，用于根据得到的所述关系ID的值、所述子关系ID的值、所述关系类别的值以及所述子关系类别的值构建所述关系数据修改表。

上述的修改装置，其中，还包括：

转化模块，用于将数据转化为中间数据格式，形成所述中间数据格式的数据库。

本发明的上述技术方案的有益效果如下：

上述方案中，所述电子地图关系数据的修改方法根据待删除数据的关系属性信息通过中间数据格式的数据库构建关系数据修改表，对满足条件的关系数据进行修改；可以满足客户特殊需求对导航电子地图属性数据进行特定修改，提供满足客户特定条件的定制化的数据产品，提高导航数据产品的灵活性，降低修改难度，优化客户体验，提升客户对导航数据产品的满意度，导航电子地图属性数据修改内容相对明确，后续产品验证测试对象明确，品质控制程度较高，导航电子地图属性数据修改内容结构清晰、简单，客户的多个需求或多种要素可共用一张成果表进行实现，导航电子地图编译程序开发成本较低。

附图说明

图1为本发明实施例的电子地图关系数据的修改方法的步骤示意图；

图2为本发明实施例的电子地图主要生产流程示意图；

图3为本发明实施例的电子地图关系数据的修改装置的结构示意图。

具体实施方式

为使本发明要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。

本发明针对现有的技术中根据客户需求修改导航电子地图数据时难度大、品质风险高、实现成本较大的问题，提供一种电子地图关系数据的修改方法，如图1所示，包括：

步骤11：获取待删除数据的关系属性信息；

步骤12：根据所述待删除数据的关系属性信息在中间数据格式的数据库进行数据查询和提取；

步骤13：根据查询和提取得到的数据构建关系数据修改表，所述关系数据修改表包括：用于表示待删除数据的标识的关系ID和用于表示待删除数据的类型的关系类别；

步骤14：根据所述关系数据修改表中的标识的关系ID从用于进行最终数据格式的编译的原始数据附表中删除与所述关系ID对应的数据，形成用于进行最终数据格式的编译的当前数据附表。

本发明实施例提供的所述电子地图关系数据的修改方法根据待删除数据的关系属性信息通过中间数据格式的数据库构建关系数据修改表，对满足条件的关系数据进行修改；可以满足客户特殊需求对导航电子地图属性数据进行特定修改，提供满足客户特定条件的定制化的数据产品，提高导航数据产品的灵活性，降低修改难度，优化客户体验，提升客户对导航数据产品的满意度，导航电子地图属性数据修改内容相对明确，后续产品验证测试对象明确，品质控制程度较高，导航电子地图属性数据修改内容结构清晰、简单，客户的多个需求或多种要素可共用一张成果表进行实现，导航电子地图编译程序开发成本较低。

本发明实施例提供的所述修改方法还包括：对所述当前数据附表进行最终数据格式的编译。由此步骤知本发明实施例提供的所述修改方法可以满足客户特殊需求对导航电子地图属性数据进行特定修改，而不用对从现有生产流程的前面环节进行调整，应用和生产成本较低；将修改导航电子地图属性数据的时间点提前，降低后期编译数据后再进行数据修改的难度和风险。

其中，所述关系数据修改表还包括：用于表示待删除数据的标识的子关系ID和用于表示待删除数据的类型的子关系类别。

进一步的，所述修改方法还包括：将数据转化为中间数据格式，形成所述中间数据格式的数据库。

对于传统的导航电子地图数据生产而言，包括产品设计、生产计划资源组织、外业实地采集数据、内业制作导航数据库、数据逻辑综合检查、转换中间数据格式、编译最终数据格式、产品测试验证这些主要的生产流程。传统导航电子地图产品生产流程多、更新周期较长，而且对于特定的导航数据生产公司而言，一般在进行产品设计的时候，数据规格标准已经制定，在一定的空间和时间范围内是相对稳定的，外业实地采集和内业制作都会遵照已制定的数据规格标准进行。这样标准化的数据生产，可能无法同时满足不同导航终端客户的存在细微差别的应用需求。

另一方面，导航电子地图数据内容丰富，主要可分为空间数据和属性数据。空间数据由包含坐标信息的点、线、面等空间实体构成，属性数据则是在空间数据基础上的各种属性、关系等信息集合。属性数据又可进行进一步细分，关系数据是其中的一种类型，表现的是将具体现实世界中的道路/背景内容等通过逻辑抽象为特定的线、点等结构，用线、点之间的组合关系展现附属在其上的相关信息，如利用进入道路、进入道路点关系表现的摄像头信息(线点关系)，利用进入道路、进入道路点、经过道路、退出道路关系表现的分歧信息(线点线关系)等，关系数据是对具体现实世界的一种高级逻辑抽象形式，也是生产导航地图数据的一项重要基础。空间数据和非关系类型的属性数据的修改与导航电子地图的数据更新的研究领域内容有部分重叠，本发明的研究对象仅为属性数据中的关系数据，即本发明为满足特定条件的关系数据修改的方法。

如上所述，如果需要提供定制化的导航电子地图数据，进行某些满足客户特定条件的关系数据的修改，目前已有的解决方案主要集中于整个生产流程的后端，如在导航应用端进行数据屏蔽，或在编译最终数据格式后或产品测试验证过程中进行数据修改，但这样，修改时间点较晚，且修改难度大、品质风险高，实现成本较大。而本发明则在导航数据生产环节的编译最终数据格式前，如图2所示，基于转换中间数据格式的数据库构建满足特定条件的具有固定表结构的关系数据修改表，对满足客户的特定条件的关系数据进行修改。达到在导航数据生产公司的数据规格标准一定的情况下，通过进行数据删除，屏蔽某些不满足客户需求的相关数据的目标。本发明具有可以满足客户特殊需求对导航电子地图属性数据进行特定修改，提供定制化的数据产品，优化客户体验，提升客户满意度；应用和生产成本较低；修改内容明确，品质控制程度较高；修改结构清晰简单；编译程序开发成本较低等多项优点。

对于满足特定条件的关系数据修改又可进行细分，一种是纯数据删除，适用于屏蔽某些不满足客户需求的相关数据；另一种是数据删除后新数据新增，适用于完全生产出满足客户需求的相关数据。后者与导航电子地图的数据更新的研究领域内容有部分重叠，且可能涉及到重新制定数据的规格标准等，情况比较复杂。本发明仅对前者进行讨论，即在导航数据生产公司的数据规格标准一定的情况下，通过进行数据删除，屏蔽某些不满足客户需求的相关数据，提供满足客户特定条件的定制化的数据产品。

一般导航电子地图数据编译使用的中间数据格式的文件类型，可能包括MIF/MID、SQLITE、Oracle等数据类型，无论何种数据类型，其基本表现之一都是数据表。本发明实施例提供的修改方法的核心是基于转换中间数据格式的数据库构建满足特定条件的具有固定表结构的关系数据修改表CONDITION_CHANGE，表结构可以设计如表1所示。

表1关系数据修改模型表

具体每个字段含义：CONDITION_ID为记录的关系ID，必填字段；SUBCONDITION_ID为子关系ID，适用于关系数据结构比较复杂、数据模型中需要增加子关系ID进行进一步细化的情况，可空字段；CONDITION_TYPE为关系类别，和CONDITION_ID字段对应，记录CONDITION_ID代表的具体关系类别，取值可以调整，能够区分不同种类的关系类别即可，CONDITION_TYPE字段与CONDITION_ID字段构成联合主键，可避免不同的关系类型出现关系ID重复的情况，具体关系类别可根据数据模型自行定义，必填字段；SUBCONDITION_TYPE记录子关系类别，和SUBCONDITION_ID字段对应，记录记录SUBCONDITION_ID代表的具体关系类别，适用于关系数据结构比较复杂、数据模型中需要对子关系类别进行进一步细化的情况，可空字段。

其中，关系ID为该对象在电子地图数据库的本类关系中的标识，比如摄像头1000001；子关系ID为关系ID的进一步细化的标识，比如1000001-1；关系类别为该对象在电子地图数据库中的属性类型，比如1；子关系类别为关系类别的进一步细化的属性类型，比如1-1。关系ID与关系类别结合，构成该对象在电子地图数据中的唯一标识。

CONDITION_ID、SUBCONDITION_ID字段内容需要基于导航数据生产公司使用的中间数据格式的数据模型进行数据查询和提取获得。客户条件明确、容易实现的可以利用SQL(结构化查询语言)语句直接基于中间数据格式的数据库进行查询获得；客户条件不容易实现的则需要基于中间数据格式的数据库使用特定的数据查询提取程序获得。但总体而言，基于客户提出的明确的、特定的条件，对于导航电子地图中间格式的数据库进行数据查询和提取，较易实现。

本发明实施例提供的所述修改方法中根据查询和提取后的数据构建关系数据修改表的步骤包括：根据提取得到的数据，确定所述关系ID的值以及所述子关系ID的值；将所述关系类别赋予一预设值；根据所述原始数据附表确定所述子关系类别的值；根据得到的所述关系ID的值、所述子关系ID的值、所述关系类别的值以及所述子关系类别的值构建所述关系数据修改表。

需要说明的是，在没有子关系ID的数据的情况下，将所述子关系ID与所述关系ID赋予相同的值。

下面举例对本发明实施例中构建关系数据修改表的步骤进行具体说明。

实施例一：

假如摄像头数据内容包括限速摄像头、移动式测速、交通信号灯摄像头、非机动车道摄像头、公交车道摄像头等多种类型。导航终端A客户认为所有类型的摄像头都在导航仪上显示会让驾驶者觉得过于密集、影响驾驶者体验，且驾驶者在实际驾驶过程中更加关注限速摄像头。客户要求只提供限速摄像头数据内容即可，删除其他类型的摄像头。摄像头数据模型和内容如表2和表3所示：

表2摄像头数据模型表

表3摄像头内容记录样例表

因客户条件明确、容易实现，直接利用SQL语句对表1进行查询即可获得不为限速摄像头的所有CAMERA_ID。样例SQL语句可以为“Select CAMERA_ID from CAMERA whereKIND<>1”。提取成果的记录样例如表4所示：

CAMERA
	CAMERA_ID
1000001
	1000003
1000005
	……

表4摄像头提取成果记录样例表

因摄像头数据没有SUBCONDITION_ID，考虑可将的SUBCONDITION_ID赋予与CONDITION_ID相同的值，CONDITION_TYPE设为1(代表摄像头关系)，SUBCONDITION_TYPE参考CAMERA表的KIND字段，便于进行数据记录区分。结合提取成果和以上内容，构建出CONDITION_CHANGE表内容如表5所示。

表5摄像头关系数据修改表

实施例二：

假如制定的数据规格标准规定高速上连续两单分歧距离在600米内时应制作为普通连续分歧，但导航终端A客户认为高速上连续两单分歧距离在300-600米范围时不应制作普通连续分歧。客户要求只提供连续两单分歧距离在100米-300米范围内的普通连续分歧数据内容即可，删除超过300米的普通连续分歧关系。分歧数据模型和内容如表6至表13所示：

表6分歧数据模型表

表7分歧类型数据模型表

表8分歧关系经过道路数据模型表

表9道路几何信息数据模型表

表10分歧内容记录样例表

表11分歧类型内容记录样例表

表12分歧关系经过道路内容记录样例表

表13道路几何信息内容记录样例表

客户条件虽然明确，但涉及到进行几何计算，用SQL语句略不容易实现，可以基于中间数据格式的数据库使用特定的数据查询提取程序获得。该数据查询提取程序的提取对象为普通连续分歧关系ID，需要满足以下条件：(1)该普通连续分歧的BRANCH_ID在表11(SERIESBRANCH表)里面的TYPE字段取值需为0；(2)该普通连续分歧的BRANCH_ID在表12(BRANCH_VIA_LINK表)里面需要存在LINK_ID(存在经过道路)；(3)该普通连续分歧BRANCH_ID对应的表12(BRANCH_VIA_LINK表)中经过道路的长度之和需要大于300米且小于等于600米(利用LINK_ID在表13-LINK_GEOMETRY表中对应的几何信息进行计算)；(4)最终提取成果中，相同的BRANCH_ID只保留一次(即结果进行去重处理)。例如：根据表11满足条件(1)的有10000001，根据表12知10000001对应的LINK-ID为12121201，根据表13知12121201对应的长度为100m，不满足长度大于300米小于600米的条件，所以10000001不满足条件(3)；同理得，10000003对应的LINK-ID为34343401和34343402,LINK-ID34343401对应的长度为200m、34343402对应的长度为150m，则10000003对应的长度之和为200+150＝350m；350米大于300米小于600米，满足所有条件，因此提取10000003这个BRANCH_ID。

基于上述这些限制条件开发数据查询提取程序，程序运行后提取成果的记录样例如表14所示：

SERIESBRANCH
	BRANCH_ID
10000003
	10000004
10000005
	10000006

表14分歧提取成果记录样例表

因分歧关系数据没有SUBCONDITION_ID，考虑可将的SUBCONDITION_ID赋予与CONDITION_ID相同的值，CONDITION_TYPE设为2(代表分歧关系)，SUBCONDITION_TYPE参考表11的TYPE字段。结合提取成果和以上内容，构建出CONDITION_CHANGE表内容如表15所示。

表15分歧关系数据修改表

在实际工作中，本发明实施例一和实施例二的成果可以进行合并，提供给编译部门进行统一编译，即实现客户多个需求或多种要素共用一张成果表。需要进行进一步说明的是，后续环节中存在编译最终数据格式步骤。编译最终数据格式是导航电子地图数据产品实现的重要过程。编译过程可以理解为将转换中间格式数据利用特定的编译程序，分解、转换成为成各种有逻辑关系的小的文件及文件夹的过程。通常编译后生成的数据为二进制导航电子地图数据，更加适宜于导航软件或者二次开发商的硬件实现需求。

编译过程实际上是一种导航电子地图数据的格式转换过程，需要保证导航电子地图信息的无丢失和无错误转换。编译程序和编译逻辑通常不是固定的，具体实现过程和各个导航电子地图产品提供商/软件生产商等有关。

目前，导航市场上，主流的转换中间格式数据格式包括RDF数据格式、NIMIF数据格式、GDF数据格式等，而编译最终数据格式包括KIWI格式、SDAL格式、NDS格式以及其他自定义等。

本发明实施例提供了一种电子地图关系数据的修改方法，这种方法适用于导航终端客户需求与导航数据生产公司的数据规格标准存在不一致时，导航数据生产公司可以在导航数据生产环节的编译最终数据格式前，基于转换中间数据格式的数据库构建满足特定条件的具有固定表结构的关系数据修改表CONDITION_CHANGE，对满足客户的特定条件的关系数据进行修改。修改对象为满足客户的特定条件的关系数据，是导航电子地图数据的属性数据中的一种；达到在导航数据生产公司的数据规格标准一定的情况下，通过进行数据删除，屏蔽某些不满足客户需求的相关数据的目标。本发明具有可以满足客户特殊需求对导航电子地图属性数据进行特定修改，提供定制化的数据产品，优化客户体验，提升客户满意度；应用和生产成本较低；修改内容明确，品质控制程度较高；修改结构清晰简单；编译程序开发成本较低等多项优点。

为了解决上述技术问题，本发明实施例还提供了一种电子地图关系数据的修改装置，如图3所示，包括：

获取模块，用于获取待删除数据的关系属性信息；

查询提取模块，用于根据所述待删除数据的关系属性信息在中间数据格式的数据库进行数据查询和提取；

构建模块，用于根据查询和提取得到的数据构建关系数据修改表，所述关系数据修改表包括：用于表示待删除数据的标识的关系ID和用于表示待删除数据的类型的关系类别；

删除模块，用于根据所述关系数据修改表中的标识的关系ID从用于进行最终数据格式的编译的原始数据附表中删除与所述关系ID对应的数据，形成用于进行最终数据格式的编译的当前数据附表。

本发明实施例提供的所述电子地图关系数据的修改装置根据待删除数据的关系属性信息通过中间数据格式的数据库构建关系数据修改表，对满足条件的关系数据进行修改；可以满足客户特殊需求对导航电子地图属性数据进行特定修改，提供满足客户特定条件的定制化的数据产品，提高导航数据产品的灵活性，降低修改难度，优化客户体验，提升客户对导航数据产品的满意度，导航电子地图属性数据修改内容相对明确，后续产品验证测试对象明确，品质控制程度较高，导航电子地图属性数据修改内容结构清晰、简单，客户的多个需求或多种要素可共用一张成果表进行实现，导航电子地图编译程序开发成本较低。

本发明实施例提供的所述修改装置还包括：编译模块，用于对所述当前数据附表进行最终数据格式的编译。由此可知本发明实施例提供的所述修改装置可以满足客户特殊需求对导航电子地图属性数据进行特定修改，而不用对从现有生产流程的前面环节进行调整，应用和生产成本较低；将修改导航电子地图属性数据的时间点提前，降低后期编译数据后再进行数据修改的难度和风险。

其中，所述关系数据修改表还包括：用于表示待删除数据的标识的子关系ID和用于表示待删除数据的类型的子关系类别。

本发明实施例提供的所述修改装置中所述构建模块包括：第一确定单元，用于根据提取得到的数据，确定所述关系ID的值以及所述子关系ID的值；赋予单元，用于将所述关系类别赋予一预设值；第二确定单元，用于根据所述原始数据附表确定所述子关系类别的值；构建单元，用于根据得到的所述关系ID的值、所述子关系ID的值、所述关系类别的值以及所述子关系类别的值构建所述关系数据修改表。

进一步的，所述修改装置还包括：转化模块，用于将数据转化为中间数据格式，形成所述中间数据格式的数据库。

需要说明的是，上述电子地图关系数据的修改方法的所述实现实施例均适用于该修改装置的实施例中，也能达到相同的技术效果。

以上所述的是本发明的优选实施方式，应当指出对于本技术领域的普通人员来说，在不脱离本发明所述原理前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种电子地图关系数据的修改方法，其特征在于，包括：

获取待删除数据的关系属性信息；

根据所述待删除数据的关系属性信息在中间数据格式的数据库进行数据查询和提取；

根据查询和提取得到的数据构建关系数据修改表，所述关系数据修改表包括：用于表示待删除数据的标识的关系ID和用于表示待删除数据的类型的关系类别；

根据所述关系数据修改表中的标识的关系ID从用于进行最终数据格式的编译的原始数据附表中删除与所述关系ID对应的数据，形成用于进行最终数据格式的编译的当前数据附表。

2.如权利要求1所述的修改方法，其特征在于，还包括：

对所述当前数据附表进行最终数据格式的编译。

3.如权利要求1所述的修改方法，其特征在于，所述关系数据修改表还包括：用于表示待删除数据的标识的子关系ID和用于表示待删除数据的类型的子关系类别。

4.如权利要求3所述的修改方法，其特征在于，根据查询和提取后的数据构建关系数据修改表的步骤包括：

根据提取得到的数据，确定所述关系ID的值以及所述子关系ID的值；

将所述关系类别赋予一预设值；

根据所述原始数据附表确定所述子关系类别的值；

根据得到的所述关系ID的值、所述子关系ID的值、所述关系类别的值以及所述子关系类别的值构建所述关系数据修改表。

5.如权利要求1所述的修改方法，其特征在于，还包括：

将数据转化为中间数据格式，形成所述中间数据格式的数据库。

6.一种电子地图关系数据的修改装置，其特征在于，包括：

获取模块，用于获取待删除数据的关系属性信息；

查询提取模块，用于根据所述待删除数据的关系属性信息在中间数据格式的数据库进行数据查询和提取；

构建模块，用于根据查询和提取得到的数据构建关系数据修改表，所述关系数据修改表包括：用于表示待删除数据的标识的关系ID和用于表示待删除数据的类型的关系类别；

删除模块，用于根据所述关系数据修改表中的标识的关系ID从用于进行最终数据格式的编译的原始数据附表中删除与所述关系ID对应的数据，形成用于进行最终数据格式的编译的当前数据附表。

7.如权利要求6所述的修改装置，其特征在于，还包括：

编译模块，用于对所述当前数据附表进行最终数据格式的编译。

8.如权利要求6所述的修改装置，其特征在于，所述关系数据修改表还包括：用于表示待删除数据的标识的子关系ID和用于表示待删除数据的类型的子关系类别。

9.如权利要求8所述的修改装置，其特征在于，所述构建模块包括：

第一确定单元，用于根据提取得到的数据，确定所述关系ID的值以及所述子关系ID的值；

赋予单元，用于将所述关系类别赋予一预设值；

第二确定单元，用于根据所述原始数据附表确定所述子关系类别的值；

构建单元，用于根据得到的所述关系ID的值、所述子关系ID的值、所述关系类别的值以及所述子关系类别的值构建所述关系数据修改表。

10.如权利要求6所述的修改装置，其特征在于，还包括：

转化模块，用于将数据转化为中间数据格式，形成所述中间数据格式的数据库。