地图显示方法及装置

技术领域

本申请涉及地图导航技术领域，具体而言，本申请涉及一种地图显示方法及装置。

背景技术

目前，车主出行越来越依赖于地图导航技术，具体而言，车辆出发前，将车辆所在的起始位置以及车主欲前往的终点位置上传至云端，云端便根据该些位置向车主推荐规划路线，以引导车辆按照规划路线行驶。

在车辆按照规划路线行驶的过程中，云端同时向车辆推送规划路线对应的地图，例如，车辆经过某个复杂路口时，云端向车辆推送该复杂路口对应的地图，以便于车主借助车辆中的终端(例如导航仪)显示该地图，以此保证车辆不会偏离规划路线。

对于终端而言，地图首先需要从云端下载，然后于本地加载，方能够显示，随着云端与终端之间的交互，不仅耗费较多的流量，而且容易因网络延迟/丢包率等客观因素的影响而导致地图显示效率不高，尤其在车辆经过路口时，很可能因为路口对应的地图显示不及时而导致车辆偏离规划路线。

由上可知，如何提升地图显示效率仍有待解决。

发明内容

本申请各实施例提供了一种地图显示方法、装置、电子设备及存储介质，可以解决相关技术中存在的地图显示效率不高的问题。所述技术方案如下：

根据本申请实施例的一个方面，一种地图显示方法，应用于第一终端，所述方法包括：基于规划路线数据中路口标识指示的规划路口，将第一终端经过的当前一个规划路口作为目标路口，规划路线数据是云端根据第一终端上传的位置消息发送的；在广播消息中查找候选路口与目标路口相匹配的广播消息，广播消息是经过候选路口的第二终端发送的；从查找到的广播消息中获取目标路口的地图数据；加载目标路口的地图数据，在第一终端中显示目标路口对应的地图。

根据本申请实施例的一个方面，一种地图显示装置，应用于第一终端，所述装置包括：目标路口确定模块，用于基于规划路线数据中路口标识指示的规划路口，将第一终端经过的当前一个规划路口作为目标路口，规划路线数据是云端根据第一终端上传的位置消息发送的；消息查找模块，用于在广播消息中查找候选路口与目标路口相匹配的广播消息，广播消息是经过候选路口的第二终端发送的；数据获取模块，用于从查找到的广播消息中获取目标路口的地图数据；数据加载模块，用于加载目标路口的地图数据，在第一终端中显示目标路口对应的地图。

根据本申请实施例的一个方面，一种地图显示装置，应用于第一终端，所述装置包括：目标路口确定模块，用于基于规划路线数据中路口标识指示的规划路口，将第一终端经过的当前一个规划路口作为目标路口，规划路线数据是云端根据第一终端上传的位置消息发送的；消息查找模块，用于在广播消息中查找候选路口与目标路口相匹配的广播消息，广播消息是经过候选路口的第二终端发送的；数据获取模块，用于从查找到的广播消息中获取目标路口的地图数据；数据加载模块，用于加载目标路口的地图数据，在第一终端中显示目标路口对应的地图。

根据本申请实施例的一个方面，一种地图显示装置，应用于第二终端，所述装置包括：候选路口确定模块，用于当第二终端根据目标路口的地图数据进行地图显示时，将目标路口作为候选路口；消息生成模块，用于根据候选路口所在位置以及候选路口的地图数据，生成至少一个广播消息；消息发送模块，用于在广播信道中进行至少一个广播消息的发送，以使第一终端能够根据至少一个广播消息中候选路口的地图数据进行地图显示。

根据本申请实施例的一个方面，一种电子设备，包括：至少一个处理器、至少一个存储器、以及至少一条通信总线，其中，所述存储器上存储有计算机可读指令，所述处理器通过所述通信总线读取所述存储器中的所述计算机可读指令；所述计算机可读指令被所述处理器执行时实现如上所述的地图显示方法。

根据本申请实施例的一个方面，一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的地图显示方法。

本申请提供的技术方案带来的有益效果是：

在上述技术方案中，基于第一终端上传的位置消息，云端向第一终端发送规划路线数据，以使第一终端能够基于规划路线数据中路口标识指示的规划路口，将其经过的当前一个规划路口作为目标路口，并基于经过候选路口的第二终端发送的广播消息，从中查找候选路口与目标路口相匹配的广播消息，进而从查找到的广播消息中获取目标路口的地图数据，以此实现在第一终端中显示目标路口对应的地图，也就是说，目标路口对应的地图不再依赖于云端下载，而能够来源于经过该目标路口的第二终端发送的广播消息，以此避免云端与第一终端之间的交互，使得地图显示不再受到网络延迟/丢包率等客观因素的影响，从而有效地解决了地图显示效率不高的问题。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1是根据本申请所涉及的实施环境的示意图。

图2是根据一示例性实施例示出的一种地图显示方法的流程图。

图3是根据一示例性实施例示出的另一种地图显示方法的流程图。

图4是根据一示例性实施例示出的另一种地图显示方法的流程图。

图5为图4对应实施例所涉及的候选路口的示意图。

图6是图2对应实施例中步骤203在一个实施例的流程图。

图7是图2对应实施例中步骤205在一个实施例的流程图。

图8是根据一示例性实施例示出的另一种地图显示方法的流程图。

图9是根据一示例性实施例示出的另一种地图显示方法的流程图。

图10是一应用场景中一种地图显示方法的具体实现示意图。

图11是根据一示例性实施例示出的一种地图显示装置的结构示意图。

图12是根据一示例性实施例示出的一种终端的结构示意图。

图13是根据一示例性实施例示出的一种电子设备的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

下面是对本申请涉及的几个名词进行的介绍和解释：

云-端融合：计算任务在云端与终端之间按需迁移、按需使用和按需调整终端/云端的计算、传输、存储、网络、电力等资源。本质上是指将云计算管理与服务从云向端自然延伸，即云-端融合。本申请中，云-端融合是指云端推送地图与终端推送地图相结合。

边缘计算：指在靠近物或数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台，就近提供最近端服务。其应用程序在边缘侧发起，产生更快的网络服务响应，满足行业在实时业务、应用智能、安全与隐私保护等方面的基本需求。边缘计算处于物理实体和工业连接之间，或处于物理实体的顶端。而云端计算仍然可以访问边缘计算的历史数据。本申请中，边缘计算基于终端侧实施。

如前所述，在车辆行驶过程中，仍存在地图显示效率不高的问题。

究其原因，是地图首先需要从云端下载，然后于终端本地加载，方能够显示，随着云端与终端之间的交互，不仅耗费较多的流量，而且容易因网络延迟/丢包率等客观因素的影响而导致地图显示效率不高，尤其在车辆经过路口时，很可能因为路口对应的地图显示不及时而导致车辆偏离规划路线。

基于此，一种解决办法是在终端本地存储规划路线中各个路口对应的地图，以此减少云端与第一终端之间的交互，以利于提升地图显示效率。然而，一旦终端消耗过多的内存资源来存储各个路口对应的地图，势必影响终端的处理效率，仍然不可避免地影响地图显示效率。

为此，本申请提供的地图显示方法、装置、电子设备及存储介质，旨在解决现有技术的如上技术问题。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

图1为一种地图显示方法所涉及的实施环境的示意图。该实施环境包括终端100和云端200。

具体地，终端100可供提供地图导航功能的客户端运行，可以是导航仪、智能手机、平板电脑、笔记本电脑等等能够部署于车辆中的电子设备，在此不进行限定。

其中，客户端，提供地图导航功能，例如，地图导航类客户端，可以是应用程序形式，也可以是网页形式，相应地，客户端进行地图显示的用户界面则可以是程序窗口形式，还可以是网页页面形式的，此处也并未加以限定。

云端200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。例如，本实施环境中，云端200为终端100提供地图数据的云存储服务。

在此说明的是，本发明各实施例中，地图通过地图数据的形式传输和存储，当地图数据加载之后方能够在终端/云端中显示相应的地图，下文不再重复赘述。

终端100与云端200之间通过无线或者有线等方式建立通信连接，以通过该通信连接实现终端100与云端200之间的数据传输。例如，传输的数据包括但不限于位置消息、规划路线数据、地图数据等等。

终端100之间，例如第一终端110与第二终端130之间，通过广播信道建立通信连接，以通过该通信连接实现第一终端110与第二终端130之间的数据传输。例如，传输的数据包括但不限于广播消息。

随着云端200与第一终端110之间的交互，就云端200来说，根据第一终端110上传的位置消息，向第一终端110返回规划路线数据。

而对于第一终端110而言，在接收到规划路线数据之后，首先确定目标路口，即第一终端110经过的规划路线中的当前一个规划路口，然后基于第二终端在广播信道中发送的广播消息，实现目标路口的地图数据的获取和加载，最终将目标路口对应的地图显示在第一终端。

上述过程中，目标路口对应的地图不再依赖于云端下载，以此显著地减少了云端与终端之间的交互，从而能够有效地解决地图显示效率不高的问题。

请参阅图2，本申请实施例提供了一种地图显示方法，该方法适用于图1所示实施环境的第一终端110。

该方法可以由第一终端执行，也可以理解为是由第一终端中运行的客户端执行，例如，地图导航类客户端。在下述方法实施例中，为了便于描述，以各步骤的执行主体为第一终端加以说明，但对此不构成限定。

如图2所示，该方法可以包括以下步骤：

步骤201，基于规划路线数据中路口标识指示的规划路口，将第一终端经过的当前一个规划路口作为目标路口。

首先说明的是，规划路线数据是云端根据第一终端上传的位置消息发送的。其中，位置消息包括车辆所在的起始位置以及车主欲前往的终点位置。

举例来说，如果车主希望从A地前往B地，则起始位置为A地，终点位置为B地。

在一个可能的实现方式，起始位置和终点位置均响应于车主触发的相关操作生成。在一个可能的实现方式，起始位置基于终端中部署的全球定位系统(GPS，GlobalPositioning System)定位生成，终点位置则响应于车主触发的相关操作生成。

相应地，云端在接收到第一终端上传的位置消息之后，便能够根据位置消息中的起始位置和终点位置，为车主规划出至少一条由起始位置指向终点位置的规划路线，并以此生成规划路线数据发送至第一终端。也就是说，规划路线数据，用于在地图中准确地描述由起始位置指向终点位置的规划路线，包括但不限于用于指示规划路线中规划路段的路段标识、用于指示规划路线中规划路口的路口标识等等。

其次，如前所述，在车辆按照规划路线行驶的过程中，尤其是每次经过规划路线中的一个规划路口，车主都将借助车辆中的第一终端显示该规划路口对应的地图，以此保证车辆不会偏离规划路线。值得一提的是，车辆经过路口，车辆中的第一终端也视为经过该路口，下文中不再重复赘述。

应当理解，由起始位置指向终点位置的规划路线中，包括至少一个规划路段和至少一个规划路口，相应地，规划路线数据中，包括用于指示规划路段的至少一个路段标识和用于指示规划路口的至少一个路口标识。在此说明的是，由于规划路线是由起始位置指向终点位置，因此规划路线数据中的路段标识/路口标识具有指向性，简单地说，针对规划路线数据中的每一个路段标识/路口标识，按照车辆行驶方向具有先后顺序。

基于此，根据规划路线数据中路口标识指示的规划路口，便能够确定第一终端经过的当前一个规划路口，并将该当前一个规划路口作为目标路口，以便于后续显示该目标路口对应的地图，来辅助车主驾驶车辆不偏离规划路线。

例如，规划路线数据中，包括四个路口标识C1、C2、C3、C4。那么，对于第一终端而言，将依次经过路口标识C1指示的规划路口C1、路口标识C2指示的规划路口C2、路口标识C3指示的规划路口C3、路口标识C3指示的规划路口C3。如果第一终端经过的当前一个规划路口为规划路口C1，则目标路口为规划路口C1。

步骤203，在广播消息中查找候选路口与目标路口相匹配的广播消息。

其中，广播消息是经过候选路口的第二终端发送的。

首先说明的是，第二终端中存储有候选路口的地图数据。在一个可能的实现方式，第二终端中存储的地图数据来自于云端推送。具体地，当车辆经过候选路口时，云端向车辆推送该候选路口对应的地图，即发送该候选路口的地图数据至车辆，相应地，车主便能够借助车辆中的第二终端显示该候选路口对应的地图，此时，第二终端中存储有该候选路口的地图数据。

发明人意识到，就第一终端来说，假设规划路线中存在一个规划路口与该候选路口一致，即表示该候选路口将作为目标路口等待第一终端经过，那么，第二终端中存储的地图数据是可以分享给第一终端的，以便于第一终端进行地图显示。

故而，本实施例中，为了减少云端与第一终端之间的交互，利用已存储地图数据的第二终端替代云端，进行目标路口对应地图的推送。

具体而言，由经过候选路口的第二终端，根据候选路口所在位置以及候选路口的地图数据，生成至少一个广播消息，并在广播信道中进行至少一个广播消息的发送。也可以理解为，广播消息中封装了候选路口的地图数据。

对于第一终端而言，面对广播信道中传输的大量广播消息，查找候选路口与目标路口相匹配的广播消息。

如果查找到候选路口与目标路口相匹配的广播消息，则跳转执行步骤205，即第一终端从查找到的广播消息中获取目标路口的地图数据。

反之，如果查找不到候选路口与目标路口相匹配的广播消息，即确定不存在已存储地图数据的第二终端，则跳转执行步骤206，即第一终端向云端请求目标路口的地图数据，如图3所示。

值得一提的是，当车辆由目标路口驶向规划路口中的后一个规划路口，对于第一终端而言，其中已存储了目标路口的地图数据，此时，第一终端的身份实质发生了转变，即可将第一终端视为经过候选路口(即目标路口)的第二终端，那么，第一终端便可根据目标路口所在位置以及目标路口的地图数据生成至少一个广播消息，并在广播信道中进行该至少一个广播消息的发送，也可以理解为，第一终端是当前经过目标路口的终端，而第二终端是曾经经过目标路口的终端。

由此，关于第二终端中存储有候选路口的地图数据，在另一个可能的实现方式，第二终端中存储的地图数据来源于广播消息，本实施例对此并非构成具体限定。

步骤205，从查找到的广播消息中获取目标路口的地图数据。

一旦查找到广播消息，表示第二终端发送广播消息所经过的候选路口即为目标路口，也就是说，第二终端曾经到达该目标路口，其中存储有该目标路口的地图数据，相应地，由经过该目标路口的第二终端发送的广播消息中，封装了该目标路口的地图数据。

基于此，目标路口的地图数据便能够从查找到的广播消息中获得。

步骤207，加载目标路口的地图数据，在第一终端中显示目标路口对应的地图。

在获得目标路口的地图数据之后，第一终端便能够进行目标路口对应的地图的显示。

具体地，首先，根据目标路口的地图数据确定与目标路口相关联的道路，并获取与目标路口相关联道路的道路形状点；其次，根据与目标路口相关联道路的道路形状点，计算与目标路口相关联道路的道路边缘形状点；然后，根据与目标路口相关联道路的道路边缘形状点以及规划路线，分别计算车道线形状点、引导线形状点和隔离带形状点；最终，根据道路边缘形状点、车道线形状点、引导线形状点和隔离带形状点，绘制道路、车道线、引导线和隔离带，从而形成显示在第一终端中包含道路、车道线、引导线和隔离带的目标路口对应的地图。

通过上述过程，实现了云-端之间的数据传输和计算转移至端-端之间的数据传输和边缘计算，从而避免终端与云端之间的交互，不仅避免地图显示受到网络延迟/丢包率等客观因素的影响，能够有效地提升地图显示效率，还能够减轻云端的负载压力，进而有利于提升云端的处理效率。

请参阅图3，本申请实施例中提供了一种可能的实现方式，该方法还可以包括以下步骤：

步骤206，如果查找不到候选路口与目标路口相匹配的广播消息，则向云端请求目标路口的地图数据。

上述过程，采取云-端融合技术，一方面，利用已存储地图数据的第二终端替代云端进行地图推送，另一方面，在不存在已存储地图数据的第二终端时，依然通过云端进行地图推送，以此来减少云端与第一终端之间的交互次数。

请参阅图4，本申请实施例中提供了一种可能的实现方式，广播消息的生成过程可以包括以下步骤：

步骤301，将候选路口的地图数据拆分为多个地图中间数据。

发明人意识到，地图数据的数据量往往比较大，即使是端-端之间进行广播消息的传输，也可能因为一次性传输完整地图数据而导致广播消息的传输效率降低，进而使得第一终端无法及时接收到该广播消息而影响地图显示效率。

基于此，本实施例中，采取拆分策略，将候选路口的地图数据拆分为多个地图中间数据。当然，根据应用场景的实际需要，拆分个数可以灵活地调整，例如，候选路口的地图数据拆分为16个地图中间数据，以此充分地保证广播消息的传输效率，进而有利于进一步有效地提升地图显示效率。

步骤303，将候选路口所在位置填充至消息头区域，以及将多个地图中间数据分别填充至不同的数据区域。

首先说明的是，候选路口所在位置，唯一地表示第二终端经过的候选路口。应当理解，随着车辆行驶方向的不同，即使是用于连通不同的若干个规划路段，或者，隶属于同一个规划路段，候选路口所在位置也将有所差别，也就是说，本实施例中，候选路口所在位置实际具有指向性，以此保证在同一个规划路段上行驶的车辆在经过同一个候选路口所在位置时显示的地图一致。

在一个可能的实现方式，候选路口所在位置包括起始路段标识、终结路段标识。在一个可能的实现方式，候选路口所在位置包括第二终端所在位置、起始路段标识。

举例来说，如图5所示，规划路线中包括规划路段D1、规划路段D2以及规划路段D3，其中，路口310、路口311连通规划路段D1和规划路段D2，路口312、路口313连通规划路段D2和规划路段D3，而路口311、路口312隶属于同一个规划路段D2。

那么，考虑车辆的行驶方向，上述路口均可作为候选路口等待第二终端经过，而路口314、路口315、路口316则不属于本次规划路线的范畴。

假设车辆由规划路段D1驶入规划路段D2，则路口310为候选路口，该候选路口所在位置可以表示为{D1，D2}；假设车辆由规划路段D2驶入规划路段D1，则路口311为候选路口，该候选路口所在位置可以表示为{D2，D1}。

或者，假设车辆由规划路段D2驶入规划路段D3，则路口312为候选路口，该候选路口所在位置可以表示为{E1，D2}，E1表示第二终端经过路口312的所在位置；假设车辆由规划路段D3驶入规划路段D2，则路口313为候选路口，该候选路口所在位置可以表示为{E2，D3}，E2表示第二终端经过路口313的所在位置。

其次，广播消息包括消息头区域和数据区域，消息头区域封装候选路口所在位置，数据区域封装地图中间数据。

由此，通过消息头区域的解析便能够实现广播消息的快速查找，有利于进一步地提升地图显示效率。

步骤305，为每一个数据区域添加消息头区域，生成多个广播消息。

也就是说，针对每一个广播消息来说，广播消息＝{消息头区域，数据区域}＝{候选路口所在位置，地图中间数据}。

由此，候选路口的地图数据被拆分到多个广播消息中，而该多个广播消息具有相同的位置消息，以此保证在海量广播消息中查找时能够准确地还原候选路口的地图数据。

通过上述过程，实现了广播消息的生成，使得端-端之间进行地图数据的传输得以实现，从而有利于提升地图显示效率。

请参阅图6，本申请实施例中提供了一种可能的实现方式，步骤203可以包括以下步骤：

步骤2031，接收第二终端发送的广播消息。

应当理解，对于繁忙的交通而言，第一终端经过目标路口时，其周围存在不止一个第二终端，该些第二终端所经过的候选路口也不止一个，也就是说，广播信道中传输的广播消息，是经过不同候选路口的不同第二终端发送的。

故而，对于第一终端来说，会接收到广播信道中传输的大量广播消息，还需要进一步查找相匹配的广播消息，方能够获得目标路口的地图数据。

步骤2033，对广播消息的消息头区域进行解析，确定第二终端发送广播消息所经过的候选路口。

本实施例中，广播消息的查找通过解析消息头区域实现。

如前所述，广播消息＝{消息头区域，数据区域}＝{候选路口所在位置，地图中间数据}，其中，候选路口所在位置唯一地表示第二终端经过的候选路口。

基于此，通过解析消息头区域，便能够获得候选路口所在位置，并由此确定第二终端经过的候选路口。

步骤2035，如果确定的候选路口与目标路口相匹配，则查找到候选路口与目标路口相匹配的广播消息。

步骤2037，如果确定的候选路口与目标路口不匹配，则丢弃广播消息。

也就是说，仅需要解析广播消息的消息头区域，便可决定是否丢弃该广播消息，并且只有相匹配的广播消息方可进行后续数据区域的解析，不仅极大地提升了广播消息的查找效率，而且能够有效地减轻第一终端关于数据区域解析的处理压力，从而有利于进一步地提升地图显示效率。

请参阅图7，本申请实施例中提供了一种可能的实现方式，步骤205可以包括以下步骤：

步骤2051，对查找到的每一个广播消息的数据区域进行解析，得到若干个地图中间数据。

如前所述，广播消息的数据区域中封装有地图中间数据，因此，通过数据区域的解析，便能够得到地图中间数据。相应地，如果查找到多个广播消息，便能够得到多个地图中间数据。

步骤2053，将若干个地图中间数据拼接为目标路口的地图数据。

应当理解，拼接实质是拆分的逆过程，相应地，拼接顺序对应于拆分顺序。那么，在一个可能的实现方式，假设优先拆分得到的广播消息优先发送，则若干个地图中间数据按照广播消息的发送时间进行拼接。或者，在一个可能的实现方式，如果拆分得到的广播消息对应的消息编号依次为1、2、3、……，则若干个地图中间数据按照消息编号进行拼接。

在上述实施例的作用下，实现了地图数据的还原，使得数据量较大的地图数据能够拆分为数据量较小的地图中间数据进行传输，以此提升端-端之间的数据传输效率，进而有利于进一步地提升地图显示效率。

本申请实施例中提供了一种可能的实现方式，该方法还可以包括以下步骤：

当第一终端经过规划路线数据中路口标识指示的后一个规划路口，删除以当前一个规划路口作为目标路口的地图数据。

也就是说，随着车辆由当前一个规划路口(即目标路口)驶入后一个规划路口，第一终端中显示的当前一个规划路口对应的地图将随之进行更新，即第一终端中显示后一个规划路口对应的地图。

由此，对于第一终端而言，当前一个规划路口的地图数据便可删除，以节省内存资源来存储后一个规划路口的地图数据。其中，删除，是指将当前一个规划路口的地图数据相关的对象实例销毁，同时释放对应的内存资源。

基于上述过程，通过地图数据的“回收”，实现了地图数据的动态加载，即第一终端不必存储规划路线中所有规划路口的地图数据，而是依据规划路线按需加载每一个规划路口的地图数据，从而大大减少了内存资源的消耗，避免第一终端因消耗过多的内存资源而影响第一终端的处理效率，进而充分地保障了地图显示效率。

请参阅图8，本申请实施例中提供了一种可能的实现方式，该方法还可以包括以下步骤：

步骤401，调用位置服务接口生成位置消息。

如前所述，位置消息包括车辆所在的起始位置以及车主欲前往的终点位置。那么，为了生成位置消息，第一终端需要获得起始位置和终点位置。

本实施例中，云端为第一终端提供位置服务，即在第一终端中部署位置服务接口，以便于第一终端生成位置消息。

具体地，对于第一终端而言，通过位置服务接口的调用，在进行地图显示的用户界面中，会为车主提供位置获取入口，使得车主可以通过该位置获取入口触发相关操作，进而使得第一终端能够检测到车主触发的相关操作而获得起始位置/终点位置。

举例来说，在进行地图显示的用户界面中，显示一输入对话框，当车主希望从A地前往B地，便可在该输入对话框中输入“B地”。其中，该输入对话框即视为位置服务接口为车主提供的位置获取入口，而该输入操作即视为车主在该位置获取入口中触发的相关操作。

此时，终端便可检测到该输入操作，进而获得终点位置B地。同理，起始位置A地也可通过位置服务接口的调用来获取，进而生成包含起点位置A地和终点位置B地的位置消息。

需要说明的是，根据第一终端所配置输入组件(例如触控屏幕上铺盖的触摸层、鼠标、键盘等)的不同，用户在控制入口触发的控制操作的具体行为也可以各不相同。例如，借由触摸层输入的导航仪而言，控制操作可以是点击、滑动等手势操作，而对于配置鼠标的笔记本电脑而言，控制操作则可以是拖拽、单击、双击等机械操作，在此不进行具体限定。

步骤403，根据位置消息向云端请求规划路线数据。

步骤405，接收云端返回的规划路线数据。

在上述过程中，实现了规划路线的推送，以此作为第一终端确定目标路口的依据，从而确保目标路口对应地图显示的准确性。

请参阅图9，本申请实施例提供了一种地图显示方法，该方法适用于图1所示实施环境的第二终端130。

该方法可以由第二终端执行，也可以理解为是由第二终端中运行的客户端执行，例如，地图导航类客户端。在下述方法实施例中，为了便于描述，以各步骤的执行主体为第二终端加以说明，但对此不构成限定。

如图9所示，该方法可以包括以下步骤：

步骤501，当第二终端根据目标路口的地图数据进行地图显示时，将目标路口作为候选路口。

步骤503，根据候选路口所在位置以及候选路口的地图数据，生成至少一个广播消息。

步骤505，在广播信道中进行至少一个广播消息的发送，以使第一终端能够根据至少一个广播消息中候选路口的地图数据进行地图显示。

通过上述实施例的配合，实现了端-端之间的地图数据传输和边缘计算，由此取代云-端之间的地图数据传输和计算，从而避免终端与云端之间的交互，不仅避免地图显示受到网络延迟/丢包率等客观因素的影响，能够有效地提升地图显示效率，还能够减轻云端的负载压力，进而有利于提升云端的处理效率。

图10是一应用场景中一种地图显示方法的具体实现示意图。该应用场景中，终端A所在车辆、终端B所在车辆、终端C所在车辆前后经过目标路口，该目标路口位于某个复杂路段，车主需要借助终端显示该目标路口对应的地图，尤其是放大地图，以此保证车辆不会偏离规划路线。

其中，终端A、终端B、终端C是部署于车辆的导航仪，该导航仪中可运行地图导航类客户端；云端则为各终端提供位置服务和地图数据的云存储服务。

对于终端A而言，假设此前并未有其余车辆经过目标路口，也就是说，终端A是第一个经过该目标路口，那么，通过终端A与云端之间的交互，终端A便能够基于规划路线确定目标路口，并接收云端推送的该目标路口对应的地图。

当终端A加载该目标路口的地图数据以显示该目标路口对应的地图时，同时根据该目标路口所在位置以及该目标路口的地图数据生成广播消息，并在广播信道中进行该广播消息的传输。

对于终端B而言，在经过目标路口时，由于广播信道中传输有封装了该目标路口的地图数据的广播消息(即终端A经过该目标路口发送的)，则通过消息头区域解析，便能够查找到该广播消息，进而再通过数据区域解析，便获得该目标路口的地图数据，以此实现终端B中该目标路口对应地图的显示。

同时，终端B根据该目标路口所在位置以及该目标路口的地图数据生成广播消息，并在广播信道中进行该广播消息的传输。

同理，对于终端C而言，便能够基于终端B经过该目标路口发送的广播消息，获得该目标路口的地图数据，最终实现终端C中该目标路口对应地图的显示。

同时，终端C根据该目标路口所在位置以及该目标路口的地图数据生成广播消息，并在广播信道中进行该广播消息的传输。

上述过程中，就终端A来说，在经过规划路线中的后一个规划路口，将回收该目标路口的地图数据，以便于重新请求云端推送后一个规划路口对应的地图或者查找封装了后一个规划路口的地图数据的广播消息。

由此可见，广播消息是由前序终端逐级传输至后序终端，前序终端A完全没必要担心后序终端C会因为地图数据被“回收”而需要重新向云端请求目标路口对应的地图。

在本应用场景中，实现同时优化地图数据传输以及内存资源加载的机制，一方面，利用传输延迟较小的端-端之间的数据传输，替代传输延迟较大的云-端之间的数据传输，不仅能够显著地提升地图显示效率，而且大大提高了地图数据的利用率；另一方面，通过地图数据的“回收”，实现了地图数据的动态加载，使得终端不必存储规划路线中全部规划路口的地图数据，而能够按需选择目标路口的地图数据加载，大大减少了内存资源的消耗，同时有利于提升终端的处理效率，进而有利于进一步地提升地图显示效率。

下述为本申请装置实施例，可以用于执行本申请所涉及的地图显示方法。对于本申请装置实施例中未披露的细节，请参照本申请所涉及的地图显示方法的方法实施例。

请参阅图11(a)，本申请实施例中提供了一种地图显示装置900，应用于第一终端，该地图显示装置900包括但不限于：目标路口确定模块901、消息查找模块903、数据获取模块905以及数据加载模块907。

其中，目标路口确定模块901，用于基于规划路线数据中路口标识指示的规划路口，将第一终端经过的当前一个规划路口作为目标路口，规划路线数据是云端根据第一终端上传的位置消息发送的。

消息查找模块903，用于在广播消息中查找候选路口与目标路口相匹配的广播消息，广播消息是经过候选路口的第二终端发送的。

数据获取模块905，用于从查找到的广播消息中获取目标路口的地图数据。

数据加载模块907，用于加载目标路口的地图数据，在第一终端中显示目标路口对应的地图。

本申请实施例中提供了一种地图显示装置900，其中的消息查找模块903包括但不限于：消息接收单元、消息头解析单元以及消息查找单元。

其中，消息接收单元，用于接收第二终端发送的广播消息。

消息头解析单元，用于对广播消息的消息头区域进行解析，确定第二终端发送广播消息所经过的候选路口。

消息查找单元，用于如果确定的候选路口与目标路口相匹配，则查找到候选路口与目标路口相匹配的广播消息。

本申请实施例中提供了一种地图显示装置900，其中的数据获取模块905包括但不限于：数据解析单元以及数据拼接单元。

其中，数据解析单元，用于对查找到的每一个广播消息的数据区域进行解析，得到若干个地图中间数据。

数据拼接单元，用于将若干个地图中间数据拼接为目标路口的地图数据。

本申请实施例中提供了一种地图显示装置900，还包括但不限于：数据删除模块。

其中，数据删除模块，用于当第一终端经过规划路线数据中路口标识指示的后一个规划路口，删除以当前一个规划路口作为目标路口的地图数据。

本申请实施例中提供了一种地图显示装置900，还包括但不限于：数据请求模块。

其中，数据请求模块，用于如果查找不到候选路口与目标路口相匹配的广播消息，则向云端请求目标路口的地图数据。

本申请实施例中提供了一种地图显示装置900，还包括但不限于：接口调用模块、路线请求模块以及数据接收模块。

其中，接口调用模块，用于调用位置服务接口生成位置消息。

路线请求模块，用于根据位置消息向云端请求规划路线数据。

数据接收模块，用于接收云端返回的规划路线数据。

请参阅图11(b)，本申请实施例中提供了一种地图显示装置1000，应用于第二终端，该地图显示装置1000包括但不限于：候选路口确定模块1001、消息生成模块1003以及消息发送模块1005。

其中，候选路口确定模块1001，用于当第二终端根据目标路口的地图数据进行地图显示时，将目标路口作为候选路口。

消息生成模块1003，用于根据候选路口所在位置以及候选路口的地图数据，生成至少一个广播消息。

消息发送模块1005，用于在广播信道中进行至少一个广播消息的发送，以使第一终端能够根据至少一个广播消息中候选路口的地图数据进行地图显示。

本申请实施例中提供了一种地图显示装置1000，其中的消息生成模块1003还包括但不限于：数据拆分单元、数据填充单元以及消息生成单元。

其中，数据拆分单元，用于将候选路口的地图数据拆分为多个地图中间数据。

数据填充单元，用于将候选路口所在位置填充至消息头区域，以及将多个地图中间数据分别填充至不同的数据区域。

消息生成单元，用于为每一个数据区域添加消息头区域，生成多个广播消息。

需要说明的是，上述实施例所提供的地图显示装置在进行地图显示时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即地图显示装置的内部结构将划分为不同的功能模块，以完成以上描述的全部或者部分功能。

另外，上述实施例所提供的地图显示装置与地图显示方法的实施例属于同一构思，其中各个模块执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。

上述过程，采取云-端融合技术，一方面利用已存储地图数据的第二终端替代云端进行地图推送，实现了端-端之间的地图数据传输和边缘计算，从而避免终端与云端之间的交互，不仅避免地图显示受到网络延迟/丢包率等客观因素的影响，能够有效地提升地图显示效率，还能够减轻云端的负载压力，进而有利于提升云端的处理效率。另一方面，在不存在已存储地图数据的第二终端时，依然通过云端进行地图推送，以此来减少云端与第一终端之间的交互次数。

请参阅图12，图12是根据一示例性实施例示出的一种终端的结构示意图。该终端适用于图1所示出实施环境中的终端100。

需要说明的是，该终端只是一个适配于本申请的示例，不能认为是提供了对本申请的使用范围的任何限制。该终端也不能解释为需要依赖于或者必须具有图12中示出的示例性的终端1100中的一个或者多个组件。

如图12所示，终端1100包括存储器101、存储控制器103、一个或多个(图12中仅示出一个)处理器105、外设接口107、射频模块109、定位模块111、摄像模块113、音频模块115、触控屏幕117以及按键模块119。这些组件通过一条或多条通讯总线/信号线121相互通讯。

其中，存储器101可用于存储计算机程序以及模块，如本申请示例性实施例中的地图显示方法及装置对应的计算机可读指令及模块，处理器105通过运行存储在存储器101内的计算机可读指令，从而执行各种功能以及数据处理，即完成地图显示方法。

存储器101作为资源存储的载体，可以是随机存储器、例如高速随机存储器、非易失性存储器，如一个或多个磁性存储装置、闪存、或者其它固态存储器。存储方式可以是短暂存储或者永久存储。

外设接口107可以包括至少一有线或无线网络接口、至少一串并联转换接口、至少一输入输出接口以及至少一USB接口等，用于将外部各种输入/输出装置耦合至存储器101以及处理器105，以实现与外部各种输入/输出装置的通信。

射频模块109用于收发电磁波，实现电磁波与电信号的相互转换，从而通过通讯网络与其他设备进行通讯。通信网络包括蜂窝式电话网、无线局域网或者城域网，上述通信网络可以使用各种通信标准、协议及技术。

定位模块111用于获取终端1100的当前所在的地理位置。定位模块111的实例包括但不限于全球定位系统(GPS)、基于无线局域网或者移动通信网的定位技术。

摄像模块113隶属于摄像头，用于拍摄图片或者视频。拍摄的图片或者视频可以存储至存储器101内，还可以通过射频模块109发送至上位机。

音频模块115向用户提供音频接口，其可包括一个或多个麦克风接口、一个或多个扬声器接口以及一个或多个耳机接口。通过音频接口与其它设备进行音频数据的交互。音频数据可以存储至存储器101内，还可以通过射频模块109发送。

触控屏幕117在终端1100与用户之间提供一个输入输出界面。具体地，用户可通过触控屏幕117进行输入操作，例如点击、触摸、滑动等手势操作，以使终端1100对该输入操作进行响应。终端1100则将文字、图片或者视频任意一种形式或者组合所形成的输出内容通过触控屏幕117向用户显示输出。

按键模块119包括至少一个按键，用以提供用户向终端1100进行输入的接口，用户可以通过按下不同的按键使终端1100执行不同的功能。例如，声音调节按键可供用户实现对终端1100播放的声音音量的调节。

可以理解，图12所示的结构仅为示意，终端1100还可包括比图12中所示更多或更少的组件，或者具有与图12所示不同的组件。图12中所示的各组件可以采用硬件、软件或者其组合来实现。

请参阅图13，本申请实施例中提供了一种电子设备400，包括至少一个处理器4001、至少一条通信总线4002以及至少一个存储器4003。例如，该电子设备400可以是部署于车辆中的导航仪、智能手机、平板电脑、笔记本电脑、微型计算机等等。

其中，处理器4001和存储器4003相连，如通过通信总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

通信总线4002可包括一通路，在上述组件之间传送消息。通信总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。通信总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图13中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态消息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储消息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器4003上存储有计算机可读指令，处理器4001通过通信总线4002读取存储器4003中存储的计算机可读指令。

该计算机可读指令被处理器4001执行时实现上述各实施例中的地图显示方法。

本申请实施例中提供了一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述各实施例中的地图显示方法。

本申请实施例中提供了一种计算机程序产品，该计算机程序产品包括计算机可读指令，该计算机可读指令存储在存储介质中。计算机设备的处理器从存储介质读取该计算机可读指令，处理器执行该计算机可读指令，使得该计算机设备执行上述各实施例中的地图显示方法。

与现有技术相比，目标路口对应的地图不再依赖于云端下载，而能够来源于经过该目标路口的第二终端发送的广播消息，以此避免云端与第一终端之间的交互，使得地图显示不再受到网络延迟/丢包率等客观因素的影响，从而有效地解决了地图显示效率不高的问题。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

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