CN106844361A - 地图类应用中的候选路线获取方法及系统 - Google Patents

Abstract

本发明公开了一种地图类应用中的候选路线获取方法及系统，其中，所述方法包括侦听得到触发地图类应用进行路线搜索的指令，通过所述指令向服务器发起路线搜索；接收所述服务器进行路线搜索返回的候选路线信息，所述候选路线信息包括公交路线和所述公交路线中最近站点的公交到站时间；及在所述地图类应用的搜索结果显示界面中，按照所述候选路线信息进行候选路线的显示，并对所述候选路线中的公交路线标注所述最近站点的公交到站时间，所述系统与上述方法相匹配。本发明能够避免现有技术的地图类应用中候选路线获取的准确性不够的问题。

Description

地图类应用中的候选路线获取方法及系统

技术领域

本发明涉及互联网应用技术领域，尤其涉及一种地图类应用中的候选路线获取方法及系统。

背景技术

随着互联网技术的不断发展，通过地图类应用等客户端进行候选路线的获取已逐渐进入了大众的视线，并由此提高了用户出行的快捷性。

目前，地图类应用中所获取到的候选路线大多是由服务器推送的，并且推送的候选路线往往不止一条，由此，地图类应用在显示的时候通常会对其中某条候选路线的优势进行标注，例如，该优势可以是较快捷、少步行、少换乘等等，以利于用户进一步地选择出行路线。

由于服务器在进行候选路线推送时考虑的推送因素过于单一，导致实际使用过程中，较快捷的候选路线未必就是较快捷的，这就使得选择该候选路线的用户的出行效率反而降低了。

因此，现有的地图类应用中的候选路线获取方法还存在准确性不够的问题。

发明内容

基于此，有必要提供一种能够提高候选路线获取的准确性的地图类应用中的候选路线获取方法。

此外，还有必要提供一种能够提高候选路线获取的准确性的地图类应用中的候选路线获取系统。

为了解决上述技术问题，本发明所采用的技术方案为：

一种地图类应用中的候选路线获取方法，包括：侦听得到触发地图类应用进行路线搜索的指令，通过所述指令向服务器发起路线搜索；接收所述服务器进行路线搜索返回的候选路线信息，所述候选路线信息包括公交路线和所述公交路线中最近站点的公交到站时间；及在所述地图类应用的搜索结果显示界面中，按照所述候选路线信息进行候选路线的显示，并对所述候选路线中的公交路线标注所述最近站点的公交到站时间。

一种地图类应用中的候选路线获取系统，包括客户端，所述客户端包括：指令侦听模块，用于侦听得到触发地图类应用进行路线搜索的指令，通过所述指令向服务器发起路线搜索；信息接收模块，用于接收所述服务器进行路线搜索返回的候选路线信息，所述候选路线信息包括公交路线和所述公交路线中最近站点的公交到站时间；及信息显示模块，用于在所述地图类应用的搜索结果显示界面中，按照所述候选路线信息进行候选路线的显示，并对所述候选路线中的公交路线标注所述最近站点的公交到站时间。

与现有技术相比，本发明具有以下有益效果：

通过地图类应用侦听得到进行路线搜索的指令，向服务器发起路线搜索，以此接收服务器进行路线搜索返回的候选路线信息，并将其显示在搜索结果显示界面中。由于候选路线信息中包括了公交路线和公交路线中最近站点的公交到站时间，在搜索结果显示界面中显示公交路线的同时，还会对显示的该公交路线进行最近站点的公交到站时间的标注，使得用户能够直接获知候选路线中公交路线所需等待的时间，从而正确地选择较快捷的候选路线，以此避免了现有技术中候选路线获取的准确性不够的问题。

附图说明

图1为一实施例的地图类应用中的候选路线获取方法运行的计算机系统结构示意图；

图2为一实施例的地图类应用中的候选路线获取方法的流程图；

图3为另一实施例的地图类应用中的候选路线获取方法的流程图；

图4为另一实施例的地图类应用中的候选路线获取方法的流程图；

图5为另一实施例的地图类应用中的候选路线获取方法的流程图；

图6为一实施例的地图类应用中的候选路线获取系统的结构框图；

图7为另一实施例的地图类应用中的候选路线获取系统的结构框图；

图8为另一实施例的地图类应用中的候选路线获取系统的结构框图；

图9为另一实施例的地图类应用中的候选路线获取系统的结构框图。

具体实施方式

体现本发明特征与优点的典型实施方式将在以下的说明中详细叙述。应理解的是本发明能够在不同的实施方式上具有各种的变化，其皆不脱离本发明的范围，且其中的说明及图示在本质上是当作说明之用，而非用以限制本发明。

如前所述，为了提高地图类应用中候选路线获取的准确性，特提出了一种地图类应用中的候选路线获取方法。

在一实施例中，一种地图类应用中的候选路线获取方法，该方法所运行的计算机系统如图1所示。该计算机系统包括客户端10和服务器20。

其中，客户端10可以是地图类应用，例如，提供网络地图搜索服务的地图应用，或者，提供便捷出行服务的打车应用等，该地图类应用能够运行于智能手机、平板电脑、计算机等，客户端10通过与服务器20进行交互实现候选路线的获取，以利于用户进一步地选择出行路线。

在具体的实现过程中，通过服务器20来实现地图类应用中的候选路线获取方法，将有利于利用现有的架构，例如，可利用现有的候选路线搜索服务器来进行整个计算机系统的架构。

请参阅图2，在一实施例中，一种地图类应用中的候选路线获取方法，包括以下步骤：

步骤210，侦听得到触发地图类应用进行路线搜索的指令，通过指令向服务器发起路线搜索。

路线搜索的指令产生于地图类应用为了获取服务器推送的候选路线，若地图类应用需要服务器进行候选路线推送时，将侦听得到用户触发进行的路线搜索的指令。

具体地，地图类应用中增设了路线搜索入口，通过在该路线搜索入口中进行的输入操作，例如，输入操作可以是用户触发输入起点位置和终点位置，或者，输入操作仅为用户触发输入目的地位置，以此产生路线搜索的指令，并通过该指令向服务器发起路线搜索。通过地图类应用与服务器的配合，服务器向地图类应用推送与该输入操作输入的内容对应的候选路线，以供用户选择下一步的出行路线。

其中，地图类应用可以是软件客户端的形式或者网页客户端的形式，相应地，路线搜索入口可以是软件客户端界面中的输入对话框，也可以是网页客户端界面中的输入对话框。

步骤230，接收服务器进行路线搜索返回的候选路线信息，候选路线信息包括公交路线和公交路线中最近站点的公交到站时间。

服务器在接收到地图类应用进行路线搜索的指令之后，将根据指令生成时用户触发输入的内容得出用户的出行路线，以按照该出行路线进行路线搜索向地图类应用推送候选路线信息。

候选路线信息中至少包含有公交路线和公交路线中最近站点的公交到站时间，以此提高用户选择出行路线的准确性。可以理解，最近站点指的是该公交路线中与用户当前所在位置距离最短的任一站点。

当然，在其他应用场景中，候选路线信息中还可以包含自驾路线、打车路线等等，以利于服务器更好地向地图类应用进行候选路线的推送，同时也扩大了用户的可选择范围。

步骤250，在地图类应用的搜索结果显示界面中，按照候选路线信息进行候选路线的显示，并对候选路线中的公交路线标注最近站点的公交到站时间。

通过搜索结果显示界面中显示候选路线信息，使得搜索结果显示界面中不仅进行候选路线的显示，例如，公交路线的显示、自驾路线的显示、打车路线的显示，而且还会对显示的公交路线进行最近站点的公交到站时间的显示。

值得一提的是，若地图类应用为提供便捷出行服务的打车应用，在显示打车路线的同时，还将显示距离与用户当前所在位置处于有效范围内的出租车或者其它可以作为出租车使用的营运车辆，尤其是对距离最近的出租车或者其它营运车辆进行着重标注，以供用户选择出最快捷的出行方式。

具体地，搜索结果显示界面中，按照推荐顺序，依次显示不同的候选路线，并在候选路线为公交路线时，在该公交路线的旁边标注最近站点的公交到站时间。例如，以滚动条的方式标注最近站点的公交到站时间。

通过如上所述的过程，将使得用户通过搜索结果显示界面即可准确地获知候选路线中公交路线所需等待的时间，并随着公交的移动而不断更新最近站点的公交到站时间，实现了公交路线及其最近站点的公交到站时间的动态显示，有利于用户准确地选择出行路线，提高用户的出行效率。

需要说明的是，本发明所指的公交包括公共汽车、地铁、轻轨、客船等公共的交通工具，相应地，站点则包括公交站、地铁站、码头等等。

请参阅图3，在一实施例中，步骤230之前，如上所述的方法还包括以下步骤：

步骤310，从服务器进行路线搜索得到的候选路线信息中提取公交路线。

如前所述，服务器在接收到地图类应用进行路线搜索的指令之后，将得到用户于地图类应用中触发输入的位置信息，例如，位置信息为起点位置和终点位置，并通过在服务器存储的公交路线数据和地图数据中对该位置信息进行匹配查找，以得到向地图类应用推送的候选路线信息。

例如，起点位置为A1，终点位置为A2，假设公交路线数据中的B公交线包含两个站点即为A1和A2，通过匹配查找，该B公交线即可作为服务器向地图类应用推送的候选路线之一。

当然，在其他实施例中，位置信息可以仅包含用户输入的目的地位置，而出发地位置则由地图类应用对用户的当前所在位置进行定位并上报得到。

候选路线信息可以包含公交路线、自驾路线、打车路线等等，由此，公交路线能够从候选路线信息中提取得到，以供服务器对该公交路线的最近站点的公交到站时间的计算。

步骤330，根据地图类应用定位上报的用户位置确定公交路线中的最近站点。

公交路线中包含了多个站点，通过地图类应用定位上报的用户位置即可计算得到与该上报的用户位置距离最短的其中一站点，该站点即为最近站点。

步骤350，根据公交路线和最近站点获取公交侧上报的行驶位置。

服务器在提取出公交路线之后，将向与该公交路线对应的公交发送行驶位置定位请求，使得公交利用其上所安装的GPS定位系统进行行驶位置的定位，得到向服务器上报的行驶位置。

由于与该公交路线对应的公交的数量不止一个，服务器接收到的公交侧上报的行驶位置也不止一个，因此，服务器还将根据确定得到的该公交路线中的最近站点进一步地获取公交侧上报的行驶位置。也就是说，服务器根据公交路线和最近站点获取到的公交侧上报的行驶位置只会有一个，且是与最近站点的距离最近的一个。

步骤370，根据最近站点和行驶位置计算最近站点的公交到站时间，并向地图类应用返回。

在服务器得到最近站点和行驶位置之后，根据二者之间的距离和对应公交的默认时速，即可计算得到最近站点的公交到站时间。

之后，服务器将候选路线信息中的其余候选路线以及提取出的公交路线和该公交路线中最近站点的公交到站时间一并返回至地图类应用。

在一实施例中，如上所述的方法还包括以下步骤：

通过搜索结果显示界面中触发的候选路线选定，突出显示选定的候选路线和其中的公交路线中最近站点的公交到站时间。

如前所述，候选路线信息中包含的候选路线的数量不止一条，其可以有公交路线、打车路线、自驾路线等等，相应地，在搜索结果显示界面中进行显示的候选路线也有多条。

进一步地，用户通过对搜索结果显示界面中显示出的多条候选路线之一进行的点击操作，即能够选择出最快捷的候选路线，使得搜索结果显示界面根据用户触发的候选路线选定，突出显示出用户选择的最快捷的候选路线。若该最快捷的候选路线中包含有公交路线，则同时突出显示出该公交路线中最近站点的公交到站时间。

其中，突出显示的方式可以是由搜索结果显示界面跳转至选定候选路线显示界面，在该选定候选路线显示界面中仅显示选定的候选路线及其相关内容，或者，还可以是停留在搜索结果显示界面中，对选定的候选路线及其相关内容进行高亮显示或不同颜色显示。例如，在搜索结果显示界面中，使选定的候选路线及其相关内容所标识的颜色不同于其它候选路线。

请参阅图4，在一实施例中，如上所述的方法还包括以下步骤：

步骤410，判断候选路线的显示时间是否达到预设的时间间隔。

如前所述，候选路线的显示界面可以是搜索结果显示界面，也可以是选定候选路线显示界面，为了保证候选路线的显示界面中显示内容的有效性和可靠性，地图类应用将按照预设的时间间隔，向服务器发起最近站点的公交到站时间的重计算请求。因此，若判断得到候选路线的显示时间达到预设的时间间隔，则进入步骤430。否则继续进行候选路线的显示时间的判断，直至该时间达到预设的时间间隔。

步骤430，向服务器发起最近站点的公交到站时间的重计算请求。

服务器接收到重计算请求之后，将重新计算最近站点的公交到站时间，以保证的到公交站时间的真实可靠。

在一实施例中，如上所述的方法还包括以下步骤：

侦听得到地图类应用由后台运行切换至前台运行，则向服务器发起最近站点的公交到站时间的重计算请求。

由于地图类应用由前台运行切换至后台运行时，为了降低服务器的运算量，服务器会停止向地图类应用返回候选路线信息。

基于此，在侦听得到地图类应用由后台运行切换至前台运行之后，需要服务器重新返回候选路线信息，尤其是返回更新的最近站点的公交到站时间，以此保证候选路线的显示界面中显示内容的有效性和可靠性。

因此，服务器将接收到由地图类应用中发起的最近站点的公交到站时间的重计算请求，以向地图类应用返回重新计算的最近站点的公交到站时间。

当然，在其他应用场景中，最近站点的公交到站时间的重新计算也可以是由用户手动进行重新搜索触发的，而无论是服务器对最近站点的公交到站时间的初次计算，还是服务器对最近站点的公交到站时间的重新计算，均执行步骤310至步骤370的过程，具体描述如前述实施例中所述，在此不再赘述。

需要说明的是，在本实施例中，即使用户当前所在位置发生了偏移，地图类应用主动发起最近站点的公交到站时间的重计算请求，候选路线的显示界面中显示的候选路线也不会相应地更新，而仅仅是最近站点的公交到站时间得到更新。只有在用户手动进行重新搜索时，其中显示的候选路线才会与最近站点的公交到站时间一起更新。

请参阅图5，在一实施例中，通过搜索结果显示界面中触发的候选路线选定，突出显示选定的候选路线和其中的公交路线中最近站点的公交到站时间的步骤之后，如上所述的方法还包括以下步骤：

步骤510，根据地图类应用中发起的最近站点的公交到站时间的重计算请求，获取地图类应用定位上报的用户位置。

如前所述，由于用户选择的最快捷的候选路线可能是包含有换乘站点的公交路线，基于此，随着用户当前所在位置的移动，最近站点也可能发生了变化。也就是说，最近站点既可能仍然是首个乘坐站点，也可能变化为换乘站点。

例如，用户选择的最快捷的候选路线为：起点A步行至B1站，乘坐B公交线至C1站，进行C公交线的换乘，并乘坐C公交线至终点D。此时，若用户通过步行，使其当前所在位置从起点A移动至B1站，则最近站点仍为首个乘坐站点，即B1站。若用户通过乘坐B公交线，使其当前所在位置从B1站移动至C1站，则最近站点变化为换乘站点，即C1站。

由此，当服务器接收到由地图类应用中发起的最近站点的公交到站时间的重计算请求时，需要获取地图类应用定位上报的用户位置，以此确定最近站点是否发生了变化，以便于后续计算最近站点的公交到站时间。

步骤530，在选定的候选路线中根据用户位置重定位最近站点，以将首个乘坐站点或者换乘站点定位为最近站点。

步骤550，计算最近站点的公交到站时间，并向地图类应用返回。

在服务器得到公交路线和最近站点之后，首先按照公交路线和最近站点获取公交侧上报的行驶位置，然后在根据最近站点和行驶位置之间的距离和对应公交的默认时速，进行最近站点的公交到站时间的计算，最后将重新计算的最近站点的公交到站时间返回至地图类应用。

通过如上所述的过程，用户在选择了最快捷的候选路线之后，通过候选路线的显示界面不仅能够直接获知首个乘坐站点的到站时间，还能够直接获知换乘站点的到站时间，从而进一步地提高了用户的出行效率。

请参阅图6，在一实施例中，一种地图类应用中的候选路线获取系统包括客户端600，客户端600包括：指令侦听模块610、信息接收模块630及信息显示模块650。

其中，指令侦听模块610用于侦听得到触发地图类应用进行路线搜索的指令，通过指令向服务器发起路线搜索。

信息接收模块630用于接收服务器进行路线搜索返回的候选路线信息，候选路线信息包括公交路线和公交路线中最近站点的公交到站时间。

信息显示模块650用于在地图类应用的搜索结果显示界面中，按照候选路线信息进行候选路线的显示，并对候选路线中的公交路线标注最近站点的公交到站时间。

请参阅图7，在一实施例中，如上所述的系统还包括与客户端600交互的服务器700，服务器700包括：路线提取模块710、第一站点确定模块730、第一位置获取模块750及第一返回模块770。

其中，路线提取模块710用于从服务器进行路线搜索得到的候选路线信息中提取公交路线。

第一站点确定模块730用于根据地图类应用定位上报的用户位置确定公交路线中的最近站点。

第一位置获取模块750用于根据公交路线和最近站点获取公交侧上报的行驶位置。

第一返回模块770用于根据最近站点和行驶位置计算最近站点的公交到站时间，并向地图类应用返回。

在一实施例中，客户端600还包括突出显示模块，用于通过搜索结果显示界面中触发的候选路线选定，突出显示选定的候选路线和其中的公交路线中最近站点的公交到站时间。

请参阅图8，在一实施例中，客户端600还包括：预设时间判断模块810及第一重计算模块830。

其中，预设时间判断模块810用于判断候选路线的显示时间是否达到预设的时间间隔。若为是，则通知第一重计算模块830。

第一请求发起模块830用于向服务器发起最近站点的公交到站时间的重计算请求。

在一实施例中，客户端600还包括第二请求发起模块，用于侦听得到地图类应用由后台运行切换至前台运行，则向服务器发起最近站点的公交到站时间的重计算请求。

请参阅图9，在一实施例中，服务器700还包括：第二位置获取模块910、第二站点确定模块930及第二返回模块950。

其中，第二位置获取模块910用于根据地图类应用中发起的最近站点的公交到站时间的重计算请求，获取地图类应用定位上报的用户位置。

第二站点确定模块930用于在选定的候选路线中根据用户位置重定位最近站点，以将首个乘坐站点或者换乘站点定位为最近站点。

第二返回模块950用于计算最近站点的公交到站时间，并向地图类应用返回。

上述内容，仅为本发明的较佳实施例，并非用于限制本发明的实施方案，本领域普通技术人员根据本发明的主要构思和精神，可以十分方便地进行相应的变通或修改，故本发明的保护范围应以权利要求书所要求的保护范围为准。

Claims (12)

1.一种地图类应用中的候选路线获取方法，其特征在于，包括：

侦听得到触发地图类应用进行路线搜索的指令，通过所述指令向服务器发起路线搜索；

接收所述服务器进行路线搜索返回的候选路线信息，所述候选路线信息包括公交路线和所述公交路线中最近站点的公交到站时间；及

在所述地图类应用的搜索结果显示界面中，按照所述候选路线信息进行候选路线的显示，并对所述候选路线中的公交路线标注所述最近站点的公交到站时间。

2.如权利要求1所述的方法，其特征在于，所述接收所述服务器进行路线搜索返回的候选路线信息的步骤之前，所述方法还包括：

从所述服务器进行路线搜索得到的候选路线信息中提取所述公交路线；

根据所述地图类应用定位上报的用户位置确定所述公交路线中的最近站点；

根据所述公交路线和所述最近站点获取公交侧上报的行驶位置；及

根据所述最近站点和行驶位置计算所述最近站点的公交到站时间，并向所述地图类应用返回。

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

通过所述搜索结果显示界面中触发的候选路线选定，突出显示选定的候选路线和其中的公交路线中最近站点的公交到站时间。

4.如权利要求1或3所述的方法，其特征在于，所述方法还包括：

判断候选路线的显示时间是否达到预设的时间间隔；

若为是，则向所述服务器发起所述最近站点的公交到站时间的重计算请求。

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

侦听得到所述地图类应用由后台运行切换至前台运行，则向所述服务器发起所述最近站点的公交到站时间的重计算请求。

6.如权利要求3所述的方法，其特征在于，所述通过所述搜索结果显示界面中触发的候选路线选定，突出显示选定的候选路线和其中的公交路线中最近站点的公交到站时间的步骤之后，所述方法还包括：

根据所述地图类应用中发起的所述最近站点的公交到站时间的重计算请求，获取所述地图类应用定位上报的用户位置；

在所述选定的候选路线中根据所述用户位置重定位所述最近站点，以将首个乘坐站点或者换乘站点定位为所述最近站点；及

计算所述最近站点的公交到站时间，并向所述地图类应用返回。

7.一种地图类应用中的候选路线获取系统，其特征在于，包括客户端，所述客户端包括：

指令侦听模块，用于侦听得到触发地图类应用进行路线搜索的指令，通过所述指令向服务器发起路线搜索；

信息接收模块，用于接收所述服务器进行路线搜索返回的候选路线信息，所述候选路线信息包括公交路线和所述公交路线中最近站点的公交到站时间；及

信息显示模块，用于在所述地图类应用的搜索结果显示界面中，按照所述候选路线信息进行候选路线的显示，并对所述候选路线中的公交路线标注所述最近站点的公交到站时间。

8.如权利要求7所述的系统，其特征在于，还包括与所述客户端交互的服务器，所述服务器包括：

路线提取模块，用于从所述服务器进行路线搜索得到的候选路线信息中提取所述公交路线；

第一站点确定模块，用于根据所述地图类应用定位上报的用户位置确定所述公交路线中的最近站点；

第一位置获取模块，用于根据所述公交路线和所述最近站点获取公交侧上报的行驶位置；及

第一返回模块，用于根据所述最近站点和行驶位置计算所述最近站点的公交到站时间，并向所述地图类应用返回。

9.如权利要求7所述的系统，其特征在于，所述客户端还包括：

突出显示模块，用于通过所述搜索结果显示界面中触发的候选路线选定，突出显示选定的候选路线和其中的公交路线中最近站点的公交到站时间。

10.如权利要求7或9所述的系统，其特征在于，所述客户端还包括：

预设时间判断模块，用于判断候选路线的显示时间是否达到预设的时间间隔；若为是，则通知第一重计算模块；

所述第一请求发起模块用于向所述服务器发起所述最近站点的公交到站时间的重计算请求。

11.如权利要求7或9所述的系统，其特征在于，所述客户端还包括：

第二请求发起模块，用于侦听得到所述地图类应用由后台运行切换至前台运行，则向所述服务器发起所述最近站点的公交到站时间的重计算请求。

12.如权利要求9所述的系统，其特征在于，所述服务器还包括：

第二位置获取模块，用于根据所述地图类应用中发起的所述最近站点的公交到站时间的重计算，获取所述地图类应用定位上报的用户位置；

第二站点确定模块，用于在所述选定的候选路线中根据所述用户位置重定位所述最近站点，以将首个乘坐站点或者换乘站点定位为所述最近站点；及

第二返回模块，用于计算所述最近站点的公交到站时间，并向所述地图类应用返回。