CN113511193A - 泊车地图的建图方法和设备、生成方法和设备及建图系统 - Google Patents

Abstract

本申请是关于一种泊车地图的建图方法和设备、生成方法和设备及建图系统。该建图方法包括：收集车端至少两次泊车数据，其中，泊车数据包括停车路线和停车位；将收集的泊车数据进行对比；如果至少两次泊车数据相同，则根据相同的泊车数据建立对应的待确认泊车地图；将待确认泊车地图发送至车端进行当前泊车数据的泊车数据比对；接收车端根据泊车数据比对结果生成的反馈信息，以根据反馈信息确认待确认泊车地图或调整待确认泊车地图。本申请提供的方案，能够避免建立泊车地图的过程中出现异常或失败时给用户带来负面情绪和紧张感，进而避免给用户造成不好的体验，同时无需用户多次泊车配合建图，提高了建图效率。

Description

泊车地图的建图方法和设备、生成方法和设备及建图系统

技术领域

本申请涉及自动驾驶技术领域，尤其涉及一种泊车地图的建图方法和设备、生成方法和设备及建图系统。

背景技术

随着自动驾驶技术的发展，自动记忆泊车是自动驾驶技术的重要应用之一。记忆泊车是通过获取车端历史的泊车数据，针对同一泊车路径和同一停车位，建立对应的泊车地图；当车端要泊入相同的停车位时，车端可以根据泊车地图进行自动记忆泊车。

相关技术中，泊车地图的建立需要用户全程参与和监督，需要用户适时进行选择或调整，直至地图完成建立。这样的建图方式，当建立地图的过程中出现异常或失败时，将给用户带来负面情绪和紧张感，造成不好的体验的同时，需要用户多次泊车配合建图，影响建图效率。

发明内容

为解决或部分解决相关技术中存在的问题，本申请提供一种泊车地图的建图方法和设备、生成方法和设备及建图系统，该泊车地图的建图方法，能够避免建立泊车地图的过程中出现异常或失败时给用户带来负面情绪和紧张感，进而避免给用户造成不好的体验，同时无需用户多次泊车配合建图，提高了建图效率。

本申请第一方面提供一种泊车地图的建图方法，其包括：

收集车端至少两次泊车数据，其中，所述泊车数据包括停车路线和停车位；

将收集的所述泊车数据进行对比；

如果至少两次所述泊车数据相同，则根据相同的所述泊车数据建立对应的待确认泊车地图；

将所述待确认泊车地图发送至所述车端进行当前泊车数据的泊车数据比对；

接收所述车端根据泊车数据比对结果生成的反馈信息，以根据所述反馈信息确认所述待确认泊车地图或调整所述待确认泊车地图。

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

如果收集的所述泊车数据互不相同，持续收集所述车端的新的泊车数据。

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

预先设置相异泊车数据的预设存储数量；所述相异泊车数据包括相异的停车路线和/或相异的停车位；

当收集的所述相异泊车数据的数量大于预设存储数量时，保留符合所述预设存储数量的最新的所述相异泊车数据。

在其中一个实施例中，所述如果至少两次所述泊车数据相同，则根据相同的所述泊车数据建立对应的待确认泊车地图，包括：

如果至少两次所述泊车数据相同，根据预设的成熟度判定条件，确定所述泊车数据的成熟度；

如果所述泊车数据的成熟度达到预设成熟值，则生成所述待确认泊车地图。

在其中一个实施例中，所述将所述待确认泊车地图发送至所述车端进行当前泊车数据泊车数据比对，包括：

当所述泊车地图的数量大于1时，将符合预设发送条件的所述待确认泊车地图发送至所述车端。

在其中一个实施例中，所述接收根据泊车数据比对结果生成的反馈信息，以根据所述反馈信息确认所述待确认泊车地图，包括：

如果所述待确认泊车地图的泊车数据与所述车端的所述当前泊车数据相同，接收所述车端对所述待确认泊车地图的泊车确认信息。

本申请第二方面提供一种泊车地图的生成方法，其包括：

接收待确认泊车地图，其中，所述待确认泊车地图根据云端收集的至少两次相同的泊车数据生成，每一所述泊车数据包括停车路线和停车位；

将所述待确认泊车地图与当前泊车数据的进行泊车数据比对，生成对应的泊车数据比对结果；

发送根据所述泊车数据比对结果生成的反馈信息至所述云端，以使所述云端根据所述反馈信息确认所述待确认泊车地图或调整所述待确认泊车地图。

在其中一个实施例中，所述发送根据所述泊车数据比对结果生成的反馈信息至所述云端，包括：

如果所述泊车地图的泊车数据与所述车端的当前泊车数据相同，显示交互确认界面；

将用户在所述交互确认界面生成的所述反馈信息发送至所述云端。

本申请第三方面提供一种泊车地图的建图设备，其包括：

泊车数据收集模块，用于收集车端至少两次泊车数据，其中，所述泊车数据包括停车路线和停车位；

泊车数据对比模块，用于将收集的所述泊车数据进行对比；

待确认泊车地图建立模块，用于如果至少两次所述泊车数据相同，则根据相同的所述泊车数据建立对应的待确认泊车地图；

待确认泊车地图发送模块，用于将所述待确认泊车地图发送至所述车端进行当前泊车数据的泊车数据比对；

反馈接收模块，用于接收所述车端根据泊车数据比对结果生成的反馈信息。

本申请第四方面提供一种泊车地图的生成设备，其包括：

待确认泊车地图接收模块，用于接收待确认泊车地图，其中，所述待确认泊车地图根据云端收集的至少两次相同的泊车数据生成，每一所述泊车数据包括停车路线和停车位；

泊车数据比对模块，用于将所述待确认泊车地图与当前泊车数据的进行泊车数据比对，生成对应的泊车数据比对结果；

反馈发送模块，用于发送根据所述泊车数据比对结果生成的反馈信息至所述云端。

本申请第五方面提供一种泊车地图的建图系统，其包括云端和车端；其中：

所述云端用于收集车端至少两次泊车数据，其中，所述泊车数据包括停车路线和停车位，并将收集的所述泊车数据进行对比，如果至少两次所述泊车数据相同，则根据相同的所述泊车数据建立对应的待确认泊车地图，并将所述待确认泊车地图发送至所述车端进行当前泊车数据的泊车数据比对；接收所述车端根据泊车数据比对结果生成的反馈信息，以根据所述反馈信息确认所述待确认泊车地图或调整所述待确认泊车地图；

所述车端用于接收所述云端发送的所述待确认泊车地图，并将所述待确认泊车地图与当前泊车数据的进行泊车数据比对，生成对应的泊车数据比对结果，及发送根据所述泊车数据比对结果生成的反馈信息至所述云端。

本申请提供的技术方案可以包括以下有益效果：

本申请的泊车地图的建图方法，通过收集车端至少两次泊车数据，将收集的泊车数据对比，如果至少两次泊车数据相同，则根据相同的泊车数据建立对应的泊车地图，将泊车地图发送至车端进行当前泊车数据进行泊车数据比对，通过接收车端根据泊车数据比对结果生成对应的反馈信息，以根据反馈信息确认待确认泊车地图，从而获得可以投入自动记忆泊车中使用的泊车地图，或调整所述待确认泊车地图。这样的设计，能够通过自主收集泊车数据和泊车数据的自主比对来建立泊车地图，无需用户频繁参与和监督建图过程，避免因建图过程中出现异常或失败时给用户带来负面情绪和紧张感，进而避免给用户造成不好的体验，同时无需用户多次泊车配合建图，提高了建图效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

通过结合附图对本申请示例性实施方式进行更详细的描述，本申请的上述以及其它目的、特征和优势将变得更加明显，其中，在本申请示例性实施方式中，相同的参考标号通常代表相同部件。

图1是本申请一实施例示出的泊车地图的建图方法的流程示意图；

图2是本申请一实施例示出的泊车地图的生成方法的流程示意图；

图3是本申请另一实施例示出的泊车地图的建图方法的另一流程示意图；

图4是本申请另一实施例示出的泊车地图的建图方法的另一流程示意图；

图5是本申请实施例示出的泊车地图的建图设备的结构示意图；

图6是本申请另一实施例示出的泊车地图的生成设备的结构示意图；

图7是本申请实施例示出的泊车地图的建图系统的结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的实施方式。虽然附图中显示了本申请的实施方式，然而应该理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本申请更加透彻和完整，并且能够将本申请的范围完整地传达给本领域的技术人员。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语“第一”、“第二”、“第三”等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

记忆泊车是通过获取车端历史的泊车数据，针对同一泊车路径和同一停车位，建立对应的泊车地图；当车端要泊入相同的停车位时，车端可以根据泊车地图进行记忆泊车。相关技术中，泊车地图的建立需要用户全程参与和监督，需要用户适时进行选择或调整，直至地图完成建立。这样的建图方式，当建立地图的过程中出现异常或失败时，将给用户带来负面情绪和紧张感，造成不好的体验的同时，需要用户多次泊车配合建图，影响建图效率。

针对上述问题，本申请实施例提供一种泊车地图的建图方法，能够避免建立泊车地图的过程中出现异常或失败时给用户带来负面情绪和紧张感，进而避免给用户造成不好的体验，同时无需用户多次泊车配合建图，提高了建图效率。

以下结合附图详细描述本申请实施例的技术方案。

参见图1，本申请实施例示出的泊车地图的建图方法，包括：

步骤S110，收集车端至少两次泊车数据，其中，泊车数据包括停车路线和停车位。

其中，至少两次泊车数据是指在针对同一车辆在不同时间分别收集的泊车数据。每次泊车数据分别包括停车路线和停车位。不同次收集的泊车数据可以相同，也可以不同。例如，两次泊车数据之间，二者的停车路线相同，停车位相同；或二者的停车路线相同，停车位不同；或二者的停车路线不同，停车位相同；或二者的停车路线不同，停车位不同。可以理解，各次的泊车数据分别具有各自的停车路线和对应的停车位，同一个停车位可以经由不同地停车路线对应，不同的停车位则对应不同的停车路线。在一实施例中，停车路线可以是车辆在进入停车场后从预设起点行驶至停车位的路线。

进一步地，由云端主动静默地收集车端的泊车数据，并将泊车数据收集至云端进行存储。在一实施例中，泊车数据可以是历史的记忆泊车的数据，也可以是用户自行泊车的数据。

步骤S120，将收集的泊车数据进行对比。

其中，将不同次的泊车数据的停车路线和停车位之间相互对应进行对比。例如，将第一次泊车数据的停车路线和第二次泊车数据的停车路线进行对比，将第一次泊车数据的停车位和第二次泊车数据的停车位进行对比，即在将不同次的泊车数据进行对比时，停车位和停车路线分别各自独立对应对比。

步骤S130，如果至少两次泊车数据相同，则根据相同的泊车数据建立对应的待确认泊车地图。

其中，不同次的泊车数据可能相同也可能不同。以两次泊车数据为例，两次的泊车数据相同是指二者的停车位相同，以及二者的停车路线相同，两次泊车数据均根据相同的停车路线驶入相同的停车位。如若二者的停车位不同，和/或停车路线不同，则二者的泊车数据不同。当收集的泊车数据为两次时，如果两次泊车数据相同，则根据相同的泊车数据建立对应的待确认泊车地图。可以理解，此时建立的待确认泊车地图还无法直接用于自动记忆泊车。

当收集的泊车数据为三次及以上时，以四次为例，如果其中两次的泊车数据相同，则根据该两次相同的泊车数据建立待确认泊车地图；如果剩余的另外两次泊车数据不相同，则另外两次泊车数据不能建立待确认泊车地图。如果另外两次的泊车数据相互相同，则根据该另外两次相同的泊车数据建立另外的待确认泊车地图，即在收集的四次的泊车数据中，存在两组相同的泊车数据，则分别建立两个对应的待确认泊车地图。或者当四次泊车数据中的其中三次泊车数据相同，除此之外的泊车数据与这三次不同，则根据这三次泊车数据建立待确认泊车地图。以此类推，根据逐次收集的泊车数据，不同次的泊车数据相互对比判断，以建立对应的待确认泊车地图。在一实施例中，根据逐次收集的泊车数据，对应建立的待确认泊车地图可以是至少一个。可以理解，待确认泊车地图包括对应的泊车数据中的停车路线和停车位。不同的待确认泊车地图的泊车数据不同。

步骤S140，将待确认泊车地图发送至车端进行当前泊车数据的泊车数据比对。

为了验证上述步骤建立的待确认泊车地图是否符合用户实际需求，云端将建立的待确认泊车地图发送至车端，并将该待确认泊车地图与车端的当前泊车数据进行泊车数据比对。在一实施例中，当前泊车数据包括车端当前行驶的当前停车路线和停泊的当前停车位。基于待确认泊车地图包括停车路线和停车位，为了验证该待确认泊车地图是否实用，泊车数据比对即为将待确认泊车地图中的停车路线和当前泊车数据的当前停车路线进行比对，以及将待确认泊车地图中的停车位和当前泊车数据的当前停车位进行比对。

进一步地，在其他实施例中，发送至车端的待确认泊车地图可以是一个待确认泊车地图，也可以是两个以上待确认泊车地图。当有两个以上待确认泊车地图发送至车端时，可以分别将每一待确认泊车地图与当前泊车数据进行泊车数据比对以便确认待确认泊车地图的泊车数据与当前泊车数据是否相同，从而便于判断待确认泊车地图是否可以投入实际的记忆泊车中进行应用。

步骤S150，接收车端根据泊车数据比对结果生成的反馈信息，以根据反馈信息确认待确认泊车地图或调整待确认泊车地图。

可以理解，在车端接收待确认泊车地图后，车端将待确认泊车地图与车端的当前泊车数据进行泊车数据比对，车端生成对应的泊车数据比对结果。根据不同的泊车数据比对结果，车端生成相应的反馈信息。

进一步地，根据泊车数据比对结果，在一实施例中，如果待确认泊车地图的泊车数据与车端的当前泊车数据相同，接收车端对待确认泊车地图的泊车确认信息。其中，如果待确认泊车地图的泊车数据与当前泊车数据相同，说明车端在当前泊车数据的当前停车路线与待确认泊车地图的停车路线相同，以及当前停车位与待确认泊车地图的停车位相同，从而说明待确认泊车地图符合用户的实际泊车行为，即可以通过车端进行确认，生成相应的反馈信息，该反馈信息即泊车确认信息，车端发送对该待确认泊车地图的反馈信息至云端，云端即可根据该反馈信息确认待确认泊车地图完成建立，待确认泊车地图形成可以投入实际的自动记忆泊车应用的泊车地图。

进一步地，根据泊车数据比对结果，在一实施例中，如果待确认泊车地图的泊车数据与车端的当前泊车数据不同，则调整待确认泊车地图。在一实施例中，调整的方式可以是更换新的待确认泊车地图，直至新的待确认泊车地图获得确认，以建立泊车地图。

综上，本申请的泊车地图的建图方法，通过收集车端至少两次泊车数据，将收集的泊车数据对比，如果至少两次泊车数据相同，则根据相同的泊车数据建立对应的泊车地图，将泊车地图发送至车端进行当前泊车数据进行泊车数据比对，通过接收车端根据泊车数据比对结果生成对应的反馈信息，以根据反馈信息确认待确认泊车地图，从而获得可以投入自动记忆泊车中使用的泊车地图，或调整所述待确认泊车地图。这样的设计，能够通过自主收集泊车数据和泊车数据的自主比对来建立泊车地图，无需用户频繁参与和监督建图过程，避免因建图过程中出现异常或失败时给用户带来负面情绪和紧张感，进而避免给用户造成不好的体验，同时无需用户多次泊车配合建图，提高了建图效率。

参见图2，一实施例中，本申请还提供一种泊车地图的生成方法，包括：

步骤S210，接收待确认泊车地图，其中，待确认泊车地图根据云端收集的至少两次相同的泊车数据生成，每一泊车数据包括停车路线和停车位。

在其中一个实施例中，车端接收云端发送的待确认泊车地图，以便将待确认泊车地图在后续步骤进行泊车数据比对。由于待确认泊车地图根据至少两次相同的泊车数据生成，待确认泊车地图包括该泊车数据的对应的停车路线和停车位。

步骤S220，将待确认泊车地图与当前泊车数据的进行泊车数据比对，生成对应的泊车数据比对结果。

可以理解，车端根据用户自行手动泊车的行为，可以在后台静默地获得对应的当前泊车数据，当前泊车数据包括当前停车路线和当前停车位。在车辆行驶的过程中及泊车时，车端在后台静默地将待确认泊车地图的停车路线与当前停车路线比对，及将停车位与当前停车位比对，生成对应的泊车数据比对结果。

泊车数据比对结果可以是待确认泊车地图与当前泊车数据相同，或待确认泊车地图与当前泊车数据不同。在一实施例中，当待确认泊车地图的停车路线与当前停车路线相同，及将停车位与当前停车位相同时，则待确认泊车地图与当前泊车数据相同。在一实施例中，当待确认泊车地图的停车路线与当前停车路线不同，和/或将停车位与当前停车位不同时，则待确认泊车地图与当前泊车数据不同。

步骤S230，发送根据泊车数据比对结果生成的反馈信息至云端，以使云端根据反馈信息确认待确认泊车地图或调整待确认泊车地图。

车端根据不同的泊车数据比对结果，生成对应的反馈信息，并将反馈信息发送至云端。在其中一个实施例中，如果泊车地图的泊车数据与车端的当前泊车数据相同，车端显示交互确认界面；将用户在所述交互确认界面生成的反馈信息发送至云端。进一步地，用户可以在交互确认界面上选择泊车信息确认，从而生成包括泊车确认信息的反馈信息，以使云端即可根据该反馈信息确认待确认泊车地图。

在其中一个实施例中，如果泊车地图的泊车数据与车端的当前泊车数据不同，车端生成相应的反馈信息并发送至云端，以使云端对该待确认泊车地图进行调整。

综上，本申请的泊车地图的生成方法，通过车端接收待确认泊车地图，并将待确认泊车地图与当前泊车数据的进行泊车数据比对，根据泊车数据比对结果生成的反馈信息，并将反馈信息发送至云端，以使云端根据反馈信息确认待确认泊车地图或调整待确认泊车地图。这样的设计，能够通过车端自主静默地完成待确认泊车地图的接收和泊车数据比对，最终发送至云端建立对应的泊车地图，无需用户频繁参与和监督建图过程，避免因建图过程中出现异常或失败时给用户带来负面情绪和紧张感，进而避免给用户造成不好的体验，同时无需用户多次泊车配合建图，提高了建图效率。

为了便于进一步详细理解本申请的泊车地图的建图方法，一并参见图3和图4，本申请实施例示出的泊车地图的建图方法，包括：

步骤S310，云端自主静默收集车端至少两次泊车数据，其中，泊车数据包括停车路线和停车位。

在一实施例中，云端可以是服务器，车端为车辆上的智能终端设备。在一实施例中，云端与车端可以通过通信连接。为了避免用户因参与建图过程而引起的紧张感，云端自主且静默地收集车端的泊车数据，即云端不会通过各种信息明示提醒用户参与或监督建图过程。在用户自行进行手动泊车的过程中，车辆行驶的停车路线和停车位，即为需要收集的泊车数据。

进一步地，泊车数据可以通过车端的定位设备、图像采集设备和超声波感知设备获取泊车数据，例如可以通过车端的GPS(Global Positioning System，全球定位系统)获取车端在泊车过程中停车路线的位置信息，还可以通过车端的摄像装置采集车端在泊车过程中的图像信息以及停车位的信息，还可以通过超声波感知设备获取车端周围的阻挡物的位置、距离和图像信息。

为了避免泊车数据占用云端过多内存，提高云端运行速度，在一实施例中，预先设置相异泊车数据的预设存储数量；相异泊车数据包括相异的停车路线和/或相异的停车位；当收集的相异泊车数据的数量大于预设存储数量时，保留符合预设存储数量的最新的相异泊车数据。其中，相异泊车数据即为不同的泊车数据，可以是停车位相同而停车路线相异，也可以是停车位相异而停车路线相同，还可以是停车位和停车路线均相异。预设存储数量越大，云端能够收集存储的泊车数据越多，预设存储数量越小，泊车数据占用云端的存储空间越小，节约云端的内存的同时，减少云端的处理负荷，云端运行更快。在一实施例中，预设存储数量可以是预设收集的相异泊车数据的次数。在一实施例中，预设存储数量可以是预设5～10个泊车数据，例如5个、8个、10个泊车数据等等。当收集的至少两次泊车数据相异时，例如收集两个相异的泊车数据时，则占据两个预设存储数量的额度。当收集的泊车数据中的部分相同时，则相同的泊车数据累积为占据一个预设存储数量的额度。

为了避免在云端存储冗余数据，当收集的相异泊车数据的数量大于预设存储数量时，保留符合预设存储数量的最新的相异泊车数据。可以理解，最新的相异泊车数据为最近时间收集的相异泊车数据，从而删除历史时间收集的相异泊车数据。例如，当相异泊车数据的预设存储数量为5个时，如果云端陆续收集存储了的相异泊车数据的数量已经包含5个，当最新收集泊车数据与云端存储的5个相异泊车数据均相异时，最新收集的泊车数据可以视为第6个相异泊车数据。如果云端直接存储第6个相异泊车数据，则云端存储的相异泊车数据6个大于预设存储数量为5个。此时，将6个相异泊车数据按照收集时间早晚进行排序，第6个则可以替换覆盖最早收集的相异泊车数据，从而使云端陆续收集存储了的相异泊车数据保持在预设存储数量之内，避免存储冗余数据，占据云端内存，同时使云端内的泊车数据保持在最新状态。以此类推，一实施例中，如果云端持续最新收集的泊车数据与历史收集存储的泊车数据相异，则继续采用最新的泊车数据覆盖最旧的泊车数据。

步骤S320，如果云端收集的泊车数据互不相同，云端持续收集车端的新的泊车数据。

为了确保记忆泊车所采用的待确认泊车地图的安全性和可靠性，基于一次待确认泊车地图无法进行对比验证和数据完善，即仅靠一次泊车数据无法直接建立待确认泊车地图。因此，当云端经过至少两次收集的泊车数据互不相同，也就是任意两个泊车数据相异时，将持续收集车端的新的泊车数据。将最新收集的泊车数据和云端历史收集的泊车数据进行对比，确认是否可以得到相同的泊车数据。若收集新的泊车数据和原有的泊车数据之间仍互不相同，则继续持续收集新的泊车数据。

步骤S330，如果至少两次泊车数据相同，云端根据预设的成熟度判定条件，计算泊车数据的成熟度；如果泊车数据的成熟度达到预设成熟值，则生成待确认泊车地图。

在一实施例中，当云端收集的泊车数据中，至少两次泊车数据相同时，则可以停止收集车端的新的泊车数据，也可以继续收集车端的新的泊车数据，以获得更多的相同的泊车数据进行待确认泊车地图的数据完善。

进一步地，为了判断泊车数据的有效性，提高创建的待确认泊车地图的可靠性，在一实施例中，可以采用预设的成熟度判定条件进行泊车数据的成熟度的计算。根据预设的成熟度判定条件计算相同的泊车数据的成熟度，从而在至少两次相同的泊车数据中，采用成熟度符合预设成熟值的泊车数据，从而建立可靠性更高的待确认泊车地图。或者结合多个均符合预设成熟值的相同的泊车数据，共同构建待确认泊车地图。

为了合理计算泊车数据的成熟度，在一实施例中，预设的成熟度判定条件可以根据泊车行为和/或用户行为进行设定。泊车行为是指沿停车路线行驶至停车位进行泊车的行为。也就是说，一次完整的泊车行为包括一条停车路线和对应的一个停车位。用户行为是指用户选择泊车确认信息的行为或选择确认待确认泊车地图不正确的行为。在一实施例中，成熟度判定条件可以针对不同的泊车行为和用户行为设定对应的预设分值，预设分值可以是正数或负数，不同的行为具有对应的预设分值。通过参考成熟度判定条件，可以对泊车数据的成熟度进行打分，最后将获得的分值累加，总分值即为该泊车数据最终的成熟度。总分值用于反应泊车数据的成熟度，总分值越大，则代表泊车数据越成熟。如果泊车数据的成熟度达到预设成熟值，则说明该泊车数据符合建图需求，该泊车数据则可以用于生成待确认泊车地图，继而提高待确认泊车地图的可靠性。待确认泊车地图基于至少两次相同的泊车数据生成，在一实施例中，各泊车数据的成熟度的分值的总和即为待确认泊车地图的对应的成熟度的分值。也就是说，待确认泊车地图也具有对应的成熟度。当云端生成的待确认泊车地图不仅限于1个时，则可以根据各待确认泊车地图的成熟度的分值进行排序，以便执行后续步骤S340。

针对同一车辆在同一停车场进行泊车，每一次泊车行为对应一个泊车数据，泊车数据包含一条停车路线和一个停车位。在一实施例中，预设的成熟判定条件可以是：(1)在云端进行第一次泊车数据收集，即车辆第一次在该停车场进行停车时，生成的第一个泊车数据具有对应的分值，成熟度分值+1。(2)如果车辆后续重复执行该泊车数据对应的停车路线和停车位，则该泊车数据的成熟度随着每次的重复执行，每次重复执行后的成熟度对应的预设分值为+1。(3)当车辆产生新的泊车数据时，即新的泊车数据与云端历史收集的泊车数据相异时，例如停入新的停车位或行驶新的停车路线，新的泊车数据的成熟度对应的预设分值为+1，历史的泊车数据的成熟度对应的预设分值为在此前累积的成熟度分值的总数上减半。(4)针对用户主动确认过的泊车数据，即例如步骤S360中用户选择泊车确认信息，该泊车数据的成熟度对应的预设分值+16。以上预设分值的数值设定仅作为举例参考，在此不做限定。(5)针对用户主动选择确认待确认泊车地图不正确的行为，对应的泊车数据扣除预设分值。在一实施例中，随着对应的泊车数据的分值变化，已经生成的待确认泊车地图的成熟度的分值亦相应调整。为了提高成熟度对比的速度，进一步地，将待确认泊车地图的成熟度向上取整或向下取整，使得泊车数据对应的成熟度为整数，更加便于对比。例如，当车端未能驶入停车位，减半前的成熟度为7，减半后的成熟度为3.5，减半后的成熟度可以向上取整为4，也可以向下取整为3。

在一实施例中，预设成熟值为大于1，当泊车数据最终获得的成熟度大于1时，则可以用于生成待确认泊车地图。通过设置成熟度判定条件对泊车数据计算成熟度，通过成熟度衡量泊车数据是否合适建立待确认泊车地图，成熟度越高的泊车数据，说明在历史泊车行为中，车辆多次根据该泊车数据进行泊车，使用率较高，泊车数据较成熟，更加适合建立待确认泊车地图。由此，通过预设成熟值能够在泊车数据中筛选出适合建立待确认泊车地图的泊车数据，避免由成熟度不符合的泊车数据生成过多的待确认泊车地图，缓解云端建图的压力，避免生成冗余的待确认泊车地图。

为了灵活设置预设成熟值，在一实施例中，预设成熟值可以是固定值，也可以是浮动值。例如预设成熟值可以根据获取的泊车数据的次数、各泊车数据的平均成熟度以及单个待确认泊车地图的泊车数据与车端的当前泊车数据泊车数据比对的次数进行浮动。例如，预设成熟值可以是泊车数据的成熟度的均值，此时预设成熟值将根据预设存储数量下的更新变化的泊车数据的成熟度进行变动。当泊车数据的收集的次数越多，达到预设成熟值的泊车数据的数量可能越多，可以通过提高预设成熟值，以避免生成过多的待确认泊车地图，提高待确认泊车地图的生成速度。当泊车数据的成熟度普遍较高时，例如高于原预设成熟度平均值时，可以提高原预设成熟值，浮动生成新的预设成熟值，以提高生成待确认泊车地图的标准，控制生成的待确认泊车地图的数量。当待确认泊车地图的泊车数据与车端的当前泊车数据比对的次数较多时，说明对应的待确认泊车地图的成熟度在不足的前提下发送至车端，可以通过提高预设成熟值避免生成多余的待确认泊车地图。

为了减少云端的计算量，在一实施例中，预先设定泊车的相异停车位的数量。相异停车位的数量即在同一车辆在同一停车场中的相异停车位的数量。可以理解，如果云端持续收集泊车数据，在不考虑停车路线的前提下，对比各泊车数据间的停车位，如果泊车的相异的停车位的数量超过预设个数后，在云端保留符合预设个数的最新的相异停车位的泊车数据，即以覆盖或删除的方式清除云端的包括历史停车位的泊车数据，从而减少云端的冗余数据，降低云端的成熟度计算量，提高处理效率。在一实施例中，相异停车位的预设个数可以为3～8个，例如3个、5个或8个。

在一实施例中，如果泊车数据的成熟度没有达到预设成熟值，则即使已经收集至少两次相同的泊车数据，该泊车数据仍然不适用于生成待确认泊车地图。为了确保待确认泊车地图的可靠性，则需要重新收集泊车数据，即重新执行步骤S310，直至收集的泊车数据在至少两次相同的情况下，且达到预设成熟值后，再生成对应的待确认泊车地图。

需要理解的是，上述步骤S320和步骤S330分别对应泊车数据不同的情形。因此在执行步骤S310后，根据云端收集的泊车数据的实际情况择一执行步骤S320和步骤S330。

步骤S340，当待确认泊车地图的数量大于1时，云端将符合预设发送条件的待确认泊车地图发送至车端。

可以理解，预设的成熟度判定条件针对不同的行为设定不同的预设分值，随着云端持续收集泊车数据，新的泊车数据可能会影响云端存储的历史泊车数据的成熟度的分值，即云端收集的泊车数据的成熟度的分值并非固定的，而是会发生变化的。相应地，生成的待确认泊车地图的成熟度也会随着泊车数据的成熟度的变化而编号。在根据成熟度符合预设成熟值的泊车数据生成待确认泊车地图后，在一实施例中，生成的待确认泊车地图的数量可能为至少1个。在一实施例中，预设发送条件可以是成熟度最高的待确认泊车地图。在一实施例中，当待确认泊车地图的数量大于1时，云端将成熟度最高的待确认泊车地图发送至车端。

进一步地，生成的待确认泊车地图的数量可能大于1，但车端在进行一次记忆泊车时，一般需要依据一个明确的待确认泊车地图进行泊车，过多的待确认泊车地图可能会干扰车端的判断。为了避免干扰车端，将云端成熟度最高的待确认泊车地图发送至车端。在一实施例中，当待确认泊车地图的数量大于1时，根据成熟度的分值由高至低对待确认泊车地图进行排序，根据排序的顺序将对应的待确认泊车地图发送至车端。进一步地，由于待确认泊车地图的成熟度是会变化的，即云端根据车端的历史泊车行为和用户行为，更新待确认泊车地图的成熟度。相应地，云端存储的各待确认泊车地图的成熟度的分值大小排序会发生变化。当待确认泊车地图的成熟度排序发生变化后，在一实施例中，云端实时将最新排序中的成熟度最高的待确认泊车地图发送至车端，以使车端可以根据最新的成熟度最高的待确认泊车地图进行记忆泊车。这样的设计，云端自动更新待确认泊车地图的成熟度，并将最新排序中的成熟度最高的待确认泊车地图发送至车端，可以使车端根据最新的成熟度最高的待确认泊车地图进行记忆泊车，无需用户参与车端的待确认泊车地图的更新，改善用户体验。

步骤S350，车端接收待确认泊车地图，并将待确认泊车地图与当前泊车数据进行泊车数据比对，直至待确认泊车地图通过泊车数据比对。

在展开泊车数据比对时，车端读入待确认泊车地图，并启动相关定位算法。在一实施例中，车端自主静默地在后台进行泊车数据比对，无需用户参与和监督。车端根据当前泊车数据进行泊车，当前泊车数据包括用户行驶的当前停车路线和停泊的当前停车位。泊车数据比对包括车端将待确认泊车地图中的停车路线根据定位算法与当前停车路线比对，以及将待确认泊车地图中的停车位根据定位算法与当前停车位比对。当停车路线和停车位均与当前泊车数据对应相同时，则表示泊车数据比对通过。否则反之，即停车路线和/或停车位与当前泊车数据对应不相同时，则表示泊车数据比对不通过。

在一实施例中，如果车端的当前泊车数据与待确认泊车地图的泊车数据不同，则将待确认泊车地图的泊车数据与车端的下一次泊车数据进行泊车数据比对；当泊车数据比对次数超多预设比对次数后，调整对应的待确认泊车地图的成熟度。

进一步地，如果车端的当前泊车数据与待确认泊车地图的泊车数据不同，即泊车数据比对不通过。也就是说，表示待确认泊车地图中的泊车数据与用户当前的停车路线和/或停车位不符合。不符合的原因可能是用户当前临时变更了泊车行为，出现了与历史泊车行为不同的停车路线和/或停车位，用户下一次泊车可能会恢复至与历史泊车行为相同。因此，将待确认泊车地图的泊车数据与车端的下一次泊车数据展开泊车数据比对，可以进行再度确认。如果待确认泊车地图的泊车数据与车端的下一次泊车数据泊车数据比对仍然不通过，则继续循环执行下一次泊车数据比对。当泊车数据比对的次数超多预设比对次数后，则表示用户确实发生了新的泊车行为，例如采用了新的停车路线和/或停车位，车端接收的待确认泊车地图的泊车数据与用户新的泊车行为不一致，即该待确认泊车地图可能不适用，则云端调整对应的待确认泊车地图的成熟度。在一实施例中，同一待确认泊车地图的预设比对次数可以是2次～5次。通过设定预设比对次数，避免过于频繁比对同一待确认泊车地图而影响地图确认进度。

进一步地，在泊车数据比对次数超多预设比对次数后，云端调整对应的待确认泊车地图的成熟度。在一实施例中，云端接收车端发送的待确认泊车地图泊车数据比对不通过的信息，并在每一次泊车数据比对不通过时产生对应的预设分值的扣除。可以理解，随着待确认泊车地图的成熟度分值的变化，云端中的各待确认泊车地图的成熟度排序可能发生变化，使得符合预设发送条件的待确认泊车地图发生变更，例如当成熟度最高的待确认泊车地图发生变更时，则重新执行步骤S340。也就是说，云端重新发送最新的符合预设发送条件的待确认泊车地图至车端，车端再重新执行步骤S350。即车端将重新接收的待确认泊车地图与用户执行的新的当前泊车数据进行泊车数据比对，直至泊车数据比对通过，才能执行后续步骤S360。否则循环执行步骤S340和步骤S350。这样的设计，在云端发送待确认泊车地图至车端后，只有当待确认泊车地图通过泊车数据比对，才足以说明该待确认泊车地图符合用户实际的泊车行为，该待确认泊车地图才适合投入记忆泊车使用。

步骤S360，当待确认泊车地图通过泊车数据比对后，车端弹窗显示交互确认界面，以供用户选择泊车确认信息，并将泊车确认信息发送至云端。

在一实施例中，如果车端的当前泊车数据与待确认泊车地图的泊车数据相同，云端发送预先设定的交互确认界面至车端，以使车端弹窗显示交互确认界面；接收用户在交互确认界面的选择的泊车确认信息。可以理解，当待确认泊车地图通过泊车数据比对，说明车端的当前泊车数据与待确认泊车地图的泊车数据相同，即表示待确认泊车地图的停车路线与车端的当前行驶路线相同，及待确认泊车地图的停车位与车端的当前停车位相同，该待确认泊车地图符合用户的当前泊车行为。进一步地，为了确保该待确认泊车地图符合用户的常用泊车行为，此时需要用户通过交互确认界面对待确认泊车地图进行确认。本实施例通过云端向车端发送预先设定的交互确认界面，车端可以通过弹窗的方式向用户显示交互确认界面。在一实施例中，交互确认界面可以向用户展示与车端的当前泊车数据相同的待确认泊车地图，以便用户了解该待确认泊车地图所包含的停车路线和停车位。在此基础上，交互确认界面还可以提供可选择的泊车确认信息，使用户自主选择泊车确认信息。如果用户选择泊车确认信息，则表示该待确认泊车地图符合实际的停车场景及用户泊车习惯，泊车确认信息发送至云端，云端则可确认该待确认泊车地图创建完成，形成泊车地图，该泊车地图可以作为车辆进行记忆泊车的地图依据，从而可以正式启用车端的自动记忆泊车。当用户下一次泊车时，车辆可以自动根据已经确认的待确认泊车地图进行记忆泊车，无需用户自行手动停车。

进一步地，用户自主选择泊车确认信息后，在一实施例中，交互确认界面还包括是否启动记忆泊车的选项。当用户选择泊车确认信息后，该确认信息代表该待确认泊车地图正确。然而，为了满足用户多种需求，针对用户不愿意启动记忆泊车而倾向于自行手动停车的情形，交互确认界面还可以进一步提供用户确认是否启动记忆泊车的选项。如果用户选择不启动记忆泊车，则车端保存该待确认泊车地图，且云端无需再针对同一车端收集新的泊车数据。直至用户下一次主动选择启动记忆泊车时，即可采用该待确认泊车地图进行记忆泊车。

在一实施例中，交互确认界面还包括确认待确认泊车地图不正确的选项。此时，用户选择待确认泊车地图不正确的选项，车端将对应的待确认泊车地图不正确的反馈信息发送至云端。针对待确认泊车地图不正确的情况，则云端重新对该待确认泊车地图的成熟度进行打分，从而使得云端存储的待确认泊车地图的成熟度排序发生变化，云端重新发送最新的成熟度最高的待确认泊车地图至车端，重复上述步骤S340至S360，直至用户选择泊车确认信息。

从上述步骤S310至步骤S360可以看出，只有在最后的步骤S360中需要用户进行最终的确认，以确定最终进行记忆泊车所采用的泊车地图。在此之前无需用户亲自参与或监督建图，而是由云端和车端自主静默地运作，从而改善用户体验。这样的设计，在用户没有参与和监督的情形下，使车端最终可以获得并存储一份可以投入记忆泊车使用的泊车地图。

综上，本申请实施例示出的泊车地图的建图方法，通过云端收集车端至少两次泊车数据，如果泊车数据互不相同，则持续收集新的泊车数据；直至累计收集的至少两次泊车数据相同，则根据预设的成熟度判定条件判断泊车数据的成熟度，采用打分的形式简单明了地对泊车数据的成熟度进行调整。如果泊车数据的成熟度达到预设成熟值，则根据对应的泊车数据生成泊车地图。当云端生成的泊车地图数量大于1时，云端将成熟度最高的泊车地图发送至车端。车端根据接收的泊车地图与当前泊车数据进行泊车数据比对，以经过实地泊车数据比对来确认该泊车地图是否符合用户的真实泊车行为。如果车端泊车数据比对通过，则弹窗显示交互确认界面，以供用户选择泊车确认信息，在用户确认的情况下，确保该泊车地图正确且适用，从而完成泊车地图的最终确立，云端则可以根据确认信息停止收集操作，降低运行负荷。本申请的建图方法，用户只需作最后的确认动作，全程无需参与和监督，减少因建图过程异常所引发的紧张感，无需用户协助，减轻了用户工作量，只需云端和车端自动静默完成，提高建图效率。

与前述应用功能实现方法实施例相对应，本申请还提供了一种泊车地图的建图设备、生成设备、建图系统及相应的实施例。

参见图5，本申请一实施例还提供一种的泊车地图的建图设备50，包括：

泊车数据收集模块510，用于收集车端至少两次泊车数据，其中，待确认泊车地图泊车数据包括停车路线和停车位；

泊车数据对比模块520，用于将收集的待确认泊车地图泊车数据进行对比；

待确认泊车地图建立模块530，用于如果至少两次待确认泊车地图泊车数据相同，则根据相同的待确认泊车地图泊车数据建立对应的待确认泊车地图；

待确认泊车地图发送模块540，用于将待确认泊车地图待确认泊车地图发送至待确认泊车地图车端进行当前泊车数据的泊车数据比对；

反馈接收模块550，用于接收待确认泊车地图车端根据泊车数据比对结果生成的反馈信息。

参见图6，本申请一实施例还提供一种的泊车地图的生成设备60，包括：

待确认泊车地图接收模块610，用于接收待确认泊车地图，其中，待确认泊车地图待确认泊车地图根据云端收集的至少两次相同的泊车数据生成，每一待确认泊车地图泊车数据包括停车路线和停车位；

泊车数据比对模块620，用于将待确认泊车地图待确认泊车地图与当前泊车数据的进行泊车数据比对，生成对应的泊车数据比对结果；

反馈发送模块630，用于发送根据待确认泊车地图泊车数据比对结果生成的反馈信息至待确认泊车地图云端。

参见图7，本申请一实施例还提供一种的泊车地图的建图系统70，包括云端710和车端720；其中：

云端710用于收集车端至少两次泊车数据，其中，泊车数据包括停车路线和停车位，并将收集的泊车数据进行对比，如果至少两次泊车数据相同，则根据相同的泊车数据建立对应的待确认泊车地图，并将待确认泊车地图发送至车端进行当前泊车数据的泊车数据比对；接收车端根据泊车数据比对结果生成的反馈信息，根据反馈信息确认待确认泊车地图或调整待确认泊车地图；

车端720用于接收云端710发送的待确认泊车地图，并将待确认泊车地图与当前泊车数据的进行泊车数据比对，生成对应的泊车数据比对结果，及发送根据泊车数据比对结果生成的反馈信息至云端。

进一步地，一并参见图5至图7，云端710可以包括泊车地图的建图设备50，车端720可以包括泊车地图的生成设备60。本申请的建图系统70可以实现自动静默建图，无需用户参与和监督，提高建图效率的同时，改善用户体验。

关于上述实施例中的设备和系统，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不再做详细阐述说明。

本申请实施例还提供一种电子设备，电子设备包括存储器和处理器。

处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器上存储有可执行代码，当可执行代码被处理器处理时，可以使处理器执行上文述及的方法中的部分或全部。

此外，根据本申请的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本申请的上述方法中部分或全部步骤的计算机程序代码指令。

或者，本申请还可以实施为一种计算机可读存储介质(或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当可执行代码(或计算机程序、或计算机指令代码)被电子设备(或电子设备、服务器等)的处理器执行时，使处理器执行根据本申请的上述方法的各个步骤的部分或全部。

以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (11)

1.一种泊车地图的建图方法，其特征在于：

收集车端至少两次泊车数据，其中，所述泊车数据包括停车路线和停车位；

将收集的所述泊车数据进行对比；

如果至少两次所述泊车数据相同，则根据相同的所述泊车数据建立对应的待确认泊车地图；

将所述待确认泊车地图发送至所述车端进行当前泊车数据的泊车数据比对；

接收所述车端根据泊车数据比对结果生成的反馈信息，以根据所述反馈信息确认所述待确认泊车地图或调整所述待确认泊车地图。

2.根据权利要求1所述的泊车地图的建图方法，所述方法还包括：

如果收集的所述泊车数据互不相同，持续收集所述车端的新的泊车数据。

3.根据权利要求1所述的泊车地图的建图方法，所述方法还包括：

预先设置相异泊车数据的预设存储数量；所述相异泊车数据包括相异的停车路线和/或相异的停车位；

当收集的所述相异泊车数据的数量大于预设存储数量时，保留符合所述预设存储数量的最新的所述相异泊车数据。

4.根据权利要求1所述的泊车地图的建图方法，其特征在于，所述如果至少两次所述泊车数据相同，则根据相同的所述泊车数据建立对应的待确认泊车地图，包括：

如果至少两次所述泊车数据相同，根据预设的成熟度判定条件，确定所述泊车数据的成熟度；

如果所述泊车数据的成熟度达到预设成熟值，则生成所述待确认泊车地图。

5.根据权利要求1所述的泊车地图的建图方法，其特征在于，所述将所述待确认泊车地图发送至所述车端进行当前泊车数据泊车数据比对，包括：

当所述泊车地图的数量大于1时，将符合预设发送条件的所述待确认泊车地图发送至所述车端。

6.根据权利要求1所述的泊车地图的建图方法，其特征在于，所述接收根据泊车数据比对结果生成的反馈信息，以根据所述反馈信息确认所述待确认泊车地图，包括：

如果所述待确认泊车地图的泊车数据与所述车端的所述当前泊车数据相同，接收所述车端对所述待确认泊车地图的泊车确认信息。

7.一种泊车地图的生成方法，其特征在于：

接收待确认泊车地图，其中，所述待确认泊车地图根据云端收集的至少两次相同的泊车数据生成，每一所述泊车数据包括停车路线和停车位；

将所述待确认泊车地图与当前泊车数据的进行泊车数据比对，生成对应的泊车数据比对结果；

发送根据所述泊车数据比对结果生成的反馈信息至所述云端，以使所述云端根据所述反馈信息确认所述待确认泊车地图或调整所述待确认泊车地图。

8.根据权利要求1所述的泊车地图的生成方法，其特征在于，所述发送根据所述泊车数据比对结果生成的反馈信息至所述云端，包括：

如果所述泊车地图的泊车数据与所述车端的当前泊车数据相同，显示交互确认界面；

将用户在所述交互确认界面生成的所述反馈信息发送至所述云端。

9.一种泊车地图的建图设备，其特征在于，包括：

泊车数据收集模块，用于收集车端至少两次泊车数据，其中，所述泊车数据包括停车路线和停车位；

泊车数据对比模块，用于将收集的所述泊车数据进行对比；

待确认泊车地图建立模块，用于如果至少两次所述泊车数据相同，则根据相同的所述泊车数据建立对应的待确认泊车地图；

待确认泊车地图发送模块，用于将所述待确认泊车地图发送至所述车端进行当前泊车数据的泊车数据比对；

反馈接收模块，用于接收所述车端根据泊车数据比对结果生成的反馈信息。

10.一种泊车地图的生成设备，其特征在于，包括：

待确认泊车地图接收模块，用于接收待确认泊车地图，其中，所述待确认泊车地图根据云端收集的至少两次相同的泊车数据生成，每一所述泊车数据包括停车路线和停车位；

泊车数据比对模块，用于将所述待确认泊车地图与当前泊车数据的进行泊车数据比对，生成对应的泊车数据比对结果；

反馈发送模块，用于发送根据所述泊车数据比对结果生成的反馈信息至所述云端。

11.一种泊车地图的建图系统，其特征在于，包括云端和车端；其中：

所述云端用于收集车端至少两次泊车数据，其中，所述泊车数据包括停车路线和停车位，并将收集的所述泊车数据进行对比，如果至少两次所述泊车数据相同，则根据相同的所述泊车数据建立对应的待确认泊车地图，并将所述待确认泊车地图发送至所述车端进行当前泊车数据的泊车数据比对；接收所述车端根据泊车数据比对结果生成的反馈信息，以根据所述反馈信息确认所述待确认泊车地图或调整所述待确认泊车地图；

所述车端用于接收所述云端发送的所述待确认泊车地图，并将所述待确认泊车地图与当前泊车数据的进行泊车数据比对，生成对应的泊车数据比对结果，及发送根据所述泊车数据比对结果生成的反馈信息至所述云端。

Images