用于处理车辆事件数据以进行行程分析的系统和方法与流程

1.汽车行业正在经历一场前所未有的彻底变革。整个运动出行生态系统都在发生颠覆。其结果是车辆更加自动化、互联化、电气化和共享化。这导致了汽车生成的数据爆炸式增长。这一丰富的新数据资产在很大程度上尚未开发。


背景技术：

2.车辆位置事件数据(诸如gps数据)极其庞大，每秒可涉及200000条至600000条记录。位置事件数据的处理对传统系统提出了一项挑战，即针对数据提供近乎实时的分析，尤其是针对个别车辆。此外，识别个别车辆数据以进行此类规模的分析的同时，个别车辆数据面临着正确匿名化的挑战。需要的是被配置为以低延迟处理和存储大容量数据的同时使大容量数据仍然可用于分析和再处理的系统平台、数据处理算法和流程。
3.虽然存在用于跟踪车辆的系统，但需要的是大量车辆数据的近乎实时且准确的行程数据。需要的是被配置为依据车辆运动和路线分析准确地识别行程和行程目的地的系统和算法。


技术实现要素：

4.下面简要说明实施方案以提供对本文阐述的创新的一些方面的基本理解。本简要说明并非意在作全面概述。其并非意在识别主要要素或关键要素，或划定或以其他方式缩小范围。其目的仅仅是以简化的形式呈现一些概念，作为稍后呈现的更详细说明的前奏。
5.简而言之，本文公开了用于处理车辆事件数据的系统、方法和计算机程序产品的各种实施方案。
6.至少一个实施方案是一种系统，该系统包括包含程序指令的存储器以及被配置为执行用于方法的指令的处理器，该方法包括：摄取位置事件数据；以及依据该事件数据识别车辆的行程，其中，该行程识别包括识别给定车辆的运动是否是行程的行程分段。
7.在实施方案中，系统处理器被配置为执行用于方法的指令，该方法包括：摄取到流处理服务器或分析处理器服务器的车辆的位置事件数据，该位置事件数据包括时间和车辆的位置(纬度/经度)；在流处理服务器或分析处理器服务器处，依据该位置事件数据识别多个车辆行程；对一段时间内的地理围栏区域的位置事件数据执行关注事件算法，该关注事件选自紧急制动事件、紧急减速事件、紧急加速事件和超速事件；以及向映射可视化界面提供馈送，该映射可视化界面被配置为使依据关注事件算法的关注事件输出可视化。紧急制动或紧急减速可被定义为在预定时间段内的减速。紧急加速被定义为在另一预定时间段内的加速。
8.在实施方案中，处理器被配置为执行用于方法的指令，该方法还包括将事件数据中的位置数据编码为邻近区域。
9.在实施方案中，将事件数据中的位置数据编码为邻近区域还可包括以下至少一项：将纬度和经度地理哈希为限定邻近区域的形状；对该地理哈希进行编码以识别州；对该
地理哈希进行编码以识别邮政编码；以及将该地理哈希编码到可唯一地识别车辆的精确度。
10.在实施方案中，将事件数据中的位置数据编码为邻近区域还可包括以下至少一项：将地理哈希编码为5个字符以识别州；将地理哈希编码为6个字符以识别邮政编码；以及将地理哈希编码为9个字符以唯一地识别车辆。在实施方案中，将事件数据中的位置数据编码为限定邻近区域的形状可包括：将纬度和经度地理哈希为多边形或矩形，该多边形或矩形的边与字符串中的字符成比例。
11.在实施方案中，将事件数据中的位置数据编码为邻近区域还可包括将地理哈希编码为4个至9个字符。
12.在实施方案中，处理器被配置为执行用于方法的指令，该方法还包括将地理哈希映射到地图数据库。映射还可包括将地理哈希映射到关注点的数据库。
13.在实施方案中，行程识别包括识别车辆的发动机启动或第一次车辆运动；识别车辆的发动机关闭或停止运动；识别车辆的停留时间；识别车辆的最短行驶距离；以及识别最短行驶持续时间。
14.在实施方案中，处理器被配置有最短行驶持续时间标准，并且处理器被配置为执行指令，该指令使用该最短行驶持续时间标准识别车辆的最短行驶持续时间。最短行驶持续时间标准可为约60秒至约90秒。在实施方案中，最短行驶持续时间标准为约60秒。
15.在实施方案中，处理器被配置有最长停留时间标准，并且处理器被配置为执行指令，该指令使用该最长停留时间标准识别车辆的最长停留时间。最长停留时间标准可为约20秒至约120秒。在实施方案中，最长停留时间标准为约30秒。
16.在实施方案中，处理器被配置有最短行驶距离标准，并且处理器被配置为执行指令，该指令使用该最短行驶距离标准识别车辆的最短行驶距离。最短行驶距离标准可为约100米至约300米。在实施方案中，最短行驶距离标准为约200米。
17.在实施方案中，行程识别包括确定行程分段不形成行程的一部分。
18.在实施方案中，系统被配置为提供主动式车辆检测。主动式车辆检测可包括依据一段时间内的多项事件识别车辆路径。在实施方案中，主动式车辆检测包括依据一天的时间段内的多项事件识别车辆路径，该识别包括使用连通分量算法，该连通分量算法包括识别包含当天车辆事件的有向图中的车辆路径。在该图中，节点是车辆，节点之间的连接是识别的车辆路径。
19.在实施方案中，系统可包括数据仓库。系统将事件数据和行程确定数据存储在该数据仓库中。在实施方案中，可以将至少一个时间列添加到存储的数据中。该时间列可包括日期列和小时列。
20.在实施方案中，系统包括聚类算法，该聚类算法用于对一段时间内的地理围栏区域中的关注事件进行聚类。聚类算法被配置为对从以下组中选择的关注事件进行聚类：紧急制动事件、紧急减速事件、紧急加速和超速事件。系统可包括拥堵检测算法，该拥堵检测算法包括关注事件聚类算法。
21.在实施方案中，映射可视化界面可被配置为在映射可视化界面上显示一段时间内的地理围栏区域的不同关注事件算法输出的叠加。系统可被配置为在映射可视化界面上显示一段时间内的地理围栏区域的不同关注事件集群的叠加。系统可被配置为在映射可视化
界面上显示具有一段时间内的地理围栏区域的关注事件算法输出的行程的叠加。
22.至少一个实施方案描述了一种由计算机实现的方法，该计算机包括处理器和存储器，该存储器包括程序存储器，该程序存储器包括用于执行上述和本文阐述方法的指令。
23.至少一个实施方案描述了一种包括程序存储器的计算机程序产品，该程序存储器包括指令，该指令当由处理器执行时执行上述和本文阐述的方法。
24.如本文所使用，行程可包括到目的地的任何旅行、航程或旅程。
25.本文阐述的系统和方法的示例性优点是经优化的低延迟，截至本公开，该低延迟每秒能够为多达1200万辆车摄取和处理多达600,000条记录的车辆事件数据。
附图说明
26.结合以下附图对非限制性实施方案和非穷尽性实施方案进行说明。在附图中，除非另有说明，否则各个图中相似的附图标记指代相似的组件。
27.为了更好地理解，以下将结合详细说明(将与附图相结合阅读)，其中：
28.图1a是可以实现各个实施方案中的至少一者的环境的系统图。
29.图1b图示了根据各个实施方案中的至少一者的云计算架构。
30.图1c图示了根据各个实施方案中的至少一者的用于云计算平台的逻辑架构。
31.图2示出了用于根据本公开的各个实施方案中的至少一者的入口服务器系统的逻辑架构和流程图。
32.图3示出了用于根据各个实施方案中的至少一者的流处理服务器系统的逻辑架构和流程图。
33.图4表示用于根据各个实施方案中的至少一者的出口服务器系统的逻辑架构和流程图。
34.图5图示了用于根据各个实施方案中的至少一者的分析服务器系统的流程的逻辑架构和流程图。
35.图6图示了用于根据各个实施方案中的至少一者的门户服务器系统的流程的逻辑架构和流程图。
36.图7是示出了系统的数据处理检查的数据质量流水线的流程图。
37.图8是示出了系统的数据流水线和数据处理的流程图。
38.图9是示出了结合到提供给可视化界面的聚合数据集的馈送数据的流程图。
39.图10示出了显示互联车辆的行程数据可视化的界面。
40.图11示出了显示互联车辆的行程数据可视化的界面。
41.图12示出了显示路线可视化的界面。
42.图13a至图13d示出了显示互联车辆的路线和行程可视化的界面。
43.图14示出了显示互联车辆的行程数据可视化的界面。
44.图15示出了显示互联车辆的行程数据可视化的界面。
45.图16示出了显示互联车辆的行程数据可视化的界面。
46.图17a至图17b示出了显示互联车辆的行程数据可视化的界面。
47.图18a至图18b示出了显示互联车辆的行程数据可视化的界面。
48.图19a至图19e示出了显示联网车辆的行程数据可视化的一系列示例性视频界面
的屏幕截图。
49.图20a至图20b示出了显示互联车辆的行程数据可视化的界面。
50.图21示出了显示路线可视化的界面。
51.图22示出了显示互联车辆的行程数据可视化的界面。
52.图23a至图23e示出了显示互联车辆的行程数据可视化的界面。
53.图24示出了显示互联车辆的行程数据可视化的界面。
54.图25示出了显示互联车辆的行程数据可视化的界面。
55.图26a至图26b示出了显示互联车辆的行程数据和关注事件可视化的界面。
56.图27a至图27c示出了显示互联车辆的行程数据和关注事件可视化的界面。
57.图28示出了显示互联车辆的行程数据和关注事件可视化的界面。
58.图29a至图29b示出了显示互联车辆的行程数据和关注事件可视化的界面。
具体实施方式
59.现在下文将结合附图对各个实施方案进行更全面的说明，附图构成本文的一部分并且通过图示的方式示出了可以实施本文阐述的创新的具体实施方案。这些实施方案可以以多种不同的形式体现并且不应被解释为限于本文阐述的实施方案。相反，提供这些实施方案是为了使本公开全面且完整，并将向本领域技术人员充分传达实施方案的范围。除此之外，各个实施方案可以是方法、系统、媒体或设备。因此，以下详细说明不应被视为限制意义。
60.在整个说明书和权利要求书中，除非上下文另有明确规定，否则以下术语采用与本文明确相关联的含义。术语“本文”是指与本技术相关联的说明书、权利要求书和附图。如本文所用的短语“在一个实施方案中，或“在实施方案中”尽管可以，但不一定指相同的实施方案或单个实施方案。此外，如本文所用的短语“在另一个实施方案中”尽管可以，但不一定指不同的实施方案。因此，如下所述，在不脱离本发明的范围或精神的情况下，可以容易地组合各个实施方案。
61.此外，如本文所用，除非上下文另有明确规定，否则术语“或者”是包含性的“或者”并且等同于术语“和/或”。除非上下文另有明确规定，否则术语“基于”并非是排他性的，并且允许基于未阐述的其他因素。此外，在整个说明书中，“一种”、“一个”和“所述”的含义包括复数引用。“在
……
中”的含义包括“在
……
中”和“在
……
上”。
62.图1a是根据至少一个实施方案的用于地理定位事件处理和分析的系统10的逻辑架构。在各个实施方案中的至少一者中，入口服务器系统100可被布置为与流处理服务器系统200和分析服务器系统500通信。流处理服务器系统200可被布置为与出口服务器系统400和分析服务器系统500通信。
63.出口服务器系统400可被配置为与数据消费者通信并向其提供数据输出。出口服务器系统400还可被配置为与流处理服务器200通信。
64.分析服务器系统500被配置为与入口服务器系统100、流处理服务器系统200和出口服务器系统400通信并接受来自它们的数据。分析服务器系统500被配置为与门户服务器系统600通信并向其输出数据。
65.在至少一个实施方案中，入口服务器系统100、流处理服务器系统200、出口服务器
系统400、分析服务器系统500和门户服务器系统600各自可以是一台或多台计算机或服务器。在至少一个实施方案中，入口服务器系统100、流处理服务器系统200、出口服务器系统400、分析服务器系统500和门户服务器系统600中的一者或多者可被配置为在单台计算机(例如网络服务器计算机)上或跨多台计算机运作。例如，在至少一个实施方案中，系统10可被配置为在网络服务平台主机上运行，诸如亚马逊网络服务(aws)或微软azure。在示例性实施方案中，系统被配置在采用spark streaming服务器的aws平台上，其可被配置为执行如本文阐述的数据处理。在实施方案中，系统可被配置为采用高吞吐量消息服务器，例如apache kafka。
66.在至少一个实施方案中，入口服务器系统100、流处理服务器系统200、出口服务器系统400、分析服务器系统500和门户服务器系统600可被布置为使用api或由服务提供的其他通信接口来集成和/或通信。
67.在至少一个实施方案中，入口服务器系统100、流处理服务器系统200、出口服务器系统400、分析服务器系统500和门户服务器系统600可托管在托管服务器上。
68.在至少一个实施方案中，入口服务器系统100、流处理服务器系统200、出口服务器系统400、分析服务器系统500和门户服务器系统600可被布置为使用一个或多个直接网络路径(包括广域接入网络(wan)或本地接入网络(lan))通过网络直接或间接地与客户端计算机通信。
69.如本文阐述，系统10、流程和算法的实施方案可被配置为在网络服务平台主机上运行，诸如亚马逊网络服务或微软云计算体系结构被配置为方便地按需网络访问可配置的计算资源的共享池(例如网络、网络带宽、服务器、处理、内存、存储、应用程序、虚拟机和服务)。云计算机平台可被配置为允许平台提供方根据需要自动单方面提供计算能力，诸如服务器时间和网络存储，而无需与服务提供方进行人工交互。此外，云计算通过网络提供并且通过标准机制进行访问，这些机制促进异构瘦客户端平台或胖客户端平台(例如，移动电话、膝上型电脑和pda)的使用。在云计算架构中，可使用多租户模型来池化平台的计算资源，从而为多个消费者、合作伙伴或其他第三方用户提供服务，并根据需求动态地分配和重新分配不同的物理资源和虚拟资源。还配置了云计算架构，使得可快速、弹性地(在某些情况下，自动地)提供平台资源，以快速向外扩展，并快速释放以快速向内扩展。
70.云计算系统可被配置有通过利用适合于服务类型(例如，存储、处理、带宽和活跃用户帐户)的某种抽象级别的计量能力来自动控制和优化资源使用的系统。可监视、控制和报告资源使用情况。如本文阐述，在实施方案中，系统10有利地由平台提供方配置为具有为低延迟而配置的创新算法和数据库结构。
71.云计算架构包括多个服务和平台配置。
72.软件即服务(saas)被配置为允许平台提供方使用在云基础设施上运行的提供方的应用程序。可通过瘦客户端界面，诸如网页浏览器(例如，基于网页的电子邮件)从各种客户端设备访问应用程序。消费者通常不管理或控制底层云基础设施，包括网络、服务器、操作系统、存储，甚至单个应用程序功能，但有限的特定于用户的应用程序配置设置可能除外。
73.平台即服务(paas)被配置为允许平台提供方将消费者创建或获取的应用程序部
署到云基础设施上，该应用程序使用提供方支持的编程语言和工具创建。消费者不管理或控制底层云基础设施，包括网络、服务器、操作系统或存储器，但可控制部署的应用程序和可能的应用程序托管环境配置。
74.基础设施即服务(iaas)被配置为允许平台提供方提供处理、存储、网络和其他基本计算资源，其中消费者能够部署和运行包括操作系统和应用程序在内的任意软件。消费者不管理或控制底层云基础设施，但可控制操作系统、存储、部署的应用程序，以及可能对选定网络部件(例如主机防火墙)的有限控制。
75.云计算架构可被提供为私有云计算架构、社区云计算架构或公共云计算架构。云计算架构也可被配置为包括两个或多个云平台(私有、社区或公共)的混合云计算架构，这些云平台仍然是独特的实体，但通过标准化或专有技术绑定在一起，实现数据和应用程序的可移植性(例如，用于云之间的载荷平衡的云爆发)。
76.云计算环境是面向服务的，侧重于无状态性、低耦合、模块化和语义互操作性。云计算的核心是包括互连节点网络的基础设施。
77.现在参考图1b，示出了图示性云计算环境50。如图所示，云计算环境50包括一个或多个云计算节点30，具有云消费者使用的本地计算设备，例如个人数字助理(pda)或蜂窝电话23、台式计算机21、膝上型计算机22和事件，诸如oem车辆传感器数据源14、应用程序数据源16、远程信息处理数据源20、无线基础设施数据源17和第三方数据源15和/或汽车计算机系统，诸如车辆数据源12。节点30可以相互通信。它们可以在一个或多个网络(诸如本文阐述的私有云、社区云、公共云或混合云或它们的组合中)以物理方式或虚拟方式分组(未示出)。云计算环境50被配置为提供云消费者无需在本地计算设备上维护资源的基础设施、平台和/或软件即服务。应当理解，图1b中所示的计算设备的类型仅意在说明，并且计算节点30和云计算环境50可通过任何类型的网络和/或网络可寻址连接(例如，使用网页浏览器)与任何类型的计算机化设备通信。
78.现在参考图1c，示出了由云计算环境50(图1b)提供的一组功能抽象层。图1c所示的部件、层和功能是说明性的，本文阐述的实施方案不限于此。如图所示，提供了以下层和相应的功能：
79.硬件和软件层60可包括硬件和软件部件。硬件部件的示例包括，例如：大型机61；服务器62；服务器63；刀片服务器64台；存储设备65；以及网络部件和联网部件66。在一些实施方案中，软件部件包括网络应用服务器软件67和数据库软件68。
80.虚拟化层70提供了抽象层，从该抽象层可提供以下虚拟实体的示例：虚拟服务器71；虚拟存储器72；虚拟网络73，包括虚拟专用网络；虚拟应用程序和操作系统74；和虚拟客户端75。
81.在一个示例中，管理层80可提供以下所述的功能。资源供应81提供用于在云计算环境中执行任务的计算资源和其他资源的动态采购。计量和定价82提供了在云计算环境中使用资源时的成本跟踪，以及对这些资源的消耗进行计费或开票。在一个示例中，这些资源可包括应用程序软件许可证。安全性为云消费者和任务提供身份验证，以及对数据和其他资源的保护。用户门户83为消费者和系统管理员提供对云计算环境的访问。服务水平管理84提供云计算资源分配和管理，以满足所需的服务水平。服务水平协议(sla)规划和履行85根据sla预测未来需求的云计算资源提供预先安排和采购。
82.工作负载层90提供了可利用云计算环境的功能的示例。可从该层提供的工作负载和功能的示例包括映射和导航91；入口处理92，流处理93；门户仪表板传送94-相同编号；数据分析处理95；以及出口和数据传送96。
83.虽然本公开描述了关于云计算平台的实施方案，但是如本文阐述的实施方案的实现不限于云计算环境。本领域普通技术人员将理解，系统10的架构是非限制性示例，其说明实施方案的至少一部分。因此，在不脱离本文阐述的创新的范围的情况下，可采用和/或以不同的方式布置更多或更少的部件。然而，系统10至少足以公开本文要求保护的创新。
84.参考图2，示出了根据至少一个实施方案的用于摄取数据和数据吞吐量的入口服务器系统100的逻辑架构。在至少一个实施方案中，可确定来自一个或多个事件源的事件。在实施方案中，如图1a所示，事件源可包括车辆传感器数据源12、oem车辆传感器数据源14、应用数据源16、远程信息处理数据源20、无线基础设施数据源17和第三方数据源15等。在至少一个实施方案中，确定的事件可对应于可由系统的下游部件(诸如流处理服务器系统200和分析服务器系统500)管理的位置数据、车辆传感器数据、各种用户交互、显示操作、印象等。在至少一个实施方案中，入口服务器系统100可进入比图1a至图2所示更多或更少的事件源。
85.在至少一个实施方案中，可从一个或多个事件源接收和/或确定的事件包括来自一个或多个数据源的车辆事件数据，例如gps设备，或由第三方数据源15提供的位置数据表，诸如oem车辆传感器数据源14。可以以数据库格式(例如json、csv和xml)摄取车辆事件数据。可通过服务提供的api或其他通信接口和/或入口服务器系统100来摄取车辆事件数据。例如，入口服务器系统100可提供与入口服务器api 106集成的api网关102接口，该入口服务器api 106使入口服务器系统100能够确定可与车辆事件源14提供的数据库相关联的各种事件。示例性的api网关可包括例如aws api网关。入口服务器系统100系统的示例性托管平台可包括kubernetes和docker，但也可以采用其他平台和网络计算机配置。
86.在至少一个实施方案中，入口服务器系统100包括被配置为接受原始数据的服务器104，例如，可被配置为接受车辆事件数据的安全文件传输协议服务器(sftp)、api或其他数据输入。入口服务器系统100可被配置为将原始数据存储在数据存储器107中以供例如分析服务器系统500进行进一步分析。事件数据可包括点火开启、时间戳(tl...tn)、点火关闭、关注事件的数据、纬度和经度以及车辆信息编号(vin)信息。示例性事件数据可包括来自本领域已知来源的车辆运动数据，例如来自车辆本身(例如，经由gps、api)或由第三方数据源15提供的位置数据表。
87.在实施方案中，系统被配置为以更高的准确度检测和映射车辆位置。为了采集有关道路网络的有用聚合信息，例如，每天/每周周期内的预期交通量和速度，系统可被配置为确定车辆如何移动通过给定的道路网络。
88.在实施方案中，系统可被配置为包括作为道路分段的线分段的集合给出的底图。对于每条线分段，系统包括有关线分段与其最近邻线分段的关系的几何信息。对于每条线分段，从流程的初始迭代中生成有关预期交通量和速度的统计信息。如上所示，车辆运动事件数据包括经度、纬度、航向、速度和一天中的时间。
89.在实施方案中，系统被配置为获取对应于道路分段的线分段的集合，并为线分段的集合创建r树索引。r树是用于空间访问方法(即用于索引多维信息，诸如地理坐标、矩形
或多边形)的树数据结构。r树被配置为将空间对象存储为边界框多边形，以表示道路分段等。首先，r树用于在规定的坐标距离内寻找候选道路分段，以便捕捉数据点。然后，使用考虑了事件数据(诸如航向)的细化度量标准对候选道路分段进行进一步检查，选择道路分段，这最有可能基于所有已知的信息。诸如速度和/或一天中的时间之类的事件数据也可用于选择道路分段。系统被配置为例如使用如上所述的r树对边界框道路分段之间的距离进行预先限定。对于预先计算的道路分段的距离，系统可被配置为选择最近邻道路分段以获得最近的距离。具体地，系统被配置为识别点(纬度/经度)和道路分段(线分段)之间的距离。项目距离干线实施方式允许将距离中的任意两个点标识为道路分段。系统可被配置为基于从纬度/经度数据点中原始或默认选择最近点来选择道路分段。如上所述，道路分段可被限定为边界框或线分段。
90.在实施方案中，入口服务器系统100被配置为处理事件数据以获取车辆运动数据，例如速度、持续时间和加速度。例如，在实施方案中，每隔x秒(例如3秒)对事件数据库拍摄快照。然后，可处理纬度/经度数据和时间数据，以使用车辆位置和时间获取车辆跟踪数据，例如速度和加速度。
91.在实施方案中，入口服务器系统100被配置为接受来自设备和第三方平台的数据。入口服务器api 106可被配置为向系统10认证设备或第三方平台和平台主机。
92.因此，在实施方案中，入口服务器系统100被配置为接收原始数据，并且对原始数据执行数据质量检查和执行模式评估。摄取和验证原始数据是系统的质量检查的数据质量流水线的开始，如图7的方框701所示。表格1示出了可接收到系统中的原始数据的示例。
93.94.[0095][0096]
表格1
[0097]
在另一个实施方案中，来自入口源的车辆事件数据可包括更少的信息。例如，如表格2所示，原始车辆事件数据可包括有限数量的属性，例如位置数据(经度和纬度)和时间数据(时间戳)。
[0098][0099]
表格2
[0100]
本公开的实施方案的示例性优点是缺失的信息可依据本文阐述的创新算法获取。例如，车辆事件数据可不包括行程识别，或者可具有不准确的行程识别。因而，当初始进入的数据具有有限的属性时，系统可被配置为获取额外的车辆事件属性数据。例如，系统可被配置为针对进入的车辆事件数据识别特定的车辆并附加车辆id。因此，系统可仅使用例如与车辆id相关联的位置和时间戳数据来跟踪车辆运动，包括启动和停止、速度、航向、加速度和其他属性。例如，在实施方案中，系统可被配置为使用设备id并且识别与设备id相关联
的字段的状态变化。
[0101]
相反，在实施方案中，在入口的数据包括丰富的数据字段(诸如燃油油位、新的传感器数据(门打开/门关闭)、安全气囊展开或传感器趋势)的情况下，可使用该丰富的数据来扩充或修改本文所述的算法。
[0102]
在实施方案中，在方框702处，所接收的数据可符合外部定义的模式，例如avro或json。数据可被转换为内部模式并验证。在实施方案中，在事件数据被传递到消息传递系统以供数据质量流水线进行下游处理之前，可根据约定的模式定义对事件数据进行验证。例如，在将经验证的数据传递到apache kafka消息传递系统之前，可采用apache avro模式定义。在另一个实施方案中，原始运动和事件数据也可由客户端节点集群配置处理，其中，每个客户端是消费者或生产者，并且实例内的集群可在它们之间复制数据。
[0103]
例如，入口服务器系统100可被配置有pulsar客户端，该客户端连接到用于pulsar集群的apache pulsar端点。在实施方案中，apache pulsar端点跟踪上次读取的数据，允许apache pulsar客户端随时连接以从上次读取的数据中提取数据。在pulsar中，“标准”消费者接口涉及使用“消费者”客户端来监听主题，处理传入的消息，并在消息被处理完毕之后最终确认这些消息。每当客户端连接到一个主题时，客户端会自动从未被确认的最早消息开始读取，因为该主题的游标由pulsar broker模块自动管理。客户端的客户端阅读器接口使客户端应用程序能够以定制的方式管理主题游标。例如，pulsar客户端阅读器可被配置为连接到主题，以指定阅读器在连接到主题时从哪条消息开始读取。当连接到主题时，阅读器接口使客户端能够从主题中最早的可用消息或主题中的最新可用消息开始。客户端阅读器还可被配置为从最早消息和最新消息之间的某个其他消息开始，例如通过使用消息id从持久性数据存储器或缓存器中获取消息。
[0104]
在至少一个实施方案中，入口服务器系统100被配置为清理数据和验证数据。例如，入口服务器系统100可被配置为包括入口服务器api 106，该入口服务器api 106可验证所摄取的车辆事件数据和位置数据并将经验证的位置数据传递到服务器队列108，例如apache kafka队列108，然后，其被输出到流处理服务器系统200。服务器104也可被配置为将经验证的入口的位置数据输出到数据存储器107。入口服务器系统100还可被配置为将无效数据传递到数据存储器107。例如，可将无效载荷存储在数据存储器107中。示例性无效数据可包括，例如具有错误字段或未识别字段，或相同事件的数据。
[0105]
入口服务器系统100可被配置为输出所存储的无效数据或允许将所存储的数据从数据存储器107拉到分析服务器系统500以进行分析，例如，以改进系统性能。例如，分析服务器系统500可被配置有诊断机器学习，该诊断机器学习被配置为对具有未识别字段的无效数据的数据库执行分析，以重新识别和标记字段以进行验证处理。入口服务器系统100还可被配置为传递所存储的入口的位置数据以供分析服务器系统500处理，例如，用于进行如本文阐述的行程分析。
[0106]
如本文阐述，系统10被配置为在流上下文和批量上下文两者中处理数据。在流上下文中，低延迟比完整性更重要，即不需要处理旧数据，事实上，处理旧数据可能会产生不利影响，因为它可能会阻止其他较新数据的处理。在批量上下文中，数据的完整性比低延迟更重要。因而，为了便于在这两种上下文中处理数据，在实施方案中，系统可默认是流式连接，该流式连接在数据可用时立即进入所有数据，但也可被配置为跳过旧数据。批量处理器
可被配置为填充流处理器因旧数据而留下的任何间隙。
[0107]
图3是根据至少一个实施方案的用于数据吞吐量和分析的流处理服务器系统200的逻辑架构。如本文阐述的流处理实现系统处理改进，包括每秒至少200,000至600,000条记录的吞吐量线性扩展的改进。改进还包括20秒的端到端系统处理，并且正在进一步改进系统延迟。在至少一个实施方案中，系统可被配置为采用服务器进行微批处理。例如，如本文阐述，在至少一个实施方案中，流处理服务器系统200可被配置为在网络服务平台主机(诸如采用spark流服务器的aws)以及高吞吐量消息传递服务器(诸如apache kafka)上运行。在实施方案中，流处理服务器系统200可包括设备管理服务器207，例如aws ignite，其可被配置为输入来自数据处理服务器的经处理的数据。设备管理服务器207可被配置为使用匿名化的数据进行个别车辆数据分析，这些数据可从外部提供或连接。系统10可被配置为实时输出数据，以及将数据存储在一个或多个数据存储器中以供将来分析。例如，流处理服务器系统200可被配置为经由接口(例如apache kafka)向出口服务器系统400输出实时数据。流处理服务器系统200还可被配置为将实时数据和批量数据存储在数据存储器107中。数据存储器107中的数据可被访问或提供给深刻见解服务器系统500以用于进一步分析。
[0108]
在至少一个实施方案中，事件信息可被存储在一个或多个数据存储器107中，以供稍后处理和/或分析。同样地，在至少一个实施方案中，可以在确定或接收事件数据和信息时对其进行处理。此外，可将事件有效载荷和流程信息存储在数据存储器中，诸如数据存储器107，以用作历史信息和/或比较信息并用于进一步处理。
[0109]
在至少一个实施方案中，流处理服务器系统200被配置为执行车辆事件数据处理。
[0110]
图3示出了根据至少一个实施方案的结合了流处理服务器系统200的逻辑架构的概述流程图。在方框202处，流处理服务器系统200对来自入口的位置201的位置事件数据执行验证。格式不正确、重复或无法识别的数据将被过滤掉。示例性无效数据可包括，例如，具有错误字段、无法识别字段或相同事件(重复)的数据或在相同地点和时间发生的发动机启动/发动机关闭数据点。验证还包括延迟检查，丢弃早于预定时间段(例如7秒)的事件数据。在实施方案中，可采用其他延迟过滤器，例如在4秒至15秒之间。
[0111]
在实施方案中，流处理服务器系统200可被配置为对有错误的字段数据执行错误校正。例如，系统可被配置为缓冲入口的车辆事件数据，以在车辆的一系列数据点中识别出一组乱序的点。然后，系统可被配置为验证最早的数据点并丢弃其他数据点，或者系统可将车辆事件数据点重新排列为正确的时间序列。在实施方案中，可配置缓冲时间以优化系统的低延迟。系统200可被配置为缓冲最少数量的入口的数据点以允许进行错误识别和验证。例如，对于每3秒提供车辆事件数据的入口数据流，系统可被配置为缓冲至少3秒以识别错误，对所缓冲的车辆事件数据执行错误检查，并且校正事件数据以进行转发至下游。对于更频繁地(例如每隔一秒)提供车辆事件数据的入口流，缓冲可更少。
[0112]
在实施方案中，如图7中的方框703所示，流处理服务器系统200被配置为执行属性边界过滤。属性边界过滤检查以确保事件数据属性在对数据有意义的数据预定义边界内。例如，航向属性被定义为圆圈(0
→
359)。squish-vin是9个至10个字符的vin。示例包括由数据提供方预定义的或由标准设置的数据。不在这些边界内的数据值表示该数据对于该属性是固有错误的。可检查并过滤掉不合格的数据。表格3给出了属性边界过滤的示例。
[0113][0114][0115]
表格3
[0116]
在实施方案中，在方框704处，系统被配置为执行属性值过滤。属性值过滤检查以确保属性值在内部设置或自定义范围。例如，虽然1970年的日期可以通过事件的日期属性的属性边界过滤检查，但对于车辆跟踪数据来说，该日期并不是合理的值。因而，属性值过滤被配置为过滤早于预定时间(例如6周或更早)的数据，这些数据可被检查和过滤。表格3给出了属性边界过滤的示例。
[0117][0118][0119]
表格3
[0120]
在方框705处，系统可对记录中的属性执行进一步验证，以确认记录数据点的属性之间的关系是一致的。例如，非零行程开始事件对于如本文阐述的行程确定没有逻辑意义。因此，如表格4所示，系统10可被配置为过滤为相同属性记录的非零速度事件，以获取作为“tripstart”或行程点火启动事件的位置的捕获时间戳和接收时间戳。
[0121][0122][0123]
表格4
[0124]
返回图3，在方框204处，在至少一个实施方案中，流处理服务器200对位置事件数据执行地理哈希。尽管可以使用地理哈希的替代方案，例如ubertm所采用的h3算法或googletm所采用的s2算法，但人们发现地理哈希为系统10提供了示例性的改进，例如系统延迟和吞吐量的改进。地理哈希还为系统10准确性和车辆检测方面提供了数据库改进。例如，使用精确度为9个字符的地理哈希可允许车辆与地理哈希唯一地关联。可在如本文阐述的行程确定算法中采用此种精确度。在至少一个实施方案中，事件数据中的位置数据被编码为邻近区域，该编码包括将每个事件的纬度和经度地理哈希为每个事件的邻近区域。事件数据包括时间、位置(纬度/经度)和用于确定关注事件的数据。关注事件的数据可包括紧急制动和紧急加速。例如，紧急制动可被定义为在预定时间段内的减速(例如，在x秒内，从40到0)，紧急加速被定义为在预定时间段内的加速(例如，在x秒内，从40英里/小时到80英里/小时)。可关联和处理关注事件数据，以便在其他算法中使用。例如，在位置上映射到时空集群的紧急制动集群可用作拥堵检测算法。因此，当以m/s2为单位的车辆加速度的值高于既定的米/二次方秒阈值时，可将紧急加速定义为驾驶行为。例如，在实施方案中，speed_rate_of_change》＝2.638m/s2
·
speed_rate_of_change_positive＝true值给出了给定旅程或行程中的多个紧急加速事件。
[0125]
可关联和处理关注事件数据，以便在其他算法中使用。例如，在位置上映射到时空集群的紧急制动集群可用作拥堵检测算法。可提供馈送数据或将其与其他数据组合成聚合的数据集，并使用界面进行可视化，例如，gis可视化工具(例如：mapbox、carto、arcgis或
google maps api)或本文阐述的其他界面。
[0126]
地理哈希算法将来自事件数据的纬度和经度(lat/long)数据编码为n个字符的短字符串。在实施方案中，地理哈希的纬度/经度数据被地理哈希为形状。例如，在实施方案中，纬度/经度数据可被地理哈希为矩形，该矩形的边与字符串中的字符成比例。在实施方案中，地理哈希可被编码为4个至9个字符。
[0127]
采用如本文阐述的地理哈希的事件数据具有诸多优点。例如，在数据库中，由地理哈希索引的数据将具有连续切片中给定矩形区域的所有点，其中，切片的数量由编码的地理哈希精确度决定。这通过允许对单个索引进行查询来改进数据库，这比多索引查询更容易或更快。地理哈希索引结构对于简化的邻近区域搜索也很有用，因为最近的点通常在最近的地理哈希中。
[0128]
在方框206处，在至少一个实施方案中，流处理服务器系统200执行位置查找。如上所述，在实施方案中，系统可被配置为对地理哈希进行编码以识别限定的地理区域，例如国家、州或邮政编码。系统可将纬度/经度地理哈希为矩形，该矩形的边与字符串中的字符成比例。
[0129]
例如，在实施方案中，地理哈希可被配置为将地理哈希编码为5个字符，并且系统可被配置为将州识别为5个字符的地理哈希的位置。例如，编码为精确度为5个切片或字符的地理哈希精确到 /-2.5公里，这足以识别州。6个字符的地理哈希可用于将地理哈希的位置识别为邮政编码，因为它精确到 /-0.61公里。4个字符的地理哈希可用于识别国家/地区。在实施方案中，系统10可被配置为对地理哈希进行编码以唯一地识别具有地理哈希的位置的车辆。在实施方案中，系统10可被配置为将地理哈希编码为9个字符以唯一地识别车辆。
[0130]
在实施方案中，系统10还可被配置为将地理哈希的事件数据映射到地图数据库。地图数据库可以是例如关注点的数据库或其他地图数据库，包括公共的或专有的地图数据库。示例性地图数据库可包括现存的街道地图数据，诸如用于当地街道地图的geofabric或世界地图数据库。采用如本文阐述的地理哈希的示例性优势在于在下游处理时允许更快的、延迟较低且丰富的车辆事件数据。例如，地理定义、地图数据和其他丰富内容可以轻松地映射到地理哈希的位置和车辆id。也可将馈送数据组合成聚合的数据集并使用界面使其可视化，例如gis可视化工具(例如：mapbox、carto、arcgis或google maps api)或其他界面来生成和接口图形报告或将报告输出给第三方15，该第三方使用经处理的数据生成分析见解，例如，经由出口服务器系统400或门户服务器系统600。
[0131]
在至少一个实施方案中，在方框208处，流处理器服务器系统200可被配置为将数据匿名化以删除识别信息，例如，通过移除或模糊事件数据中的车辆数据的车辆识别号(vin)中的个人识别信息。在各个实施方案中，事件数据或其他数据可包括vin编码，其包括代表车辆的产品信息的编号，诸如品牌、型号和年份，还包括唯一地识别车辆以及可用于将其识别为属于某个车主个人的字符。系统10可包括算法，例如从车辆数据中删除vin中唯一地识别车辆的字符，但留下其他识别序列号(例如品牌、型号和年份)的算法，例如squish vin算法。在实施方案中，系统10可被配置为向匿名化的数据添加唯一的车辆标签。例如，系统10可被配置为向匿名化的数据添加唯一的编码、字符或其他识别信息，以便在删除了与vin相关联的个人识别信息之后，可跟踪、处理和分析唯一车辆的事件数据。匿名化的数据
的示例性优点在于匿名化的数据允许在外部提供经处理的事件数据，同时仍然保护数据中的例如可能法律要求或用户可能希望保护的个人识别信息。
[0132]
在至少一个实施方案中，如本文阐述，9个字符的地理哈希还可提供车辆的唯一识别而无需获得或需要个人标识信息，诸如vin数据。可通过处理数据库事件数据来识别车辆，并且将其地理哈希到可识别唯一的车辆的足够精确度，例如编码到9个字符，然后可识别、跟踪车辆，并如本文阐述的对它们的数据进行处理。
[0133]
如上所述，对于实时流处理，在方框202处，数据验证过滤掉具有过长延迟的数据，例如超过7秒的延迟。但是，批量数据处理可在没有间隙的情况下利用完整的数据集运行，因此可包括未过滤延迟的数据。例如，如关于图5所示的用于分析的批量数据处理可被配置为接受长达6周的数据，而流处理服务器系统200的流堆栈被配置为过滤超过7秒的数据，并且因此包括在方框202处的延迟验证检查，并拒绝具有更高延迟的事件。
[0134]
在方框209处，在至少一个实施方案中，流处理器服务器系统200对事件数据执行行程分段分析。在实施方案中，流处理器服务器系统200被配置为从事件数据识别车辆的行程，包括识别给定车辆的路线或运动是否是出于驾驶到行程目的地的目的，其中，该行程识别包括：识别车辆的发动机启动或第一次运动；识别车辆的发动机关闭或停止运动；确定车辆的停留时间；以及确定最短行驶持续时间。虽然行程分段处理被示出为在设备匿名化208之后开始，但是行程分段流程209可在进入数据201之后的任何点开始。
[0135]
在至少一个实施方案中，行程可包括从起点到最终目的地的一个或多个行程分段。行程分段包括车辆的发动机启动/开始运动和发动机关闭/停止运动事件之间的行驶持续时间和距离。
[0136]
然而，真实的驾驶员在前往目的地时可能有一个或多个停靠点。行程可以有两个或多个行程分段，诸如当有多个停靠点的行程时。例如，驾驶员在从家去上班时可能需要停下来加油或在红绿灯处停车。因此，车辆事件分析中的问题和挑战包括为如本文阐述的实施方案开发准确的车辆跟踪。尽管本领域中已经采用了其他行程算法或处理，例如，对从已识别车辆的已知目的地出发的行程进行反向工程，本公开包括使用如本文阐述的技术为不可知的车辆跟踪而开发和有利实施的实施方案和算法，包括数据分析、数据库、接口、数据处理和其他技术产品。
[0137]
在块210，流处理器服务器系统200被配置为执行计算以根据事件信息来限定行程。在实施方案中，流处理器服务器系统200被配置有行程检测标准，包括持续时间标准、距离标准和停留时间标准。在至少一个实施方案中，持续时间标准包括最短持续时间标准，其中，系统需要最短行驶持续时间以在行程中包括行程分段。在发动机启动或开始运动之后的最少行驶持续时间可包括行驶持续时间，例如，约60秒至约90秒。在示例性实施方案中，流处理器服务器系统200可被配置为要求车辆行驶超过60秒，以便将其包括为行程分段。例如，如果识别了车辆的(1)发动机启动/点火事件，或(2)在已知的(例如，前一次行程或行程的)最后一次运动之后识别的车辆的第一次运动，或(3)新识别的车辆的第一次运动，并且该事件之后的短行驶持续时间少于60秒，则流处理器服务器系统200被配置为从行程确定中排除该行程分段。流处理器服务器系统200被配置为确定车辆的短持续时间运动不是行程开始或目的地。
[0138]
在实施方案中，行程检测标准包括行驶距离标准，例如200米。流处理器服务器系
统200可被配置为从行程分段中排除200米或更短的距离。最短行驶距离标准可包括预定的行驶距离(例如，约100米至约300米)的持续时间。最短距离x(例如，200米)可被定义为包括最短距离x的约50％容差的指数。
[0139]
在实施方案中，停留时间标准可包括车辆的停止时间。例如，停留时间标准可以是约30秒至约90秒。最长停留时间可包括同一车辆的发动机关闭/停止运动和发动机启动/开始运动之间的停止持续时间，例如，约20秒至约120秒。例如，如果流处理器服务器系统200确定车辆停止或其发动机关闭少于30秒，则系统可被配置为不将该停止时段包括在行程结束或行程对象中。
[0140]
如上所述，在实施方案中，流处理器服务器系统200被配置为处理车辆事件数据以确定一个或多个行程分段是否包括车辆的行程。例如，发动机启动或开始运动事件之后的距离可以超过距离标准(例如超过200米)。因此，系统的持续时间标准将其识别为行程的分段。然而，如果该汽车此后停止并继续保持静止超过30秒，则流处理器服务器系统200被配置为不将其计为行程的分段。如果车辆随后停止少于30秒然后再次运动，则满足停留时间标准，并且流处理器服务器系统200被配置为将该行程分段包括在该车辆前往其最终目的地的行程中。因此，该算法可以将每天实时驾驶目的地的行程或行程对象的多个行程分段连接起来，例如，当驾驶员在家中启动汽车(发动机启动/开始运动)，行驶10英里(距离标准)，在红绿灯处停止29秒，继续行驶到工作的最终目的地(发动机关闭/停止运动)时。流处理器服务器系统200可被配置为忽略不太可能代表行程中断的事件，例如在红绿灯处停止29秒(停留标准)或运动少于200米(距离标准)或少于60秒(持续时间标准)。
[0141]
在实施方案中，例如，流处理器服务器系统200可以基于可变数据包括用于停留标准、距离标准或时间标准中的每一者的多个标准。因此，该算法可以将普通实时驾驶到目的地的行程的多个行程分段连接起来，其中关于车辆和位置的附加数据是已知的。例如，如果车辆被识别为合法上路的电动车辆，例如电动汽车，则停留标准可包括在被识别为充电站的位置处停留20分钟的最大停留时间标准。因此，例如基于有关位置的其他数据(例如，指示停靠点是诸如加油站、休息区或餐厅之类的关注点的数据)，停留时间可延长2分钟至20分钟之间。当电动汽车的驾驶员在家启动汽车(发动机启动或第一次运动)，行驶100英里(距离标准)到充电站进行充电(发动机关闭/停止运动、12分钟、停留标准、变量、充电站)，然后再次启动(发动机启动/开始运动)并继续行驶至销售会议的最终目的地(发动机关闭/停止运动)时，流处理器服务器系统200可被配置为识别行程。在另一个示例中，在由入口源提供丰富的数据(例如，燃油油位)的情况下，燃油消耗可用作标准。例如，停车时燃油的液位的微小变化(-002)可用于识别可被忽略的停留标准(例如，停车时间少于60秒，燃油液位有小幅下降)。因而，如将理解的，以上标准中的每一者可被配置为可变的，尤其取决于关于事件车辆数据点获取或获得的知识。
[0142]
在实施方案中，在方框211处，流处理器服务器系统200被配置为将行程分段聚合成行程对象。流处理器服务器系统200被配置为根据上述标准为给定设备识别候选行程分段链。此外，可实例化复合行程对象，其起点为链的开始，其终点为链中的最后分段的终点。可以从事件数据中提取单独的行程对象表格，并且可将获取的复合行程生成到另一个表格中。在实施方案中，包括所有发动机启动/发动机关闭或开始运动/停止运动事件的数据集被标识为唯一的车辆id或设备id。例如，车辆的发动机启动/发动机关闭或开始运动/停止
运动事件中的每一者可被放置在包括候选行程分段的单行上。然后，可以通过距离标准、持续时间标准和停留标准中的每一者来处理发动机启动/发动机关闭或开始运动/停止运动事件的行，以确定可以从行程对象的行程确定中包括或排除哪些行程分段。在实施方案中，流处理器服务器系统200可生成另一个行程表格，表格中填有依据满足上述行程标准的车辆的事件而确定的行程对象。
[0143]
在至少一个实施方案中，系统10被配置为通过分析车辆事件数据的数据库并将行程点汇总成具有诸如开始时间、结束时间、开始位置、结束位置、数据点计数、平均间隔等属性的行程对象来提供主动式车辆检测。在实施方案中，可以将行程对象放入单独的数据表格中进行处理。
[0144]
在示例性实施方案中，系统10可被配置为执行车辆跟踪，而无需预先识别车辆(例如，通过vin编号)。如上所述，可以对事件数据的数据库采用地理哈希以将数据地理哈希到9个字符的精确度，其对应于足以将事件与车辆唯一地相关的形状。在实施方案中，主动式车辆检测包括依据一段时间内的多项事件识别车辆路径。在实施方案中，主动式车辆检测可包括依据一天(24小时)的时间段内的多项事件识别车辆路径。该识别包括使用例如连通分量算法。在实施方案中，连通分量算法用于识别包含当天车辆事件的有向图中的车辆路径，其中，在该图中，节点是车辆并且节点之间的连接是识别的车辆路径。例如，创建行程起点和行程终点的图形，其中，节点代表起点和终点，边线是车辆采取的行程。在每条边线上，起点和终点按时间排序。创建边线以将终点连接到该节点的下一个起点，按时间排序。节点是gps坐标的9位数的地理哈希。连通分量算法查找连接的节点和边线的集合，并且在一天开始时将生成的设备id沿确定的子图传递，以唯一地识别由同一车辆采取的行程(边线)。
[0145]
本方法的示例性优点是无需预先识别事件数据的车辆。在满足如本文阐述的行程标准的车辆路径中的行程分段可用于检测行程并排除如上所述的不合格的行程事件。例如，显示车辆相隔x秒(30秒)的时间内从停止运动/发动机关闭到开始运动/发动机启动的被编码为9位数(最高分辨率)的事件数据的地理哈希可被视为行程的同一车辆。对于到达和离开的序列，可以通过图形将行程计算为行程分段的最短路径。
[0146]
在实施方案中，在方框212处，过滤了延迟的转换的位置数据和被拒绝的延迟数据两者均被输入到服务器队列中，例如apache kafka队列。在方框214处，流处理服务器系统200可将数据拆分成数据集，该数据集包括完整数据216(过滤了延迟的转换的位置数据和被拒绝的延迟数据)以及转换的位置数据的另一个数据集222。完整数据216存储在数据存储器107中，以用于访问或传送到分析服务器系统500，而过滤后的转换的位置数据被传送到出口服务器系统400。在另一个实施方案中，也可以将包括被拒绝的数据的完整数据集或其部分传送到用于第三方平台的出口服务器系统400，以供其自身使用和分析。在此类实施方案中，在方框213处，可将过滤了延迟的转换的位置数据和被拒绝的延迟数据直接提供给出口服务器系统400。
[0147]
在至少一个实施方案中，流处理服务器200可被配置为将事件数据和行程确定数据存储在数据仓库107中。可以以数据库格式存储数据。在实施方案中，时间列可被添加到处理的数据中。在另一个实施方案中，由于分析服务器500可被配置为独立于流处理服务器来执行行程确定，因此流处理服务器200的行程确定可出口到出口服务器400并且从流处理服务器中删除。
[0148]
图4是出口服务器系统400的逻辑架构。在至少一个实施方案中，出口服务器系统400可以是被布置为摄取、吞吐记录和输出事件数据的一台或多台计算机。出口服务器系统400可被配置为基于推或拉的方式提供数据。例如，在实施方案中，系统10可被配置为采用apache spark集群的推送服务器410。推送服务器可被配置为处理来自流处理服务器系统200的转换的位置数据，例如，用于延迟过滤411、地理过滤412、事件过滤413、转换414和传输415。如本文阐述，地理哈希极大地改善了系统10的吞吐量延迟，这使得在接近事件的情况下(例如在几分钟甚至几秒钟内)，处理的数据能够得到及时推送通知的优势。例如，在实施方案中，系统10被配置为以低于60秒的延迟为目标。如上所述，流处理服务器系统200被配置为过滤延迟少于7秒的事件，并且还提高了吞吐量。在实施方案中，可经由api网关404提供用于拉取数据的数据存储器406，并且拉取api 405可跟踪哪些第三方15用户正在拉取数据以及用户正在请求什么数据。
[0149]
例如，在实施方案中，出口服务器系统400可基于由系统10提供的过滤器提供模式数据。例如，系统可被配置为提供地理围栏过滤器412来过滤给定位置的事件数据。提供地理围栏过滤器412以过滤一个或多个给定位置的事件数据。如将理解的，地理围栏可被配置为如本文阐述的针对多种模式和配置界定和处理行程和事件数据。例如，在实施方案中，出口服务器系统400可被配置为提供“停车”过滤器，该过滤器被配置为将数据限制在由用户提供或选择的经度/纬度范围内的行程的起点和终点(点火-钥匙启动/关闭事件)。可配置此数据的更多过滤器或例外情况，例如按州(州代码或纬度/经度)。系统10还可被配置有“交通”过滤器以提供交通模式数据，例如，具有从过滤器中排除的给定州和纬度/经度边界框。
[0150]
图5表示用于数据分析和见解的分析服务器系统500的逻辑架构。在至少一个实施方案中，分析服务器系统500可以是被布置为分析事件数据的一台或多台计算机。实时数据和批量数据两者均可被传递到分析服务器系统500，用于本文阐述的其他部件进行的处理。在实施方案中，分析服务器系统500可采用集群计算框架和批量处理器，诸如结合了批量数据处理和流数据处理的apache spark集群。提供给分析服务器系统500的数据可包括，例如来自入口服务器系统100、流处理服务器系统200和出口服务器系统400的数据。
[0151]
在实施方案中，分析服务器系统500可被配置为接受可存储在数据存储器(诸如数据存储器107)中的车辆事件有效载荷和经处理的信息。如图5所示，存储包括来自出口服务器系统400的实时出口的数据、来自流处理服务器系统200的转换的位置数据和拒绝的数据、以及来自入口服务器系统100的批量和实时原始数据。如图2所示，存储在数据存储器107中的入口的位置可被输出或拉入分析服务器系统500。分析服务器系统500可被配置为以与图2所示的流处理服务器系统200相同的方式处理入口的位置数据。如上所述，流处理服务器系统200可被配置为将数据拆分成完整数据集216，完整数据集216包括完整数据(过滤了延迟的转换的位置数据和被拒绝的延迟数据)以及转换的位置数据222的数据集。完整数据集216存储在数据存储器107中，以用于访问或传送到分析服务器系统500，而过滤后的转换的位置数据被传送到出口服务器系统400。如图5所示，可处理实时过滤的数据以用于近乎实时的上报，包括运行522、入口与出口524、操作监控526和警报528的报告。
[0152]
因而，在图5的方框502处，在至少一个实施方案中，可选地，分析处理服务器系统500可被配置为以与图3中的方框202和图7中的方框701至705所示相同的方式对来自入口
的位置的原始位置事件数据执行验证。在实施方案中，如图7所示，在方框706处，系统10可以采用记录的批处理来对多个事件记录的属性执行进一步的验证，以确认事件数据点的属性之间的内部记录关系是有意义的。例如，如表格5所示，系统10可被配置为分析所分析的数据点以确保行程事件的逻辑顺序(例如：行程的行程事件可选“tripstart-tripend-tripstart”并且不重复“tripstart-tripstart-tripend-tripend)”。
[0153][0154]
表格5
[0155]
参照图5的方框504，在至少一个实施方案中，可选地，分析服务器系统500可被配置为对如图3中方框204所示的位置事件数据执行地理哈希。在图5的方框506处，可选地，分析服务器系统500可执行位置查找。在图5的方框508处，可选地，分析服务器系统500可被配置为执行设备匿名化，如图2的方框206和方框208所示。
[0156]
在方框510处，在至少一个实施方案中，分析服务器系统500可被配置为对如图3中方框209所示的事件数据执行行程分段分析。在方框512处，分析服务器500被配置为依据如图3中方框210所示的事件信息执行计算以限定行程。在至少一个实施方案中，在方框514处，系统10被配置为通过分析车辆事件数据的数据库并且将行程点汇总成具有如图2的方框211中所述的属性的行程对象来提供主动式车辆检测。分析服务器系统中采用的行程分段算法的说明在美国专利申请第16/787755号中进行了描述，该专利申请的名称为“system and method for processing vehicle event data for journey analysis”，其全部内容通过引用方式并入本文。
[0157]
在至少一个实施方案中，在方框515处，系统10可被配置为将事件数据和行程确定数据存储在数据仓库517中。可以以数据库格式存储数据。在实施方案中，时间列可被添加到处理的数据中。在实施方案中，数据库还可包括关注点(poi)的数据。
[0158]
分析服务器系统500可包括分析服务器部件516以对存储在数据仓库517中的数据执行数据分析，例如spark分析集群。分析服务器系统500可被配置为执行评估530、聚类531、人口统计分析532和定制分析533。例如，可以将日期列和小时列添加到数据以处理存
储在仓库517中的行程数据和位置数据。这可用于定制分析533，例如，根据日期和时间确定交叉口x处的车辆数量。系统10还可被配置为在出口服务器系统400处提供定制分析533，如图4所述。4.
[0159]
在实施方案中，可将地理空间索引行添加到存储的仓库517数据，例如，以执行超本地目标定位或加速对地理哈希的数据的即席查询。例如，解析为4位小数或4个字符的位置数据可对应20米或以下的分辨率。
[0160]
分析服务器系统500可被配置有诊断机器学习534，该诊断机器学习被配置为对具有未识别字段的无效数据的数据库执行分析，以重新识别和标记字段以进行验证处理。
[0161]
在实施方案中，系统10可被配置为执行如方框510所述的行程分段的批量分析。例如，在图7的方框707处，行程分段提取可包括通过识别标有唯一id的所有事件进行简单的行程提取。行程分段提取及计数的示例如表格6所示。
[0162][0163]
表格6
[0164]
系统10还可被配置为使用如方框512所述的用于图7的方框708处的行程值过滤的行程标准依据事件信息执行计算以限定行程。行程值过滤的示例如表格7所示。
[0165][0166]
表格7
[0167]
在实施方案中，可处理批量数据以用于系统性能上报535。例如，在实施方案中，系
统10可被配置为生成关于系统延迟的报告。针对捕获的和接收的时间戳数据之间的百分比范围进行的批量分析延迟上报的示例如表格8所示。系统10可被配置为对潜在数据执行间隔分析。针对百分比范围进行的间隔/捕获率上报的示例如表格9所示。
[0168][0169][0170]
表格8
[0171][0172][0173]
表格9
[0174]
图6是门户服务器系统600的逻辑架构。在至少一个实施方案中，门户服务器系统600可以是被布置为摄取和吞吐记录和事件数据的一台或多台计算机。门户服务器系统600可被配置有门户用户界面604以及用于门户api 608的api网关606，以与平台第三方15用户进行接口并接受其数据在实施方案中，门户服务器系统600可被配置为提供每日静态聚合并被配置有搜索引擎和访问门户，用于实时访问由分析服务器系统500提供的数据。在至少一个实施方案中，门户服务器系统600可被配置为向用户(例如，向第三方15客户端计算机)提供仪表板。在至少一个实施方案中，来自分析服务器系统500或流处理服务器系统200的信息可流向由门户用户界面604提供的报告生成器。在至少一个实施方案中，报告生成器可被布置为基于运行信息生成一个或多个报告。在至少一个实施方案中，可基于一个或多个报告模板来确定报告并使报告格式化。
[0175]
在至少一个实施方案中，仪表板显示器可呈现显示由系统10的其他部件产生的信息。在至少一个实施方案中，仪表板显示器可呈现在通过网络访问的客户端计算机上。在至少一个实施方案中，可在不脱离要求保护的主题事项的精神和/或范围的情况下采用用户界面。此类用户界面可具有任意数量的用户界面元素，这些元素可以以各种方式布置。在一些实施方案中，可使用网页、移动应用程序、gis可视化工具802、映射界面、电子邮件、文件服务器、pdf文档、文本消息等来生成用户界面。在至少一个实施方案中，入口服务器系统
100、流处理服务器系统200、出口服务器系统400、分析服务器系统500或门户服务器系统600可包括用于生成用户界面的流程和/或api。
[0176]
图7是示出了如上所述的数据处理的数据流水线的流程图。如图7所示，在实施方案中，事件数据通过七(7)个阶段的数据质量检查流水线来传递数据。此外，采用流处理和批处理两者进行数据处理。流式处理一次对一条记录进行操作，不保存行程的任何先前记录的上下文，并且可用于在属性和记录级别执行的检查。批处理可查看更完整的数据，并且可包含完整的端到端流程。批处理执行与流式处理相同的检查以及对跨多个记录和行程执行的检查。
[0177]
低延迟提供了将信息从车辆源传送到最终用户的超快速连接。进一步的数据捕获实现每个数据点3秒的高捕获率，例如，每个月捕获多达3300亿个数据点。如本文阐述，数据精确到具有位置数据的车道级别并且95％精确到3米半径范围内，即典型汽车的尺寸。如本文阐述，车辆数据精确到交叉路口级别，能够识别哪些道路拥堵或畅通，包括确切的拥堵位置和时间。这种新的细粒度信息为最终用户和合作伙伴(例如，交通运输部门和其他道路安全管理机构以及交通应用程序开发人员)赋能。系统可被配置为提供分析和界面，尤其是拥堵监控、收费公路使用和信号发送，使用速度和行驶方向实时提供精确的交通信息。
[0178]
例如，在实施方案中，本文阐述的系统可被配置为为交通流提供新的视角和直观的界面。系统可被配置为向最终用户提供准确的历史交通量视图，并揭示交通数据中的潜在模式，这些模式仅靠当前的监控和测量技术并不是始终可见。这还有助于用户了解和管理季节性交通趋势、为行驶时间建模并且例如在建设项目或重大体育活动或音乐活动期间，规划更有效的路线。交通情报精确地确定车辆流量，以识别真正的趋势并预测行为。它揭示了多种道路交通运行情况，以缩短驾驶员到达其目的地的时间。
[0179]
在实施方案中，系统可被配置为对一段时间内(例如，1个月的时间段内)的在给定道路分段出现的所有数据点进行地理围栏。在实施方案中，可通过在关注区域周围绘制多边形“捕捉”到道路网络来选择道路分段。一旦选择了道路分段，就可基于与每个事件相关联的gps轨迹的纬度和经度来绘制所有极端驾驶事件。该映射的事件数据可用于产生分析结果，该分析结果可提供给如本文阐述的界面。
[0180]
在实施方案中，馈送输出可包含交通密度图，该交通密度图依据地图上显示的任何选定道路网络的关注事件得出。可选择多段时间内的输出。例如，输出可将整个月的数据作为聚合视图进行查看。也可将输出呈现为每日明细的月度汇总。还可将输出呈现为每日明细。如将理解的，可选择任意时间段以查看事件分析输出。
[0181]
如本文所示，系统被配置为提供额外的数据分析，捕获和提供驾驶行为和交通行为，包括例如：
[0182]
在超速事件主要集中的道路上；
[0183]
超速是否与道路限速的变化相关；
[0184]
在相同的区域，紧急制动和快速加速是否直接相关；以及
[0185]
工作日/周末司机的通勤行为是否有所不同。
[0186]
图8是示出第一英里/最后一英里互联的数据处理的示例性数据流水线的流程图。如图8所示，如本文阐述，将错误的数据点删除并且生成干净的数据，可对这些数据进行可视化处理或输出到界面。识别特定地区的数据。例如，对地区的事件数据进行地理围栏，位
置数据被解析为例如小数点后6位(例如，9msq)。可使用道路网络数据库限定道路网络，例如，包括usgs national transit dataset的数据库。可使用可视化工具902为整体地理围栏数据集绘制数据。
[0187]
例如，如图9所示，也可以将馈送数据组合成聚合数据集并使用界面902使其可视化，例如gis可视化工具(例如：mapbox、carto、arcgis或google maps api)或其他界面。在实施方案中，针对来自佛罗里达州和纽约的互联车辆(cv)事件数据的示例性数据处理，下面描述了一种系统，该系统被配置为提供cv深刻见解以及用于该系统的交通产品界面902，如图10至图29b的界面所示。在图10至图29b所示的示例中，界面还可被配置为，例如，通过出口服务器或门户服务器，使得用于产生分析深刻见解的经处理的数据直观可视化。如图9所示，数据馈送可包括示例性馈送，诸如交通运输数据集904、交通运输时间表906和被地理围栏的互联车辆运动数据906，包括行程数据。
[0188]
图10至图29b表示根据各个实施方案中的至少一者的用于cv深刻见解可视化的图形用户界面902。在至少一个实施方案中，可在不脱离本公开的精神和/或范围的情况下，采用用户界面902。此类用户界面902可具有任意数量的用户界面元素，这些元素可以以各种方式布置。在一些实施方案中，可使用网页、移动应用程序等生成用户界面。在至少一个实施方案中，入口服务器100、流处理服务器200、出口服务器400、分析服务器500或门户服务器600可包括用于生成用户界面的流程和/或api。
[0189]
在实施方案中，针对来自佛罗里达州和纽约的互联车辆(cv)事件数据和行程数据的示例性数据处理，下面描述了一种系统，该系统被配置为提供cv行程和数据深刻见解以及用于该系统的交通产品界面902，如本文阐述，如图10至图29b的界面902。如上面关于图9所述，数据馈送可包括示例性馈送，诸如交通运输数据集904、交通运输时间表906和被地理围栏的互联车辆运动数据906，包括行程数据。例如，在一个月的时间里，分析了迈阿密北部劳德代尔堡超过75000辆汽车的信息，涵盖350万次行程。在此期间，发生了7,000多起道路交通事故。如本文阐述的行程数据分析和地理围栏与映射数据库相结合，以识别存在导致紧急制动和事故的道路状况、布局或标志问题的位置和poi。研究发现，紧急制动和交通碰撞之间存在很强的关联，但也存在一些紧急制动发生率很高却没有发生碰撞的位置。因此，如本文阐述的界面能够精确定位与源于行程的关注事件相关联的交通区域和道路特征，从而可用于例如预防或查找事故原因。
[0190]
例如，图10示出布劳沃德县的所有公共汽车服务停靠点和路线。为了以可读的格式显示交通运输数据，首先将数据可视化为整体图像，然后重点关注特定的路线和服务上，以提供更深入的上下文。在下面的图中，界面902以白色显示公共汽车路线912和所有可用的公共汽车停靠点914，以允许用户立即看到关注区域以进行潜在研究。
[0191]
图11是示出布劳沃德县的服务1的公共汽车路线912和停靠点914的界面902。图12是示出布劳沃德县的服务19的公共汽车路线和停靠点的界面。
[0192]
图13a至图13b示出了显示布劳沃德县的路线72的公共汽车路线912和停靠点914的界面。13a至图13b的界面示出了按停靠点类型划分的布劳沃德县的服务72的公共汽车路线912和停靠点914，包括符合《美国残疾人法案》(ada)的法律规定的停靠点。深色停靠点914b表示非ada公共汽车停靠点(不适合轮椅进出)，浅色停靠点914a表示符合ada的深色停靠点。图13b示出了图13a中的标注，图13a示出了非ada公共汽车停靠点914b的集群以及沿
路线72的符合ada的公共汽车停靠点914a的潜在间隔。如图13c和图13d所示，选择了路线72以供进一步分析是因为使用量很大而且它在整个周末期间运营。如图13c所示，与星期一至星期六的行程数量相比，路线72的行程安排的覆盖率较高。如图13d所示，由于更严格的运营时间，路线72的行程安排错过了星期日的大部分行程。经处理的数据界面显示，在公共汽车路线的西南区域，几乎没有符合ada标准的停靠点。
[0193]
图14示出在公共汽车路线上花费至少其行程5分钟的所有联网车辆(cv)行程的界面。在实施方案中，系统可被配置为实现每条路线上可实现的阈值，以显示路线上的行程时间的比例。例如，系统可被配置为显示20分钟的公共汽车路线上花费至少15分钟的行程。对行程进行了分析，以确定哪些车辆行程在任意时间点经过了路线72。为确保数据正确简洁，仅选择了沿路线72花费了5分钟或更长时间的行程。发现有些行程很长。例如，图14示出在地图顶部中心处的行程915可跟随到地图的右下侧。朝向地图左侧的另一个行程916穿过整个县到达地图的右侧。
[0194]
图15示出了放大图14的一部分以通过数据叠加使行程可视化的界面。如上所述，特别关注了服务72的公共汽车路线914，因为有多个行程均在这条路线上开始和结束。放大之后，发现多个行程发生在路线72上、该路线周围和通过该路线(整个地图中心突出显示的路线)。据推测，第一英里互联可多次复制这段行程。
[0195]
图16示出界面902，该界面显示从该县的西北部开始并最终在72公共汽车路线914上结束其行程的cv行程915。界面902可被配置为查看行程并且使用户能够查看，例如穿过整个州的特定行程915。这可用于获取有关行程行为的潜在深刻见解。例如，可通过查看最后一英里的行程时间与行程的其余部分，鼓励多式行程(即，行驶通过公共交通运输可解决的行程的最后一英里是否需要更长的时间？)。
[0196]
图17a的界面902示出再现了路线72的约90％的行程的互联车辆行程917。行程917的最终终点917e距离公共汽车路线914仅较短的距离。在这里，界面示出实际上再现了公共汽车路线914的行程917，除了起点和终点正好落在路线之外。作为参考，行程的开始917s(地图界面的左侧)继续到行程的较深颜色部分(行程在917e结束的地图界面的右侧)。图17b示出围绕路线72的事件聚类的界面示例，其突出显示了在给定的一天中，行程的起点和终点位于相对比较邻近路线72的附近区域。示出了超过1个月的所有行程起点和终点的事件聚类，示出了行程起点和终点明显集中沿着sr 816高速公路上的突出显示的公共汽车路线914。这就产生了一个问题：为什么人们不乘坐沿着这条路线的公共汽车？
[0197]
图18a示出重点关注行程起点与ada可用停靠点的热图界面902的示例。深色点表示非ada停靠点914b，浅色点表示符合ada的停靠点914a。热图在界面902上显示图17b中的事件聚类，该界面显示行程起点明显集中与非ada停靠点重叠。
[0198]
图18b示出重点关注行程起点与ada可用停靠点的另一示例热图界面902。粗线表示铁路路线919(trirail路线)。通过界面，可以很容易地看到，可视化的右侧的密度更高，但是在其中一个区域上，只有不符合ada的公共汽车停靠点914b。这凸显了沿该路线的特定道路分段投资更多公共汽车停靠点的潜在需求。也可以假设ada停靠点周围所需的基础设施不足(即用于停车和乘车的基础设施，司机停车和乘坐公共汽车的机会很少)。
[0199]
更仔细地研究密度更高的区域，界面显示有两个清晰可见的特定位置。图像中心处的区域920是唯一一个只有不符合ada的公共汽车停靠点914b的区域。在研究特定位置之
后，确定了这是一个购物中心。因此，鉴于到访那里的人数，可假设应该有更多的ada公共汽车停靠点。这可能会增加从购物中心开始的高密度行程区域，因为在附近没有其他公共出行的方式。
[0200]
图19a至图19e示出示例性视频热图界面的一系列屏幕截图，示出了行程热点的车辆行程趋势。从图18b中突出显示的热点区域，从具有不符合ada的停靠点的区域920开始绘制行程。视频界面被配置为显示6小时内的行程。界面显示从该区域920开始并随后沿其他公共汽车路线行驶的行程可拼接在一起，以进行多式联运。
[0201]
图20a示出显示trirail路线921的界面。通过利用trirail时间表和路线数据，绘制出了每个trirail停靠点和班车停靠点。深色点922表示trirail停靠点，而浅色点923表示班车停靠点。如图20a所示，在一些位置缺少班车停靠点，而在其他位置则存在过度索引，例如图18b中的cypress creek停靠点。
[0202]
图20b示出了沿着与公共汽车路线921完全相同的路线进行的行程924，其中，在行程924s的起点有一个小弯路。当进一步研究为什么司机可能会再现路线时，分析了行程数据中的行驶时间，发现汽车的路线大约需要1小时3分钟才能完成，但是公共汽车则需要1小时53分钟至2小时33分钟才能完成，其中，从行程起点到最近的公共汽车停靠点需要额外步行33分钟。
[0203]
图21详细示出cypress creek停靠点乘坐的3趟班车的路线925、路线926、路线927。图22是显示trirail班车路线925、926、927的界面902，并详细示出了cypress creek班车服务的3趟班车路线925、926、927的行程的拥堵程度。界面902显示，在行程数据内，在特定区域928(magnolia park站)周围存在高密度的交通量。更仔细地查看之后，发现公共汽车路线921在此处终止，要继续向北行进的乘客需要更换公共汽车路线。
[0204]
图23a至图23e示出在magnolia park站的停靠点928处的多个行程930至935。这一系列界面示出了最终在trirail路线921上的magnolia park停靠点928结束的行程930至935的起始位置。关注的行程如下：
[0205]
图23d清楚地示出本来可以通过trirail完成的行程935。图23a、图23c和图23e中示出的行程930、931、932示出了多式行程机会的示例。每个行程930、931、932的第一部分前往trirail，在那里本来可以将汽车换成铁路，但事实并非如此。
[0206]
图24是示出行程再现的界面。该图像详细示出了cv的行程936，其完美地再现了从南到北的trirail行程921。该车辆在magnolia park停靠点928的地区结束了它的行程。行程936再现引发了一个问题，即为什么在这种情况下车辆没有采用trirail。行程数据分析结果显示，该车辆行程936总共需要1小时3分钟才能完成其行程，其中包括大约20分钟的停靠。相比之下，如果通过trirail完成相同的行程，则可能需要1小时53分钟至2小时33分钟才能到达目的地。
[0207]
图25示出了在劳德代尔堡机场trirail停靠点附近开始的行程的数量。在1个月的时间里，超过150次行程在trirail停靠点附近开始。可以假设，cv数据用于显示trirail广告在特定区域的影响，例如，通过确定投放广告之后，起始点在该区域的cv行程的数量是否减少。
[0208]
通过分析交通运输数据连同cv行程数据，很明显，系统可被配置为通过使用cv数据可以影响多式转变。观察到的多个行程和行为有利于多式联运转变的机会。为了影响多
式联运的任何转变，必须有令人信服的理由让司机选择乘坐trirail或公共汽车路线，这并不意味着通勤时间更长。
[0209]
图26a示出界面902，该界面显示了佛罗里达收费公路沿线的紧急制动事件的可视化。深色圆圈937表示聚类紧急制动事件，而白色圆圈938表示紧急加速事件。图26b示出界面902，该界面显示了热映射的超速事件939。图26a的可视化与图26b的超速可视化相结合，突出显示了佛罗里达收费公路沿线的潜在风险区域和事故热点。界面902显示制动事件和加速事件集中在沿该道路分段的交叉点。
[0210]
就交通而言，纽约市是世界上第三大拥堵城市，也是美国第二大拥堵城市，仅次于世界上最拥堵的城市洛杉矶。在2017年，纽约市司机堵车时间为平均91个高峰小时，与莫斯科并列第二。纽约市司机有13％的时间是在拥堵中度过，其中的11％是因白天交通拥堵造成。
[0211]
图27a至图27c示出包括布朗克斯皇后区高速公路(bronx queens expressway,boe)可视化的界面902，该高速公路被分为三个分段，以考虑粒度。较浅颜色的阴影939(界面上为绿色)表示缓慢移动的交通，标度移动到较深颜色的阴影940(界面上为深蓝色)以显示更高的速度。因此，界面902被配置为显示bqe沿线的多个潜在拥堵点，指示可能因通勤者路线而造成交通拥挤或一般城市拥堵。也可能存在道路工程或施工分段，导致交通缓慢。
[0212]
图28示出了bqe的界面可视化，示出了聚类紧急制动和加速事件，较暗颜色的圆圈937示出了聚类紧急制动事件，而浅色圆圈938示出了紧急加速事件。分析和界面显示在道路转弯处出现的次数更多，与图27a至图27c的速度热图一致。
[0213]
图29a至图29b示出了界面902，可视化了覆盖在一组事故热点数据的事故热图940上的图28的紧急制动事件937。图29a至图29b建立了两个实例之间的直接相关性。界面902还示出了紧急加速事件938和事故热点数据的热图940(图29b)之间的相同的相关性。因此，该系统被配置为识别并提供直观界面，确认与源于行程和关注事件算法的事故相关的一般交通行为。
[0214]
在实施方案中，可用poi数据库中的poi数据来丰富数据以供进一步发现。例如，在实施方案中，如上所述，将行程数据聚类并与体育活动和音乐会分层。研究发现，在滚石乐队举行音乐会的那天，乘车前往纽瓦克自由国际机场的时间比平均时间长15分钟。只要提前10分钟离开音乐会或nfl比赛，粉丝们即可避免当地最严重的交通拥堵情况。因此，系统可被配置为识别行程、执行事件分析、识别poi并提醒用户最好何时上车以避免拥堵。
[0215]
应当理解，流程图的每个方框以及流程图中的方框的组合可由计算机程序指令实现。可将这些程序指令提供给处理器以产生机器，使得在处理器上执行的指令创建用于实现在流程图方框或方框中指定的动作的装置。计算机程序指令可由处理器执行以使得处理器执行的一系列操作步骤产生计算机实现的流程，使得在处理器上执行的指令提供实现一个或多个流程图方框中指定的动作的步骤。计算机程序指令还可使流程图的方框中所示的至少一些操作步骤并行执行。此外，一些步骤还可以跨多个处理器执行，诸如可能出现在多处理器计算机系统中，甚至可能出现在一组多计算机系统中。此外，在不脱离本公开的范围或精神的情况下，流程图中的一个或多个方框或方框的组合也可以与其他方框或方框的组合同时执行，甚至以与所示出的不同的顺序执行。
[0216]
因而，流程图的方框支持用于执行指定动作的组合、用于执行指定动作的步骤的
组合以及用于执行指定动作的程序指令装置。还应理解，流程图的每个方框以及流程图中的方框的组合可由基于专用硬件的系统实现，该系统执行指定的动作或步骤，或者专用硬件和计算机指令的组合。前述示例不应被解释为限制性和/或详尽无遗，而是说明性用例以示出各个实施方案中的至少一者的实施方式。