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

本文作者介绍

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

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来实现海量数据的动画效果。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180725G0M4L400?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

同媒体快讯

扫码关注腾讯云开发者

领取腾讯云代金券