【论文阅读】-- Visual Exploration of Big Spatio-Temporal Urban Data: A Study of New York City Taxi Trips

---

期刊: IEEE Transactions on Visualization and Computer Graphics（发表日期: 12/2013）
作者: Nivan Ferreira; Jorge Poco; Huy T. Vo; Juliana Freire; Claudio T. Silva

摘要

随着越来越多的城市数据被捕获和可用，数据驱动分析出现了新的机会，可以通过基于证据的决策和政策改善公民的生活。在本文中，我们关注一个特别重要的城市数据集：出租车出行。出租车是有价值的传感器，与出租车行程相关的信息可以提供对城市生活许多不同方面的前所未有的洞察，从经济活动和人类行为到出行模式。但分析这些数据提出了许多挑战。这些数据很复杂，除了与每次旅行相关的多个变量之外，还包含地理和时间成分。因此，很难指定探索性查询并执行比较分析（例如，随时间比较不同区域）。由于数据规模庞大，这个问题变得更加复杂——纽约市平均每天有 500,000 次出租车出行。我们提出了一种新模型，允许用户直观地查询出租车行程。除了标准分析查询外，该模型还支持出发地-目的地查询，从而能够研究整个城市的流动性。我们证明该模型能够表达广泛的时空查询，而且它非常灵活，不仅可以组合查询，还可以应用不同的聚合和视觉表示，允许用户探索和比较结果。我们构建了一个可扩展的系统来实现该模型，该模型支持交互式响应时间；利用自适应细节层次渲染策略为大型结果生成整洁的可视化；并通过使用叠加热图向用户显示隐藏的详细信息。我们提出了一系列由交通工程师和经济学家推动的案例研究，展示了我们的模型和系统如何使领域专家能够执行他们以前无法完成的任务。
关键词：时空查询；城市数据；出租车移动数据；视觉探索

1 引言

历史上第一次，世界上一半以上的人口居住在城市地区。使城市能够有效地提供服务，高效、可持续地发展是本世纪最重要的事业之一。虽然在不久前，决策者和社会科学家在获取了解城市动态和评估政策和实践所需的数据方面面临着巨大的限制，但现在数据已经很丰富了。许多城市已经开始提供广泛的数据集，例如参见[24,10,7]。现在的挑战是如何理解这些数据。

我们研究了一个特别重要的城市数据集：出租车出行。在纽约市，每天有 13,000 辆出租车载客超过 100 万人次，平均出行次数为 500,000 次，每年总计超过 1.7 亿次。因此，出租车出行是城市生活的宝贵传感器。考虑一下图 2 中的图，它显示了 2011 年和 2012 年每天的出行次数如何变化。有很多规律性：这两年的图线非常相似。例如，感恩节、圣诞节和除夕夜，出行数量大幅下降。但剧情也显示出一些异常现象。 2011 年 8 月和 2012 年 10 月出现大幅下降，分别对应飓风“艾琳”和“桑迪”。更细粒度地观察数据，会出现其他有趣的模式。图2中的地图显示了2011年5月1日早上7点到11点整个曼哈顿的出租车密度。早上8点到10点，出租车沿着第六大道消失，从中城到市中心；然后，上午 10 点他们又出现了。事实证明，在此期间，街道因五博罗自行车之旅而禁止通行。1 正如我们稍后讨论的，通过分析这些数据可以发现其他有用的信息，包括热门夜生活场所和服务不足的经济弱势社区乘坐出租车，了解不同时间和日期跨地区的出行模式（见图 1）。

与许多城市数据集一样，出租车行程包含地理和时间成分。此外，它们还对有关运动的信息进行编码：一次行程与上车和下车的位置和时间相关联。行程还包含其他属性，包括出租车 ID、行驶距离、票价和小费金额，例如，可以用于研究票价结构和最佳车队规模的经济学。毫不奇怪，探索这些数据具有挑战性。我们对社会科学家和工程师进行了采访，他们在研究中使用了该数据集，以更好地了解他们的需求。他们的分析可能很复杂，并且受到数据大小的极大限制。常用的工具，包括R、MatLab、Stata、ArcGIS和Excel，都无法处理大型数据集。这使得科学家无法分析整个数据。相反，他们首先选择小切片，然后将它们加载到这些工具中进行分析。这个过程既乏味又耗时。此外，虽然这些工具支持复杂的分析，但用户必须熟悉底层语言。例如，在 ArcGIS 中，用户必须构建类似 SQL 的查询，对于没有接受过数据库培训的科学家来说，这项任务是遥不可及的。

为了解决这些限制，在本文中，我们提出了一种新的可视化查询模型，该模型支持对起始目的地（OD）数据的复杂时空查询。用户不需要是任何文本查询语言的专家：他们可以使用可视化操作直接查询数据。我们证明该模型支持广泛的查询，特别是 Peuquet 类型学中的三类查询 [29]： 识别给定位置和时间的一组对象；给定时间和一组物体，描述物体占据的位置；并描述一组物体占据一组给定位置的时间。该模型还支持探索出租车移动所需的出发地-目的地查询。虽然视觉语言是针对时空数据和移动物体提出的，但它们针对的是不同类型的数据——连续数据（即完整的轨迹），并使用了图形语言[18, 12]。我们的模型允许用户直接（直观地）操作数据，而不是要求用户草拟查询。使用图形小部件指定查询并可视化其结果的能力部分受到 Ahlberg 等人的开创性工作的启发。 [2]关于动态查询。然而，我们的重点不同：我们的目标是支持大型时空 OD 数据的探索，并提供既可用又高效的可视化服务。我们模型的另一个重要特征是每个查询都与一组行程相关联。因此，不仅可以组合和细化查询，还可以聚合查询结果并应用不同的视觉表示，同时仍然保持空间和时间上下文。查询组合还支持使用交叉过滤视图 [37]，这是我们的模型支持 Peuquet 类型学中的查询类的关键。

我们构建了 TaxiVis，一个实现该模型的分析环境。它结合了多种交互功能，使用户能够对数据的所有维度进行查询，并灵活地探索与出租车行程相关的属性。该系统的另一个重要特征是能够通过多个协调视图来比较时空切片。用户可以交互地编写和细化查询，并通过执行参数扫描来概括它们。为了处理可扩展性，系统实施了许多策略来支持交互式响应时间和在地图上渲染大量图形图元。正如第 2 节中所讨论的。 5，这些包括高效的数据存储，以及使用自适应细节层次渲染来提供清晰的结果可视化。

我们通过一系列由交通工程师和经济学家推动的案例研究来证明我们系统的实用性，他们的需求推动了我们的设计。这些案例研究展示了我们的模型（和系统）如何使领域专家能够执行他们以前无法完成的任务。

2 相关工作

分析出租车数据。认识到可以从出租车数据中获取大量信息，最近，一些工作集中在它们的分析上。葛等人。 [19] 和袁等人。 [39]为出租车司机提出了推荐系统，以优化寻找乘客的成本（从而减少气体排放）。潘等人。 [26]使用接送信息根据土地用途对位置进行分类。维罗索等人。 [35, 34] 使用出租车数据来研究里斯本的人员流动性。他们探索了上车和下车地点的分布模式以及与城市环境的关联。梁等人。 [22]研究了北京的出租车数据，发现出租车的位移分布与大多数人员流动数据的分布不同。彭等人。 [28]分析了上海158万次出租车出行，通过建模算法得出结论，人们在工作日出行主要出于三个目的：家庭和工作场所之间的通勤、工作场所之间的出行以及休闲活动等其他目的。廖等人。 [23] 设计了一个视觉分析系统来检测出租车产生的 GPS 流中的异常情况。他们生成流的可视化，应用异常检测模型，并利用用户交互来逐步改进他们的模型。这些工作都有一个重要的要求：需要进行探索性分析。我们提出的可视化查询模型和可扩展系统有可能使这些分析变得更容易，从而使这些工作受益。

可视化运动。运动数据最近在可视化社区中受到了广泛关注（有关调查，请参阅[5]）。大部分工作都集中在轨迹数据上，其中记录了移动实体的完整轨迹。相反，我们考虑的数据（第 3 节）是多变量 OD 数据 [38]：仅记录开始和结束位置，以及与运动相关的属性。还设计了可视化 OD 数据的技术。潘等人。 [30]提出了一种自动生成显示两个位置之间移动的流量图的方法。伍德等人。 [38]提出了OD图，它将行程编码为一组空间有序的小倍数，以避免将流量图应用于大量行程时出现的遮挡效应。虽然这两种技术仅考虑空间，但 Boyandin 等人。 [8]提出了Flowstrates，它同时考虑了空间和时间。这些技术是正交的，可以与我们的模型相结合。例如，除了我们系统的数据摘要视图当前支持的绘图（第 5 节）之外，我们还可以显示 Flowstrate 可视化，供用户探索起点-目的地查询的结果。

可视化数据选择和查询。数据选择是查询和可视化的基本任务。已经提出了许多方法来简化这项任务。阿尔伯格等人。 [2] 引入了动态查询的概念，其中查询是通过图形小部件指定的。 VIQING [25] 允许用户通过直接操作可视化来创建选择查询。赫尔等人。 [21]更进一步，提出使用查询松弛来交互式地概括选择。我们的方法遵循这些系统的传统：用户可以直观地指定选择，并通过直接操作可视化来探索结果；他们还可以概括查询。 Shrinivasan 和 Van Wijk [32] 提议在探索过程中创建 Select & Slice 表，以帮助对语义区域（即用户定义的数据区域）和数据子集进行交叉制表。使用这些表，用户可以操作区域并探索区域和数据切片之间的关系。在这个方向上的另一个值得注意的努力是 Polaris 系统 [33] 及其后继者 Tableau。 Polaris 开创了一种可视化模型，让用户可以通过将数据库列名称拖到可视化变量的架子上来指定查询和可视化。我们模型的一个显着特征是视觉操作旨在支持 OD 数据的时空查询。请注意，像 Tableau 这样的系统是为了操作表格数据而开发的，因此它们还可以支持对表中存储的数据进行时空查询。然而，指定时空选择并在这些通用系统中比较它们可能具有挑战性。我们的模型与 Tableau 的另一个区别是，后者为用户提供了构建查询的可视化界面，它不支持直接查询可视化数据。

已经针对时空数据提出了视觉查询模型[16,18,12]。它们从用户指定的查询草图的拓扑中推断查询。与我们的模型一样，这些作品旨在实现表现力。然而，它们有一些重要的局限性，使得它们不适合我们的问题。首先，它们是为连续时空数据而设计的，即记录完整的轨迹时。其次，他们的视觉表示“字典”非常复杂——用户需要掌握大量逻辑运算符和视觉语法，这对可用性产生了负面影响。

3 数据和设计要求

纽约市出租车数据。我们研究中使用的数据由纽约市出租车和豪华轿车委员会提供，包含 2009 年、2011 年和 2012 年所有牌照出租车行程的信息。原始数据以 CSV 文件形式提供，总大小约为 120 GB，包含超过 5.4 亿次出行。每条行程记录包括：行程 ID、出租车 ID、司机 ID、上车地点、下车地点、上车日期和时间、下车日期和时间、行驶距离、车费金额、小费金额和通行费金额。出租车和司机 ID 均已匿名，以避免记录与实际的出租车牌照和出租车司机执照相关联。请注意，旅行的轨迹不会被记录。

视觉探索的渴望。为了更好地了解他们想要研究的问题，我们对来自纽约大学经济和交通工程系的总共五名研究人员（2名工程师和3名经济学家）进行了采访。我们已经确定了专家想要执行的不同类型的查询。他们有兴趣了解城市的动态，以及数据的不同方面如何随空间和时间变化。例如，“工作日从市中心到机场的平均行程时间是多少？”或“出租车车队活动在工作日有何变化？”。他们还想探索特定时间的特定事件，例如“总统访问期间中城的出租车活动受到了怎样的影响”或“艾琳飓风期间的移动模式发生了怎样的变化？”；以及不同社区的模式有何不同，例如“中城和哈莱姆区的出租车频率是多少？”。当他们探索数据时，他们需要自由地混合这些查询并从高级摘要深入到单个事件。

与任何纵向分析一样，比较不同的数据切片至关重要：模式如何随空间和时间以及不同尺度变化。例如，“全天以及一周中不同日期中城和肯尼迪机场之间的流动情况如何变化”。此外，他们需要快速检验假设的能力。例如，从有关特定社区的查询开始（“中城和肯尼迪机场之间的移动模式是什么？”），然后将其推广到曼哈顿的所有社区。

目前，专家所做的分析大多是证实性的。他们使用 R、MatLab、Stata、Excel 等通用分析工具，并使用基本过滤器和可视化工具来验证他们的假设。由于这些工具的可扩展性有限，专家必须选择数据的（小）子集进行分析。当他们识别模式并探索需要在其他数据切片上进行测试的假设时，他们需要返回原始数据。这个过程不仅乏味且容易出错，而且还阻止他们对整个数据集甚至一年的数据进行分析。此外，很难复制分析、对不同的数据子集应用分析以及比较不同的数据切片。

为了解决这些限制，我们工作的一个重要目标是统一探索的两个阶段：数据选择和可视化分析。我们认为，通过这样做，领域专家将能够对完整的出租车数据集进行验证性和探索性分析。由于这些专家没有接受过计算机科学培训，因此该系统应该可用，并且不需要专业编程或查询语言的知识。简单性必须与表现力相平衡：探索系统必须具有足够的表现力，以支持不同空间和时间尺度的时空选择和分析、不同行程参数的选择以及细化和概括查询的能力。

由于数据规模较大，系统还应支持结果汇总。除了提供对数据的洞察之外，摘要还可以帮助指导探索，包括有关潜在有用的查询优化的提示。此外，探索必须灵活，并允许用户在聚合摘要和单个对象之间来回切换。

TaxiVis 系统。考虑到这些要求，我们构建了 TaxiVis，一个用于探索大型 OD 和时空数据的系统。该系统的一个关键组件是一个易于使用且富有表现力的可视化查询模型。正如我们在第二节中讨论的那样。 4、系统支持Triad Framework[29]中定义的查询类型。系统的功能模块如图3所示。用户通过与地图和其他视觉表示交互来直观地制定查询。在内部，生成一个文本查询，然后由存储管理器进行评估。为了支持交互式时空查询，我们构建了一个基于 k-d 树的专门索引 [11]（第 5.4 节）。一旦得出结果，系统就会将它们呈现在地图上，用户可以通过视觉交互迭代地完善他们的查询。由于结果集可能很大，我们利用自适应细节级别和密度热图。 （第 5.3 节）。为了创建这些可视化，必须为每个空间区域计算附加信息，例如行程频率。 TaxiVis 使用数据过滤器来概括此过程。在秒。 5、我们更详细地描述该系统。

4 可视化查询模型

根据第3节提出的要求，我们设计了一个可视化查询模型，旨在实现简单性和表现力之间的平衡。用户可以直观地指定查询，并且可以通过直接操作结果来迭代地优化查询。下面，我们介绍该模型并描述它如何简化时空切片的选择，并实现查询组合和结果探索。我们还讨论了它支持的不同类别的查询。请注意，虽然该模型是为出租车出行设计的，但它也可以应用于其他类似的 OD 和时空数据。

4.1 定义和编写查询

制定时空查询的一个关键挑战是通过查询约束选择（和细化）数据切片。在我们的模型中，查询遵循以下模板：

SELECT ∗ FROM t r i p s
WHERE

他们不要求用户在 WHERE 子句中编写约束，而是通过可视化操作来完成。在我们的模型中，存在三种类型的约束：空间约束、时间约束和属性约束。这些约束涵盖出租车数据集中的所有变量（实际上，任何 OD 或时空数据集）。此外，每个查询都与其结果中包含的行程集相关联。由于每个行程都由行程 ID 唯一标识，因此可以组合查询：用户可以迭代地细化查询并进一步探索结果。这有两个重要的含义：它允许在维护空间和时间上下文的同时创建摘要和可视化，并允许将查询直接应用于派生的可视化。为了形式化查询组合的过程并正确定义查询语义，我们使用两种类型的查询：原子查询和复杂查询，它们使用原子查询作为构建块。

原子查询。原子查询由一组时间、属性和空间约束组成。时间约束定义限制查询时间范围值的间隔。时间约束由间隔 [tMin,tMax] 指定。如果 trip.pickup time,trip.dropoff time ∈ [tMin,tMax]，则行程满足约束。也可以设置仅限制上车时间或仅限制下车时间的约束。
属性约束可以使用相等条件（对于分类属性）或区间条件（对于数字属性）来表达。如果对于给定值 a，trip.A = a，则行程满足与分类属性 A 关联的属性相等约束。如果约束与数值属性相关联，则如果 trip.A ∈ [lA, rA]，则行程满足区间 [lA, rA] 的约束。

空间约束有两种形式：单区域约束和方向约束。单区域约束由连接的空间区域定义，并与上车位置（起始约束）或下车位置（目的地约束）相关联。如果 trip.pickupregion ∈ r（对于起始约束）或 trip.dropo f fregion ∈ r（对于目的地约束），则行程满足区域 r 的约束。方向约束用于构造有关出发地和目的地的查询。方向约束限制了与上车和下车位置相关的区域。分别给定源和目的地区域 rsource 和 rdest ，如果 trip.pickup location ∈ rsource 且 trip.dropoff location ∈ rdest ，则行程满足约束。

我们定义一个名为 result 的函数，它将原子查询作为输入，并返回满足查询约束的所有行程记录的集合。结果函数决定如何评估查询。原子查询可以组合起来构造新的原子查询。给定两个原子查询 Q1、Q2，可以构造一个新查询 Q3，使得 result(Q3) = result(Q1) ∩ result(Q2)。这是可能的，因为查询约束的基本属性：它们在交集下闭合。这可以很容易地验证区间和等式约束，因为两者在交集下都是封闭的；当然，交叉点可以是空的。

对于空间约束，如果它们属于同一类型（起点和目的地单个区域，或方向约束），或者一个是单个区域约束，另一个是方向约束，则可以通过减少（相交）将它们组合成单个约束）对应的区域。否则，一个必须是单个区域起始约束，另一个必须是单个区域目的地约束，在这种情况下，两者可以组合在一个方向约束中。正如我们在第 2 节中所描述的那样。 5，这构成了 TaxiVis 中分组操作的基础。

复杂查询。复杂查询是通过析取组合一组原子查询来构造的。我们通过归纳扩展结果函数来赋予这些查询以意义。请注意，原子查询是复杂查询的特殊情况，其中查询集具有单个元素。然后，给定两个复杂查询 Q1 和 Q2，result(Q1 ∪ Q2) = result(Q1) ∪ result(Q2)。一般来说，给定一个原子查询 Q，不可能找到一个原子查询 Q′，使得 result(Q′) = result(Q)C（result(Q) 的补集）。然而，总是可以定义满足此条件的复杂查询 Q’。因此，可以对复杂查询的结果执行集合论运算以构建新的复杂查询。

视觉表现。图 4 说明了原子查询和复杂查询如何在我们的系统中直观地表示。时间约束是使用时间选择小部件 (A) 指定的，属性约束是在单独的视图中定义的（见图 6）。我们在第 2 节中描述了这两者，以及工具栏 © 中定义的约束。 5. 在这里，为了说明查询模型的语义，我们重点关注在地图视图 (B) 上定义的空间视图。单区域约束由多边形定义，方向约束由箭头定义。多边形内部的透明颜色定义了约束的类型：蓝色表示起始约束，红色表示目标约束（见图 4）。多边形边框和箭头上的颜色标识不同的查询（有 3 个查询：橙色、红色和蓝色）。橙色和红色查询是原子查询，仅包含原子时间和空间约束。蓝色查询 Q 是一个复杂查询，由两个原子查询的并集组成：单区域起始查询 Q1 和定向查询 Q2。在类似 SQL 的文本表示法中，Q1 可以表示为：

其中 NYCNeighborhood 和 NYCRegion 是分别给定邻域名称或区域名称的函数，返回相应的空间区域。

4.2 探索查询结果

如上所述，原子查询和复杂查询返回一组行程。因此，给定一组查询，例如图 4 中所示的查询，可以将其他查询应用于它们的结果，并且可以使用不同的视觉表示来探索它们。例如，在此图中，地图下方的图显示了每个查询返回的行程数。图中的线条通过颜色链接到查询。在图 1 中，散点图用于检查一天中不同时间前往机场的持续时间。可以使用其他类型的视觉表示，包括例如特定于 OD 数据的表示[30,38,8]。正如我们稍后讨论的，可以直接操作这些可视化来直观地定义属性约束并构建精炼的查询（见图 6）。最后但并非最不重要的一点是，通过使用多个协调视图，可以并排比较查询结果。

4.3 查询表达能力

所提出的查询模型能够表达丰富的查询类别。特别是，它支持 Peuquet Triad Framework [29] 中的查询类型。 Peuquet 考虑了时空数据的不同组成部分——空间（哪里）、时间（何时）和对象（什么），并对这些组成部分可能出现的问题集进行了分类。下面，我们描述这些问题以及我们的模型如何支持它们。

何时 + 何处 → 什么。这些查询描述在给定时间或一组时间出现在给定位置或一组位置的对象。在我们的模型中，可以通过空间和时间约束的定义以简单的方式构建它们。
什么时候+什么→哪里。给定一组对象和一个或一组时间，这些查询将返回对象的位置。这可以通过结合时间和属性约束来实现。
哪里+什么→什么时候。这些查询返回给定对象或一组对象占据给定位置或一组给定位置时的时间或一组时间。它们可以通过组合空间和属性约束来构造。

尽管我们最初的目标是支持这三类查询，但通过单独的约束，我们的模型能够表达其他类型的查询，包括何时→什么+哪里、哪里→何时+什么以及什么→哪里+何时，通过简单地定义单一类型的约束。

5 系统

在本节中，我们将描述我们构建的用于支持出租车数据交互式分析的系统。它将上述可视化查询模型与其他可视化操作和表示相结合，以满足第 2 节中提出的要求。 3.

5.1 用户界面组件

我们系统的主视图如图4所示。下面描述其组件及其在系统中的作用。

地图。地图在我们的系统中具有不同的用途。它们提供了一个用于显示查询结果的画布，供用户指定空间约束和撰写/优化查询。

时间选择小部件。该小部件允许用户指定时间约束。如图 5 所示，我们在第 2 节中描述了两个可用的小部件。 5.2.

数据摘要视图。可以使用数据摘要视图中的不同表示来可视化与查询结果相关联的信息。例如，此视图可以将选定的行程显示为不同属性的时间序列、直方图和散点图。由于我们的查询模型支持视图中的多个子查询（用不同的颜色表示），因此可视化过滤器可以区分它们的结果。例如，可以生成每行对应一个子查询的图。

工具栏。通过工具栏支持多种操作。前 3 个按钮（从上到下）允许用户指定其查询是否应考虑上车、下车或两者兼而有之。第四个按钮支持创建定向查询。分组和取消分组（第五和第六）按钮为用户提供了一种简单的机制来组合（和拆分）基于区域的查询和定向查询。系统还可以将查询结果导出为 CSV 文件，然后可以使用其他工具进行分析。最后，属性探索按钮为用户提供了定义属性约束的可视化机制。

多个协调视图。图 4 中的视图用于指定一组共享时间约束和属性约束但具有不同空间约束的查询。通过使用多个视图，用户可以指定具有不同时间和属性约束的其他查询（见图 1）。为了进行比较，可以同步这些视图以显示相同的空间区域并同步属性摘要的比例。

5.2 可视化查询规范

空间约束由地图视图上的多边形和箭头指定。这些是通过刷涂或选择与纽约市的社区、邮政编码和行政区相对应的预定义多边形来创建的。为了创建单区域空间约束，用户首先通过选择开始/结束约束按钮（通过工具栏）来选择与要创建的选择关联的参数，然后通过刷选创建原子空间约束。可以移动、编辑和删除选定的区域。用户还可以链接两个区域以形成方向约束（图 4）。原子空间约束可以分组形成复杂的空间约束。这是通过首先选择要分组的区域和箭头，然后按工具栏中的合并按钮来实现的（参见图 4 中的蓝色查询）。

时间约束是使用时间选择小部件指定的：常规选择和循环选择（图 5）。在常规选择小部件中，用户通过分配开始时间和结束时间字段的值来定义原子时间约束。使用“循环选择”小部件，用户可以通过选择年、月、星期几和小时的任意组合来指定涵盖不同时间尺度的复杂约束。这个小部件类似于 TEMPEST 系统中的时间轮 [13]。

属性约束是通过属性选择视图定义的，该视图可通过工具栏中的探索按钮访问。如图 6 所示，该视图显示了总结左侧所示查询结果集中行程的属性值的直方图。通过刷出所需的值或值范围（深灰色矩形），可以导出属性约束并将其添加到原始查询中。细化查询的结果显示在右侧。

5.3 查询结果可视化

在地图上渲染行程。查询结果的空间部分在地图视图中可视化。图 7 说明了替代可视化。此类数据的基本视觉表示是点云，其中每次行程都由一对表示其上车和下车位置的点表示。一对的两个点通过颜色区分：蓝色用于上车，红色用于下车。对于少量出行，这种可视化可以让我们快速了解出租车活动在整个城市的分布情况。然而，随着行程次数的增加，它很快就会变得混乱，如图 5.3(a) 所示。该数字包含一周内所有出租车行程对应的积分。点云几乎覆盖了整个地图，使用户很难辨别正在发生的事情。

为了解决这个问题，我们应用了一组技术来为用户提供替代的可视化效果。首先，如图 5.3（b）所示，我们采用自适应细节层次（LOD）策略来减少渲染的点数。我们的 LOD 策略首先根据空间坐标（即它们与赤道和本初子午线的距离）对所有点进行排序。然后，我们在排序点的顶部构建一棵二叉树，并执行中序遍历，根据访问顺序再次对它们进行排序。这相当于在 Z 顺序曲线上为规则网格构建分层索引 [27]。最后，所有点都线性排列，使得前 n 个元素也是原始点云大小为 n 的分层子采样。在用户交互期间，n 将根据地图缩放级别按比例缩放，在最精细级别上 n = 1e6。这也是我们的应用程序将显示的最大点数，即使实际匹配记录数更高。

其次，我们的系统支持密度摘要可视化或热图（见图 5.3©），可用于显示某个区域中上车和/或下车的分布。用户界面右侧的工具按钮还可用于选择使用哪个位置属性（上车、下车或两者）来构建热图。例如，如果同时选择上车和下车位置，则上车和下车位置都将用于聚合热图的每个像素。这样的热图可以帮助回答诸如“出租车多久前往特定社区？”之类的问题。热图上较暗的位置表示该区域的活动水平较高。与点云LOD相结合，这是快速汇总数据的强大工具。

最后，我们还概括了热图的概念，以应用于我们系统中的网格地图。网格地图是一组单元格，用户可以自定义它们的几何形状和视觉表示。一个例子是纽约市邮政编码或社区的网格地图，显示出租车接送数量（见图 5.3(d)）。热图也可以被视为网格图，其中其单元是规则网格上的点，其视觉表示只是球形梯度纹理。

行程数据可视化并与之交互。除了在地图上显示查询结果之外，还可以对结果应用过滤器以获得不同的视觉表示。在我们当前的实现中，我们提供了对适合与行程相关的属性类型的视觉表示的支持。例如，时间序列、直方图和散点图（见图 4、图 1 和图 6）。此外，正如我们在第二节中讨论的那样。 5.2 中，这些可视化可以是主动的，并可作为进一步细化查询的手段。

5.4 存储管理器

支持交互性是我们方法的重要要求。因此，性能是我们系统设计的关键因素。我们已经尝试了几种可以在单台机器上交互式运行的数据存储设计。特别是，我们评估了两种传统的数据库管理系统：PostgreSQL 和 SQLite，后者用于内存存储。尽管这两个系统都提供了空间查询的扩展，但它们的查询性能不适合交互性，更不用说这两个系统都需要花费大量时间来构建空间索引。例如，SQLite 仅仅为一年的数据构建索引就花费了 52 个小时。此外，单个原子时空查询可能需要几秒到几十秒才能完成，而复杂的查询（例如由循环时间选择小部件指定的查询）可能需要几分钟。这些数据库系统的另一个问题是它们的内存占用很大。在我们的实验中，PostgreSQL 和 SQLite 分别使用了超过 200GB 和 100GB 的 RAM（在 SQLite 的内存设置中）。我们认为它们不适合我们的交互式系统，因为高内存使用量会导致更多的磁盘分页。

为了解决这些问题，我们构建了一个轻量级数据库变体，允许快速查询所有属性，包括时空约束。我们的实现基于空间分区数据结构 k-d 树 [11]，它将每次出租车行程视为 k 维空间中的一个点。在我们的实现中，点仅存储在叶子中。我们的代码只需 30 分钟即可为整整 3 年的数据构建索引，并且仅使用 30GB 的磁盘空间。在运行时，包括数据点在内的整个数据结构被映射到系统虚拟内存，因此，它可以根据可用资源自适应地在核心内或核心外运行。在我们的测试中，与上述数据库系统相比，我们的系统内存使用量要小得多，相对于所探索的数据量来说，大多停留在数百兆字节。这种设计在我们的交互式系统的需求范围内执行，并且查询速度显着加快。在表 1 中，我们总结了实验中获得的结果，其中 1k-query 和 100kquery 分别指返回大约 1000 次和 100,000 次行程的查询。

5.5 渲染注意事项

地图视图的性能对于提供良好的用户体验也极其重要。因此，选择一个兼具灵活性和效率的地图渲染系统是我们设计的首要任务。有不同的选择： (1) 由在线地图服务（例如 Google Maps、Bing Maps 或 OpenStreetMap）提供的基于 Web 的引擎； (2) 基于 2D 桌面的引擎，用于从 OpenStreetMap 渲染地图图块，例如 KDE 的 Marble。由于基于 Web 的渲染引擎不能保证跨 Web 浏览器和硬件的一致图形加速，因此它会阻碍我们的一些可视化，例如使用帧缓冲区对象动态构建热图或使用 OpenGL 着色器执行行程动画的能力。此外，使用基于Web的地图API有效地显示大量数据仍然是一个重大挑战，包括在哪里托管数据以及如何有效地呈现它们。另一方面，虽然选项(2)中的可用系统解决了兼容性问题和数据传输问题，但它们仅支持特定的2D渲染引擎。比如现在的KDE的Marble，渲染必须通过Qt的QPainter对象来完成；尚不支持 OpenGL。不幸的是，我们的许多渲染层都需要使用 OpenGL。我们的解决方案是 (1) 和 (2) 的组合：我们嵌入一个 Web 浏览器作为渲染地图的底层，并将其他本机可视化放在其顶部。在我们的应用程序中，我们使用 Qt 并将 QGraphicsWebView 提升为我们的嵌入层。该小部件放置在 QGraphicsView 小部件的 OpenGL 画布内，因此，其他层可以与 Qt 的 QPainter 和 OpenGL 本机图形兼容。所有地理空间转换都在地图视图上方的薄层中完成。需要注意的是，基于Web的组件仅用于显示地图，所有其他渲染均在OpenGL中完成，以最大限度地提高系统性能。

6 案例研究

在本节中，我们将介绍案例研究来说明我们的模型和系统的强大功能和简单性。

6.1 调查不同地区的出租车活动

在分析一个城市的出租车服务时，比较不同的地理区域是很有用的。在 TaxiVis 中，用户可以选择不同粒度级别的区域：通过自由选择、按邮政编码和社区。图 8 显示了四个不同区域一周内的上车和下车情况变化情况。在这里，我们利用分组来分析组合社区的行为。例如，我们将东、西和格林威治村（以绿色显示）以及哈莱姆区和东哈莱姆区（蓝色）分组。到目前为止，中城（橙色）是工作日内活动最多的地方，其次是上东区（红色）。在周末，情况会发生变化，我们会看到市中心的活动更加活跃。请注意，周四（5 月 5 日）出发的出行数量开始增加，周五（5 月 6 日）晚间接载高峰——这表明市中心周末的夜生活非常热闹。

这个为期一周的概述准确概述了城市生活、人们去哪里以及何时去。它还凸显了社会不平等。居住在哈莱姆区的人们长期以来一直抱怨他们的社区缺乏出租车服务。情节清楚地表明他们的不满是有道理的。与其他较富裕的社区相比，往返哈莱姆区的出行次数存在超过一个数量级的差异。热图还显示，虽然人们乘坐出租车前往哈莱姆区，但那里几乎没有任何接送服务。在探索与旅行相关的其他参数时，我们发现了一个令人惊讶的事实：从哈莱姆出发的每次旅行的小费高于其他社区（见图 9）。进一步的分析还表明，哈莱姆区每英里的票价较低，因此出租车进入该地区的经济动力较小。较高的小费可能是奖励前往哈莱姆区的司机的一种手段。

6.2 探索运动：交通枢纽

机场和主要火车站（即宾州车站和中央车站）是纽约市的主要交通枢纽。通过分析往返这些地点的出租车流动情况，我们可以深入了解人们如何进出城市。为了比较从肯尼迪机场和拉瓜迪亚机场出发的出行次数，我们选择了其附近的地区并检查了 1 周期间（2011 年 5 月 1 日至 2011 年 7 月 5 日）。如图 10 顶部的图所示，大多数日子里，拉瓜迪亚机场的接载量比肯尼迪国际机场的接载量还要多。另一个有趣的问题是乘客去哪里。突出显示纽约市社区的分区统计图（图 10 顶部）显示，大多数人前往中城（最​​黑暗的地区），其次是上西区。

通过将鼠标悬停在某个街区上，系统会显示在该街区结束的确切行程数量。我们还可以使用热图获得有关热门目的地的确切下车地点的更细粒度信息。

为了研究机场和火车站的运动模式，我们可以将它们分组（图10底部）。我们选择宾夕法尼亚车站和中央车站周围的区域，并使用“分组/取消分组”按钮对它们进行分组（注意两个绿色轮廓）；我们还将从机场出发的行程分组（蓝色轮廓）。绘图立即更新以显示两个区域的皮卡数量。请注意，火车站周围还有更多接送服务。另一个有趣的观察是，从周一到周四，从火车站出发的出行数量大致保持不变，周五开始减少，周六达到最低点。这反映了许多在工作日而非周末前往市区的通勤者的行为。请注意，虽然在这个例子中我们关注的是上车，即到达的人，但也很容易研究下车的情况。从图10所示的地图视图开始，我们可以简单地选择机场和火车区域（通过双击它们），然后单击“Dropoff”按钮。

使用摘要视图，我们可以进一步探索所选行程的特征。例如，通过检查每英里的平均出行成本，我们可以发现曼哈顿内的平均出行成本更高。这激励出租车公司留在曼哈顿，避免前往机场。请注意，虽然出租车拒绝载客是违法的，但当目的地是肯尼迪国际机场时，这是一种常见做法。2 这个问题在工作日的高峰时段尤为突出，此时行程需要更长的时间（参见图 1），并导致潜在的收入减少。

6.3 研究随时间变化的行为

出租车需求模式。研究出租车需求随时间变化的情况有助于了解城市动态。对于出租车公司来说，这些信息可以帮助做出决策，既可以安排司机轮班，也可以实现利润最大化。为了简化比较多个时间片的过程，TaxiVis 提供了时空探索机制。用户首先选择感兴趣的时间片。这可以使用时间选择小部件来完成（图 5）。在常规选择模式下，通过指定时间范围、步长（例如一小时、一天、一周）和步数来选择切片。在循环选择模式中，时间范围列表已经由小部件表达和生成。例如，选择 2011 年、5 月和星期日，将返回 5 个时间范围，每个时间范围对应 2011 年 5 月的星期日。给定时间范围列表，时空探索的结果是多视图可视化每个时间间隔显示一张地图，以及聚合时间间隔结果的数据摘要视图。每个地图视图和绘图线都与分配给其时间范围的颜色相关联。如图 11 所示。在这里，我们检查了 2011 年 5 月和 2012 年 5 月的所有星期一。这两年的出行次数非常相似，包括阵亡将士纪念日的大幅下降。后者表明假期期间街道上的出租车数量可能会减少。

飓风桑迪和艾琳。出租车数据还可以深入了解重大事件的影响。我们利用时空探索来研究飓风桑迪当周的出租车活动。图 12 显示了从周日（飓风前一天）到周六的出租车行程。热图密切反映了该事件造成的破坏程度。周一，即飓风登陆当天，整个曼哈顿的出行数量大幅下降。周二，大多数地区的生活开始恢复正常，但曼哈顿下城除外，那里已经五天几乎没有出租车了。该地区遭遇严重停电，周六才恢复。我们还研究了飓风艾琳周围的时期（见图 13）。请注意，尽管活动较早恢复正常，但在飓风当天，几乎没有出租车：只有 1,076 趟车次，而平均有 500,000 趟车次。这似乎表明，艾琳虽然较短，但在曼哈顿造成了更大的破坏。

7 结论

在本文中，我们提出了一种新系统，支持对大起点-终点和时空数据进行可视化探索。该系统的一个关键组件是可视化查询模型，允许用户快速选择数据切片并探索它们。我们已经证明该模型在简单性和表现力之间取得了良好的平衡。这项工作的另一个重要贡献是系统设计，它不仅将可视化查询模型与其他可视化原语结合起来，而且还解决了由于数据规模而出现的性能挑战。特别是，为了支持交互性，我们设计了一个高效的存储管理器和渲染子系统。我们使用包含纽约市超过 5.2 亿次出租车行程的大型数据集展示了一系列案例研究，这说明了我们系统和设计决策的功能和有效性。

未来的工作有多种途径。我们的系统已部署给我们机构的一些领域科学家，并且反馈非常积极。我们希望在广泛使用之前进行更大规模的可用性研究。虽然我们的可视化查询模型很灵活，但我们的第一个实现有一些限制。例如，有一些有用的时间约束无法用当前时间小部件表示。我们计划针对时间和属性约束规范尝试替代且更灵活的小部件。此外，我们希望使系统完全基于网络，但考虑到第 2 节中概述的系统注意事项。 5、由于现有技术的限制，这具有挑战性。我们的计划是删除一些功能以允许此类部署，并在浏览器及其 API 变得更易于使用、更可靠、更强大和更便携时将它们添加回来。我们还计划增加对其他数据源的支持，例如，纽约市将在 2013 年春季部署世界上最大的自行车共享计划，并且自行车将进行 GPS 跟踪，信息计划公开。此外，我们当前的系统依赖于用户对城市的了解来推断出租车数据的模式。我们打算添加更多有关城市的上下文信息，以便用户能够将出租车数据与有关该地区主要商业活动的信息等相关联。最后，我们希望添加更多的数据分析功能来支持更复杂的分析。

致谢

作者感谢纽约市出租车和豪华轿车委员会提供本文使用的数据。我们还感谢 Daniel Osmari 和 Wendel Silva 帮助进行数据预处理。这项工作得到了国家科学基金会（CNS-1229185、CNS-1153503、IIS 1139832、IIS-0905385、IIS1142013、AGS 0835821）和能源部的部分支持。

参考文献