可视化驱动治理：公共交通系统的可视化实践

本文作者介绍

杨柳桦樱，目前为是MIT Senseable City Lab驻新加坡的数据可视化设计师（Data Visualization Specialist) 。今年夏天，在美国东北大学修完信息设计与可视化硕士（MFA，Information Design & Visualization) 。在去美国之前，已在国内修完应用心理学的本科和硕士学位，并在IT行业从事了两年用户体验研究和产品经理。

个人网站：http://liuhuaying.go4trees.com/

2017年夏天，我有幸以可视化助理的身份在MBTA（Massachusetts Bay Transportation Authority，马萨诸塞州湾运输管理局）实习。MBTA 位于波士顿，管理着美国麻省所有的地铁和公交。但其公共交通之发达在美国算是数一数二。截止到2017年，除了渡船和其它特殊服务线路外，共有8362个站点、8条地铁线和192条公交线路，每日平均至少4万搭乘人次。

每年冬天，MBTA会因暴雪而停止部分服务，下图是网友在推特上的吐槽，可见也是真爱。

在实习的一年里，从设计到前端开发，完成了数个可视化工具的项目。这些工具目前都在实际使用中，虽然用户不多，毕竟是针对管理人员，但仍然广受好评。其中，我将绿线地铁可视化工具、公交路况可视化工具和ODX可视化工具作为毕设项目，完成了我的毕业论文《可视化驱动治理：公共交通系统的可视化实践》。该论文有幸成为本届杰出论文之一（Neurath Award for Outstanding Design Inquiry）。

之所以选这3个项目，是因为这3个项目分别解决了不同的问题。绿线工具在于实时信息的获取，公交路况可视化工具除了实时性外，还有信息的全局性。而ODX工具主要解决的是复杂数据的理解和沟通，比如准确理解数据模型、打破数据查询和获取的技术屏障、发现数据模型本身的应用局限等。

更重要的是，这些可视化工具的集合本身又是一个可视化工具。举个例子说明这个概念的含义：在监控室里，往往不止一个可视化工具，其中有监控车辆、街道、数据等，所以监控室本身对于调度员来说就是一个工具。所以，我的这三个工具的集合，在本质上，是一个针对MBTA系统的可视化工具。而这些所有可视化工具在机构系统里的应用集合，就是我所谓的“可视化驱动”（visualization-driven）。

虽然以可视化工具为案例，但实际上，我主要是从实践的角度来论证和探讨一个基本问题，即我们为什么需要可视化。可视化应用不仅仅是指将相关数据可视化，更重要的是，解决了在人与科技共存之下如何交流的问题。下面简单讲讲这三个项目的故事。

1/3

绿线：发生了什么？

绿线是波士顿最早的地铁线路，准确说应该是轻轨，因为有部分是在路面上和其它车辆一起跑，乘客在马路中间上下车。据说建成于1897年，说得好听点叫很有历史感，但其实就是很老旧，每次起步和进站都是一阵巨响，比十年前国内的火车噪音还大。绿线有B、C、D、E共4条支路，四条支路有两个合并点，每条支路又有不同的终点。抵达终点的车辆会在终点掉头，并入到另一个方向继续运行。

MBTA绿线图

支路的运营已经使得绿线的运营比其它线路难，但硬件设施配置不齐全导致情况更复杂。绿线的车辆运行数据来自轨道上的传感器（sensors），和车辆上的定位系统（GPS）。在站台和轨道变轨点附近装有自动车辆识别设备（AVI，Automatic Vehicle Identification），负责自动根据所来车辆的支路来变更轨道的方向。AVI需要预编程，这样当车辆临近时，轨道才能通过识别车辆编号获知所属支路。但是，并不是所有路段都有传感器和AVI，所以除了车辆上的GPS做辅助以外，主要站台的现场调度员需要手动指挥。

简单来说，现场调度员的主要工作是评估每辆途径车辆是否能准时发车。如果不能，则需要做出临时调整，并通知司机和调度中心（Operation Control Center）新的发车时间。同时，作为绩效考核的一部分，他们还需要手工填写实际发车时间表。所以，一旦有车辆未及时到站，或任何异常，他们最想知道的就是到底发生了什么。

因为一辆车的延误可能是多因素决定的。前一辆车的延误、前一站的车辆滞留、堵车等，都可能导致当前这一辆车无法准点。对于调度员来说，从指挥和成效这一过程实则是一个黑箱：我的准点发车并不能保证这辆车准点到站；我的准点发车可能导致下一站点车辆堵塞；我推迟发车可能减缓下一站车辆滞留的情况。只有调度员能够获取到自己调度操作的结果反馈，他才能学习和改进调度技能。

但这种学习是难以在传统模式中获得的。每个人各司其职，参与着整个大系统的一个小部分，比如，规划员负责做计划，调度员负责实时调度。在这种情况下，调度员不仅要知道自己站点的情况，还需要知道相关的其它车辆情况和路况。好的调度必然是基于一系列有效的信息交换。

在使用我的工具之前，为了了解相关信息，他们只能用对讲机向其他调度员或司机询问。现在，他们可以在移动设备上使用我的工具，实时查看各支路车辆的当前位置、车辆行驶间隔（headway）和预计抵达时间。

绿线可视化工具

http://liuhuaying.go4trees.com/work-at-mbta/gl-headway-viewer/

其实绿线可视化工具是一个显而易见的需求。但因为经费有限等各种原因，一直没有得到重视。直到我完成这个工具的设计和开发，以实验性项目的名义，项目组长争取到经费给调度员配备了几个平板。在短短半个月的试用之后，因为调度组的反馈非常好，MBTA正式成立了一个产品专项组负责针对绿线调度的产品研发。

项目结束后的某一天，看到组长给我留得纸条：

2/3

公交路况：堵车了吗？

公交控制中心（Bus Control Center）面临着类似的信息问题。调度人员坐在控制中心室里，在屏幕上监控公交的准点运营情况。他们不仅要监控日常的发车情况，还要处理因地铁临时故障的应急调度。实际运行中，虽然公交比地铁更灵活，但也因此比地铁更易受路况的影响。

控制中心配备有调度系统，系统上可以看到每辆公交车的所在位置、延误情况等信息。但目前这个系统没有实时路况信息。当公交延误时，调度员只能通过系统对讲机与公交司机联系来了解当下的情况，比如是否堵车了。但实际上，每个公交司机都只能汇报自己眼前的情况。

公交路况可视化工具填充了这个信息需求。我结合了拥堵数据和公交车辆位置数据，调度员通过看到服务范围内的实时运营全貌，不仅能知道车辆是否遇到了堵车，还能预见车辆的堵车并提前采取措施。

公交路况可视化工具

http://liuhuaying.go4trees.com/work-at-mbta/bus-traffic/

3/3

ODX：乘客去了哪儿？

ODX表示乘客一次出行中的起点（Origin）、终点（Destination）和转乘点（Transfer）。对于乘客出行需求的分析，是公共交通规划的必答题。其中，ODX分析是重中之重，因为它回答了乘客从哪里上车、下车和转乘的问题。对于MBTA来说，ODX分析不仅用于评估因服务规划更改而受影响的乘客数，还用于评估因临时关闭某段服务路线而需要投放的摆渡车辆数。

ODX可视化工具是对ODX数据进行可视化的网页工具。 通过选择站点或路线，服务规划员可以知道任意时间段或支付方式下的乘客在哪里上车、下车和转乘。在结果分析上，不仅提供了站点或路线的分析，比如多少乘客在哪些站点上下车、从哪条线路转乘到哪条线路，也包括区域分析，比如乘客是从哪一块区域乘车到哪一区域。

ODX可视化工具

http://liuhuaying.go4trees.com/work-at-mbta/odx-tool/

在这个工具之前，MBTA的服务规划员是可以通过查询数据库来获取这个数据的。但不是每个规划员都会写查询语句，这导致ODX分析需要会查询的人先获取数据。并且因为数据量极大，他还需要预处理，才能进行小组的业务讨论。从效率上来说是很低的，因为MBTA的站点和线路很多，需要分析的场景也很多。再者，因为大波士顿之间有一条河，实际规划必须考虑这个重要的地貌信息，而单纯的数据表是难以反映这个信息的。这些优势也是我曾经访问过规划员所强调的。

我曾经问过ODX项目的项目经理，市面上不乏成熟的、针对公共交通规划的可视化软件，为什么不用？为什么要自己开发？她说，对于小的公交企业，比如只有十几条线路，可能可以使用那些软件。但对于MBTA来说，不仅有上百条线路，在数据上也很复杂。比如，有很多综合性站台（公交和地铁的混合站台），站台编号是有层级关系的，综合站台本身有一个母编号，里面的公交站点和地铁站台分别有各自的独立编号。在概念上，使用的是母编号，但车辆出行计划的数据只与独立编号关联。目前市面上的软件，还不能处理这类复杂或极端的情况。

小结：为什么可视化

那么，回到最开始的问题：我们为什么需要可视化。

从前面的故事可以感受到，人们需要可视化工具的本质上是为了交流。可视化是一种表达方式，是一种语言。就像在办公室，我们会用英语或普通话来交流工作。从语言运用的角度来说，数据可视化所解决的交流不是单向的，不是一篇新闻报道那样上传下达的传播，而是一种互动和沟通。这种交流包括机构内的交流，机构与外界的交流。对于大机构来说，有同部门之间的日常交流，和部门之间的协作交流。

机构外的交流可以以猫和老鼠的关系来比喻。公交系统不是非营利组织，仍然预期发出的车能有乘客搭乘。为此，公交公司需要琢磨乘客的出行行为，逐渐相应地调整服务计划。而根据不断调整的公共交通服务，乘客也同样在不断调整自己的出行策略。

机构内的交流价值体现在数据的流动性。从服务规划、运营到评估，是一套连续且循环流动的管理体验。

管理服务体验图

循环流动的服务阶段

在这个循环流里，工作行为的结果作为数据的一部分，流动到下一使用部门。比如，服务规划者的工作是制定服务计划，服务计划作为工作结果，传递到运营部门，而运营部门根据这个计划运营车辆，运营车辆的数据又用于下一次的服务规划。如果运营工作并不准确按照计划执行，那么所产生的运营数据的价值也是有折扣的。服务规划者不知道这个服务体验不好是因为原计划导致的，还是因为运营效果差而计划本身没有问题。

为此，我的论文提出了可视化驱动治理（visualization-driven governance）的概念。治理（governance），这个词听起来很严肃。在概念上讲，治理区别于管理。管理是关于执行和控制，讲求把事情做对（do the things right）；治理则是侧重于策略和交涉，强调做对的事情（do the right things）。在交通管理领域下，管理是封闭的，负责站点、车辆等设施设备的建设、使用和维护，以及服务计划执行和评估。而治理是开放的，不仅包括管理本身，比如管理的效率，还包括企业、员工、乘客、城市规划、社区资源、政府资金等多方面利益相关者的协调与公平性。

治理与管理关系图

在治理的观念下，我所讨论的公共交通可视化应用，不仅仅是指将公共交通数据可视化，更在于可视化应用实践所形成的开放的生命系统（open living system）。在大型的基础设施机构里，设备设施的管理运营和数据的收集分析只是一个方面。科技始终在发展和进化，在未来，我们会更快地获得更丰富的数据，算法和人工智能甚至能代理简单的决策性操作。但人们不只是使用技术，而是与之生活在一起、工作在一起。尤其是员工，即这些技术的直接使用者，如何适应和应对这个技术时代？如何感知海量的数据和理解深奥的模型？如何在情感上接受和信任这些机器决策？最后反过来，又如何通过这些成果来战略性地部署和应用这些技术？我认为，可视化是唯一出路。 因为它有效地提供了易读性。因为阅读和理解的可能性，我们得以以平等的方式获知，从而通往共识与信任的可能性。

花絮

先补充一个设计框架图，是我开题时做的，不过最后没有放在论文里。

设计框架图

最后再补充两个MBTA服务网络的可视化设计。两个都是利用开源的GTFS（General Transit Feed Specification）数据来做的，颜色编码采用的是MBTA官方定义，即黄色表示公交，绿、红、蓝、紫分别表示绿线、红线、蓝线、紫线地铁。

第一个是实习中为MBTA市场部团队做的一个简单的可视化，可以通过滑动滑条等操作来了解MBTA在不同时段的服务网络。技术上没有什么特别的，但有意思的是，一位资深的MBTA经理看到后感叹说，每次她都从我做的这些可视化项目学到了新的业务知识。可见，即便是对于面对业务数据很多年的人，可视化也能提供新的洞见。

第二个是课堂项目，主要运用时间流的方式，来展示公交是如何连接地铁站，使城市像流动的生命体。由于单是车辆发车原始数据便有100M以上，所以除了对数据结构做部分预处理外，主要通过canvas来实现海量数据的动画效果。

　大家都在看　

2017年R语言发展报告（国内）

精心整理 | R语言中文社区历史文章合集（作者篇）

精心整理 | R语言中文社区历史文章整理（类型篇）

公众号后台回复关键字即可学习

回复 爬虫            爬虫三大案例实战  
回复 Python       1小时破冰入门

回复 数据挖掘     R语言入门及数据挖掘
回复 人工智能     三个月入门人工智能
回复 数据分析师  数据分析师成长之路 
回复 机器学习      机器学习的商业应用
回复 数据科学      数据科学实战
回复 常用算法      常用数据挖掘算法