CN112449676A - 根据计算的参数之间的折衷生成导航路线并识别拼车选项 - Google Patents

Abstract

一种用于生成导航路线的技术，该技术包括获得指示用户先前经过的各个起始位置和目的地之间的多条路线的路线数据(702)。该技术还包括使用地图数据识别多条路线内的第一类型的路段和至少一种其他类型的路段，以生成路段数据(704)，以及使用路线数据和路段数据确定用于在用户选择导航路线时测量第一类型路线的路段的属性和至少一种其他类型的路段的属性之间的折衷的定量度量(706)。在接收到对起始位置和目的地的指示之后(708)，该技术包括为用户生成起始位置和目的地之间的导航路线，包括应用定量度量来约束对路段的选择(710)。

Description

根据计算的参数之间的折衷生成导航路线并识别拼车选项

技术领域

本公开涉及导航系统，并且更具体地，涉及计算和应用指示用户导航决策中参数之间的折衷(trade-off)的定量度量。

背景技术

此处提供的背景描述是为了总体呈现本公开的情境。在本背景技术部分中描述的程度上，当前提及的发明人的工作，以及在提交时可能不符合现有技术的描述的方面，既不明确地也不隐含地被认为是针对本公开的现有技术。

如今，诸如个人计算机、平板、手机、专用导航仪等的电子设备提供地理区域的数字地图(map)和用于在地理位置之间导航的逐步方向。导航服务可以经由专用软件应用(诸如地图(mapping)应用和导航应用)以及经由通用软件应用(诸如web浏览器)提供导航方向，并且在一些情况下还可以提供相关的数字地图。除了驾驶方向，导航服务还可以提供步行方向、公共交通方向、骑自行车方向等。

导航服务通常从用户接收对导航方向的请求，并根据诸如时间或距离等因素的某个预定顺序生成导航路线。更具体地，导航服务可以生成几个候选导航路线，并以升序的总距离或总行驶时间呈现这些候选。导航服务器试图针对时间优化导航路线(即，生成需要最少时间量的路线)，或者针对距离优化导航路线(即，识别可用的最短路线)。在一些情况下，导航服务生成候选导航路线，并提供用于识别具有与特定标准相匹配的路段的导航路线的额外控制(例如，收费)。这些指示是二进制的，因此仅指示导航路线或该路线的部分是否满足该标准。

然而，导航服务不生成以定量方式反映用户过去的导航路线选择中的导航路线的参数或其他导航决策中的参数之间的关系的导航路线。

发明内容

一般地，本公开的系统被配置为为用户生成用于测量一种类型(“目标类型”)的路段和另一种类型的路段之间的折衷的定量度量，并且在生成导航方向(更具体地，从起始位置到目的地的导航路线)时应用该定量度量。为了生成定量度量，系统可以处理对用户经过(traverse)的过去导航路线的指示。例如，对于某个起始位置和某个目的地，系统可以确定用户遵循具有目标类型的N公里路段的导航路线，并且不具有这种类型的任何路段的备选导航路线将需要额外的M分钟。系统可以使用这个实例作为用户在M分钟的时间内选择目标类型的N公里路段的折衷的示例。使用相似计算的多个实例，系统可以生成定量度量来预测用户将来可能选择的折衷。然后，系统可以将该度量用作为在为用户或自动车辆生成导航路线时的约束，从而更好地针对一组需求优化这些路线。

系统可以向设备输出导航路线中的一个或多个，以显示给用户。在其他实现方式中，系统可以向自动车辆的控制器提供导航路线。

在一些实现方式中，系统可以根据其他情境信号来动态调整定量度量。例如，系统可以基于定量度量来确定时间约束(例如，某个已知时间在目的地的约会)可以超过或覆盖该约束。

在一些实现方式中，系统可以使用用户经过的多个导航路径的指示、哪些路段对应于用户潜在地应用折衷的类型的指示以及潜在的其他信号来训练机器学习模型。作为更具体的示例，当训练机器学习模型时，系统可以应用这样的特征，其中选择目标函数的路段是减少行驶时间的函数。

系统可以应用本公开的技术的目标类型的一个特定示例是路段的难度级别。系统可以使用诸如来自驾驶员的反馈、一段时间内报告的事故数量、对道路几何形状(例如急转弯、两条以上道路的交叉口、窄车道)的分析、对道路类型(例如泥路)的指示等的信号来估计难度级别。目标类型的另一个示例是由经过路段的车辆生成的估计的燃料排放，例如，其可以与路段的路面类型或道路速度相关。目标类型的另一个示例是需要付费才能经过该路段。在这种情况下，系统可以确定当备选方案可用时路段的额外单位时间(例如，一分钟)的大致财务成本，并确定用户的定量度量是高于还是低于该成本。

此外，本公开的系统可以实现额外的特征，诸如基于目标类型的路段提供导航路线的累积评估。例如，系统可以通过估计与导航路线相关联的一个或多个通行费(toll)、导航路线的总难度或燃料的总成本来提供导航路线的总财务成本。例如，系统可以使用这些累积评估来对候选导航路线进行排序。作为这种特征的另一个示例，系统可以自动地识别拼车充分降低导航路线的总财务成本的情况，系统根据为用户计算的定量度量原本不会向用户推荐该导航路线。例如，使用高占用率车辆(high-occupancy vehicle，HOV)车道可以减少时间和/或成本。

本公开的技术的一个示例实施例是一种用于生成导航路线的方法，该方法可以由诸如导航服务器的一个或多个处理器的处理硬件来执行。该方法包括获得指示用户先前经过的各个起始位置和目的地之间的多条路线的路线数据；使用地图数据识别多条路线内的第一类型的路段和至少一种其他类型的路段，以生成路段数据；以及使用路线数据和路段数据确定用于在用户选择导航路线时测量第一类型路线的路段属性和至少一种其他类型的路段属性之间的折衷的定量度量。当接收到对起始位置和目的地的指示时，该方法包括为用户生成起始位置和目的地之间的导航路线，包括应用定量度量来约束对路段的选择。

另一示例实施例是包括一个或多个处理器和计算机可读存储器的系统。存储器存储指令，当指令被一个或多个处理器执行时，使得系统获得指示用户先前经过的各个起始位置和目的地之间的多条路线的路线数据。指令还使得系统使用地图数据识别多条路线内的第一类型的路段和至少一种其他类型的路段，以生成路段数据，并且使用路线数据和路段数据来确定用于在用户选择导航路线时测量第一类型路线的路段和至少一种其他类型的路段之间的折衷的定量度量。当接收到对起始位置和目的地的指示时，指令使系统为用户生成起始位置和目的地之间的导航路线，包括应用定量度量来约束对路段的选择。

附图说明

图1是其中可以实现根据参数之间的折衷来生成导航路线的技术的系统的框图；

图2A是其中折衷控制器被配置为对候选导航路线进行排序的子系统的框图，该子系统可以作为图1的系统的组件来操作；

图2B是其中包括折衷控制器的路线生成器生成排序后的候选导航路线的子系统的框图，该子系统可以作为图1的系统的组件来操作；

图3是根据指示参数之间的折衷的一个或多个定量度量、生成排序后的候选导航路线的示例方法的流程图，其可以在图1的系统中实现；

图4示意性地示出了为了计算总通行费而对导航路线的分段，其是图1的系统可以实现的；

图5是图1的系统可以利用以生成指示参数之间的折衷的定量度量的示例机器学习模型的框图；

图6A是图1所示的地理应用可以生成以提供某条导航路线的通行费估计的示例用户接口屏幕；

图6B是图1所示的地理应用可以生成以为多个备选导航路线提供相应通行费估计的示例用户接口屏幕；

图6C是图1所示的地理应用可以生成以提供某条导航路线的通行费估计的另一示例用户接口屏幕；

图6D是图1所示的地理应用可以生成以为多个备选导航路线提供相应通行费估计的示例用户接口屏幕；

图6E是图1所示的地理应用可以生成以提供通行费和高占用率车辆(HOV)支付信息的示例用户接口屏幕；

图6F是图1所示的地理应用可以向用户提供以用于调整折衷设置的示例用户接口屏幕；

图7是使用指示参数之间的折衷的定量度量来生成起始位置和目的地之间的导航路线的示例方法的流程图，其可以在图1的系统中实现；

图8A是用于基于单驾驶员和HOV场景之间的成本差生成用于潜在拼车匹配的信号的示例方法的流程图，其可以在图1的系统中实现；

图8B示意性地示出了包括涉及拼车的绕行的路线选项；

图8C是根据图8B所示的选项估计绕行成本的示例方法的流程图，其实图1的系统可以实现的；以及

图9是生成与收费道路相关的提醒的示例方法的流程图，其可以在图1的系统中实现。

具体实施方式

本公开描述了用于计算和应用指示用户导航决策中的参数之间的折衷的定量度量的技术，以及用于生成导航方向的其他技术。如下所述，定量度量可以指示地理服务应该如何考虑一个参数相对于另一个参数的重要性、生成由时间、距离、难度、成本等参数化的导航路线。地理服务可以自动地或根据明确的用户输入来确定该度量。

首先参考图1讨论可以实现这些技术的示例通信系统100，随后参考图2A和图2B讨论其中折衷控制器生成并对候选导航路线进行排序的示例子系统。

通信系统100包括客户端计算设备102，例如，该客户端计算设备102可以是个人计算机、诸如平板计算机或智能手机的便携式设备、可穿戴计算设备、专用汽车导航仪、嵌入车辆的头部单元中的设备等。通信系统100一般可以包括任何合适数量的客户端计算设备。

通信系统100还包括由地图和导航服务提供商操作的一个或多个地理数据服务器104。服务器104可以向客户端计算设备102和其他客户端设备提供地图数据和导航数据。通信系统100一般可以包括任何合适数量的、与运输相关的内容和/或数据库的提供商，诸如火车、公共汽车、渡轮等的调度和路由(routing)信息的提供商。

此外，通信系统100可以包括第三方道路信息提供商106以及支付系统108，第三方道路信息提供商106可以向服务器104提供特定位置的通行费信息(例如，各种车辆类型的费率、一天中的时间、一周中的各天、占用率级别)，服务器104可以与该支付系统108通信以便于通行费支付、检查支付状态、管理订阅等。

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

服务器104还耦合到路段属性数据库142，该路段属性数据库142为各种路段S₁、S₂等存储对特定属性的指示，诸如不同驾驶员基于个人经验报告的或基于事故报告的数量确定的难度级别。在一些实现方式中，路段属性数据库142存储特定路段的通行费信息。例如，数据库142中的记录可以指示经过路段S_i需要付费。取决于场景，记录可以为不同类型的车辆、一天中的时间、一周中的各天等指示不同的金额。记录还可以识别收取通行费的机构、支付的类型(例如，手动、电子、基于相机的)、HOV折扣的可用性等。此外，记录可以指示应用于计算的规则，如下面更详细讨论的。数据库142可以以任何合适的方式来界定路段，诸如通过收费站和/或自动收费器的位置、附近的道路入口或出口、全球定位系统(GPS)的坐标等。

此外，服务器104耦合到存储多个用户的匿名轨迹的过去路线数据库144，匿名轨迹中的每一个可以是由位置/时间元组组成的时间序列。在一些实现方式中，用户操作某些控件和/或安装某些应用来指示服务器104可以使用他或她的过去路线数据来确定用户关于导航的偏好，包括指示用户如何评估路段的参数之间的折衷的定量度量。

作为更具体的示例，数据库144中的数据可以指示用户沿着包括几个收费路段S_toll1、S_toll2、…S_{toll N}的导航路线在位置L₁和L₂之间行进，并且用户花费平均时间T来经过导航路线。使用该数据以及地图数据库140和可能的其他相关数据(例如，交通数据)源，地理数据服务器104可以确定L₁和L₂之间的备选导航路线不包括收费路段，但是平均需要不同的时间量T’来经过。地理数据服务器104相应地可以将总通行费与时间T和T’之间的差进行比较。

此外，在一些情况下，数据库144存储指示用户过去对导航路线的选择的更明确的信号。例如，用户可以请求到目的地的导航方向，从地理数据服务器104接收几个候选导航路线，使得一个候选导航路线包括通行费但需要更少的时间、而另一个候选导航路线不包括通行费但需要更多的时间，并且明确地从这些候选中选择导航路线。通常，用户可以选择结合他们明确请求和选择的导航路线或者与所请求的导航路线无关(例如，当用户选择共享他们的位置数据时)，以任何合适的格式向数据库144提供过去导航路线的指示。

用户偏好数据库146可以存储用户报告的额外偏好。例如，用户可以配置她的个人简档，以指示她偏好避免通行费。此外，在系统100的一些实现方式中，她还指定了服务器104基于其生成道路参数之间的折衷的定量度量的规则。例如，用户可以操作客户端计算设备102来明确地指定她愿意支付不超过X美元来节省每个N分钟的时间。

更具体地，客户端计算设备102可以包括处理硬件(诸如一个或多个处理器152、非暂时性存储器150(例如，硬盘、实现持久和/或非持久存储组件的闪存驱动器))、用户接口154(其可以包括诸如触摸屏、键盘、麦克风等输入设备的任何合适的组合以及输出设备(诸如屏幕、扬声器等))。存储器150存储实现地理应用160的指令，地理应用160被配置为从服务器104接收导航路线和其他导航数据，并经由用户接口154提供包括导航路线的导航方向。各种实现方式中的地理应用160还可以提供交互式数字地图、定位信息等。客户端计算设备102还可以包括各种传感器(未示出以避免混乱)，诸如检测客户端计算设备102的位置的全球定位系统(GPS)模块、确定客户端计算设备102的方向的罗盘、确定旋转和倾斜的陀螺仪、加速度计等。

在一些情景下，客户端设备102耦合到车辆的头部单元，以在所谓的投影模式下操作。更具体地，客户端设备102可以经由内置在头部单元中的触摸屏、车辆中的扬声器等提供输出，并且相应地经由触摸屏、内置在头部单元中的麦克风等接收输入。客户端设备102和头部单元可以经由短程有线或无线通信链路(诸如通用串行总线(USB)链路、

或另一种合适的无线个人区域网(WPAN)链路、

或另一种合适的无线局域网(WLAN)链路等)进行通信。

继续参考图1，服务器104实现众包(crowdsourcing)技术，并从驾驶员接收路段属性的指示。例如，车辆120A、120B、120C等的驾驶员可以使用便携式设备(例如，经由类似于地理应用160的地理应用124A、124B)或使用内置在相应车辆中的组件124C来报告他们遇到的通行费。更一般地，服务器104可以从任何合适的源(诸如第三方馈送、安装在道路上的传感器、处理由客户端设备或仪表板相机捕获的影像以识别路标或电子收费(ETC)设施的成像软件等)接收关于路段属性的信息。

服务器104、第三方道路信息提供商106和支付系统108可以经由网络110互连，例如，网络110可以是诸如互联网的广域网，并且包括有线和/或无线通信链路。客户端计算设备102也可以经由网络110访问服务器104，并且车辆120A、120B、120C和/或在这些车辆中操作的便携式设备可以经由网络110访问服务器104。

如图1所示，服务器104可以包括路由引擎170，路由引擎170包括参数估计模块172和折衷控制器174。在操作中，模块172为各种路段或包括路段的路径生成估计。例如，模块172可以估计经过与收费相关联的几个路段的财务成本，或者估计包括驾驶员过去报告有难度的几个路段的路线的总难度。路由引擎170使用折衷控制器174根据道路参数(例如，时间和难度、时间和成本)之间的关系来约束对导航路线的选择，从而为指定的起始位置和目的地生成导航路线。

为了更清楚，图2A和图2B示出了包括折衷控制器的子系统的几个示例实现方式。这些子系统的组件可以使用硬件、软件、固件或硬件、软件和固件的任何适当组合来实现。

首先参考图2A，子系统200包括耦合到路线生成器202A的折衷控制器204A和通行费估计模块206A。路线生成器202A和通行费估计模块206A可以分别作为折衷控制器174和参数估计模块172来操作，并且图2A所示的其他模块也可以作为图1的路由引擎170的组件来操作。如下文更详细讨论的，折衷控制器204A被配置为对路线生成器202A输出的候选导航路线进行排序。

具体地，路线生成器202A接收描述用户对导航方向的请求的信号，包括例如起始位置和目的地信号210、请求的时间212、拼车信息214等。路线生成器202A还接收不特定于用户的信号，诸如地图数据220、交通数据222、天气数据225、燃料价格数据226(在路线足够长而需要对油箱进行一次或多次补充的情况下)等。一般地，路线生成器202A可以使用更少的信号，或者相反，可以使用任意数量的额外的信号，诸如用户车辆的燃料状态、加油站的位置、燃料消耗等。折衷控制器204A接收与对导航方向的请求相关联的输入定时要求216(例如，“必须在下午3：00之前到达目的地”)，路线生成器202A输出的候选路线240，以及通行费估计模块206A基于候选路线240生成的估计242。此外，子系统200A可以利用用户偏好机器学习模型230来为用户估计一个或多个定量度量，诸如用于测量道路难度和时间之间的折衷或通行费金额和时间之间的折衷的定量度量。在该示例实现方式中，用户偏好机器学习模型230向折衷控制器204A提供一个或多个度量作为额外的输入232。折衷控制器204A基于候选路线240并根据用户度量232来生成排序后的候选路线250A。

在操作中，路线生成器202A可以生成信号210指定的起始位置和目的地之间的几条候选导航路线R₁、R₂、…R_N。为此，路线生成器202A可以应用任何合适的技术，以使用对(在地图数据220中提供的)真实地理的描述来识别位置之间的路径，并且例如，尝试在时间或距离方面优化候选导航路线R₁、R₂、…R_N。路线生成器202A可以考虑诸如交通(使用信号222)的实时因素，以专门针对请求的时间(信号212)优化路线。在一些实现方式中，路线生成器202A还应用燃料价格数据226和拼车信息214作为额外的权重来识别候选路线。

由用户偏好机器学习模型230输出的用户度量232可以指示针对另一参数(例如，时间)专门测量的某个参数(例如，路线难度、成本)的可能权重。因此，例如，机器学习模型230可以生成用户度量232，以指示用户愿意支付X美元来节省N分钟的时间。机器学习模型230可以基于与用户先前经过的导航路径相关的各种信号的集合来生成该信号，如下面参考图5更详细讨论的。可替代地，另一组件通过算法(例如，通过计算一定数量的通行费和相应的节省的分钟数之间的比率)生成输入232。作为又一替代，诸如地理应用160的软件应用可以基于用户输入生成用户度量232。

在一些实现方式中，模型230生成情境特定的度量的集合作为用户度量232的部分。例如，模型230可以生成当用户经过相对长的路径(例如，50英里或更长)时时间和成本之间的折衷的一个度量，以及当用户经过相对短的距离时时间和成本之间的折衷的另一个度量。对于某个示例用户来说，这些多个度量一方面可以更好地反映当行程时间长时减少成本的偏好，另一方面可以更好地反映当行程时间短时减少时间的偏好。作为另一示例，模型230可以生成当用户在白天驾驶时时间和路线难度之间的折衷的一个度量，以及当用户在夜间驾驶时时间和路线难度之间的折衷的另一个度量。例如，某个用户可能偏好在天黑时避免在容易发生事故的路段上驾驶，但同一用户不介意白天(或天空不阴时)在类似的路段上驾驶。

图2B示出了一般类似于子系统200A的子系统200B，但是在该实现方式中，路线生成器202B包括通行费估计模块206B和折衷控制器204B。路线生成器202B和通行费估计模块206AB可以分别作为折衷控制器174和参数估计模块172来操作，并且图2B所示的其他模块也可以作为图1的路由引擎170的组件来操作。与图2A的实现方式不同，折衷控制器204B和通行费估计模块206B作为路线生成器202B的组件来操作，以生成排序后的候选路线250B。换句话说，在该实现方式中，路线生成器202B使用折衷控制器204B的输出来选择候选路线250B并对候选路线250B排序。

在一些情况下，由于缺少用户的数据，模型230不能产生用户特定的度量232。在这些情况下，折衷控制器134A或134B可以使用其他用户的偏好来确定用户度量的初始值。例如，折衷控制器134A或134B可以确定对于某个起始位置和某个目的地，76％的用户偏好更快的路线而不是更便宜的路线，并且最初将度量232设置为该值。

现在参考图3，可以在地理数据服务器104或者另一合适的设备或设备组中实现示例方法300，该示例方法300用于根据指示参数之间的折衷的一个或多个定量度量来生成排序后的候选导航路线(为了方便，在下面参考地理数据服务器104讨论该方法)。方法300可以被实现为可由诸如一个或多个处理器的处理硬件执行的指令集。

在框302，地理数据服务器104接收对导航方向的请求。该请求可以以任何合适的格式(例如，兴趣点、地址、GPS坐标)指示起始位置和目的地。在一些场景中，当用户明确地或隐含地(例如，通过选择交互式地图上的兴趣点)提交对导航方向的初始请求时，客户端设备102生成对导航方向的请求。在其他场景下，当客户端计算设备102遵循先前接收到的导航方向时，客户端计算设备102周期性地或响应于事件(诸如由于事故而快速减速)，生成对导航方向的更新后的请求。此外，在一些情况下，客户端设备102的用户可以选择向路线添加另一站或以其他方式修改路线，并且客户端设备102相应地可以向地理数据服务器104发送包括新参数的更新后的请求。更进一步地，用户可以选择修改一个或多个折衷(例如，因为天已经黑了，所以随着时间的推移增加安全路线的重要性)，如参考图6F更详细讨论的。

接下来，在框304，地理数据服务器104接收定时要求，诸如所需的到达时间，和/或其他情境信号，诸如，例如拼车伙伴的潜在存在。

接下来，在框306，地理数据服务器104获得路线参数之间的折衷的一个或多个用户特定的定量度量。如上所述，该定量度量可以测量诸如时间的一个参数如何与诸如成本的另一个参数相关。换句话说，地理数据服务器104可以通过根据一个参数表达另一个参数的函数来约束对导航路线的选择。然后，在框308，地理数据服务器104根据一个或多个度量来生成候选路线并对候选路线进行排序。然后，地理数据服务器104可以将排序后的候选路线发送到诸如客户端计算设备102的设备，以例如由地理应用160显示给用户。

图4示意性地示出了为了计算总通行费、而对在起始位置402和目的地404之间的导航路线406A的分段，其是图1的参数估计模块172或另一合适的模块可以实现的。需要一定量的时间T₁来经过导航路线406A，并且导航路线406A包括与通行费相关联的几个部分，特别是部分410、412和414。图4还示出了相同起始位置402和相同目的地404之间的备选路线406B。备选路线406B包括与收费不相关联的部分，但是平均需要更多的时间(T₂)来经过。

在一些场景中，服务器104使用地图数据库140和路段属性数据库142中的信息生成对导航路线406A和406的描述。当过去路线数据144包括用户经过导航路线406A和/或导航路线406B的指示时，服务器104可以比较时间T₁和T₂，以及导航路线406A和406B的相应通行费支付(如果有的话)。当计算测量用户的成本和时间之间的折衷的定量度量时，服务器104可以使用这些差作为数据点之一。

为了确定分段410、412和414的总成本，估计模块172可以选择适用的定价模型。作为一个示例，估计模块172可以应用固定通行费模型，根据该模型，存在与分段410、412和414中的每一个相关联的相应固定成本。当估计模块172应用递增通行费模型时，用户预计要支付的总金额根据用户在道路上花费的时间和/或驾驶员经过的连续路段的数量而变化。因此，例如，经过包括路段410、412和414的序列的整个路线406A的成本会高于单独经过路段410、412和414中的每一个的成本的总和。

此外，在一些情况下，估计模块172可以应用动态通行费模型，根据该模型，成本取决于特定时间的交通条件。作为更具体的示例，例如，路段410的通行费可以随着交通量的增加而增加，并且相应地随着交通量的减少而减少。此外，通行费可以取决于用户的车辆中是否有多个乘客而改变(例如，当用户拼车时通行费减少)。

更进一步地，估计模块172可以根据额外的信号来估计通行费金额，额外的信号诸如车辆的类型(例如，对于不同汽车大小有不同的金额，对于混合动力或电动汽车有更低的通行费或甚至没有通行费，对于摩托车有更低的通行费或没有通行费，对于卡车有更高的通行费)；一些用户可能拥有的支付服务的特殊许可和/或订阅；一周中的几天(例如，周末有较低的通行费)、一天中的时间、诸如假日的特殊日期等。

在任何情况下，当导航路线406A对应于用户对导航方向的请求时，图4的示例中的估计模块172可以生成对导航路线406A的通行费支付的估计，并且地理应用可以经由用户接口154(参见图6A)显示通行费的估计的总数。另一方面，当导航路线406A对应于用户先前经过的路线时，估计模块172类似地可以估计通行费的总额(参见下面的图5)。

尽管图4的场景仅涉及在道路上收取的通行费，但是一般地，估计模块172可以生成对其他行驶模式以及多模式导航路线的估计。这种多模式导航方向的一个示例包括汽车经过的路段和渡轮运输车辆的其他路段。其他示例可以包括导航方向，根据该导航方向，客户端设备102的用户使用公共交通经过路线的部分并步行经过其他部分，驾驶通过路线的一部分并使用公共交通经过另一部分，骑自行车走过路线的一部分并步行走过另一部分等。在这些情况下，估计模块172可以应用上述模型的任何合适的组合。

现在参考图5，在一些实现方式中，路由引擎170使用各种输入信号、相应的标签、用户反馈数据等来训练用户偏好机器学习模型230(其可以向如图2A和图2B所示的折衷控制器提供用户度量)。路由引擎170可以从过去路线数据库144接收各种输入作为训练数据，并且经由特征提取函数502将该数据应用于模型230。

例如，特征提取函数502可以接收位置之间的路线(信号510)、对用户经过路线的时间的指示(信号512)、对路线的总成本的估计(信号514)、指示当经过路线时用户是否使用HOV车道、HOV定价等的拼车信息(信号520)、一天中用户经过路线的时间(信号522)、用户经过路线时的天气(信号524)等。特征提取函数502可以接收信号510、512、520、522、524等作为描述用户经过的过去路线的数据的部分。为了生成估计的成本信号514，参数估计模块172可以应用合适的通行费计算技术，诸如上面参考图4讨论的那些技术。在其他场景下，成本信号514对应于用户报告的金额。更一般地，特征提取函数502可以接收与路线或行进发生的情境直接相关的任意数量的参数。

为了更有效地训练模型230(即，更快地收敛到可靠的预测值)，示例实现方式中的特征提取函数502生成特征向量504，该特征向量504考虑时间参数和成本参数之间的关系(而不是单独考虑时间参数和成本参数，或者除了单独考虑时间参数和成本参数之外，还考虑时间参数和成本参数之间的关系)。因此，特征提取函数502可以被视为使用函数F(成本、时间)来训练模型230。该特定示例中的特征向量504是包括例如以下各项作为元素的矢量：起始位置和目的地(L₁、L₂)元组、与使用包括通行费的导航路线在L₁和L₂之间行进相关联的时间、与使用包括通行费的导航路线在L₁和L₂之间行进相关联的成本、与使用不包括通行费的导航路线在L₁和L₂之间行进相关联的时间、与使用不包括通行费的导航路线在L₁和L₂之间行进相关联的成本，以及情境信号(诸如行进的时间)。特征向量504可以包括标签，诸如用户是选择收费导航路线还是免费路线的指示。

路由引擎170可以使用特征向量504的多个实例以及地图数据220和/或所有用户共有的其他数据来训练模型230。路由引擎170可以生成定量度量232来测量时间和成本之间的折衷。模型230还可以生成用户将来将从几个候选路线中选择哪个导航路线的预测530。反馈处理540可以(例如，通过处理用户在预测之后选择哪个选项的指示)评估预测530的质量，并且向特征提取函数502提供反馈数据以继续训练模型230。

在一些实现方式中，模型230还基于用户的过去路线数据来估计用户在未来某个时间段内可能支付的通行费金额。地理数据服务器104可以自动地将该估计与从支付系统108接收到的通行(pass)或订购的价格进行比较，并且在一些情况下生成供用户订购通行费支付计划的建议。更一般地，模型230可以生成预测，基于该预测，服务器104可以为用户确定收费道路的最佳安排。

图6A是地理应用160可以生成以提供导航路线的通行费估计的示例用户接口屏幕602。如图6A所示，用户接口屏幕602包括驾驶员在前往目的地的途中预计应支付的总估计的通行费的指示。地理数据服务器104不是仅提供导航路线包括通行费的指示，而是(例如，使用参考图4所讨论的技术)估计路线的总成本，并将该估计提供给地理数据服务器104，以经由用户接口154显示。

图6B的示例用户接口屏幕604包括多个备选导航路线的相应通行费估计。如图6B所示，第三候选导航路线包括车辆中有三个或更多个人的HOV选项。图6C示出了地理应用160可以生成以提供特定导航路线的通行费估计的另一个示例用户接口屏幕606，而图6D是地理应用160可以生成以提供多个备选导航路线的相应通行费估计的示例用户接口屏幕608。图6E是地理应用160可以生成以提供通行费和高占用率车辆(HOV)支付信息的示例用户接口屏幕610。

参考图6F，地理应用160可以生成包括交互式控件620-626的用户接口屏幕612，经由交互式控件620-626，用户可以指定他或她关于折衷的偏好。在该示例实现方式中，用户可以调整时间和通行费的成本、时间和距离、时间和碳排放(carbon footprint)、时间和在恶劣天气条件下驾驶之间的折衷的数字表示。更一般地，地理应用160可以为路段的任何参数对(或三个或更多个参数的组)提供折衷控件。在该示例实现方式中，用户可以旋转虚拟旋钮来指定一个参数相对于另一个参数的重要性。图6所示场景中的用户操作虚拟旋钮620来指定时间比通行费重要的多。用户可以逆时针旋转虚拟旋钮620以使时间比通行费更重要，或者相反地，顺时针旋转虚拟旋钮620以指定时间与通行费同等重要或者通行费比时间更重要。虚拟旋钮620-626一般可以允许用户以任何期望的粒度指定任意数量的中间值。

当地理应用160向用户提供用户接口屏幕612时，地理应用160可以基于地理数据服务器104使用用户经过的过去导航路线的指示而生成的定量度量来获得虚拟旋钮620-626中的每一个的初始设置。例如，折衷控制器204A可以生成一个或多个度量232，并将这些度量提供给在客户端设备102上执行的地理应用160。然后，地理应用160可以以对应于的这些度量的初始设置来显示旋钮620-626。用户可以接受这些设置或手动地修改设置中的一个或多个，从而调整相应折衷的定量度量。然后，地理应用160可以将新的定量度量发送到地理数据服务器104。

地理应用160可以在用户提交对导航方向的请求之前或者结合特定导航路线来提供用户接口屏幕612。在后一种情况下，地理应用160可以根据所请求的情境确定显示旋钮620-626中的哪一个，以及使用哪个初始设置。如上所述，根据路线的长度、一天中的时间、一周中的某天、汽车中乘客的数量、用户的日历是否包括目的地位置的事件等，折衷控制器134可以在相同参数对之间应用不同的折衷度量。

接下来，参考图7-图9讨论地理数据服务器104和/或地理应用160可以实现的几个示例方法。

首先参考图7，路由引擎130可以实现示例方法700，方法700用于使用指示参数之间的折衷的定量度量来生成起始位置和目的地之间的导航路线。

在框702，路由引擎130获得指示用户先前经过的路线的路线数据。为此，路由引擎可以使用过去路线数据库144。对于某条路线，路线数据可以指定起始位置、目的地、起始位置和目的地之间的路段的序列等。在一些情况下，路线数据还包括对与路线相关联的情境的指示，例如，一天中用户沿着路线行进的时间、一周中的某天、乘客的存在或不存在等。

接下来，在框704，路由引擎130识别特定类型的路段以及至少一种其他类型的路段。例如，路由引擎130可以识别由于几何形状(例如，车道比平均值窄一定百分比、道路曲率高于某个阈值、街道在交叉路口处交汇的角度小于某个阈值)而困难的路段以及不困难的车道，以分别定义第一类型和另一类型。作为另一示例，路由引擎130可以识别与通行费相关联的路段以及免费的路段。

在框706，路由引擎130可以使用路线数据和路段数据来生成选择这些不同类型的路段之间的折衷的定量度量。折衷可以对应于最终生成的导航路线的属性，诸如总时间、成本、难度等。作为更具体的示例，折衷的定量度量可以是用户为了节省时间而倾向于接受的路线难度的函数F₁(F₁(难度，时间))。作为另一示例，折衷的定量度量可以是用户愿意支付以类似地减少行进时间的成本的函数F₂(F₂(难度，时间))。路由引擎130可以实现诸如参考图5讨论的机器学习技术、合适的算法或显式用户输入来生成定量度量。更一般地，定量度量可以描述导航路线的任何属性对之间的关系。

接下来，在框708，路由引擎130接收对从某个起始位置到目的地的导航指令的请求。在各种场景下，请求可以包括额外的信号，例如，诸如定时限制。然后，路由引擎130在框710生成导航路线。路由引擎130应用定量度量来约束对导航路线的选择。例如，如以上参考图2A和图2B所讨论的，路由引擎可以生成候选导航路线，并使用折衷控制器来根据定量度量生成对候选导航路线的排序，或者使用折衷控制器来应用定量度量和其他信号，以生成候选导航路线。

现在参考图8A，地理数据服务器104可以实现方法800，方法800用于基于单驾驶员和HOV场景之间的成本差生成潜在拼车匹配的信号。方法800开始于框802，其中服务器104生成从起始位置到目的地的导航路线。然后，在框804，服务器104根据用户独自驾驶的假设，计算导航路线的总成本。在框806，服务器104确定导航路线是否包括HOV车道，如果包括，流程进行到框808。否则，流程直接进行到框816。

在框808，服务器104计算导航路线的总成本，这次是根据用户的车辆成为高占用率车辆的假设。在框810，服务器104计算在框804和框808计算出的成本估计之间的差。如果服务器104在框812确定差超过某个阈值，则流程进行到框814；否则，流程进行到框816。在框814，服务器104生成用于潜在拼车匹配的信号。例如，服务器104可以为用户生成建议，该建议指示在用户拼车的情况下路线的成本可以降低的金额。在一些实现方式中，服务器104在框812可以应用指示几个参数之间的关系的定量度量，而不是简单地依赖于成本差。

对于各种候选导航路线和/或各种候选拼车伙伴，服务器104可以多次执行方法800。因此，例如，服务器104可以识别将涉及拼车并且在时间或成本方面相对于单驾驶员路线有利的两条或更多条候选路线。然后，服务器104可以从这些候选中选择建议的导航路线。

接下来，参考图8B的几个路线选项的示意性表示和图8C，讨论根据时间或距离估计绕行(detour)成本的示例方法。根据图8B的示例方案830，用户可以直接(沿着路线R_D)或者经由一个或多个上下车位置间接地(沿着路线R_I)在起点832和目的地834之间行进。在该示例中，用户可以从起点832行进到上车位置842以搭载乘客，在下车位置844放下乘客，并继续前进到目的地834。更一般地，间接路线R_I可以包括任何合适数量的上车位置和下车位置。

对于直接路线R_D和间接路线R_I中的每一个，路由引擎170可以确定起点832和目的地834之间的距离、起点832和目的地834之间的行进时间、起点832和目的地834之间的行进的成本等中的一个或多个。路由引擎170可以使用这些估计来评估直接路线和涉及拼车的间接路线之间的折衷。

参考图8C，路由引擎170可以将示例方法850实现为可由诸如一个或多个处理器的处理硬件执行的指令集。为了方便起见，下面参考地理数据服务器104，更具体地说，参考路由引擎170来讨论该方法。

方法850开始于框852，其中路由引擎170接收起始位置(或起点)、目的地、至少一个上车位置和至少一个下车位置的指示。例如，路由引擎170可以接收地址、坐标或位置832、834、842和844的任何其他合适的指示。路由引擎170一般可以从任何合适的源(诸如用户可以经由其请求乘车的共乘(rideshare)服务)接收位置842和844的指示。作为一个这样的示例，独立于路由引擎170操作的共乘服务可以经由适当的API向路由引擎170提供对于在特定的时间段内为在上车位置842和下车位置844之间的行程找到共乘匹配的请求。路由引擎170可以确定在位置832和834之间行进的用户是否已经指示他或她希望共乘，然后如上所述地确定与经由位置842和844的绕行相关联的折衷。在一些实现方式中，只有当驾驶员和潜在的共乘同伴在社交图上的一定相互距离内时，路由引擎170才执行该分析。

作为另一示例，路由引擎170可以确定社交图中具有一定接近度的两个用户将在彼此的某个时间段内从接近的起始位置行进到接近的目的地。为此，路由引擎170检查这两个用户是否已经指示他们愿意拼车。

作为更具体的示例，计划从起点832行进到目的地834的用户可以配置他或她的简档以指示对潜在拼车匹配的偏好。回头参考图6F，地理应用160可以向用户呈现一般类似于虚拟旋钮620、622等的界面，以指定通行费和拼车之间的折衷。因此，例如，用户可以指示对单独乘坐的一般偏好，其中当相对于单独乘坐节省至少30％的金额时，拼车成为可接受的选择。在另一实现方式中，用户简单地指示他或她是否愿意考虑拼车。此外，用户可以在社交图上设置对共乘同伴的接近度的限制。

在一个示例实现方式中，在框854，路由引擎170估计起点和目的地之间的直接行进时间T_D。接下来，在框856，路由引擎170估计起点和目的地之间经由上车位置和下车位置的间接行进时间T_I。在另一个实现方式中，路由引擎170估计直接行进距离D_D和间接行进距离D_I，而不是估计行进时间，或者除了行进时间之外，还估计直接行进距离D_D和间接行进距离D_I。更一般地，路由引擎170可以生成用于比较直接路线R_D和间接路线R_I的任何合适的定量度量。

在框858，路由引擎170使用在框854和框856确定的估计来确定经由上车位置和下车位置的绕行的成本C_DETOUR。在一个示例实现方式中，例如，路由引擎170计算T_D和T_I之间或D_D和D_I之间的差和/或比率。在另一示例实现方式中，路由引擎170计算T_D和T_I之间、D_D和D_I之间的比率等。为了在用户拼车时计算通行费的成本，路由引擎170可以应用不同于适合于单个驾驶员的模型的模型。

在任一情况下，然后，路由引擎170可以使用所确定的成本C_DETOUR来确定地理数据服务器104是否应该生成用于潜在拼车匹配的信号。在路由引擎170生成该信号的那些场景中，地理数据服务器104可以向用户提供潜在拼车同伴的指示。在一些实现方式中，路由引擎170还自动地为潜在拼车同伴生成通知，并且例如，用户可以经由地理应用160请求路由引擎170将这些通知发送给所识别的潜在拼车同伴。

图9是地理应用160可以实现以生成与收费道路相关的提醒的示例方法900的流程图。在框902，地理应用160可以确定用户经过了与收费系统相关联的路段。例如，客户端计算设备102的用户可以操作某些控件来允许地理应用160确定用户的当前位置。作为更具体的示例，地理应用160可以从服务器104接收导航指令，并且在交互式数字地图上显示导航路线的同时，确定用户已经到达与通行费相关联的路段。

在框904，地理应用160可以生成经过收费路段的时间戳记录。地理应用160可以将记录存储在存储器150中。在框906，地理应用160还可以装备(arm)定时器(例如，一小时、三小时、十小时)来生成支付通行费的提醒。例如，地理应用160可以基于一天中的时间来调整定时器周期，以防止深夜或清晨通知。在框908，地理应用160检测定时器期满，并且在框910，提供支付通行费的提醒。

可替代地，地理应用160可以经由网络110自动地联系支付系统108，并以电子方式提交支付。地理应用160可以实时地(即，例如，当用户的车辆经过收费路段时或根据固定时间表)联系支付系统108。

其他考虑

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

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

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

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

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

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

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

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

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

Claims (15)

1.一种用于生成导航路线的方法，所述方法包括：

通过处理硬件获得指示用户先前经过的各个起始位置和目的地之间的多条路线的路线数据；

由处理硬件使用地图数据识别所述多条路线内的第一类型的路段和至少一种其他类型的路段，以生成路段数据；

由处理硬件使用所述路线数据和所述路段数据来确定用于在由用户选择导航路线时测量第一类型路线的路段的第一属性和所述至少一种其他类型的路段的第二属性之间的折衷的定量度量；

由处理硬件接收对起始位置和目的地的指示；以及

由处理硬件为用户生成所述起始位置和所述目的地之间的导航路线，包括应用所述定量度量来约束对路段的选择。

2.根据权利要求1所述的方法，其中，确定所述定量度量包括确定用户按照第一路线在位置对之间行进的时间量不同于用户按照第二路线在所述位置对之间行进的时间量，其中，所述第一路线包括所述第一类型的路段，并且所述第二路线不包括所述第二类型的路段。

3.根据权利要求1或2所述的方法，还包括：

由处理硬件接收指示用户必须到达所述目的地的时间的时间约束参数；

其中，生成所述导航路线包括应用所述时间约束参数来进一步约束对路段的选择。

4.根据前述权利要求中任一项所述的方法，还包括：

由处理硬件接收指示在所述起始位置和所述目的地之间拼车对于用户是否可用的拼车参数；

其中，生成所述导航路线包括应用所述拼车参数来进一步约束对路段的选择。

5.根据前述权利要求中任一项所述的方法，还包括：

由处理硬件接收指示用户将在所述起始位置和所述目的地之间行进的时间的行进时间参数；

其中，生成所述导航路线包括应用所述行进时间参数来进一步约束对路段的选择。

6.根据前述权利要求中任一项所述的方法，还包括：

由处理硬件使用所述路线数据和所述路段数据来训练机器学习模型，所述机器学习模型被配置为生成指定位置之间的候选路线。

7.根据前述权利要求中任一项所述的方法，其中，确定所述定量度量包括：

经由计算设备的用户接口提供用于指定所述第一类型的路段和所述至少一种其他类型的路段之间的折衷的交互式控件；以及

经由用户接口中提供的所述交互式控件接收所述定量度量。

8.根据前述权利要求中任一项所述的方法，还包括：

响应于确定在没有另外数据的情况下所述路线数据不足以确定所述定量度量，确定所述定量度量还使用对于所述起始位置和所述目的地之间的路线的、关于所述第一属性和所述第二属性的其他用户偏好的指示。

9.一种计算系统，包括：

一个或多个处理器；以及

计算机可读存储器，其上存储指令，当由一个或多个处理器执行所述指令时，所述指令使得所述计算系统：

获得指示用户先前经过的各个起始位置和目的地之间的多条路线的路线数据，

使用地图数据识别多条路线内的第一类型的路段和至少一种其他类型的路段，以生成路段数据，

使用所述路线数据和所述路段数据来确定用于在用户选择导航路线时测量第一类型路线的路段的第一属性和所述至少一种其他类型的路段的第二属性之间的折衷的定量度量，

接收对起始位置和目的地的指示，以及

为用户生成所述起始位置和所述目的地之间的导航路线，包括应用所述定量度量来约束对路段的选择。

10.根据权利要求9所述的计算系统，其中，为了确定所述定量度量，所述指令使得所述系统确定用户按照第一路线在位置对之间行进的时间量不同于用户按照第二路线在所述位置对之间行进的时间量，其中，所述第一路线包括所述第一类型的路段，并且所述第二路线不包括所述第二类型的路段。

11.根据权利要求8或9所述的计算系统，其中，所述指令还使得所述系统：

接收指示用户必须到达所述目的地的时间的时间约束参数，以及

为了生成所述导航路线，所述指令使得所述系统应用所述时间约束参数来进一步约束对路段的选择。

12.根据权利要求9-11中任一项所述的计算系统，其中，所述指令使得所述系统：

接收指示在所述起始位置和所述目的地之间拼车对于用户是否可用的拼车参数，以及

其中，为了生成所述导航路线，所述指令使得所述系统应用所述拼车参数来进一步约束对路段的选择。

13.根据权利要求9-12中任一项所述的计算系统，其中，所述指令还使得所述系统：

接收指示用户将在所述起始位置和所述目的地之间行进的时间的行进时间参数，

其中，为了生成所述导航路线，所述指令应用所述行进时间参数来进一步约束对路段的选择。

14.根据权利要求9-13中任一项所述的计算系统，其中，所述指令还使得所述系统：

使用所述路线数据和所述路段数据训练机器学习模型，所述机器学习模型被配置为生成指定位置之间的候选路线。

15.根据权利要求9-14中任一项所述的计算系统，其中，为了确定所述定量度量，所述指令使得所述系统：

经由计算设备的用户接口提供用于指定所述第一类型的路段和所述至少一种其他类型的路段之间的折衷的交互式控件；以及

通过用户接口中提供的所述交互式控件接收所述定量度量。

Images