在路线规划中使用路线偏好而提高的用户效率的制作方法
路线规划应用通常用于向用户提供感兴趣点的方向，诸如特定建筑物、地址、地理坐标等。在示例场景中，用户提供至少具有开始位置和结束位置(例如，开始和结束地址)的路线规划应用。路线规划应用可以分析道路和交叉点的表示，以输出行进路线。常规的路线生成算法试图最小化或优化以下各项之一：在提供给用户的路线中的总行进距离或总行进时间。
现代路线规划应用是围绕恒定性和普遍性的假定而构建的，使得提供给用户的路线不能针对用户偏好进行优化。虽然有些具有基本的可配置性，但是它们无法考虑偏好上的折中，用户可能考虑该折中以达到最佳路线。这种折中的一个示例是，当路线比使用主道路的备选路线足够优选时，通常偏好主道路的驾驶员可能愿意采取该路线中的边道而不是主道路。使用常规方法，使用户实现可选路线需要大量的时间和资源投入，诸如研究道路状况和手动设置路线路点(waypoint)。
技术实现要素：
提供本“发明内容”是为了以简化的形式介绍一些概念，这些概念将在下面的“具体实施方式”中进一步描述。本“发明内容”不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。
本公开的各方面涉及在路线规划中使用路线偏好来提高用户效率。根据本公开的实现，针对各个用户跟踪路线偏好。基于路线制订请求生成路线。偏好权重对应于机器学习模型，机器学习模型基于由一个或多个传感器与用户相关联地提供的传感器数据。基于偏好权重确定路线的路线得分，并且基于路线得分向用户提供建议路线。
在另外的方面，路线可以由路线分量组成。在生成路线得分时，可以为路线分量确定路线偏好子得分。路线偏好子得分可以被平均或以其他方式组合以形成路线得分。在一些情况下，通过预测用户将穿越路线分量的估计时间来确定路线偏好子得分。可以利用估计时间来更准确地确定路线偏好子得分，从而提高路线得分的准确性。
在本公开的另外的方面，基于路线上的估计行进时间、参考路线的距离或其组合来选择参考路线。在一些情况下，参考路线基于参考路线具有响应于路线制订请求而生成的路线中的路线上的最低估计行进时间而被选择。将建议路线与参考路线进行比较，可以基于比较将建议路线提供给用户。在某些方面，基于建议路线上的估计行进时间处于阈值内来提供建议路线，该阈值基于参考路线上的估计行进时间。超出阈值的路线可以被丢弃，而不作为建议路线被提供给用户。此外，在一些情况下，将参考路线作为建议路线提供给用户，诸如在没有其他路线在阈值内的情况下。预期这些和其他概念在本公开的范围内。
附图说明
下面参考附图详细描述本发明，在附图中：
图1是示出根据本公开的实现的示例性操作环境的框图。
图2是示出根据本公开的实现的示例性系统的框图；
图3是示出了根据本公开的实现的方法的流程图；
图4是示出了根据本公开的实现的方法的流程图；
图5是示出了根据本公开的实现的方法的流程图；以及
图6是适用于本公开的实现的示例性计算环境的框图。
具体实施方式
本文具体描述了本发明的主题以满足法定要求。然而，说明书本身并不旨在限制本专利的范围。相反，本发明人已经设想所要求保护的主题也可以以其它方式实施，以包括不同步骤或与本文档中描述的步骤类似步骤的组合、结合其它现有技术或未来技术。此外，尽管在本文中可以使用术语“步骤”和/或“框”来表示所采用的方法的不同要素，但是这些术语不应被解释为暗示本文公开的各个步骤之中或之间的任何特定顺序，除非明确地描述了个别步骤的顺序。
本公开的各方面涉及在路线规划中使用路线偏好来提高用户效率。根据本公开的实现，针对各个用户跟踪路线偏好。基于路线制订请求生成路线。偏好权重对应于机器学习模型，机器学习模型基于由一个或多个传感器与用户相关联地提供的传感器数据。基于偏好权重确定路线的路线得分，并且基于路线得分向用户提供建议路线。路线偏好的示例包括：对由很多用户更频繁使用的主路线分量的偏好、对用户更熟悉的路线分量的偏好、对更安全或危害更小的路线分量的偏好、对具有更好的蜂窝接收的路线分量的偏好、以及对具有更好的天气状况的路线分量(诸如较少刮风的路线分量或用户不太可能使他或她的眼睛被太阳晃到的路线分量)的偏好。
在另外的方面，在生成路线得分时，可以为路线分量确定路线偏好子得分。路线偏好子得分可以被平均或以其他方式组合以形成路线得分。在一些情况下，通过预测用户将穿越路线分量的估计时间来确定路线偏好子得分。可以利用估计时间来更准确地确定路线偏好子得分，从而提高路线得分的准确性。
在本公开的另外的方面，基于路线上的估计行进时间、参考路线的距离或其组合来选择参考路线。在一些情况下，参考路线基于参考路线具有响应于路线制订请求而生成的路线中的路线上的最低估计行进时间而被选择。将建议路线与参考路线进行比较，可以基于比较将建议路线提供给用户。在某些方面，基于建议路线上的估计行进时间处于阈值内来提供建议路线，该阈值基于参考路线上的估计行进时间。超出阈值的路线可以被丢弃，而不作为建议路线被提供给用户。此外，在一些情况下，将参考路线作为建议路线提供给用户，诸如在没有其他路线在阈值内的情况下。
通过使用本文中描述的方法，通过有效地评估和预测针对用户的最佳路线，在路线规划中使用用户偏好提高了用户效率。例如，通过包含基于机器学习模型的偏好权重，本公开的实现考虑了用户的路线偏好中的折中以获取针对用户的最佳路线。因此，为了使用户获取最佳路线，用户不需要投入大量时间和资源。例如，用户不需要研究道路状况，预测道路状况，以及为用户界面中的每个路线手动设置路线路点。另外，用户无需手动或通过在每个路线之前提交问卷的答案，来配置多个路线偏好。
进一步根据用于计算机辅助路线规划/导航的常规技术，当在路线上强制执行用户偏好时，它们被视为硬约束。因此，这些技术经常向用户提供满足偏好的路线，但是在持续时间、距离或复杂性方面过长。本公开的一些实施例通过将路线与一个或多个阈值和/或参考路线进行比较，来确定是否将这些路线提供给用户来解决这些和其他技术问题。该比较的阈值和/或参考路线可以约束路线的持续时间、距离和/或复杂度，以滤除不太可能被用户接受的缺陷路线。因此，与常规技术相反，(例如，在完全生成路线之前或之后)滤除常规上为用户提供和/或评估的、不可接受的路线。这保存了计算能力，否则这些计算能力将用于确定和/或评估缺陷路线。此外，在服务器端执行过滤的实现中，保存了网络资源，因为它们不会被浪费在传输缺陷路线上。在另外的方面，通过过滤路线，可以通过向用户建议更少的、具有整体较高合意性的路线来简化用户界面。至少以这些方式，本公开的实施例改进了计算机辅助的路线规划技术。
现在转向图1，提供了示出可以采用本公开的一些实施例的示例操作环境100的框图。应该理解的是，本文描述的这种布置和其它布置仅作为示例阐述。除了示出的这些布置之外或者代替示出的这些布置，可以使用其它布置和元件(例如，机器、接口、功能、顺序、和功能分组等)，并且为了清晰起见而完全可以省略一些元件。进一步地，本文描述的许多元件是能够被实施为离散或分布式组件或者结合其它组件实施、并且以任何合适的组合且在任何合适的位置中实施的功能实体。本文描述的由一个或多个实体执行的各种功能可以由硬件、固件、和/或软件执行。例如，一些功能可以由执行存储在存储器中的指令的处理器执行。
除了未示出的其它组件，示例操作环境100包括：多个用户设备，诸如用户设备102a和102b至102n；多个数据源，诸如数据源104a和104b至104n；服务器106；传感器103a和107；以及网络110。应该理解的是，图1所示的环境100是一个合适的操作环境的示例。图1所示的每个组件都可以经由任何类型的计算设备实施，诸如例如结合图6描述的计算设备600。这些组件可以经由网络110彼此通信，网络110可以包括但不限于一个或多个局域网(lan)和/或广域网(wan)。在示例性实施方式中，网络110包括在各种可能的公用和/或专用网络中的任何一个网络当中的互联网和/或蜂窝网络。
应该理解的是，在本公开的范围内，在操作环境100内可以采用任何数量的用户设备、服务器和数据源。每个用户设备、服务器和数据源都可以包括在分布式环境中协作的单个设备或多个设备。例如，可以经由设置在共同提供本文描述的功能的分布式环境中的多个设备来提供服务器106。另外，未示出的其它组件也可以被包括在分布式环境内。
用户设备102a和102b至102n可以是操作环境100的客户端侧的客户端设备，而服务器106可以在操作环境100的服务器侧。服务器106可以包括服务器侧软件，该服务器侧软件被设计为与用户设备102a和102b至102n上的客户端侧软件一起工作以便实施在本公开中讨论的特征和功能的任何组合。提供操作环境100的这种划分以图示合适环境的一个示例，并且针对每种实施方式并不要求的是，服务器106以及用户设备102a和102b至102n的任何组合保持为单独的实体。
用户设备102a和102b至102n可以包括能够由用户使用的任何类型的计算设备。例如，在一个实施例中，用户设备102a至102n可以是本文参照图9描述的计算设备的类型。作为示例而非限制，用户设备可以体现为个人计算机(pc)、膝上型计算机、移动设备、智能电话、平板计算机、智能手表、可穿戴计算机、个人数字助理(pda)、mp3播放器、全球定位系统(gps)或设备、视频播放器、手持式通信设备、游戏设备或系统、娱乐系统、车载计算机系统、嵌入式系统控制器、相机、遥控器、条形码扫描仪、计算机化测量设备、电器、消费性电子设备、工作站、或者这些描绘的设备的任何组合、或者任何其它合适的设备。
数据源104a和104b至104n可以包括数据源和/或数据系统，其被配置为使数据可用于：操作环境100的各个组成部分、或者结合图2描述的系统200中的任何一个。(例如，在一个实施例中，一个或多个数据源104a至104n将用户数据提供给图2的数据收集组件215(或者使一个或多个数据源104a至104n可以访问用户数据)。)数据源104a和104b至104n可以与用户设备102a和102b至102n以及服务器106分立，或者可以被合并和/或集成到这些组件中的至少一个组件中。在一个实施例中，数据源104a至104n中的一个或多个包括一个或多个传感器，其可以被集成到(一个或多个)用户设备102a、102b或102n或者服务器106中的一个或多个中，或者与(一个或多个)用户设备102a、102b或102n或者服务器106相关联。这样的数据源的一些示例包括：在图1中描述的传感器103a或107。结合图2的数据收集组件215来进一步地描述由数据源104a至104n提供的感测的用户数据的示例。
操作环境100可以用于实现图2中描述的系统200的一个或多个组件，包括用于以下的组件：收集用户数据、监测活动事件、确定活动模式、消耗活动模式信息以提供改进的用户体验、生成个性化内容和/或向用户呈现通知和相关内容。
现在与图1一起参考图2，提供了示出适用于实施实施例并且总体被表示为系统200的示例计算系统架构的各个方面的框图。系统200仅表示合适的计算系统架构的一个示例。除了示出的这些布置或者代替示出的这些布置之外，可以使用其它布置和元件，并且为了清晰起见而可以完全省略一些元件。进一步地，与操作环境100一样，本文描述的许多元件是能够被实施为离散或分布式组件或者结合其它组件实施、并且以任何合适的组合且在任何合适的位置中实施的功能实体。
系统200包括诸如数据收集组件215、存储装置220、路线制订引擎260、推断引擎212和呈现组件298等组件，所有这些组件经由网络210通信地耦合，网络210可以包括与图1的网络110相同或不同的网络。
在一些实现中，由系统200的组件执行的功能与一个或多个个人助理、路线制订、和/或导航应用、服务或例程相关联。具体地，这种应用、服务或例程可以在一个或多个用户设备(诸如用户设备102a)、服务器(诸如服务器106)上进行操作，可以分布在一个或多个用户设备和服务器上，或者在云中实施。而且，在一些实现中，系统200的这些组件可以跨网络分布、分布在云中、或者可以驻留在用户设备(诸如用户设备102a)上，该网络包括一个或多个服务器(诸如服务器106)和客户端设备(诸如用户设备102a)。与操作环境100一样，本文中描述的一些组件可以被实施为一组经编译的计算机指令、计算机功能、程序模块、计算机软件服务、或者在诸如结合图6描述的计算设备600等一个或多个计算机系统上执行的过程的布置。
这些组件、由这些组件执行的功能、或者由这些组件进行的服务可以被实施在(一个或多个)计算设备的(一个或多个)适当的抽象层处，诸如操作系统层、应用层、硬件层等。备选地或另外，本文中描述的这些组件的功能和/或本发明的实现可以至少部分地由一个或多个硬件逻辑组件执行。可以使用的示例性类型的硬件逻辑组件包括：现场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、片上系统(soc)、复杂可编程逻辑设备(cpld)等。另外，尽管本文相对于示例性系统200所示的特定组件描述了功能，但是设想在一些实现中，这些组件的功能可以跨其它组件共享或分布。
通常，存储装置220被配置为存储在本文中描述的实施例的实现中使用的计算机指令(例如，软件程序指令、例程或服务)、数据和/或模型。在一些实现中，存储装置220存储经由系统200的各种组件接收的信息或数据，并且向系统200的各种组件提供对该信息或数据的访问。例如，存储装置220可以存储这样的信息或数据作为：关于数据收集组件215而被描述的用户、路线和解释性数据、交互数据、推断数据、语义信息、语义特征、交互数据集、众包数据集、个人源数据集、用户例程模型、例程相关推断、例程相关简档、用户简档(例如，用户简档222)和路线简档(例如，路线简档224)。在实现中，存储装置220包括数据存储器(或计算机数据存储器)。尽管描绘为单个组件，但是存储装置220可以实施为一个或多个数据存储器或者可以是在云中。此外，存储装置220中的信息可以以任何合适的方式分布在一个或多个数据存储器上以便存储。
数据收集组件215通常负责从一个或多个数据源(诸如图1的数据源104a到104n)获取、访问或接收(并且在一些情况下还标识)用户数据、路线数据和解释性数据。用户数据对应于与一个或多个用户相关联地获取的数据。在适当的情况下，以不指示用户的身份的匿名方式来收集用户数据。如本文中使用的，用户可以与用户帐户相关联，该用户帐户包括以下中的一个或多个：用户名、密码、用户设备(例如，媒体访问控制地址)、互联网协议(ip)地址、通用唯一标识符(uuid)和/或其他用户标识符。
在一些情况下，至少一些用户数据可以不直接与由系统200维护的用户帐户相关联，但可以与已知或指定为与同一用户相对应的另一用户帐户相关联。例如，用户帐户可以链接到可以在另一系统或其他系统中的一个或多个其他用户帐户。例如，同一用户可以拥有
路线数据对应于与由系统200用来表示路线的一个或多个路线分量相关联地收集的数据。“路线”可以包括一个或多个路线分量的集合，诸如跨越地理位置的道路、路段、路径和/或交叉点。内部路线分量可以以任何合适的方式表示，诸如使用具有表示交叉点的节点和节点之间表示路段的连接的图。路线分量可以可选地分成多个子组件用于分析和/或跟踪目的。例如，路段可以分成多个子段。
解释性数据对应于用于补充系统200中的信息的解释的数据。在这方面，系统200中的各种组件中的任何组件可以使用解释性数据来支持基于系统200可用的信息(诸如语义特征和交互数据)的推断。解释性数据可以由系统200的各种组件中的任何组件用来提供信息的上下文，以支持由推断引擎212在系统200中进行的推断。作为示例，交互数据(例如，用户数据)可以指示用户不正确地驾驶，而解释性数据可以包括推断引擎212使用的天气信息，以推断用户在暴风雪中驾驶。推断的类型贯穿本申请而适用。
由数据收集组件215获取的数据(包括用户数据、路线数据和解释性数据)可以由数据收集组件215从其中数据可以以各种格式可用的各种来源收集。用户或路线数据的示例包括：从可以对应于图1的数据源104a至104n中的任何一个的一个或多个传感器得出的数据。如本文中使用的，传感器可以包括用于感测、检测或以其他方式获取诸如用户数据或路线数据等信息的功能、例程、组件或其组合，并且可以被实施为硬件、软件或两者。作为示例而非限制，用户或路线数据可以包括：从一个或多个传感器感测或确定的数据(本文中称为传感器数据)，诸如(多个)移动设备的位置信息、智能手机数据(诸如电话状态、收费数据、日期/时间、或来自智能手机的其他信息)、用户活动信息(例如，应用使用；在线活动；搜索；语音数据，诸如自动语音识别；活动日志；通信数据，包括电话、文本、即时消息和电子邮件；网站帖子；与通信事件相关的其他用户数据；等)，用户活动信息包括在多于一个用户设备上发生的用户活动、用户历史、会话日志、应用数据、联系人数据、日历和日程安排数据、通知数据、社交网络数据、新闻(包括搜索引擎或社交网络上的热门或趋势项目)、在线游戏数据、电子商务活动(包括来自诸如microsoft账户、amazon.com、ebay、paypal或xboxlive等在线账户的数据)、(多个)用户帐户的数据(其可以包括来自用户偏好的数据或与个人助理应用或服务相关联的设置)、家庭传感器数据、家电数据、全球定位系统(gps)数据、车辆信号数据、交通数据、天气数据(包括预报)、可穿戴设备数据、其他用户设备数据(其可以包括设备设置、简档、网络连接(诸如wi-fi网络数据)、或配置数据、有关型号、固件、或者设备、设备配对的数据，诸如用户具有与蓝牙耳机配对的移动电话的情况)、陀螺仪数据、加速度计数据、支付或信用卡使用数据(其可以包括来自用户的paypal账户的信息)、购买历史数据(诸如来自用户的amazon.com或ebay账户的信息)、可以由传感器(或其他检测器)组件感测或以其他方式检测的其他传感器数据，包括从与用户相关联的传感器组件得出的数据(包括地点、运动、定向、位置、用户访问、用户活动、网络访问、用户设备充电、或能够由一个或多个传感器组件提供的其他数据)、基于其他数据而得出的数据(例如，可以从wi-fi、蜂窝网络或ip地址数据得出的位置数据)、以及可以如本文所述感测或确定的几乎任何其他数据源。
在某些方面，至少一些数据可以作为输入信号提供给系统200的各种组件。输入信号可以对应于来自对应源或传感器(诸如上述各种源或传感器中的任何一种)的数据馈送。用户信号可以指包括来自对应数据源的用户数据馈送的输入信号。例如，用户信号可以来自智能手机、家庭传感器设备、gps设备(例如，用于位置坐标)、车辆传感器设备、可穿戴设备、用户设备、陀螺仪传感器、加速计传感器、日历服务、电子邮件帐户、信用卡帐户或其他数据源。类似地，路线信号可以是指来自对应数据源的路线数据馈送。例如，路线信号可以来自温度计、富网站摘要(rss)文档、twitter用户、气压计、网站或其他数据源。
应当理解，在一些情况下，用户数据也可以用作路线数据。作为示例，假定与用户相关联的蜂窝电话提供来自设备中的陀螺仪的用户数据。推断引擎212可以利用该信息作为用户数据来推断用户处于事故中。推断引擎212可以使用该数据的聚合，来推断特定路线分量(例如，路段)对应于高事故区域。
在本公开的一些方面，用户数据包括交互数据，交互数据可以从与用户相关联或在某些情况下与多个用户相关联的多个用户设备(诸如图1的用户设备102a至102n)接收。以这种方式，可以接收来自用户使用的多个用户设备(例如，用户的移动电话、膝上型电脑、平板电脑等)的、特定用户的用户活动作为交互数据。交互数据可以由数据收集组件215接收、获取或访问，并且可选地累积、重新格式化和/或组合，并且存储在诸如存储装置220等一个或多个数据存储中。例如，至少一些交互数据可以存储在用户简档222之一中或与用户简档222之一相关联地存储，如本文所述。因此，一个或多个数据存储可以对路线制订引擎260、事件跟踪器216、推断引擎212和呈现组件298可用。
在一些实现中，数据收集组件215被配置为累积反映由一个或多个传感器针对个体用户检测到的用户活动的交互数据(“个体来源的交互数据”)。在一些实现中，数据收集组件215被配置为累积与多个用户的用户源交互相关联的交互数据(“众人来源的交互数据”)。任何个人标识数据(即，专门标识特定用户的交互数据)可以不从具有交互数据的一个或多个数据源上载，可以不永久存储，和/或可以不可用于路线制订引擎260、事件跟踪器216、推断引擎212和/或呈现组件298。可以处理至少一些交互数据以生成用户简档222和/或路线简档224，如下面进一步详细描述的。
交互数据可以从其中数据可以以各种格式可用的各种源来接收。例如，在一些实现中，由数据收集组件215累积的用户数据经由与用户设备(诸如用户设备102a和/或与用户相关联的其他设备)、服务器(诸如服务器106)和/或其他计算设备相关联的一个或多个传感器来接收。
用户数据、路线数据和解释性数据可以通过各种可能的数据源和/或数据系统随时间连续地收集。意图在于，用户数据和路线数据的收集和积累实施针对个人、企业和公共部门组织的、强健的隐私和数据保护。在这方面，用户可以控制与相关联数据相关的很多方面，包括选择加入或退出数据收集的能力和/或本文所述的各种跟踪或分析特征中的任何一种。此外，将实施保护措施，以在没有用户或帐户管理员的明确同意的情况下，保护敏感数据不被其他方(包括其他用户)访问。此外，任何收集的数据都应当尽可能匿名。
除了从数据源获取数据之外，数据收集组件215还可以从用户数据、路线数据和/或可以被包括在所获取的数据中的其他数据的任何组合中提取语义信息，诸如用户、路线和/或路线分量的显性和/或推断的语义特征。所提取的用户的语义特征可以与一个或多个用户简档(诸如用户简档222)相关联地存储。用户特征232可以对应于这些语义特征。用户特征包括描述用户的任何信息。每个用户可以具有与该用户相关联的对应用户简档和用户特征。
所提取的路线或路线分量的语义特征可以与一个或多个路线简档(诸如路线简档224)相关联地存储。路线特征228可以对应于这些语义特征。路线特征包括描述一个或多个路线分量和/或其部分的任何信息。例如，路线分量的路线特征可以包括与分量相对应的道路或多条道路的名称、分量的类别或多个类别、以及分量的语义、推断或定义的特征(例如，季节性天气状况、车道合并信息、事故频率等)。每个路线分量可以具有与该路线分量相关联的相应的路线简档和路线特征。
语义特征的示例(这些可以提供路线规划的上下文，如稍后进一步详细描述的)包括用户、路线和/或路线分量(例如，地理区域)的例程特征。例程特征对应于对于位置或用户而言是例行的、常见的或常规的语义特征。可选地，例程特征可以使用事件跟踪器216和/或推断引擎212来推断(例如，该用户经常在该特定道路中行进或者该位置靠近快餐店，或者该位置经常下雨)。偶发特征可以对应于位置或用户的以下特征，该特征对于位置或用户而言是不规则的、偶然的或孤立的。
特征是例程特征还是偶发特征可以取决于系统的观点、理解和知识。例如，例程特征和偶发特征二者都可以是由系统发现的推断特征的类型。例程特征可以是由系统确定为由系统检测和跟踪的例程的一部分的特征(例如，场所访问、访问模式和/或行为模式、或例程)。偶发特征可以是由系统确定的特征，而不是由系统检测和跟踪的、位置或用户实践的已知例程的部分(例如，不是已知实践例程的一部分的事件，相比于可能是或可能不是已知实践例程的一部分的事件)。在一些情况下，可以从多个特征中推断出偶发或例程特征，这些多个特征可以包括至少一个例程特征或偶发特征。
用户的例程特征的一些示例包括用户偏好，诸如饮食偏好、品牌偏好、道路偏好、驾驶偏好、电影偏好、音乐偏好、父母状态(即，用户是否是父母)、人口统计信息(例如，年龄、性别、婚姻状况、订婚的用户、结婚的用户、单身用户、读写能力/教育、就业状况、职业、居住地点)、常规访问的场所(例如，用户中心)等。用户的偶发特征的示例包括：用户生病、用户渴望快餐、用户上班迟到、用户偏离或与预期的所跟踪例程相矛盾、用户正在度假(正在度假的用户可能对风景路线比其他路线具有更多的偏好)、用户的特定个人事件，诸如婚礼(有事件要参加的用户可能对快速路线具有更强的偏好)等。
位置(例如，路线或路线分量)的例程特征的示例包括：类型或功用类别(例如，公路、高速公路、泥路、地面街道、自行车道、步行道等)、一天中的特定时间的交通状况、正在进行的建设、车道合并的出现、该位置的交通高峰时间、特定位置的用户的总体或通告的驾驶速度、特定位置处或附近的常规事件(例如，年度游行)、总体用户人口统计数据、总体用户特征、该位置的总体事故统计数据、该位置的总体犯罪统计数据以及其他许多。偶发特征的示例包括：在特定位置在特定日期或特定时间发生的特定事件(例如，事故、临时道路、交叉点或斜坡弯道关闭)、特定位置的交通意外飙升(例如，人员或车辆)、特定位置的当前天气状况、特定位置发生的异常事件或活动等。
显性语义特征对应于显性信息，其可以是来自用户的显性信息，或者来自数据源(例如，网页、文档、文件、黄页、地图、索引等)的显性信息，信息从该数据源被提取。作为示例，显性信息可以从用户所输入的喜欢和不喜欢的数据记录中被提取到与用户简档222之一相对应的用户简档中。作为另一示例，数据可以从社交媒体网站上的“喜欢按钮”记录喜欢，其被提供给系统200。作为另一示例，显性信息可以包括从用于路线分量的黄页或街道地图集中提取的街道名称或路线类别。
如上所述，通过提取经推断的语义特征，系统200可以更深入地理解用户和路线。系统可以通过根据系统200可用的任何信息进行推断，来发现经推断的语义特征。这包括用户和路线数据的任何组合、以及一个或多个用户(例如，用户)、路线和/或路线分量的、先前提取的显性和/或经推断的语义特征。在一些实现中，随着附加信息可用于推断，可以随时间更新经推断的语义特征。例如，附加信息可以用于确定一个或多个经推断的语义特征不再适用于一个或多个用户或路线分量。例如，这可以是用户或路线分量的性质变化的结果，系统200基于附加信息更好地理解用户、路线分量或世界的结果。在一些情况下，基于系统200可用的信息变得陈旧或以其他方式成为历史，可以附加地或替代地随时间更新经推断的语义特征。在经推断的语义特征改变的情况下，可以更新基于语义特征的任何信息。
在一些情况下，事件跟踪器216可以用于帮助由系统200中的任何各种组件生成推断。事件跟踪器216被配置为从交互数据(诸如用户和路线数据)中标识和跟踪一个或多个用户或路线分量的事件和可选的例程。可以根据构成例程的一个或多个重复事件来定义“例程”(建模例程)。“事件”(建模事件)可以对应于一个或多个定义的动作、行为和/或活动，其与从用户和/或路线数据可检测并且由系统200跟踪的用户或路线分量相对应。
事件的示例是：用户驾驶、用户在特定街道上行进、用户在特定地理区域或地区中、用户启动路线、用户与路线交互、用户收听歌曲或视频、用户下载路线、用户在地理位置、用户参加会议、接收与用户相关联的传感器读数、用户去健身房、用户正在工作、用户加速到阈值量以上、用户在车辆中进行特定方向的转弯、用户与特定的人在一起、用户与家人在一起、用户与孩子在一起、以及用户独自一人、以及更多可能性。这些事件可以由推断引擎212使用来自与用户相关联的用户设备的传感器数据来标识。注意，一个事件至所有事件可以与例程相关联。然而，在很多情况下，事件可以不与例程相关联(例如，事件可以被检测为一次性事件)。
事件跟踪器216可以将在跟踪用户和路线和/或路线分量的例程和/或事件时使用的各种数据中的任何数据分别存储为用户跟踪数据和路线跟踪数据(每种数据可以包括事件发生模式、和/或由系统200推断或发现的其他信息)。随着时间的推移，在定期分析数据并且发现、修改新事件和例程或将其与用户和路线和/或路线分量解除相关联时，事件跟踪器216可以更新跟踪数据。可以从跟踪数据推断用户和路线和/或路线分量的一个或多个语义特征。因此，应当理解，还可以基于数据来更新和发现诸如驾驶模式、驾驶条件等语义特征。在一些情况下，事件跟踪数据包括存储或以其他方式指示与例程和/或事件相关联的各种数据中的任何数据的记录，诸如例程的事件和/或与这些事件的跟踪变量相关联的值(例如，各种参数，诸如时间戳)。
跟踪变量是由事件跟踪器216关于对应的检测到的事件实例而分配和/或记录的事件变量。对应于跟踪变量的值可以与事件跟踪数据中的用户、路线和/或路线分量相关联地存储。跟踪变量可以对应于各种用户数据或路线数据中的任何一个，其示例已经在上面描述并且包括可以由一个或多个传感器感测的传感器数据或读数(诸如与用户设备相关联的关于地点、位置、动作/定向、用户访问/触摸、连接/断开充电器、用户设备上的用户活动的信息、或者可以由一个或多个传感器(诸如移动设备上的传感器)感测的其他信息、gps坐标样本，以及许多其他信息)。
应当理解，跟踪变量的值可以与一个或多个事件和/或例程相关联，并且不需要是事件或例程特定的。跟踪变量的示例是对应于事件的相应实例的时间戳，诸如街道上的驱动器(其对应于可以由推断引擎212标识的路线分量)、与特定路线的使用或用户交互、使用位置、或本文中描述的事件的各种示例中的任何一个。时间戳可以指示事件的实例相对于事件的其他实例、以及可选地对应例程的一个或多个其他事件的实例的相对次序或顺序。
作为跟踪变量的另外的示例，事件可以包括用户驾驶到商店。一个跟踪变量可以对应于到达位置或地点，诸如到达位置名称或地点名称。在检测事件时，事件跟踪器216可以基于包括用户电话(例如，图1的用户设备102a)上的gps数据的用户数据来推断到达被实现，其中到达位置名称或地点名称被分类为商店，并且基于解释性数据来存储，该解释性数据包括用于将来自用户的电话的坐标与相应的位置或地点名称相关联的地图数据。因此，作为示例，对于一个事件实例，名称可以是“walmart”，并且对于另一实例，名称可以是“target”。然而，应当理解，事件的检测和跟踪中的粒度级别可以变化。因此，作为示例，名称不必是跟踪变量。此外，潜在跟踪变量或更一般地是事件变量的其他示例包括：到达时间(例如，时间戳)、到达位置坐标、行进速度、汽油里程、车辆名称、天气状况、道路状况、记录偏离由路线应用提供的路线的信息、以及许多其他。
诸如与用户交互相对应的事件等事件的实例可以与事件实例记录相关联地存储。每个事件实例记录可以包括位置或多个位置和时间戳的任何组合。时间戳对应于事件的相应实例，并且可以指示事件的实例相对于事件的其他实例、以及可选地相对于系统200内的一个或多个其他跟踪事件的实例的相对次序或顺序。位置对应于事件的相应实例并且标识与事件的实例相关联的地理区域(例如，事件发生的地方)。
通常，使用位置可以包括适合于系统200将事件的实例与指定的地理区域相关联的任何信息，诸如在路线分量中使用的那些信息。使用位置的示例是系统200可以在地理区域内确定的地理点(例如，地理坐标)。另一示例是地理区域或路线或路线分量的标识符。又一示例是系统200可以在地理区域或区块内标识的路线id。在一些实现中，推断引擎212可选地与用户交互相关联地推断由用户进行的路线访问，并且基于所标识的路线(或可能被标识的候选路线)生成使用位置。
针对事件实例记录的位置可以可选地至少部分地基于一个或多个空间样本，诸如空间时间样本。空间时间样本可以对应于对在特定时间在特定位置的特定事件、用户和/或设备进行标识的数据。例如，空间时间样本可以包括地理位置和与地理位置相对应的时间戳。事件跟踪器216可以使用时间戳作为事件实例记录的时间戳，或者可以使用它来生成该时间戳(例如，多个时间戳的平均值或中值)。地理位置可以包括诸如纬度和经度等位置坐标、以及可能的指示地理位置准确性的测量不确定性信息。
在空间时间样本由诸如gps接收器等传感器提供的情况下，时间戳与其gps坐标一起可以由传感器生成，例如在由传感器确定和/或测量位置的时间。在一些情况下，可以从一个或多个用户信号中提取位置数据，以提供被聚合到事件的位置中的位置数据流。这可以包括使用空间时间样本的聚类分析，并且可以考虑其他形式的位置数据和算法以到达针对事件实例记录的位置。
虽然描述了gps接收器，但是用于确定使用位置的位置数据可以至少部分地由数据收集组件215使用以下方法中的任意方法来提取：用于确定事件的用户位置以及可选的对应于该位置的时间的各种方法。在一些实施方式中，例如，位置数据可以使用wi-fi接入点迹线和/或蜂窝跟踪来生成。用户可以在用户设备102a上，用户设备102a能够与来自一个或多个wi-fi接入点和/或蜂窝网络的信号交互。数据收集组件215可以至少部分地基于这些交互信号来定位用户并且相应地生成位置数据，使得事件跟踪器216可以使用位置数据来定位用户。作为示例，位置数据可以基于检测这些网络中的一个或多个，并且可以包括对应于网络的一个或多个网络名称和/或网络标识符。事件跟踪器216可以使用位置数据来将网络映射到对应于用户的位置，或者可以以其他方式利用从交互信号得到的信息(例如，可选地与空间时间样本结合)。
数据收集组件215获取的数据总体形成事件实例的模式的详细记录，事件实例涉及用户和路线和/或路线分量。这些模式可以向系统200提供理解和知识，并且可以由包括事件跟踪器216、推断引擎212和路线制订引擎260在内的各种组件来标识和检测。例如，路线制订引擎260可以使用这些事件实例模式中的至少一些来向用户建议路线。
路线制订引擎260可以利用通过数据收集组件215以及推断引擎212而对系统200可用的、本文中描述的各种数据的任何组合，以便为用户构建路线和/或为用户选择路线。在这样做时，路线制订引擎260可以考虑偏好上的折中，该折中可能会被要求以确定针对用户的最佳路线。很多驾驶员对于他们偏好的驾驶路线具有偏好。在各种实现中，路线制订引擎260可以考虑这些偏好，这些偏好可以随着用户而不同，并且基于围绕对路线的用户请求的其他上下文(例如，用户和/或路线分量的语义特征)而变化。此外，路线制订引擎260可以考虑这些各种因素的重要性随用户的变化。在这样做时，路线制订引擎260可以为用户构建路线和/或为用户选择路线，同时自动管理在确定用户偏好哪些路线的过程中对特定用户起作用的各种折中。
路线制订引擎260包括路线生成器250、路线选择器252和反馈分析器256。路线制订引擎260被配置为响应于路线制订请求而向用户提供一条或多条建议路线。可选地包括反馈分析器256，以分析来自用户的关于建议路线的反馈，该反馈可以用于改变将来向用户建议哪些路线。
路线生成器250和路线选择器252被配置为向用户提供建议路线，建议路线满足可以由路线制订请求指定的各种路线制订条件。如本文中使用的，路线制订条件指定对由路线制订引擎260建议的路线的硬约束。路线制订条件可以是明确地来自用户的，或者可以是经推断的，诸如根据用户上下文和/或围绕路线制订请求的上下文。例如，用户可以使用诸如用户设备102a等用户设备在路线规划应用(例如，gps导航应用或基于网络的地图应用)中配置一个或多个路线制订条件。在某些情况下，可以出于这些目的向用户提供菜单选项、切换和其他gui元素。
作为示例，路线制订请求可以包括至少结束位置，结束位置可以由用户使用用户设备指定(例如，在设备上的路线规划应用中)。结束位置指定由路线制订引擎260响应于路线制订请求而提供的路线的地理结束。路线制订请求还可以包括开始位置，开始位置可以由用户使用用户设备指定或者可以从传感器数据推断。开始位置指定路线制订引擎260响应于路线制订请求而提供的路线的地理开始。在一些情况下，为路线制订请求提供一个或多个中间位置。路线制订条件的其他示例是：用于避免或包括在建议路线中的特定街道、交叉点或其他路线制订分量。
路线制订条件的另外示例是：要避免或包括在建议路线中的街道、交叉点或其他路线分量，基于其具有一个或多个指定的语义特征(例如，多雨区域、交通流量高或低的区域、具有坑洞的区域、没有建筑的区域等)。在一些情况下，路线制订条件包括针对一个或多个语义特征和/或偏好的阈值，用户可以设置该阈值或该阈值可以是机器学习的。在超过该阈值时，路线制订条件将被满足，并且被实施在建议给用户的路线上。例如，用户可以指定路线中应当不超过两个(阈值)事故。
作为另一示例，反馈分析器256可以通过分析用户在被呈现多个路线时选择哪些路线和/或基于来自用户的显性反馈(例如，通过使用机器学习)来确定阈值(例如，呈现组件298可以向用户提示消息，诸如在用户设备上，并且分析用户的响应)。
除了满足路线制订条件之外，路线生成器250和路线选择器252可以被配置为提供满足一个或多个路线偏好的建议路线。路线偏好和路线制订条件在本文中更一般地被称为路线制订因子。路线制订引擎260可以基于路线制订因子262提供建议路线，如图2所示。例如，路线生成器250可以分析与路线制订请求相关联的各种路线制订因子，并且基于路线制订因子响应于路线制订请求而生成一条或多条路线。作为示例，路线生成器250可以选择以下路线分量，这些路线分量为用户制订从开始位置到结束位置或到基于那些指定位置的位置的路线。
本文中的路线偏好是指对由路线制订引擎260建议的路线的软约束。例如，路线制订条件可以是，由路线制订引擎260建议的任何路线不应当包括山丘(例如，超过阈值的海拔变化或以其他方式基于海拔变化的条件)。路线偏好可以允许路线包括山丘，尽管路线生成器250和路线选择器252不太可能基于软约束提供包括山丘的路线。通过在路线规划中考虑一个或多个路线偏好和/或路线制订条件，路线制订引擎260可以向用户建议更期望的路线。
一些路线偏好可以是一般路线偏好，并且其他路线偏好可以是用户路线偏好。一般路线偏好是指不特定于系统200的特定用户的路线偏好。一般路线偏好的示例是：总计而言，用户偏好在路线中避免或包括路线分量，可选地在某个指定上下文下(例如，当下雨时用户倾向于避开特定街道)。相反，用户偏好是指特定于系统200的至少一个特定用户的路线偏好，诸如正在为其生成路线的用户。用户路线偏好的类似示例是，用户特别偏好在路线中避免或包括路线分量，可选地在某个指定上下文下(例如，当下雨时该用户倾向于避开特定街道)。
在一些实现中，至少一些路线偏好对应于偏好权重度量，其量化路线偏好中的强度水平。路线偏好的偏好权重度量可以为路线偏好提供偏好权重。路线制订引擎260可以使用偏好权重，以在为用户生成和/或选择路线时考虑路线偏好。在偏好的强度水平增加时，对于路线偏好的偏好权重可以更高，使得偏好在向用户提供路线时具有更大的权重。
本文中描述的每个度量(诸如偏好权重度量)可以对应于一个或多个机器学习模型。例如，每个偏好权重度量可以对应于相应的机器学习模型。因此，与其他权重一样，偏好权重可以是机器学习的。在某些情况下，机器学习模型可以定义共同对应于路线偏好的输入。例如，机器学习模型的至少一些输入可以对应于与用户相关联地被提供的、来自一个或多个用户设备的传感器数据。这可以包括各种经推断的语义特征(例如，用户特征232)。
本文中，用于机器学习的合适的机器学习模型可以利用监督、半监督或无监督学习。示例包括：隐马尔可夫模型(hmm)、决策树学习、集成(ensemble)、线性回归模型、神经网络、最近邻模型、有限状态机(fsm)模型、逻辑回归模型和支持向量机(svm)模型。
在一些情况下，路线制订引擎260使用一个或多个偏好权重来生成路线得分，诸如路线得分258。路线得分可以根据路线度量生成，路线度量包括来自一个或多个偏好权重度量的偏好权重。路线度量可以基于在路线度量中考虑的一个或多个路线偏好来量化对应路线(或其一部分)的总体合意性水平。与对应于相对较低路线得分的路线相比，对应于较高路线得分的路线对应于更理想的路线。路线制订引擎260可能更有可能向用户建议具有较高路线得分的路线，而不是具有较低路线得分的路线，这将在后面进一步详细描述。
在一些实现中，用户偏好230包括与用户相关联的路线制订因子。例如，每个路线制订简档可以包括与路线简档相关联的用户的路线制订因子。与用户相关联的路线制订因子可以由路线制订引擎260用来为用户建议路线。附加地或替代地，一个或多个路线制订因子可以从用户偏好230和/或用户特征232中推断或以其他方式提取。
在一些实现中，路线制订引擎260在建议一个或多个路线时是否考虑一个或多个路线制订条件和/或路线偏好是基于路线制订上下文，诸如路线制订上下文264。例如，用于响应于路线制订请求而生成和/或构造一条或多条路线的路线度量可以基于上下文而被选择、构造或确定。在一些情况下，路线制订引擎260使用上下文来确定哪些偏好权重度量被包括在路线度量中。作为另一示例，路线制订引擎260选择与上下文相对应的路线度量。
除了或代替前述内容，上下文可以确定将偏好权重度量的哪个版本应用于路线度量。特别地，所采用的偏好权重度量版本可以基于上下文而变化。作为示例，基于路线制订引擎260确定特定上下文应用于路线偏好，路线制订引擎260可以为与特定上下文相对应的偏好权重来选择偏好权重，或者可以使用与特定上下文相对应的调节因子来调节偏好权重的基值，并且利用经调节的值来确定路线得分。
可选地，例如，可以将偏好权重和/或调节因子与一个或多个特定用户相关联地存储在用户偏好230中。这些值可以形成用户的上下文简档。基于路线制订引擎260将一个或多个上下文因子标识为应用于路线制订请求，路线制订引擎260可以响应于路线制订请求而利用一个或多个相应的上下文简档来建议路线。利用上下文简档可以包括：利用与该上下文简档相对应的上下文值和/或调节因子来确定应用于路线度量的偏好权重。
路线制订上下文264可以包括一般路线制订上下文和/或用户路线制订上下文。一般路线制订上下文是指不特定于系统200的特定用户的路线制订上下文。具体地，当一般路线制订上下文应用于路线制订请求时，基于一般路线制订上下文而应用的、用于确定要建议哪个或哪些路线的偏好权重不是系统200的特定用户或多个用户特定的(定制的)。一般路线制订上下文的示例是基于用户的用户特征232而应用的路线制订上下文，用户特征232指示用户在预定义的年龄组中。相反，用户路线制订上下文是指特定于系统200的至少一个特定用户的路线制订上下文，诸如正在为其生成路线的用户。用户路线制订上下文的示例是基于发出路线制订请求的特定用户而应用的路线制订上下文。另一示例是基于确定一个或多个特定用户将使用建议路线或多条建议路线(例如，在同一车辆中驾驶)而应用的路线制订上下文。
路线制订上下文可以指示或以其他方式对应于路线制订请求的原因或理由。在一些情况下，路线制订上下文包括路线制订请求的一个或多个类别。例如，推断引擎212可以将一个或多个预定类别分配给路线制订请求。可以为分配给路线制订请求的类别定制建议路线，并且建议路线可以从用户的一个或多个语义特征中推断。类别的分配可以可选地基于对用户数据(例如，总体用户数据和/或对应于该用户的用户数据)和/或解释性数据的分析。用于路线制订请求的性质的预定类别的示例包括：跑腿、休闲活动、工作、外出就餐、锻炼、喝咖啡或购物。因此，可以基于这些类别中的每个类别向用户建议不同的路线。
路线制订上下文的附加示例是对应于一组用户(诸如家庭、一对夫妇或由关系定义的其他用户)的路线制订上下文。关系的一个示例是家庭关系。例如，父母可能希望在与孩子一起驾驶时总是或通常避免高犯罪率区域，并且当单独驾驶或仅与另一成人或配偶一起驾驶时可能更容忍建议路线中的那些区域。在一些实现中，关系由推断引擎212推断。例如，关系可以基于用户特征232来推断。路线制订引擎260可以基于确定上下文应用于路线制订请求来利用对应的上下文。作为示例，路线制订引擎260可以基于来自用户和/或与该用户相关联的其他用户(例如，作为该组的一部分的用户)的一个或多个用户信号来确定路线制订上下文。在一些情况下，这包括路线制订引擎260确定组的成员在彼此的预定义距离内(例如，基于设备位置和/或通过来自用户设备的音频中的用户语音或用户参考来标识用户)。在一些情况下，用户可以明确地指示路线制订上下文适用，诸如通过在路线规划应用中使用设置。
路线制订上下文的其他示例是对应于一天中的时间、一周中的天、一年中的季节或者以时间为基础的那些路线制订上下文。作为示例，用户可能更愿意在白天的上下文中而不是在夜间的上下文中在高犯罪区域驾驶。应当理解，本文中诸如愿望和意愿等术语与偏好水平类似，其可以通过被用于向用户建议路线的偏好权重的大小来表示。
路线制订上下文的其他示例是与针对路线制订请求的运输模式相对应的路线制订上下文，作为一些示例，诸如实现路线的用户是否正在或将要步行、驾驶、跑步、海航或骑自行车。作为示例，与驾驶相对，用户可能更愿意在骑车时在边道上而不是主街道上行驶。
路线制订上下文的附加示例基于来自其他用户的众人来源信息。路线制订引擎260可以基于确定用户与其他用户类似来在为用户生成路线的过程中应用路线制订上下文。例如，相似性可以对应于：路线制订引擎确定用户与其他用户共享一个或多个语义特征。例如，这可以包括被路线制订引擎260标识为与具有与其他用户类似的一个或多个偏好的用户共享类似路线的驾驶员、或者以其他方式确定和/或标识为与以某种定义的方式与其他用户类似的驾驶员。附加示例包括：浏览类似网站、进行类似购买、去类似场所(诸如餐馆)、听类似音乐、驾驶类似车辆、也有孩子、具有类似社交媒体特征、或者具有由路线制订引擎260可检测或可标识的其他用户活动的用户。
在一些情况下，当用户被标识为与其他用户类似时，可以在路线规划中应用来自其他用户的一个或多个偏好，否则这些偏好将不会应用于该用户。例如，可以通过总计分析其他用户的偏好来标识偏好。作为另一示例，可以利用其他用户的偏好来确定针对该用户的偏好权重。例如，这可以基于针对其他用户的偏好权重的平均或其他聚合度量。在一些情况下，用户简档222包括一个或多个聚合用户简档，当上下文应用于该用户时，一个或多个聚合用户简档可以类似于特定于用户的用户简档来使用。
基于来自其他用户的众人来源信息的路线制订上下文可以应用于本文中描述的各种用户偏好中的任何一个。作为示例，这包括以下偏好：避免阳光或其他天气状况，穿越主路线分量，穿越熟悉的路线分量，穿越风景路线分量，避免危害路线分量，避免诸如山丘等显著高度海拔，穿越具有更好的蜂窝接收的路线分量，穿越更安全的路线分量，等等。因此，路线制订引擎260可以基于确定或标识一个或多个路线制订因子262应用于路线制订请求，而确定响应于路线制订请求来建议哪个或哪些路线。如上所述，当应用路线偏好时，可以将与路线偏好相对应的偏好权重并入路线度量中，用于量化路线的合意性。还如上所述，所使用的偏好权重还可以取决于路线制订上下文。
在一些实现中，还可以利用从偏好度量生成的路线偏好得分。偏好度量对应于量化路线的路线偏好的强度的偏好得分。在一些实现中，对于特定路线偏好，利用路线度量来确定路线偏好的路线偏好得分，并且利用对应的偏好权重来调节路线偏好得分(例如，以生成加权路线偏好得分)。偏好度量可以是用户不可知的，并且偏好权重度量用于针对用户和/或路线制订请求定制路线偏好得分。因此，路线度量的简单示例是r＝p1(w1)+p2(w2)+p3(w3)，其中r是路线得分，p1是针对路线的第一路线偏好的路线偏好得分，p2是针对路线的第二路线偏好，p3是针对路线的第三路线偏好，w1是用于第一路线偏好的偏好权重，w2是用于第二路线偏好的偏好权重，并且w3是用于第三路线偏好的偏好权重。
在一些实现中，偏好度量被应用于路线中的多个道路分量(例如，每个道路分量或每个特定类型，诸如道路类型)，以确定针对该路线分量的路线偏好子得分。子得分被组合或以其他方式并入偏好度量中，以形成针对路线偏好的路线偏好得分。作为示例，偏好度量可以包括构成路线的路线分量的路线偏好子得分的平均值、模式、最小值、最大值或中值。
在一些实现中，至少一些路线偏好子得分在偏好度量中被加权。例如，可以基于与路线偏好子得分相对应的路线分量来加权每个路线偏好子得分。在一些情况下，在确定路线得分时对路线分量的加权基于路线分量的长度或距离。路线制订引擎260可以被配置为：与较短的路线分量相比更多地加权较长的路线分量。路线分量长度可以利用任何合适的方式确定，诸如通过参考路线特征228中的对应长度数据。长度数据可以由数据收集组件215从任何合适的源(诸如地图数据)收集。
在一些情况下，机器学习模型定义共同对应于路线偏好子得分(例如，路线偏好子得分度量)的输入。例如，机器学习模型的至少一些输入可以对应于与路线分量相关联地被提供的、来自一个或多个用户设备的传感器数据。这可以包括各种经推断的语义特征(例如，路线特征228)。因此，路线偏好子得分的权重可以至少部分是机器学习的。
作为另一示例，在确定路线得分时对路线分量的加权可以附加地或替代地基于针对路线的路线分量上的估计行进时间(即，穿越要花多长时间)。路线制订引擎260可以被配置为：与具有较低的估计行进时间的路线分量相比，对具有较高的估计行进时间的路线分量加权更多。可以利用任何合适的方式确定行进时间，诸如通过参考路线特征228中的对应行进时间数据。在一些情况下，行进时间基于路线制订上下文(例如，路线制订上下文264)来确定，诸如时间信息(例如，一天中的时间、一年中的时间等)、天气状况(例如，下雨、下雪、结冰、晴天、刮风等)、事故数据(例如，路线分量处的平均事故、路线分量处的当前事故数等)、或者所标识的、所估计的和/或所预测的数据的其他组合。
在一些实现中，基于路线分量的估计穿越时间(即，预期穿越发生时)，针对道路分量预测估计行进时间。例如，路线制订引擎260可以基于针对路线的开始时间、以及在路线分量之前针对路线的一个或多个预期穿越速度，来确定道路分量的估计穿越时间。预期穿越速度或速率可以至少基于用户或多个用户的历史驾驶数据或被分配的速度限制，并且还可以基于与路线相关联的其他时间数据(例如，一天中的时间、一年中的天、季节等)。使用预期穿越速度，路线制订引擎260可以估计每个路线分量的穿越时间并且基于该时间预测路线分量的条件。当驾驶员开始旅途时和当驾驶员实际到达路线分量时，路线分量的状况可能会发生显著变化。因此，该方法可以引起针对路线的更准确的估计行进时间、以及道路状况(即，路线特征)的更准确的预测，从而改善向用户建议的路线。
附加地或替代地，估计穿越时间可以用于确定路线偏好得分的路线偏好子得分。例如，路线制订引擎260可以使用针对一个或多个路线分量的估计行进时间，来为一个或多个路线分量预测路线偏好子得分的对应路线偏好。作为示例，路线制订引擎260可以基于历史数据确定路线分量在下午5点可能具有高水平的交通流量或拥塞，引起针对路线分量的高的路线偏好子得分。假定用户具有下午3点的路线的开始时间，并且路线分量历史上在下午3点没有太多的交通流量。如果没有预测，路线偏好子得分将更低，这可能导致为用户建议不太理想的路线。
已经描述了用于确定诸如路线得分258的路线得分的方法的示例，下面提供路线选择和生成的示例。在一些方法中，路线生成器250可选地确定并且利用路线得分258来生成路线。例如，路线生成器250可以在路线被构建时分析路线(不完整路线)，并且利用路线得分来确定要在路线中包括哪些路线分量。在一些情况下，当生成一个或多个路线时，路线生成器250基于确定路线分量违反一个或多个路线制订条件而从一条或多条路线中排除路线分量。该确定可以通过分析路线特征228来进行。在一些情况下，路线分量的路线偏好子得分被用于此目的。例如，路线制订条件的阈值可以在该确定中被应用于路线偏好子得分。在路线偏好子得分未能符合阈值的情况下，可以丢弃路线分量。然而，应当注意，阈值不需要被应用于阈值，并且可以应用于与路线分量相关联的各种路线特征228中的任何一个，以预测方式或以其他方式(例如，路线制订引擎260可以估计交通流的速度在阈值对应于25mph的路线分量上将为10mph)。
在一些情况下，路线生成器250为用户输出一条或多条建议路线。因此应当理解，在某些情况下，可能不需要路线选择器252。在其他情况下，路线选择器252可以用于从由路线生成器250生成的候选路线(完整路线)中选择一条或多条建议路线。本文中的完整路线是指跨越指定开始位置和指定结束位置的路线。每条候选路线和/或建议路线可以跨越相同的开始和结束位置。这里的不完整路线是指仅跨越开始位置和结束位置的一个或多个部分的路线。
虽然路线生成器250可以在生成路线时考虑路线偏好和/或路线得分(例如，通过将它们并入其优化功能中)，但在其他情况下，路线生成器250仅优化路线的时间和/或距离。在这些情况下，仍然可以使用路线选择器252来应用路线偏好。
在路线选择器252从由路线生成器250生成的候选路线中选择一条或多条建议路线的情况下，路线选择器252可以为每条候选路线生成路线得分。上面已经描述了用于生成路线得分的各种方法，并且这些方法可以由路线选择器252或更一般地由路线制订引擎260使用。可以将路线度量应用于每条路线，以生成针对每条路线的路线得分。在一些实现中，路线选择器252选择最高得分路线并且响应于路线制订请求来建议最高得分路线。在其他情况下，路线选择器252提供给定数目的最佳路线，并且响应于路线制订请求来提供这些路线作为建议路线。一条或多条附加路线可以可选地被包括在建议路线中，诸如仅针对时间和/或距离优化(例如，使用优化功能)的至少一条路线、或者具有最短时间、距离和/或其组合的一条或多条候选路线。
在一些实现中，路线选择器252选择具有最高路线得分的一条或多条候选路线，并且将这些路线与参考路线进行比较。参考路线可以是例如具有最短时间、距离和/或其组合的候选路线。最短时间、距离和/或其组合可以可选地用作建议参考。在一些情况下，路线选择器252基于建议参考来选择一条或多条候选路线。例如，在基于其路线得分而被选择的候选路线具有超过建议参考阈值量的时间、距离和/或其组合的情况下，可以丢弃候选路线和/或可以在建议路线中包括参考路线。作为示例，阈值量可以对应于固定量(例如，5分钟、10英里)或者是建议参考的一个百分比(例如，10％)。
路线选择器252可以附加地或替代地为一个或多个特定路线偏好应用最小阈值。例如，可以基于一个或多个路线偏好得分(例如，加权或未加权的偏好得分)低于阈值而丢弃路线。在一些情况下，通过使用该方法，可以在生成路线得分期间或在分析候选路线集合之前丢弃路线，从而节省处理能力。
路线偏好的附加示例
路线偏好的示例对应于针对建议路线的、对主道路或路线分量的偏好。主路线分量对应于：与非主路线分量相比，用户总计更频繁地穿越的路线分量。在一些实现中，路线制订引擎260可以通过使用偏好度量聚合用户来量化一个或多个路线分量的穿越频率。在一些情况下，路线制订引擎260使用流量统计数据来确定偏好度量，诸如可以由数据收集组件215从交通数据库的部门获取的流量统计数据、和/或从分析来自用户设备的gps数据而获取的流量统计数据。作为另一示例，地图数据可以指示哪些路线分量或其部分对应于主道路，诸如公路、边道、辅路等。频率可以从该道路类型或其他地图数据中提取。
路线偏好的另一示例对应于用户穿越一个或多个熟悉路线分量的偏好。熟悉路线分量对应于：与不熟悉路线分量相比，特定用户总计更频繁地穿越的路线分量。在一些实现中，路线制订引擎260可以使用偏好度量来量化用户对一个或多个路线分量的穿越频率。在一些情况下，路线制订引擎260通过分析来自与用户相关联的用户设备的gps数据来确定偏好度量。作为另一示例，路线制订引擎260可以分析用户接受和/或穿越的建议路线。作为另一示例，可以由用户明确地指示熟悉度(例如，通过使用用户设备的gui)。
路线偏好的另一示例对应于避免一个或多个危害和/或一个或多个特定危害的偏好。危害的示例包括固有路线分量特征，诸如车道合并、车道数目、道路状况(例如，诸如颠簸、损坏、污垢、严峻等材料状况)、停车标志、停车灯、自行车道等。这些特征可以在路线特征228中指示，并且数据收集组件215可以随时间更新路线特征以反映变化的状况。
危害的其他示例包括暂时路线分量特征。暂时路线分量特征的示例包括事故、停放的车辆和天气状况。在一些实现中，一个或多个暂时路线分量特征可以从用户设备被报告，诸如与和路线制订请求相对应的用户不同的用户相关联的用户设备。例如，路线规划应用gui可以包括允许用户指定前述内容中的任何一项的报告界面。
在一些实现中，路线偏好对应于避免在太阳方向上行进(例如，面向太阳)的偏好。在一些实现中，路线制订引擎260确定用户是否将在路线分量上沿太阳的方向行进。这可以基于以下中的一个或多个：在穿越路线分量期间的用户朝向、历史太阳位置数据、路线分量的估计穿越时间、以及参照太阳的入射角和基于路线分量的位置(例如，用户在穿越期间的预期位置)。在一些情况下，路线偏好的偏好度量对应于太阳方向上的行进程度，其是使用前述信息的任何组合(例如，其基于入射角而变化)来计算的。作为示例，路线偏好得分可以与行进程度成比例。
路线偏好的另一示例对应于路线期间的蜂窝接收的偏好。在一些情况下，路线偏好的偏好度量对应于在路线分量上蜂窝接收是否可用。附加地或替代地，偏好度量可以对应于路线分量上的信号强度。作为示例，路线偏好得分可以与信号强度成比例。例如，可以根据用户设备在穿越路线分量期间(例如，在操作路线规划应用时或在其他情况下)生成的数据(例如，通话中断数据、信号电平数据等)来确定蜂窝接收。作为另一示例，可以由数据收集组件215从一个或多个覆盖图提取蜂窝接收。与这里描述的其他路线分量数据一样，这些语义特征可以从路线特征228存储和/或提取。
路线偏好的另一示例对应于路线期间对更安全区域的偏好。在某些情况下，针对路线分量的更安全区域根据犯罪率来通过偏好度量量化。附加地或替代地，针对路线分量的更安全区域可以根据事故统计来通过偏好度量量化。例如，这些统计数据可以由数据收集组件215从一个或多个数据库中提取和/或由系统200的用户报告。
附加特征
建议路线可以由路线制订引擎260传输到一个或多个用户设备，诸如提供路线制订请求的用户的设备。例如，可以在用户设备102a至102n的任何组合上呈现用户的建议路线，诸如建议路线299。在该能力中，呈现组件298可以从路线制订引擎260接收路线建议，并且采用关于用户简档222和路线简档224示出的任何各种数据以及其他数据。呈现组件298可以确定何时和/或如何向用户呈现建议路线。呈现组件298可选地请求路线建议(并且可以如上所述为建议提供一个或多个选择标准或路线制订因子)，或者建议可以被推送到呈现组件298。在一些实施例中，呈现组件298包括在计算设备(诸如图6中描述的包括用户设备的计算设备600，诸如移动计算设备)上或在云中运行的一个或多个应用或服务。例如，呈现组件298可以是路线规划应用的至少一部分，诸如用户设备(例如，用户设备102a)上的gps路线应用。
由呈现组件298关于呈现路线做出的确定可以用于帮助用户，诸如通过请求建议，并且基于确定路线与用户上下文相关来向用户提供路线，或者在某些上下文中避免向用户提供一条或多条建议路线，从而减少网络资源的利用。
可以基于来自用户和/或与用户相关联的用户设备的、针对建议的特定路线制订请求，由呈现组件298向用户呈现建议，或者可以不特定地请求建议。例如，在一些情况下，用户可以使用路线规划应用的gui来请求建议路线。作为另一示例，可以将建议推送到用户设备并且在用户设备上主动地或被动地呈现建议。
应当理解，在一些情况下，由路线制订引擎260和/或系统200的其他组成部分做出的建议可以作为云服务被提供给应用或服务。在这方面，用户设备上的应用可以可选地包含应用编程接口(api)，用于与云服务通信并且用于提供呈现组件298的至少一些功能。以这种方式，可以向应用提供用于向用户定制路线的公共框架。在其他情况下，路线制订引擎260位于云中。在其他情况下，其中的一个或多个组成部分(诸如路线选择器252和/或路线生成器250)是用户设备上的位置(例如，作为其上的路线规划应用的一部分)。
如上所述，用户反馈可以可选地并入一个或多个路线度量中。路线制订引擎260可以利用反馈分析器256来分析用户反馈，诸如通过应用反馈来更新偏好权重、用户特征、路线特征以及由推断引擎212使用机器学习做出的其他推断。换言之，由推断引擎212做出的任何推断可以利用机器学习。因此，反馈分析器256可以基于分析用户数据(诸如用户的交互数据)来确定和/或更新针对用户的偏好权重。例如，可以分析上述各种传感器数据中的任何一种。
在一些实现中，从接收到一个或多个路线建议的用户设备或路线规划应用提供反馈。反馈可以包括以下中的一个或多个：在路线穿越期间与建议路线的偏差、在用户设备上呈现的建议路线列表中一条或多条建议路线或者一条或多条特定建议路线的接受。如上所述，在一些实现中，呈现组件298可以提示用户提供用户反馈。可以在用户设备上显示提示，例如，基于确定偏好权重超过阈值。在用户使用gui确认路线偏好的情况下，可以增加偏好权重和/或可以在用于建议路线的路线度量中为用户激活偏好权重(例如，以生成路线得分)。在用户使用gui拒绝路线偏好的情况下，可以降低偏好权重和/或可以在用于建议路线的路线度量中为用户停用偏好权重。
在一些实现中，可以基于用户接受路线(例如，“您为什么喜欢这个路线”伴随与路线偏好相对应的可选择的选项)，基于用户当前穿越路线(例如，“当下您觉得这个路线如何”伴随与路线偏好相对应的可选选项)，或者基于路线的完成(例如，“之前您觉得这个路线如何”伴随与路线偏好相对应的可选选项)来显示提示或消息。
在一些情况下，在用户设备上呈现建议路线时，呈现组件298显示路线得分的一个或多个路线偏好的一个或多个指示符，该路线得分被用于选择建议路线。例如，可以为多个得分最高的一个或多个路线偏好提供指示。作为一些示例，指示可以包括表示路线偏好的文本和/或图标。
注意，在一些情况下，向用户建议单条路线，并且在用户设备上的路线规划应用中自动实现单条路线。实现路线可以包括自动启动用户设备上的导航功能(例如，gps路线制订和跟踪)。在一些情况下，可以基于单条路线的路线得分超过阈值或者以其他方式基于对建议路线的分析来建议和/或实现单条路线。因此，用户可以发出路线制订请求，其自动导致接受符合用户偏好的建议路线。
现在参考图3，提供了流程图，其示出了用于在路线规划中提高用户效率的方法300的实施例。方法300和本文描述的其它方法的每个框都包括可以使用硬件、固件和/或软件的任何组合执行的计算过程。例如，各种功能可以由执行存储在存储器中的指令的处理器执行。该方法也可以体现为存储在计算机存储介质上的计算机可用指令。仅举几个示例，这些方法可以由独立应用、服务或托管服务(独立的或与另一托管服务组合)、或者对另一产品的插件来提供。
在框310处，方法300包括标识路线制订因子。例如，路线制订引擎260可以基于与用户设备102a的用户相关联的路线制订请求来标识路线制订因子262。路线制订因子可以包括：用户的路线偏好，其可以可选地在用户偏好230中被指示。路线制订因子还可以包括一个或多个路线制订条件，诸如建议路线的开始位置和结束位置中的一个或多个。
在框320处，方法300包括生成路线。例如，路线生成器250可以基于路线制订请求生成多个路线。在一些情况下，路线生成器250生成符合路线制订条件的路线。
在框330处，方法300包括确定路线偏好的偏好权重。例如，路线制订引擎260可以确定多个路线偏好中的每个路线偏好的偏好权重。每个偏好权重可以对应于机器学习模型，机器学习模型基于由一个或多个传感器与用户相关联地提供的传感器数据。在一些情况下，偏好权重存储在用户的用户简档的用户偏好230中，或者至少一些偏好权重可以根据需要来确定。在一些情况下，用户偏好230使用用户特征232来确定，其中至少一些用户特征可以由推断引擎212推断。例如，用户的语义特征可以根据从本文中描述的各种传感器中的任何传感器获取的用户数据来推断。
在框340处，方法300包括基于偏好权重确定路线的路线得分。例如，对于多条路线中的每个路线，可以基于多个路线偏好中的每个路线偏好的偏好权重来确定路线的路线得分。这些路线得分可以对应于路线得分258。在一些情况下，路线是不完整的路线，并且路线生成器250在路线生成中利用路线得分来评估不完整路线。在其他情况下，路线可以是完整路线，并且路线选择器252利用路线得分来确定向用户建议的路线。
在框350处，方法300包括基于路线得分提供建议路线。例如，路线制订引擎260可以向与用户相关联的用户设备102a提供建议路线。建议路线可以对应于多条路线中的所选择的路线，并且可以基于所选择的路线的路线得分而被提供。在一些情况下，所选择的路线由路线生成器250提供。在其他情况下，路线选择器252从由路线生成器250生成的多条路线中选择路线。如上所述，可以向用户提供任何数目的路线作为建议路线。每条建议路线可以对应于多条路线中的一条或多条路线。
现在参考图4，提供了示出用于在路线规划中提高用户效率的方法400的一个实施例的流程图。在框410处，方法400包括：从路线规划应用接收路线制订请求。例如，路线制订引擎260可以接收从路线规划应用的用户界面提供的、来自用户的路线制订请求。路线规划应用可以在用户设备102a上运行，用户设备102a通过一个或多个网络通信提供路线制订请求。用户界面可以是例如gui或其他类型的用户界面，诸如基于文本或语音的界面、或这些界面的组合。例如，用户可以通过与用户界面的交互来发出路线制订请求。这可以包括选择提交按钮，这引起路线制订请求。可选地，用户可以通过与用户界面的交互来指定一个或多个路线制订条件。这可以包括建议路线的开始位置和/或结束位置。在一些情况下，路线规划应用是导航应用，诸如基于gps的导航应用。作为另一示例，路线规划应用可以对应于基于浏览器的地图应用。
在框420处，方法400包括标识路线制订因子。例如，路线制订引擎260可以基于所接收的路线制订请求来标识路线制订因子262。路线制订因子262包括用户的多个路线偏好。
在框430处，方法400包括生成路线。例如，路线生成器250可以基于路线制订请求生成多个路线。
在框440处，方法400包括确定偏好权重。例如，路线制订引擎260可以确定多个路线偏好中的每个路线偏好的偏好权重。每个偏好权重可以对应于机器学习模型，机器学习模型基于由一个或多个传感器与用户相关联地提供的传感器数据。
在框450处，方法400包括确定路线的路线得分。例如，路线制订引擎260可以基于多个路线偏好中的每个路线偏好的偏好权重来为多条路线中的每个路线确定路线的路线得分。路线得分可以对应于路线得分258。
在框460处，方法400包括基于路线得分选择建议路线。例如，路线选择器252可以基于建议路线的路线得分、从多条路线中选择建议路线。路线选择器252还可以基于建议路线与参考路线之间的比较来选择建议路线。在一些情况下，路线选择器252基于参考路线在路线生成器250生成的路线中具有路线上的最短估计行进时间来确定参考路线。与每个路线一样，参考路线可以可选地由路线生成器250独立于路线偏好生成。例如，路线生成器250可以优化在路线上的最小估计行进时间、路线的距离和/或其组合。然后，可以在来自路线生成器250的候选路线中进行选择时、通过使用路线得分来考虑路线偏好。然而，如上所述，可以基于路线偏好来生成至少一些路线。
例如，该比较可以包括：将建议路线上的估计行进时间与从参考路线上的行进时间(例如，参考路线上的估计行进时间)得出的阈值进行比较。如上所述，阈值可以是参考路线上的行进时间的特定百分比或固定量。附加地或替代地，可以使用该阈值或另一阈值将参考路线的距离与建议路线的距离进行比较。可以基于时间和/或距离不超过(多个)阈值来选择建议路线。
在一些情况下，基于超过一个或多个前述阈值而丢弃多条路线中的一条或多条。在一条或多条路线以这种方式而不足的情况下，可以将参考路线作为建议路线提供给用户。在某些情况下，参考路线可能是响应于路线制订请求而被建议给用户的唯一路线。例如，在基于路线偏好没有所生成的路线可以被充分选择的情况下，可以基于路线上的估计行进时间来提供参考路线。这可能在所生成的路线都不在时间和/或距离的(多个)阈值内的情况下发生。作为另一示例，每个生成的路线可能关于一个或多个路线偏好在某种程度上不足(例如，至少一个路线偏好得分可能不超过阈值)。
在框470处，方法400包括向路线规划应用传输建议路线。例如，路线制订引擎260可以向路线规划应用的用户界面传输(多条)建议路线。建议路线可以通过一个或多个网络通信来传输。通过从传输中排除缺陷路线，可以节省网络带宽。此外，因为建议路线使用偏好权重而考虑路线偏好中的折中，所以提高了用户效率。例如，用户无需手动研究路线偏好以平衡偏好，或调节路线的路径点。在一些情况下，用户发出路线制订请求，并且建议路线响应于路线制订请求被自动提供，而不要求另外的用户交互。作为示例，建议路线可以由用户设备上的导航应用自动执行。
现在参考图5，提供了示出用于在路线规划中提高用户效率的方法500的一个实施例的流程图。在框510处，方法500包括基于路线制订请求来标识路线制订因子。例如，路线制订引擎260可以基于路线制订请求来标识路线制订因子262。与其他实现一样，标识可以可选地基于路线制订上下文。
在框520处，方法500包括生成路线。例如，路线生成器250可以基于路线制订请求生成路线。
在框530处，方法500包括基于路线偏好确定路线的路线得分。例如，路线制订引擎260可以基于路线制订因子262的路线偏好来确定路线得分。可以使用任何合适的方法来生成路线得分。
在框540处，方法500包括基于建议路线与参考路线之间的比较从路线中选择建议路线。例如，路线选择器252可以基于建议路线的路线得分来选择建议路线。如上所述，参考路线可以可选地由路线生成器250生成，并且在一些情况下可以是所选择的路线(例如，由于参考路线具有候选路线中最短的估计行进时间)。
在框550处，方法500包括响应于路线制订请求而提供建议路线。例如，路线制订引擎260可以向用户提供建议路线，并且可选地提供多条建议路线。建议路线可以显示在与用户相关联的用户设备上。
已经描述了本公开的实施方式，下面描述其中可以实施本发明的实施例的示例性操作环境，以便为本公开的各个方面提供一般上下文。首先参考图6，特别地，示出了用于实施本发明的实施例的示例性操作环境，并且其一般性地指定为计算设备600。计算设备600仅是合适的计算环境的一个示例，并且不旨在对本发明的使用或功能的范围提出任何限制。也不应将计算设备600解释为对所图示的组件中的任何一个组件或者组件组合具有任何依赖性或要求。
本发明可以在计算机代码或机器可用指令的一般上下文中描述，机器可用指令包括由计算机或其它机器执行的计算机可执行指令、诸如程序模块，其他机器诸如为个人数据助理或者其它手持式设备。通常，包括例程、程序、对象、组件、数据结构等的程序模块指的是执行特定任务或实施特定抽象数据类型的代码。本发明可以在各种系统配置中实践，包括手持式设备、消费性电子产品、通用计算机、更多专业计算设备等。本发明还可以在分布式计算环境中实践，在分布式计算环境中，由通过通信网络链接的远程处理设备执行任务。
参照图6，计算设备600包括直接或间接地耦合以下设备的总线610：存储器612、一个或多个处理器614、一个或多个呈现组件616、输入/输出(i/o)端口618、输入/输出组件620、以及说明性电源622。总线610表示可以是一根或多根总线(诸如地址总线、数据总线或它们的组合)。尽管为了清晰起见用线示出了图6的各个框，但是实际上，描绘各种组件不是那么清楚，并且隐喻地，线条将更准确地是灰色和模糊的。例如，可以将呈现组件(诸如显示设备)认为是i/o组件。同样，处理器具有存储器。本发明人在此认识到这是本领域的性质，并且重申图6的图仅说明了能够结合本发明的一个或多个实施例使用的示例性计算设备。在诸如“工作站”、“服务器”、“膝上型计算机”、“手持式设备”等类别之间不进行区别，因为所有这些都被考虑在图6的范围内并且指代“计算设备”。
计算设备600通常包括各种计算机可读介质。计算机可读介质可以是能够由计算设备600访问的任何可用介质，并且包括易失性和非易失性介质以及可移动和不可移动介质。作为示例而非限制，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储信息(诸如计算机可读指令、数据结构、程序模块或其它数据)的任何方法或技术实施的易失性和非易失性介质以及可移动和不可移动介质。计算机存储介质包括但不限于，ram、rom、eeprom、闪存或其它存储技术、cd-rom、数字通用光盘(dvd)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁存储设备、或者可以用于存储期望信息并且可以由计算设备600访问的任何其它介质。计算机存储介质不包括信号本身。通信介质通常以诸如载波等调制的数据信号或其它传输机制来体现计算机可读指令、数据结构、程序模块或其它数据，并且包括任何信息传递介质。术语“调制的数据信号”表示以对信号中的信息编码的方式设置或改变其一个或多个特性的信号。作为示例而非限制，通信介质包括有线介质(诸如有线网络或直接有线连接)和无线介质(诸如声学、rf、红外和其它无线介质)。上述任何组合也应被包括在计算机可读介质的范围内。
存储器612包括易失性和/或非易失性存储器形式的计算机存储介质。存储器可以是可移动的、不可移动的或它们的组合。示例性硬件设备包括固态存储器、硬盘驱动器、光盘驱动器等。计算设备600包括从各种实体(诸如存储器612或i/o组件620)读取数据的一个或多个处理器。(多个)呈现组件616将数据指示呈现给用户或其它设备。示例性呈现组件包括显示设备、扬声器、打印组件、振动组件等。
i/o端口618允许计算设备600能够被逻辑地耦合至其它设备(包括i/o组件620)，一些i/o端口可以被内置。说明性组件包括麦克风、操纵杆、游戏手柄、卫星天线、扫描仪、打印机、无线设备等。i/o组件620可以提供处理由用户生成的悬浮手势、语音或其它生理输入的自然用户界面(nui)。在一些情况下，可以将输入传输到适当的网络元件以进行进一步的处理。nui可以实施语音辨识、触摸和手写笔辨识、面部辨识、生物辨识、屏幕上和屏幕附近的手势辨识、悬浮手势、头部和眼睛追踪、以及与计算设备600上的显示器相关联的触摸辨识的任何组合。计算设备600可以配备有深度相机，诸如立体相机系统、红外相机系统、rgb相机系统以及这些的组合，以用于手势检测和辨识。另外，计算设备600可以配备有能够实现运动检测的加速度计或陀螺仪。可以将加速度计或陀螺仪的输出提供给计算设备600的显示器以渲染沉浸式提高现实或虚拟现实。
可以理解，本公开的实现提供了向用户建议路线。已经关于特定实施例描述了本发明，这些特定实施例在所有方面均旨在是说明性的而不是限制性的。在不脱离本发明范围的情况下，备选实施例对于本发明所属领域的普通技术人员而言将变得显而易见。
在不脱离下文的权利要求的范围的情况下，所描绘的各个组件的许多不同布置以及未示出的组件都是可能的。已经以说明性而非限制性的意图描述了本发明的实施例。在阅读本公开之后并且由于阅读了本公开，备选实施例对于本公开的读者来说将变得显而易见。在不脱离下文的权利要求的范围的情况下，可以完成实施前述内容的备选手段。某些特征和子组合是实用的，可以在不参照其它特征和子组合的情况下采用并且被考虑在权利要求的范围内。
实施例1.一种计算机实现的方法，包括：基于与用户相关联的路线制订请求来标识路线制订因子，路线制订因子包括用户的多个路线偏好；基于路线制订请求生成多条路线；确定多个路线偏好中的每个路线偏好的偏好权重，每个偏好权重对应于机器学习模型，机器学习模型基于由一个或多个传感器与用户相关联地提供的传感器数据；基于多个路线偏好中的每个路线偏好的偏好权重来为多条路线中的每个路线确定路线的路线得分；以及向与用户相关联的用户设备提供建议路线，建议路线对应于多条路线中的所选择的路线，并且基于所选择的路线的路线得分而被提供。
实施例2.根据实施例1所述的计算机实现的方法，其中路线制订因子包括开始位置和结束位置，并且多条路线中的每条路线是跨越开始位置和结束位置的完整路线。
实施例3.根据实施例1至2中任一项所述的计算机实现的方法，还包括：独立于多个路线偏好生成参考路线；基于参考路线确定阈值；以及基于在建议路线上的估计行进时间与阈值之间的比较来选择建议路线用于传输。
实施例4.根据实施例1至3中任一项所述的计算机实现的方法，还包括：基于确定多条路线中的缺陷路线上的估计行进时间、缺陷路线的距离、或估计行进时间和距离的组合中的至少一项超过阈值，来排除将缺陷路线作为建议路线提供给用户设备。
实施例5.根据实施例1至4中任一项所述的计算机实现的方法，还包括：独立于多个路线偏好生成参考路线，参考路线被优化以最小化参考路线上的行进时间；基于行进时间确定阈值；以及基于确定多条路线中的缺陷路线上的估计行进时间超过阈值，来排除将缺陷路线作为建议路线传输到用户设备。
实施例6.根据实施例1至5中任一项所述的计算机实现的方法，其中路线得分的确定包括：为路线的多个路线分量中的每个路线分量确定路线分量的路线偏好子得分；将多个路线分量中的每个路线分量的路线偏好子得分组合成表示路线偏好的路线偏好得分；以及将偏好权重应用于路线偏好得分。
实施例7.根据实施例1至6中任一项所述的计算机实现的方法，其中路线得分的确定包括：为路线的多个路线分量中的每个路线分量确定路线分量的相应的估计穿越时间；基于相应的估计穿越时间来为路线的多个路线分量中的每个路线分量预测路线分量的天气状况；以及根据多个路线分量中的每个路线分量的所预测的天气状况来确定路线得分。
实施例8.根据实施例1至7中任一项所述的计算机实现的方法，其中多个路线偏好中的给定路线偏好对应于针对主路线分量的偏好，与非主路线分量相比，用户总计更频繁地穿越主路线分量。
实施例9.根据实施例1至8中任一项所述的计算机实现的方法，其中多个路线偏好中的给定路线偏好对应于穿越熟悉路线分量的偏好，与不熟悉路线分量相比，用户总计更频繁地穿越熟悉路线分量。
实施例10.根据实施例1至9中任一项所述的计算机实现的方法，其中多个路线偏好中的给定路线偏好对应于用于避免与固有路线分量特征相对应的危害的偏好。
实施例11.根据实施例1至10中任一项所述的计算机实现的方法，其中多个路线偏好中的给定路线偏好对应于对路线期间、基于犯罪统计数据的更安全区域的偏好。
实施例12.根据实施例1至11中任一项所述的计算机实现的方法，其中多个路线偏好中的给定路线偏好对应于基于路线期间的蜂窝接收的偏好。
实施例13.一种计算机实现的系统，包括：包括一个或多个处理器的路线制订引擎；存储计算机可用指令的一个或多个计算机存储介质，计算机可用指令在由一个或多个处理器执行时使得一个或多个处理器执行包括以下的操作：基于与用户相关联的路线制订请求来标识路线制订因子，路线制订因子包括用户的多个路线偏好；基于路线制订请求生成多条路线；确定多个路线偏好中的每个路线偏好的偏好权重，每个偏好权重对应于机器学习模型，机器学习模型基于由一个或多个传感器与用户相关联地提供的传感器数据；基于多个路线偏好中的每个路线偏好的偏好权重来为多条路线中的每条路线确定路线的路线得分；并且向与用户相关联的用户设备传输建议路线，建议路线对应于多条路线中的所选择的路线，并且基于所选择的路线的路线得分而被提供。
实施例14.根据实施例13所述的计算机实现的系统，其中该方法还包括：独立于多个路线偏好来生成参考路线；基于参考路线确定阈值；并且基于建议路线上的估计行进时间与阈值之间的比较来选择建议路线，用于传输。
实施例15.根据实施例13至14中任一项所述的计算机实现的系统，其中多个路线偏好中的给定路线偏好基于标识路线的多个路线分量中的给定路线分量的海拔。
实施例16.根据实施例13至15中任一项所述的计算机实现的系统，其中多个路线偏好中的给定路线偏好基于确定在路线的多个路线分量中的路线分量上相对于太阳的行进方向。
实施例17.根据实施例13至16中任一项所述的计算机实现的系统，其中路线得分的确定包括：为路线的多个路线分量中的每个路线分量确定路线分量的相应的估计穿越时间；基于相应的估计穿越时间来为路线的多个路线分量中的每个路线分量预测路线分量的天气状况(例如，下雨、刮风、晴朗等)；并且根据多个路线分量中的每个路线分量的所预测的天气特征来确定路线得分。
实施例18.一种或多种存储计算机可用指令的计算机存储设备，计算机可用指令在由一个或多个计算设备使用时使得一个或多个计算设备执行包括以下的方法：经由用户界面从用户接收路线制订请求；基于所接收的路线制订请求来标识路线制订因子，路线制订因子包括用户的多个路线偏好；基于路线制订请求生成多条路线；确定多个路线偏好中的每个路线偏好的偏好权重，每个偏好权重对应于机器学习模型，机器学习模型基于由一个或多个传感器与用户相关联地提供的传感器数据；基于多个路线偏好中的每个路线偏好的偏好权重来为多条路线中的每个路线确定路线的路线得分；基于建议路线的路线得分，并且基于建议路线与参考路线之间的比较来从多条路线中选择建议路线；以及通过一个或多个网络通信向路线规划应用的用户界面传输建议路线。
实施例19.根据实施例18所述的一种或多种计算机存储设备，还包括基于参考路线上的估计行进时间来选择参考路线，用于比较。
实施例20.根据实施例18和19中任一项所述的一种或多种计算机存储设备，还包括生成参考路线，其中参考路线被优化以最小化参考路线上的行进时间。
实施例21.根据实施例1至12中任一项所述的计算机实现的方法，其中经由用户设备提供建议路线包括以下中的一项或多项：在用户界面上显示建议路线，经由用户界面提供分路段方向，在用户设备上呈现路线，并且向计算机控制的运输车辆提供建议路线。
- 还没有人留言评论。精彩留言会获得点赞！