交通路线选择的多模式方法

摘要

从第一用户操作的第一用户设备接收第一出发位置和第一目的地的指示，并且从第二用户操作的第二用户设备接收第二出发位置和第二目的地的指示。考虑第二用户从第二出发位置行进到第二目的地，生成从第一出发位置到第一目的地的多模式路线。生成多模式路线包括：(i)第一用户和第二用户能够使用乘车共享服务一起历经的多模式路线的乘车共享路段和(ii)与除了乘车共享服务以外的交通方式关联的路线的路段。将从第一出发位置到第一目的地的多模式路线的指示提供给第一用户设备。

说明书

技术领域

本公开涉及地理应用，并且特别地，涉及使用公共和私人交通方式来提供逐步的导航指示(navigation direction)。

背景技术

当今，可以在许多电子设备(诸如个人计算机、平板计算机、移动电话、作为专用设备提供或嵌入到交通工具的主控单元(head unit)中的导航仪等)上提供地理区域的数字地图和用于通过地理区域导航的逐步指示。数字地图和/或导航指示通过专用软件应用(诸如地图应用程序或“app”)以及通过通用软件应用(诸如web浏览器)提供。

软件应用通常针对特定交通方式(诸如驾驶、步行或乘坐公共汽车等)提供导航指示。用户通常指定交通方式以及出发点和目的地，或者在某些情况下，软件应用针对用户最后选择的交通方式生成导航指示。这些导航指示并不总是最佳的。例如，对于某个出发位置和某个目的地，一般的软件应用提供包括地铁和公共汽车且预期持续45分钟的一个选项；30分钟的出租车乘车作为另一选项；以及骑自行车30分钟作为第三选项。但是，用户已经通过实验确定，最快的选项实际上是搭乘短途出租车乘车，然后乘坐快速公共汽车，整个行程仅耗时15分钟。作为另一示例，一般的软件应用针对另一对位置提供耗时2小时15分钟、总费用约为200美元的乘车共享作为一个选项；以及耗时大约15个小时、费用为10美元的公共交通作为另一选项。但是，用户也可以乘坐出租车到某个火车站，然后乘火车走完余下的路途，从而使总出行变为耗时大约两个小时且总费用为20美元。

发明内容

一般而言，本公开的软件系统确定用于从某个源(source)行进到某个目的地的多模式(multi-modal)路线，其中，该多模式路线的一个路段与公共交通类型(例如，火车、公共汽车、渡轮)对应而另一路段与私人交通类型(例如，乘车共享)对应。软件系统可以考虑诸如时间和费用的因素来确定多模式路线。在一些实施方式中，软件系统允许用户指定多少重要性应当归属于每个因素(例如，“费用的重要性是时间的两倍”)。在生成多模式路线时，软件系统可以考虑使某些交通方式更具成本效益和/或更可能可用的某些因素，诸如在某些位置和/或某些时间使乘车共享选项更有可能被使用的预计的客流量高峰(spike)。

这些技术的一个示例实施例是用于为用户生成多模式导航指示的方法。该方法可以由一个或多个处理器执行。该方法包括：从第一用户接收第一出发位置和第一目的地的指示；从第二用户接收第二出发位置和第二目的地的指示；和考虑第二用户从第二出发位置行进到第二目的地，为第一用户生成从第一出发位置到第一目的地的多模式路线。生成多模式路线包括：生成(i)第一用户和第二用户能够使用乘车共享服务一起历经的多模式路线的乘车共享路段和(ii)与除了乘车共享服务以外的交通方式关联的路线的路段。该方法还包括提供从第一出发位置到第一目的地的多模式路线的指示。

这些技术的另一示例实施例是一种计算系统，该计算系统包括一个或多个处理器以及存储用于为用户生成多模式导航指示的指令的非暂时性计算机可读存储器。当由一个或多个处理器执行时，该指令使计算系统从由第一用户操作的第一用户设备接收第一出发位置和第一目的地的指示，从由第二用户操作的第二用户设备接收第二出发位置和第二目的地的指示，考虑第二用户从第二出发位置行进到第二目的地，为第一用户生成从第一出发位置到第一目的地的多模式路线，包括生成(i)第一用户和第二用户能够使用乘车共享服务一起历经的多模式路线的乘车共享路段和(ii)与除了乘车共享服务以外的交通方式关联的路线的路段，以及向第一用户设备提供从第一出发位置到第一目的地的多模式路线的指示。

这些技术的又另一示例实施例是一种计算设备，该计算设备包括一个或多个处理器，被配置为接收来自用户的输入并向用户提供输出的用户接口，用于通过通信网络与一个或多个服务器进行通信的网络接口，以及存储用于获得多模式导航指示的指令的非暂时性计算机可读存储器。该指令在由一个或多个处理器执行时，使该计算设备通过用户接口接收出发位置和目的地的指示，通过用户接口接收私人交通选项和公共交通选项的选择，从一个或多个服务器接收从第一出发位置到第一目的地的多模式路线的指示，并通过用户接口提供从第一出发位置到第一目的地的多模式路线的指示。多模式路线包括(i)与公共交通方式关联的公共交通路段，和(ii)第一用户能够使用乘车共享服务与另一用户一起历经的乘车共享路段。

这些技术的又另一实施例是计算设备中的用于考虑多个因素生成导航指示的方法。该方法包括通过一个或多个处理器从由第一用户操作的第一用户设备接收出发位置和目的地的指示。该方法还包括通过一个或多个处理器经由用户接口接收要应用于费用(或价格)因素的第一权重和要应用于时间因素的第二权重的选择，其中，第一权重和第二权重中的每一个具有大于零且小于百分之一百的相应值。该方法还包括：考虑第一权重和第二权重，生成从第一出发位置到第一目的地的路线；以及经由用户接口提供从第一出发位置到第一目的地的路线的指示。

在各个实施例中，以上用于考虑多个因素而生成导航指示的方法包括以下特征中的一个或多个。该方法包括经由用户接口提供用于选择第一权重的第一交互式控件和用于选择第二权重的第二交互式控件。第一和第二交互式控件包括相应的滑动条。生成路线包括生成多模式路线，该多模式路线具有(i)用户可以使用乘车共享服务一起历经的乘车共享路段，以及(ii)与公共交通方式关联的公共交通路段。生成该路线包括生成多个候选路线，并且对于多个候选路线中的每一个：确定每个路线的相应费用，确定每个路线的相应时间，并分别将第一权重和第二权重应用于该费用和时间，以计算路线的总得分；并基于对应的总得分从多个候选路线中选择路线。

附图说明

图1是在其中可以实现用于提供多模式路线选择(routing)的技术的示例系统的框图；

图2是用于考虑用户指定的因素生成导航指示的示例方法的流程图，该方法可以在图1的客户端计算设备中实现；

图3是示例用户界面屏幕，在图1的客户端计算设备中操作的地图应用可以生成该示例用户界面屏幕以接收用于生成导航指示的因素；

图4是用于考虑另一用户而为用户生成多模式路线的示例方法的流程图；

图5示意性地示出了两个用户的多模式路线共享与公共交通关联的路段的情形；和

图6是在其中在图1的系统中操作的服务器为由不同的相应用户操作的两个设备生成多模式路线的情形的消息图。

具体实施方式

概述

如本文所提及的，在某个出发位置(或“源”)与某个目的地之间的多模式路线(multi-modal route)包括用户可以使用不同的交通方式来历经的至少两个路段。一些交通方式是公共的。公共交通的示例包括地铁、公共汽车、火车、有轨电车(tram)或无轨电车(trolley)、轮渡等。其他交通方式(诸如汽车或自行车)是私人的。当今提供的某些乘车共享可以与传统出租车和个人或少数人请求一起乘车的服务以及拼车服务(即陌生人之间共享的乘车以降低成本)的提供者相类似地进行操作。在任一种情况下，乘车共享服务提供的交通在本文中都称为私人交通方式。

本公开的软件系统生成多模式路线，该多模式路线包括用户使用公共交通方式历经的至少一个路段和用户使用私人交通方式历经的至少一个路段。相对于从出发点到目的地的单方式路线或仅使用公共交通选项的多方式路线(例如，地铁随后是公共汽车)，该多模式路线可能更省时和/或更节省费用。例如，对于某个出发位置，软件系统可以生成多模式路线，该多模式路线包含使用私人交通到从该出发位置使用公共交通难以接近的交通枢纽的相对较短的乘车，以及随后使用公共交通的乘车。因此，软件系统可以识别用户可以从私人交通切换到公共交通或相反地从公共交通切换到私人交通的中间位置。

如下面更详细地讨论的，软件系统可以通过迭代地考虑候选位置、确定在这些候选位置处终止的路段的时间和成本、确定在交通方式之间切换的时间和确定总体时间和费用来生成具有与私人交通方式和公共交通方式对应的路段的多模式路线。为此，系统可以调用由乘车共享服务的第三方提供者提供的API，以例如获得路线的路段的时间和费用估计，或者使用历史数据估计乘车的时间和费用。

在某些情况下，软件系统通过识别可以使用拼车选项的位置来确定何时可以降低历经路线的费用。在一个示例情形中，软件系统识别在某时间特定类型的公共交通的客流量高峰，并从预期有许多乘客到达的交通枢纽生成拼车的建议。在另一示例情形中，软件系统确定请求导航指示的多个用户具有他们使用乘车共享服务快速研究(case)且节省费用地历经的共享路段。

此外，在一些实施方式中，软件系统允许用户指定时间和费用因素的相对重要性。用户可以例如指示时间的重要性是费用的两倍，而不是请求系统针对时间或费用优化路线。为此，软件系统可以提供交互式控件，诸如滑动条，用于为这些因素分配数值。

软件系统可以包括在客户端设备上执行的组件，诸如地图和/或导航应用；在服务器上执行的组件，诸如被配置为生成路线以为来自客户端设备的请求提供服务的路由引擎；并且在某些情况下，还包括第三方提供的组件，诸如由乘车共享服务的第三方提供者公开(expose)并由客户端设备或服务器调用的API。

示例计算环境

参考图1，在其中可以实现上面概述的技术的示例通信系统100包括客户端计算设备102、103等，其可以是例如个人计算机、诸如平板计算机或智能电话的便携式设备、可穿戴计算设备、专用汽车导航仪、嵌入在交通工具的主控单元中的设备等。通信系统100通常可以包括任何合适数量的客户端计算设备。

通信系统100还包括由地图和导航服务的提供者操作的一个或多个服务器设备104(为简单起见仅示出一个)。服务器设备104可以将地图数据和导航数据提供给客户端计算设备102和其他客户端设备。再另外，该示例配置中的通信系统100包括乘车共享服务的第三方提供者的一个或多个服务器106(为简单起见仅示出一个)。第三方提供者独立于服务器设备104与之关联的提供者且单独地操作。通信系统100通常可以包括与交通有关的内容和/或数据库的任何合适数量的提供者，诸如火车、公共汽车、渡轮等的调度和路由信息的提供者。服务器设备104、106；客户端计算设备102、103；和任何其他数据提供者可以通过网络108彼此通信。例如，网络108可以是诸如互联网的广域网，并且包括有线和/或无线通信链路。

服务器设备104可以通信地联接到存储各种地理区域的地图数据的数据库110。地图数据可以以任何适当的格式存储，例如矢量图形、栅格化图像，标签文本等，并根据任何适当的原则进行组织(例如，在某个缩放级别覆盖相同面积量的正方形地图图块)。地图数据可以指定地理特征(诸如道路、建筑物、湖泊、河流、公园等)的形状和各种属性。地图数据还可以包括街道级别的影像和从各个有利点(vantage point)拍摄的照片。此外，地理区域的地图数据可以包括有关位于该地理区域内相应位置的实体店企业(brick-at-mortarbusiness)的信息：营业时间、产品和服务描述、用户评论等。

在该示例配置中，服务器设备104通信地联接到存储与公共和私人交通类型有关的数据的交通数据库112。例如，交通数据库112可以存储针对火车、公共汽车和其他类型的公共交通的路线和时间表。交通数据库112还可以存储历史数据，该历史数据指示用户何时、何地、针对什么目的地等倾向于请求乘车共享服务。在某些情况下，交通数据库112还存储各种公共和/或私人交通类型的价格信息。

服务器设备104在操作期间可以访问的其他数据库可以存储交通数据、天气数据、商业数据(广告、报价、优惠券等)、事件数据(例如，音乐、电影、音乐会)和与地理相关或可与地理相关的任何其他数据。

使用存储在数据库110和112中的地图数据，路由引擎120可以生成地理区域的地图以及历经这些地理区域的路线，包括多模式路线，该多模式路线包括公共交通路段和私人交通路段。路由引擎120可以被实现为一组指令，该组指令存储在包括诸如硬盘、闪存驱动器等的非暂时性介质的存储器中，并且可以由一个或多个处理器122执行。

继续参考图1，客户端计算设备102可以包括存储器130、一个或多个处理器132、网络接口134、用户接口(UI)136和传感器138。存储器130可以是非暂时性存储器，并且可以包括一个或多个合适的存储器模块，诸如随机存取存储器(RAM)、只读存储器(ROM)、闪存、其他类型的持久性存储器等。网络接口134可以支持任何合适的通信协议以经由通信网络108与远程服务器和其他设备进行通信。UI 136可以包括输入设备(诸如触摸屏、键盘、麦克风等)和输出设备(例如屏幕、扬声器等)的任何适当组合。取决于实施方式，一个或多个传感器138可以包括全球定位系统(GPS)模块，以检测客户端计算设备102的位置；罗盘，以确定客户端计算设备102的方向；陀螺仪，以确定旋转和倾斜；加速度计等。

存储器130存储操作系统(OS)140，该操作系统可以是任何类型的合适的移动或通用操作系统。存储器130还存储地图和导航应用142，其可以被配置为生成交互式数字地图和导航指示。地图应用142可以从地图数据数据库110和/或服务器设备104接收栅格(例如，位图)或非栅格(例如，矢量图形)格式的地图数据。在某些情况下，地图数据可以被组织成层，诸如描绘道路、街道、自然地形(natural formation)等的基本层；描绘当前交通状况的交通层；描绘当前天气状况的天气层；描绘到达目的地的路径的导航层等。地图应用142可以提供导航指示，作为数字地图上的图形叠加、作为包括文本和/或图像的指示序列、作为经由扬声器的一组语音化指示或其任何合适的组合。例如，地图应用142可以本地地经由UI136或通过交通工具的主控单元以投影方式提供数字地图和导航指示。

存储器130还可以存储实现第三方乘车共享API的指令，客户端计算设备102可以从第三方提供者106接收该指令。在该示例中，第三方提供者106可以向客户端设备以及服务器104提供API 150。API 150可以公开这样的功能，诸如请求指定位置和指定时间的乘车共享选项的可用性、获得价格选项、获得行进时间估计、请求指定位置和指定时间的乘车共享服务、获得关于乘车进度的信息等。在一个示例实施方式中，第三方提供者106可以提供类似于传统出租车或个人或一起出行的一小群人请求私家车的豪华轿车服务的乘车服务，以及拼车服务，其中可能彼此不熟悉的人共享乘车或乘车的一部分，并相应地拆分车费。取决于实施方式，服务器104和/或客户端计算设备102、103可以调用API 150以获得关于潜在或实际乘车的信息。除了API 150之外，第三方提供者106的存储器还可以存储包括乘车处理软件154的指令，该乘车处理软件154处理来自客户端102、103和/或服务器104的各种类型乘车的请求。

为了简单起见，图1将服务器设备104示为仅服务器的一个实例。然而，根据一些实施方式，服务器设备104包括一组一个或多个服务器设备，每个服务器设备配备有一个或多个处理器并且能够独立于其他服务器设备进行操作。在这样的组中操作的服务器设备可以以分布式方式单独处理来自客户端计算设备102的请求(例如，基于可用性)或根据任何其他合适技术处理该请求，在分布式方式中，与处理请求关联的一个操作在一个服务器设备上执行，而与处理该同一请求关联的另一操作则在另一服务器设备上执行。为了该讨论的目的，术语“服务器设备”可以指单个服务器设备或两个或更多个服务器设备的组。

考虑用户指定的多个参数选择路线

图2示出了用于考虑多个用户指定的因素生成路线的导航指示的示例方法200的流程图。在某些情况下，生成的路线是多模式路线，其具有与公共交通关联的路段以及与私人交通关联的路段。方法200可以以存储在计算机可读存储器中并且可由客户端计算设备102和/或服务器设备104的一个或多个处理器执行的一组指令实现。为了方便起见，下面参考地图应用142讨论方法200。

在框202处，地图应用142可以提供用户当前位置的地理区域的交互式数字地图。更一般地，地图应用142可以提供用于请求导航指示的任何合适的入口点(entry point)。例如，地图应用可以显示某个兴趣点的信息卡，并提供用于直接请求导航指示的控件。作为另一示例，地图应用142可以检测请求导航指示的语音命令。

在示例方法200中，地图应用124呈现搜索栏或其他合适的控件，用于接收地址(例如，“亚当斯街120号”)、兴趣点的名称(例如，“扬基体育场”)、或兴趣点的类型(例如，“咖啡店”)的形式或任何其他合适形式的地理位置指示。一旦地图应用124以互动形式在地图、列表或信息卡上提供一个或多个搜索结果，用户就可以激活适当的控件或提供适当的语音命令以请求到该地理位置的导航指示。例如，如图3所示，地图应用124可提供用于指定出发点和目的地的输入框(entry box)302，作为界面300的一部分。在某些实施方式中，界面300还可以提供用于选择用户希望离开的时间、用户希望到达目的地的时间等的控件。

在框206处，地图应用142可以提供用于向在生成出发位置和目的地之间的路线时使用的费用、时间和其他参数分配权重的交互式控件。例如，参考图3，地图应用142可以提供滑动条306和308，用户可以经由滑动条306和308分别指定费用和时间的重要性。在示例实施方式中，重要性范围可以为零至100％。在一些实施方式中，滑动条306和308是互连的，从而例如经由滑动条306指定费用的重要性为75％使得地图应用自动将时间的重要性设置为25％。当然，用户可以操作滑动条306和/或308以指定一个费用的重要性为100％，而时间的重要性为0％，反之亦然。

地图应用142还可以提供用于选择可接受的交通方式的控件，而不将用户限制到公共或私人交通方式。如图3所示，用户可以在区域304中勾选任意数量的框。当用户选中与私人交通和公共交通对应的两个选项时，图1的系统评估仅包括私人交通方式、仅包括公共交通方式以及包括公共和私人交通方式的潜在路线。此外，界面300可以包括切换选项310，以允许用户选择拼车选项。在一些实施方式中，仅当用户通过控件304之一选择乘车共享选项时，地图应用142才显示切换选项310。

在框208处，根据经由控件306、308和310指定的选择来确定导航路线。为了进一步清楚起见，接下来考虑几种示例情形。

在一种情形中，用户指定出发点和目的地，仅选择公共交通，并指示费用的重要性是时间的两倍。在该示例情形中，地图应用142获得单方式路线。与针对时间或费用优化路线的系统相比，在此，地图应用142和/或服务器104可以生成费用多于针对费用优化的路线但少于针对时间优化的路线，并且耗时多于针对时间优化的路线但少于针对费用优化的路线的路线。为此，系统可以确定候选路线，计算该路线的预期费用和时间，将相应的权重应用于费用和时间估计，并计算加权费用和时间估计的总和以确定该路线的总得分。然后，系统可以根据得分的计算方式选择总得分最高或最低的路线。

在另一种情形中，经由控件306和308选择公共交通和私人交通选项并指示费用和时间都重要。系统可以迭代地考虑用户可以在公共和私人交通方式之间转换的多个中间位置。例如，系统可以确定目的地在地铁站的步行距离之内，但是出发位置在地铁站的步行距离之外。系统可以获得出发位置和更接近出发位置的地铁站之间的乘车共享服务的时间和费用估计，获得地铁乘车的时间和费用估计，并确定该路线的总得分。这样，系统可以生成包括私人和公共交通方式的多模式路线。

类似地，系统可以识别接近出发位置和目的地的多个站(station)、停车站(stop)和其他公共交通“端点”。对于这些公共交通端点中的每一个，系统可以考虑通过私人交通到达端点，或者相反，在公共交通端点处转换到私人交通的费用和时间。通常，路线可以包含私人和公共交通之间的任意数量的转换：在一种情况下，系统生成以私家车的短途乘车开始、包括相对较长的火车乘车且以私家车的另一相对较短途乘车结束的路线；在另一种情况下，系统生成包括到公共汽车站的步行、在公共汽车上的乘车以及在私家车中的拼车乘车的路线。

为了通过第三方提供者确定乘车的预期费用和/或时间，系统可以调用第三方提供者公开的适当的API，诸如图1的API 150，或者使用例如指示各种端点对的平均时间和费用的历史数据来生成估计。

继续参考图2，可以在框210处给用户提供如上所述生成的一个或多个路线以供选择。地图应用142可以将多个路线显示为同一数字地图上的单独的叠加，例如使用颜色或阴影将彼此在视觉上相互区分。一旦用户选择了这些路线之一，系统就可以生成导航指示，以沿着选择的路线引导用户。系统可以以图形叠加数字地图、文本、语音指示等的形式提供导航指示。图3的示例用户界面300包括地图部分312以示出路线的第一路段(或整个路线，例如，这取决于用户选择)和框314中的路线的高级文字概述。

当用户选择包括不是多模式路线的路段序列中第一路段的乘车共享路段的路线时，系统可以估计用户到达接载位置的时间并提供请求在某个将来时间接载的选项。例如，当多模式路线由步行路段、然后是公共汽车乘车并且再然后是乘车共享路段组成时，系统可以估计用户到达乘车共享路段的接载位置的时间，使得可以提前请求接载位置的乘车共享。

选择具有拼车路段的多模式路线

在某些情况下，系统可以确定可以为行进到相应目的地的几个用户生成相应的多模式路线，该相应的多模式路线具有该几个用户可以通过共享乘车共享服务提供的私人交通(即拼车)来一起历经的路段。拼车路段通常相对于两个用户各自专用的私人交通降低这两个用户行程的总费用。此外，拼车路段可以相对于公共交通选项减少路线的总时间。

更特别地，图4是用于考虑另一用户为用户生成多模式路线的示例方法400的流程图。类似于方法200，方法400可以以存储在计算机可读存储器中并且可由客户端计算设备102和/或服务器设备104的一个或多个处理器执行的一组指令实现。为方便起见，下面参考地图应用142讨论方法400。

方法400在框402处开始，其中，从操作第一客户端计算设备(例如，设备102)的第一用户接收对路线和关联的导航指示的请求。该请求可以包括某个出发位置和目的地，在某些情况下，地图应用142基于客户端计算设备的当前位置来推断该出发位置。

在框404处，从操作第二客户端计算设备(例如，设备103)的第二用户接收对路线和关联的导航指示的请求。该请求也可以包括某个出发位置和目的地。

在一些情况下，在框406处，系统考虑第二用户生成第一用户的多模式路线。特别地，系统可以确定某个候选路线包括第一用户可以在没有拼车选项的情况下以一定的费用并耗时一定的预期时间开销使用乘车共享服务历经的路段。然后，系统可以确定另一用户的候选路线可以包括相同的路段。如果两个用户都指示考虑拼车选项的意愿(例如，通过操作图3中的控件310)，则系统可以确定如果两个用户共享由乘车共享服务提供的私人交通并一起历经该路段，则可以降低两个用户的路线的费用。

作为更特定的示例，音乐会、体育比赛、集会或其他活动可能被安排在某个时间在某个场地开始，并且可以预期在同一时间窗口内会有很多人到达距该场地两英里火车站。系统可以将该窗口定义为持续10分钟、15分钟、20分钟等。第一用户和第二用户可能大约同时从不同地点到达该火车站，因此本公开的系统可以生成包括具有拼车的乘车共享路段的多模式路线。

此外，在事件结束之后，可以预期许多参与者大约同时使用乘车共享选项返回火车站，并且系统可以再次考虑其他用户的行进计划为用户生成多模式路线。因此，在各种情形中，与拼车关联的路段可以在与公共交通关联的路段之前，或者相反，与公共交通关联的路段可以在与拼车关联的路段之前。

图5示意性地示出了示例情形，其中，第一用户的多模式路线包括地铁路段450和460、乘车共享路段470和到目的地474的短途步行(图5中的路段未按比例绘制)。第二用户的多模式路线包括不同的地铁路段452和462、乘车共享路段470和到目的地472的短途步行。乘车共享路段470在火车站464开始。

如果第一用户和第二用户不同时到达火车站464，则系统可以考虑等待时间来计算对应的多模式路线的得分。例如，如果第一用户将在上午10:00到达火车站464，并且第二用户将在上午10:05到达火车站464，则与第二用户拼车会给第一用户的路线增加五分钟。但是，例如，也可以预期与第二用户拼车将使第一用户的路线的总费用降低3美元。例如，系统可以考虑通过用户界面300(参见图3)分配给费用和时间的权重来计算第一路线的总得分。

尽管在图5的情形中，第一用户和第二用户共享路段470和接载位置464，但是通常，系统无需要求接载位置相同。例如，私人交通可以在一个位置接载一个用户，在另一位置接载第二用户，并且共享路段相应地可以在第二用户的接载位置开始。

再次参考图4，在框408处可以向第一用户提供多模式路线的指示。当用户选择建议的多模式路线时，系统可以通过与第二用户和乘车共享提供者通信来协调乘车共享路段。

接下来，图6描绘了在其中在图1的系统中操作的服务器为由不同用户操作的设备102和103生成多模式路线的情形500的消息图。用户指定出发位置、目的地、行进时间，并且用户设备102通过消息502将这些参数提供给服务器104。用户类似地指定出发位置、目的地、行进时间，并且用户设备103通过消息504将这些参数提供给服务器104。服务器104确定多模式路线(事件506)并提供对应的指示510和512。在这种情形中，多模式路线共享操作设备102和103的用户可以使用共享乘车而一起历经的路段。

一旦用户选择具有共享路段的多模式路线，设备102和103就将相应的指示520和522转发给服务器104。在这种情形中，服务器104可以通过与乘车共享服务器通信(事件524)并接收确认(事件526)来为操作设备102和103的用户自动设置共享乘车。

在一些情形中，服务器104持续接收关于用户设备102和103沿着相应的路线的进程的更新(事件530、532)。服务器104继而可以更新乘车共享服务器106(事件534、536)。乘车共享服务器160可以向用户设备102和103提供更新引导(事件540、542)。例如，在某些情况下，如果一个或两个用户经历低于某个预定阈值(例如，1分钟、2分钟)的延迟持续时间，则乘车共享服务器可以自动调整接载时间。在其他情况下，乘车共享服务器106可以通知用户拼车选项不再可用(例如，如果用户之一不能在先前确定的接载时间的预定阈值内到达接载位置)。

识别多模式路段的可能的乘车共享机会

在另一示例情形中，系统从用户接收对导航指示的请求，并识别具有乘车共享路段的高效的候选多模式路线。用户已经指示拼车是选项，但是在请求导航指示时，系统无法识别可以与拼车安排中的用户共享乘车共享路段的另一用户。但是，系统可以确定在用户到达接载位置时，乘车共享提供者有可能向用户提供拼车。例如，系统可以确定例如在接载位置或在接载位置的大致附近，在当用户将需要乘车共享服务时的时间使用私人交通的乘车者的数量通常会增加。

作为更特定的示例，系统可以生成多模式路线，根据该多模式路线，用户在交通枢纽下火车并使用乘车共享服务来走完余下的路途。系统可以使用历史汇总数据来确定大约在当用户下火车时的时间，相对大量的人在交通枢纽处请求乘车共享。系统相应地确定乘车共享服务可能将向用户提供拼车选项(并因此降低行程的总费用)，并向该多模式路线分配对应的得分。

更一般地，系统可以使用任何数量的合适信号来确定在特定时间在特定位置处乘车共享服务或特定类型的乘车共享服务将可用的可能性。这样的信号可以包括各种位置和时间的历史数据，没有历史数据时则为公共交通时间表(schedule)，有关各种事件(例如，音乐会、体育赛事)的信息，有关某些公共交通方式暂时不可用的信息(例如，由于故障或事故火车服务变得不可用)等。

此外，当乘车路段不是路线中的第一路段时，并且当乘车共享提供者无法提前提供估计或预订时，系统类似地可以使用各种信号来确定乘车共享服务的可能可用性。例如，系统可以识别包含相对长的火车乘车(例如，五个小时)，然后是使用私人交通的乘车的候选多模式路线。系统可以使用与上述信号类似的信号来确定乘车共享是否可能将可用、等待时间等。在这种情况下，系统可以确定乘车共享服务的可能可用性，而不管用户是否愿意拼车。

附加考虑

以下附加考虑适用于前述讨论。在整个说明书中，多个实例可以将所描述的组件、操作或结构实现为单个实例。尽管将一种或多种方法的单独操作示出并描述为单独的操作，但是可以同时执行一个或多个单独的操作，并且不需要按所示顺序执行操作。在示例配置中呈现为单独组件的结构和功能可以实现为组合结构或组件。类似地，呈现为单个组件的结构和功能可以实现为单独的组件。这些和其他变化、修改、添加和改进落入本公开的主题的范围内。

此外，本文将某些实施例描述为包括逻辑或多个组件、模块或机构。模块可以构成软件模块(例如，存储在机器可读介质上的代码)或硬件模块。硬件模块是能够执行某些操作的有形单元，并且可以以某种方式被配置或布置。在示例实施例中，一个或多个计算机系统(例如，独立的客户端或服务器计算机系统)或计算机系统的一个或多个硬件模块(例如，处理器或一组处理器)可以通过软件(例如，应用或应用部分)被配置为进行操作以执行本文描述的某些操作的硬件模块。

在各种实施例中，硬件模块可以包括永久地被配置为执行某些操作的专用电路或逻辑(例如，作为专用处理器，诸如现场可编程门阵列(FPGA)或专用集成电路(ASIC))。硬件模块还可以包括通过软件临时地被配置为执行某些操作的可编程逻辑或电路(例如，如包含在通用处理器或其他可编程处理器内)。将可以理解，在费用和时间方面考虑可以决定机械地在专用且永久配置的电路中或在临时配置的电路(例如，通过软件配置)中实现硬件模块。

因此，术语“硬件”应理解为包含有形实体，是指物理地构造、永久地被配置(例如，硬连线)或临时地被配置(例如，编程)为以某种方式进行操作或执行本文描述的某些操作的实体。但在本文使用时，“硬件实现的模块”是指硬件模块。考虑其中硬件模块临时地被配置(例如，编程)的实施例，每个硬件模块不需要在任何一个时间实例被配置或实例化。例如，在硬件模块包括使用软件被配置的通用处理器的情况下，通用处理器可以在不同时间被配置为相应不同的硬件模块。软件可以相应地被配置在处理器上，例如，以在一个时间实例时构成特定的硬件模块，并在不同的时间实例时构成不同的硬件模块。

硬件模块可以向其他硬件提供信息并从其他硬件接收信息。因此，所描述的硬件模块可以被认为是通信联接的。在同时存在多个这样的硬件模块的情况下，可以通过连接硬件模块的信号传输(例如，通过适当的电路和总线)来实现通信。在其中在不同时间配置或实例化多个硬件模块的实施例中，可以例如通过在多个硬件模块可以访问的存储器结构中存储和取回信息来实现这样的硬件模块之间的通信。例如，一个硬件模块可以执行操作并将该操作的输出存储在与它通信联接的存储设备中。然后，另一硬件模块可以在以后的时间访问存储设备以取回和处理所存储的输出。硬件模块也可以发起与输入或输出设备的通信，并且可以对资源(例如，信息的集合)进行操作。

方法200和400可以包括有形的计算机可执行指令的形式的一个或多个功能块、模块、单个功能或例程，其被存储在非暂时性计算机可读存储介质中并且使用计算设备(例如，如本文所述的服务器、个人计算机、智能电话、平板计算机、智能手表、移动计算设备或其他个人计算设备)的处理器来执行。方法200和400可以作为任何后端服务器(例如，如本文所述的地图数据服务器、导航服务器或任何其他类型的服务器计算设备)的一部分、示例环境的便携式设备模块的一部分被包括在内，或作为这样的环境外部的模块的一部分被包括在内。尽管为了便于说明可以参考其他附图来描述附图，但是方法200和400可以与其他对象和用户接口一起使用。此外，尽管以上说明描述了由特定设备(诸如客户端计算设备102、103和服务器设备104)执行的方法200和400的步骤，但这仅出于说明目的。

本文描述的示例方法的各种操作可以至少部分地由临时地被配置(例如，通过软件)或永久地被配置为执行相关操作的一个或多个处理器执行。无论是临时地被配置还是永久地被配置，这样的处理器都可以构成处理器实现的模块，这些模块进行操作以执行一个或多个操作或功能。在一些示例实施例中，本文所指的模块可以包括处理器实现的模块。

类似地，本文描述的方法或例程可以至少部分地由处理器实现。例如，方法的至少一些操作可以由一个或多个处理器或处理器实现的硬件模块执行。某些操作的执行可以分布在一个或多个处理器之间，该一个或多个处理器不仅驻留在单个计算机内，而且可以跨多个计算机部署。在一些示例实施例中，一个或多个处理器可以位于单个位置(例如，在家庭环境、办公室环境内或作为服务器场)，而在其他实施例中，处理器可以分布在多个位置。

一个或多个处理器还可以进行操作以支持在“云计算”环境中执行相关操作或作为SaaS。例如，如上所述，至少一些操作可以由一组计算机(作为包括处理器的机器的示例)执行，这些操作可以通过网络(例如，互联网)以及通过一个或多个适当的接口(例如，API)来访问。

再另外，附图仅出于说明的目的描绘了示例环境的一些实施例。本领域技术人员将从下面的讨论中容易理解，在不脱离本文描述的原理的情况下，可以采用本文所示的结构和方法的替代实施例。

在阅读了本公开之后，本领域技术人员将理解用于通过本文中公开的原理生成导航路线的再另外的替代结构和功能设计。因此，尽管已经示出和描述了特定的实施例和应用，但是应当理解，所公开的实施例不限于本文所公开的精确构造和组件。在不脱离所附权利要求书所限定的精神和范围的情况下，可以对本文公开的方法和装置的布置、操作和细节进行对本领域技术人员而言显而易见的各种修改、改变和变化。