未来交通︱一位少年的信号交叉口分析软件之梦

编程对我来说有一种独特的吸引力，享受着用代码将自己的想法一步步实现这个过程，付出的代价就是牺牲掉不少空闲时间。当其他人吃着火锅唱着歌的时候，我可能正默默的对着电脑屏幕发呆或敲着一行行代码。

本科和研究生阶段的研究方向都是交通信息与控制，闲来无事的时候喜欢捣鼓捣鼓软件，先后接触了vissim、synchro、sidra、visum、TC等。这些软件功能涉及面广，在行业各领域被广泛应用。但是在应用过程中，惊觉大多微观交通软件的开发是以国外的交通情况为背景，针对国内实际交通情况应用并不能完全协同。但若对模型参数进行校正则可以在国内交通情境中较好地应用，上述软件在国内有较高的占有率也说明了这一点。不过国内实际交通情况及其复杂，用户的操作习惯也存在差异，这些软件还是有一些不太适应的地方，某些情境下无法解决用户的实际痛点。以常用的synchro和sidra两款交叉口软件为例，总结起来主要有以下几方面：

交叉口渠化示意图最能直观反映交叉口软件模型和实际情况的差异，看两者“长”得是否相像就能辨别。

上图为两款软件的渠化示意图：其箭头标志大小、类型，人行横道线，整体的渠化示意图风格与国标《道路交通标志和标线（GB5768-2009）》存在较大的差异。除此之外，上述两款软件渠化示意图也无法对实际交叉口中的左转待转区、直行待转区、可变车道、公交专用道，导流线渠化岛等进行处理。

在实际项目中，交叉口渠化示意图、流量图和信号控制方案一般需要以图片的形式在报告中直观呈现。现阶段渠化示意图主要使用CAD进行描图处理，流量图多采用TC或者CAD绘制，信号控制方案主要采用Excel或者PPT绘制。

synchro和sidra更加注重的是数据评价分析，还很难满足实际项目报告对图形化结果的需求，需要借助于其他的软件来实现，并且实现过程相对繁琐。

现阶段交叉口软件大多只能对交叉口进行单方案评价和优化分析，无法直接实现多方案对比。例如：利用上述两款软件对某一交叉口的早高峰、平峰和晚高峰三种流量和信控方案进行对比分析，需要将三种评价结果导出到excel或者其他软件中通过绘图分析。过程较为繁琐费时。

因此，在大四的时候萌发了开发一款便捷的信号交叉口评价分析软件的想法，不过那会儿编程水平也仅仅停留在能考过计算机二级的水平（年少无知的我居然还参加了计算机二级的培训班，此刻允许你鄙视我3秒钟）。理想丰满，现实骨感，想法有了，等待我的是一个个“深不见底的坑”，编程语言中什么面向对象，继承、多态等复杂的概念难以理解。网上找编程的程视频资料学习，跟着视频敲一行行代码，不断重复，从此便踏上了一边学习编程，一边开发应用的“不归路”。对于编程基础薄弱的我来说，开发一款信号交叉口评价分析软件是一项“浩大”的工程。我没有选择一开始就进行整个软件的开发，而是将整个软件拆分成一个个小的功能模块进行单独开发，最后将各个功能模块组成一个完整软件应用。

开发的第一个功能模块是绘制交叉口流量图。一图胜千字，在报告中用交叉口流量图来表示各个转向之间的交通需求比使用表格和文字要直观明了。在此之前交叉口流量图主要采用TC、CAD和PPT绘制：TC绘制流量转向图步骤较为繁琐，且无法处理掉头流量；CAD主要适用于十字交叉口流量绘制，难以直观展现各个方向交通需求大小；PPT是手动绘制各个线条，比较耗时。

流量图也是整个信号交叉口软件相对容易实现的功能，以流量图作为开发的第一个模块功能，目的就是先找个软柿子捏捏，作为编程学习的练习项目，这个阶段利用C#的GDI进行绘图。原本以为画几条粗细不一的线上去，再添加上流量标签就能搞定的事情，却比想象的要麻烦得多。实际交叉口的复杂程度远超想象：每条线条的起始点位置、宽度、曲率、与输入流量之间的关系等问题都需要解决；点位计算结果不稳定，一个点位的偏差就会造成整个绘制出错；编程水平太low：程序漏洞百出，经常出现各种始料未及的麻烦。

这个阶段，不断验算点位计算公式，调试代码存在的问题，笔记本上的笔记也越来越多。

经过了挺长一段时间的优化完善，尽管仍然偶尔出现不稳定的状况，桌面端的交叉口流量图应用已经可以逐渐可以在一些实际项目中运用了。

经过一段时间的试用体验后，我发现桌面端的交叉口流量图应用在实际使用中还是存在着问题，即无法在xp、macOS和其它部分操作系统中正常使用。那时候web端在线应用逐渐增多，web应用优点是运行在浏览器环境中，打破了操作系统之间的限制，能够更灵活地适应用户需求。参考了html5中的canvas绘图功能，决定尝试开发web端的交叉口流量图应用。

由于之前没有接触过html5、css、js等，所以又开始一边学习，一边开发。web端应用分为前端和后端：前端canvas负责绘图，后端负责点位计算等。前端页面布局设计内容相对较少，主要通过html和css完成；前端绘图功能利用js控制canvas进行绘图完成，这个过程就是将之前在桌面端的核心代码用js实现了一遍。由于是第一次使用js语言来写应用，其整体语言风格跟C#存在较大差异，刚开始难以适应，编码质量也很差，开发进度缓慢。

尽管进展缓慢，有了桌面端的开发经验，前端绘图功能总体进展还算顺利，终究还是将桌面端绘图功能用js语言实现了。

Web端交叉口流量图功能开发的难点在于后台功能的开发，之前完全没有接触过后台开发，也不知道使用什么后台语言，经过一番对比，在php、java、Python和nodejs中最后选用了nodejs作为后台开发工具，选择nodejs最重要的原因是后台也可以用js实现，不用再去研究新的语言，开发速度会快一些。

选定nodejs作为后台开发后，紧接着就是学习nodejs的相关内容，感谢这个伟大的互联网时代，获取学习资料的难度比我想象中要小得多，一番学习之后搭建起了初步了web端交叉口流量图框架。Web端开发的最后一个难点就是将应用部署到服务器上，跟着网上的攻略买服务器、买域名、学习基本的linux系统操作命令，一切就绪之后，web端的交叉口流量图应用终于可以正式运行。

尽管现在回过头来看界面设计简直惨不忍睹，当时完成上线后能正常访问心里还是有些小激动的。

Web端交叉口流量图应用上线后，便开始准备开发交叉口渠化示意图功能。为了使得渠化示意图能最大程度的贴合实际交叉口，我重点参考了国标中关于交叉口标线相关的规范，借鉴了国标中交叉口示意图的绘图风格，并以此作为渠化示意图绘制的基本风格，功能上能够实现处理左转待转区、直行待转区、可变车道、公交专用道，右转渠化岛等。

交叉口渠化示意图开发中，需要计算的点位数远多于交叉口流量转向图，对点位计算的精度要求也更高，所以整体开发难度更大，加之期间有其他事情耽搁，开发周期相当漫长，交叉口渠化示意图最后上线测试也比预期推迟了很长一段时间。

上线测试一段时间后，根据大家的反馈，部分交叉口左转或者掉头半径不足时左转或掉头车道会被设置在进口道外侧。因此又增加了车道调整功能，通过点击箭头标志更换箭头类型，使其更加适应实际交叉口情况。

要构成一个完整的信号交叉口设计评价分析应用，有了交叉口流量图和渠化示意图模块后，还缺少信号方案设计和评价分析模块。将已有的流量图和渠化示意图模块组合到一起搭建初步的交叉口应用框架。首先需要解决的问题是应用界面设计，流量图和渠化示意图界面看起来严重缺乏设计感，也不太满足软件交互需求。为此学习了一段时间界面设计，参考其他一些在线应用的界面设计风格，在AI中绘制了初始版本的界面。

交叉口信号方案一般由相位相序图和相位配时图组成，考虑了非机动车相位、行人相位、搭接相位、待转相位等开发了信号方案设计模块。

完成信号方案设计模块后，开始开发评价分析功能。根据交叉口评价分析的实际需求，选择交叉口饱和度、延误、排队长度和服务水平作为评价分析指标，基于HCM2000手册中评价分析模型进行计算。结合项目报告中对评价分析结果图形化的需求，四个指标的评价结果均采用了图形化展示效果。

考虑到实际应用中对交叉口评价分析大多数需要对早高峰、平峰、晚高峰等情况进行评价分析，或者某个交叉口改造中不同方案的对比，交叉口应用支持对渠化、流量、信号等进行多方案设计，并可以在评价结果中直接对比分析不同方案，也支持将评价分析结果导出到excel中进一步处理分析。