在城市交通领域待久了你会发现一个特别明显的事实很多问题归根结底都是空间问题。哪条路在堵、哪片区域需求旺盛、公交覆盖有没有盲区、信号灯配时和路网结构匹不匹配这些事只要落到地图上立刻一目了然。这也是为什么“基于GIS技术的城市交通管理应用”这个方向这些年几乎成了智慧交通项目的标配。但说句实在话真正把GIS用明白的项目不多。很多系统做着做着就变成了“一张会变色的地图”看起来花团锦簇核心分析能力却几乎没有。我参与过几个类似的项目跟各路团队反复磨合踩了不少坑也沉淀了一些真正能落地的经验。这篇文章不聊虚的就把我从需求拆解、技术选型到数据建模、功能落地、问题排查的完整思路写出来给正在做或者准备做这类系统的朋友一个参考。1. 项目整体思路GIS在交通管理里到底解决什么问题1.1 核心需求解析不是画地图而是算空间关系接到“基于GIS技术的城市交通管理应用”这个标题时首先要纠正一个普遍误解GIS不是用来画图的而是用来做空间分析和空间决策的。一张静态地图只能告诉你“哪里是哪里”真正有价值的是“从这里到那里要多久”“这个区域的交通压力有多大”“如果把这条路封闭对周边路网会产生什么影响”。我习惯把这类系统的核心需求拆成三个层次第一层是“可视”把路网、卡口、信号灯、公交线路、事故点位这些交通要素按照真实的地理坐标呈现在地图上。这一层最基础但很多项目连这层都做不扎实问题主要出在数据坐标不统一、路网拓扑没构建后面细说。第二层是“分析”包括最短路径分析、服务范围分析、OD分析起终点出行分析、交通拥堵时空演变分析等。这一层才是GIS的看家本领。比如你要新开一条公交线路不能凭感觉画线而是要用GIS算出沿线的人口覆盖、岗位覆盖、与现有线路的重复系数这些数据出来之后决策才有依据。第三层是“协同”把GIS的分析结果和其他业务系统联动起来。信号灯配时优化需要知道路口上下游的流量关系这依赖路网拓扑应急调度需要知道最近的救援力量在哪里、走哪条路最快这依赖实时路况和路径分析。GIS在这里扮演的是“空间计算中枢”的角色而不是一个孤立的地图展示模块。1.2 为什么必须选择GIS而不是纯图表工具有人会问交通数据我用报表工具也能看为什么非要上GIS道理很简单交通数据的绝大部分属性都跟位置强相关脱离空间位置的统计几乎没有意义。举个例子你说“某区域早高峰平均车速25公里/小时”这个数字本身没有决策价值。但如果你把车速数据渲染到路网上看到主干道东段拥堵严重、西段畅通再叠加周边土地利用数据发现拥堵路段附近有个大型居住区、而西段是产业园你就能推断出通勤潮汐方向进而优化信号配时或者调整公交运力。这个“叠加分析”的过程就是GIS的核心价值。再比如事故多发点鉴别黑点识别传统做法是按行政区统计事故数但事故往往发生在行政边界附近统计结果经常失真。用GIS做基于路网的事故密度分析核密度分析能在真实路网上找出事故簇集位置精度完全不一样。我参与过的一个模拟项目里某市交警部门一直以为某个路口事故最多结果用GIS把三年事故数据落到路网上做聚类分析发现真正的高发点是距离该路口200米的一个弯道只是因为事故记录里填写的“路口名称”不统一导致传统统计完全走偏。这种例子太多了说到底就是空间归因的问题。1.3 系统的边界与定位先理清“不做什么”做这类系统最容易犯的错误是需求边界无限膨胀。交通管理涉及的子系统太多了信号控制、诱导发布、公交调度、停车管理、车路协同……如果什么都想做进GIS平台里最后一定失控。我建议在项目启动时必须先跟业务方对齐搞清楚GIS平台承担的角色边界。以我参与过的项目为例我们最后明确了三个核心定位交通态势“一张图”汇聚多源数据做实时监测和态势研判不直接控制信号机但为信号优化提供分析依据。空间分析“计算器”提供专业的交通空间分析工具集供业务人员按需调用。辅助决策“沙盘”支持方案推演比如某路段施工封闭后绕行方案是否可行、对周边路网冲击多大先用GIS模拟。这几个定位一旦明确后面的数据规划、功能设计、开发排期就都有了依据。反之如果定位含糊开发过程中需求会像滚雪球一样越来越大。2. 技术选型与架构设计稳定压倒一切2.1 三个关键选型引擎、数据库、前端框架技术选型是这类项目的第一个大坑。我见过不少团队一上来就追求技术新颖选了一些社区很小、文档稀缺的组件最后查问题都找不到人问。做交通管理这类强业务系统我的原则是成熟优先、生态优先、性能其次。GIS引擎方面我推荐优先考虑开源里的GeoServer或MapServer。为什么不用商业引擎不是商业的不行而是考虑到后续扩展、信创环境适配和成本问题开源方案通常更稳妥。GeoServer对矢量数据的支持、WMS/WFS服务的发布、样式配置的灵活度在中小型项目里完全够用。大型项目如果对并发性能和稳定性要求极高再考虑商业引擎也不迟。我在参与某项目的早期团队里有人建议自研地图切片方案折腾了两个礼拜发现效果远不如直接用现成方案果断回退。前车之鉴别重复造轮子。空间数据库方面PostgreSQL配合PostGIS扩展是绝对的主流选择。PostGIS提供丰富的空间函数和索引支持空间查询性能在同等硬件条件下优于很多商业数据库。特别是对于路网分析这种需要大量空间运算的场景PostGIS的pgrouting插件能直接跑最短路径避免了后端自己实现复杂图算法的麻烦。前端框架上开源的地图库像Leaflet、OpenLayers都很成熟。Leaflet轻量、上手快适合做功能相对集中的管理端OpenLayers功能更全面对投影转换、多图层叠加、要素编辑的支持更好适合做数据编辑类业务。我之前做过的项目里前端核心用的是OpenLayers因为它对大量矢量要素的渲染性能和控制力更好。前端还需要搭配一套UI框架市面上主流的管理端UI库都可以关键是团队熟悉。2.2 分层架构设计前后端分离接口标准化整个系统的架构我习惯分成四层数据层核心是空间数据库负责存储路网数据、交通态势数据、业务专题数据。另外需要独立的文件存储来存放地图切片如果用了瓦片服务的话。这一层的关键设计是所有带位置属性的业务数据表都必须包含空间字段并且创建空间索引。服务层GIS服务地图发布、要素查询、空间分析、数据服务业务数据CRUD接口、分析服务路径规划、缓冲区分析、叠加分析等。服务层统一走RESTful API返回GeoJSON格式的数据。选用GeoJSON而不是其他自定义格式是为了降低前后端沟通成本生态支持也最广泛。应用层包括大屏可视化、Web管理端、移动端如果有需要。这一层不对接数据库全部通过接口访问服务层。集成层与外部系统的对接比如信号控制系统的数据接口、浮动车数据的推送接口、视频监控平台的取流接口等。这层往往决定了项目的实施难度因为外部系统格式五花八门一定要在接口设计上做好适配。2.3 几个容易忽略的架构细节有几个细节我建议在架构设计阶段就考虑清楚不然后面返工很痛苦。投影坐标系的选择。很多团队在这个问题上吃过亏。城市级应用建议使用高斯-克吕格投影的CGCS2000坐标系并且在数据入库时统一完成坐标转换。前端展示时统一转换为Web MercatorEPSG:3857。千万别让前端同时处理多个坐标系的数据那会让地图错位问题变得极难排查。实时数据与基础数据的分离。路网数据、POI数据这类相对静态的基础数据可以发布成地图服务供前端直接调用。但实时路况、车辆位置、卡口过车记录这类高频更新数据不应该直接打在基础图层里而是通过接口动态加载用图层叠加的方式渲染。原因很简单基础图层可以被浏览器或中间层缓存实时数据则需要高频刷新混在一起会让缓存机制失效地图加载性能崩得很惨。数据更新时间要有保障机制。GIS数据的价值很大程度上取决于时效性。路网新增了道路、封路施工、单行线调整如果底图不及时更新再好的分析功能都是空中楼阁。我见过有项目上线半年底图还是半年前的旧路网新开通的高架桥在图上根本不存在业务人员直接失去信任。这个问题一定要在需求阶段跟业务方明确数据更新的责任主体和频率。3. 数据体系设计GIS系统的“地基工程”3.1 交通GIS数据到底包含哪些我把交通管理GIS系统的数据分成四大类项目初期就得理清楚基础地理数据行政区划、水系、建筑物轮廓、绿地、地名注记等。这类数据一般向测绘部门或各地数据主管部门申请获取。注意版权和数据更新周期问题签约时看清楚授权范围。交通路网数据这是最核心的数据包含道路中心线、道路面、交叉口、匝道、桥梁隧道等。路网数据不仅要看几何形状是否正确更要看拓扑关系是否建立——也就是说每条道路的端点、连通关系、转向限制这些逻辑信息是否完整。没有拓扑的路网数据充其量是一堆画在地图上的线条无法用于路径分析。交通设施数据信号灯、标志标线、电子警察、卡口、诱导屏、公交站点、停车场的空间位置和属性信息。这类数据往往是业务系统里的台账数据需要做地理编码或者通过坐标字段关联到空间位置。动态交通数据实时路况、事故信息、交通管制信息、公交实时位置、出租车轨迹等。这类数据更新频率高通常是流式接入需要定时任务或者消息队列处理。3.2 路网拓扑空间分析的命脉我一直强调路网数据是整个系统分析能力的命脉。没有构建拓扑关系的路网路径分析、等时圈分析、OD分析全都做不了因为算法要求“沿路网可达”而不是“两点之间直线最近”。路网拓扑构建包含几个要素线段端点是否精确相接、交叉口是否建立了连接关系、单向通行和转向限制是否录入。市面上有专业的路网编辑工具也可以借助ArcGIS或QGIS的拓扑检查功能。但说实话城市路网的数据整理工作量非常大一个中等规模城市的主干路网往往需要两三个有经验的数据工程师干一两个月。我踩过的坑是把地图厂商提供的路网数据拿过来直接用结果发现转向限制丢失严重交叉口处线段端点有微小偏移导致拓扑断裂。后来老老实实做了拓扑重建和转向建模。这里有一个经验从互联网地图商获取的基础路网数据用于底图展示没问题但要用在专业的路径分析场景必须进行拓扑预处理不能直接拿来做分析。补充一点路径分析还涉及到道路等级、通行速度、通行方向双向、单向、禁行等属性。这些属性直接影响路径计算的权重和结果。在设计路网属性表时这些字段必须留好并且建立数据填报规范避免不同路段属性口径不一致。3.3 坐标统一与数据校核最无聊但最关键的工作数据校核真的是这个项目里最无聊但又最关键的工作。几个常见问题坐标系统一。城市里不同部门的数据来源五花八门有的用经纬度有的用地方坐标系必须全部统一到同一个参考系。我在项目里专门写了一套坐标转换工具批量处理各类数据源的坐标字段转换后立即抽查校验差一米都不行。这活儿不能靠人工拿鼠标在屏幕上点着看一定要写自动化校验脚本。几何拓扑校核。包括重叠要素检查两条路网线重合、悬挂节点检查路段端点悬空、伪节点检查无需分割的线段被切断等。QGIS里有很多现成的拓扑检查插件建议集成到数据日常维护流程中。属性逻辑校核。比如道路等级和限速是否合理匹配、单行道属性是否与地面标志一致。这类错误很难通过GIS算法自动发现需要实际巡检或者依赖业务部门反馈。我建议在系统里做一个“数据问题上报”的入口让一线业务人员在日常使用中发现数据问题时能直接反馈比定期审查效率高得多。3.4 数据更新机制系统能不能长期活下去的关键很多GIS项目上线时数据漂漂亮亮半年后就成了摆设问题就出在更新机制缺失。对一个真实的城市交通管理系统来说我建议至少建立以下更新流程基础底图数据按季度或半年更新一次来源为测绘数据主管部门路网数据按月度更新来源包括规划审批信息、工程完工交付信息交通设施数据按业务变动实时更新比如新增卡口、调整限速标志业务部门在OA流程里发起变更后同步到GIS动态交通数据则依赖对接数据源按分钟级或秒级接入。我参与过的某模拟项目里专门设计了一个数据更新工单模块业务人员发现某条路改了单行在系统里发起变更申请附上新方案由管理员审核后进入路网编辑流程修改完成后发布新版本。整个链条跑通后数据质量好很多。这种东西业务上不复杂但需要制度化技术只是支撑。4. 核心业务功能拆解从“有用”到“好用”4.1 实时交通态势监测一张图看懂城市交通实时监测是这类系统最直观的功能也是业务方最容易“验收”的部分。技术上要做的是把多源交通数据落到一个时空坐标系里地图上叠加显示。我在项目中优先接入的数据源是浮动车数据出租车、网约车轨迹因为覆盖范围广、更新频率高算法相对成熟。通过对轨迹点做地图匹配——把GPS点匹配到实际道路路段上——再计算路段平均速度就能得到整个路网的实时通行速度场。用不同颜色分级渲染速度区间绿色畅通、黄色缓行、红色拥堵这就是典型的“交通态势一张图”。但做实时监测有一个容易忽视的问题路段的颜色不只是为了好看还要能“穿透”到具体事件。业务人员点开一段红色拥堵路段至少要看到拥堵长度、持续时间、行驶速度、跟去年同期对比等信息。光有颜色没有详情那依然是一张“图”不是一个“应用”。我习惯在弹窗信息里集成“拥堵溯源”入口通过分析上下游路况初步判断拥堵成因汇入瓶颈、事故、施工占道等辅助业务人员快速响应。4.2 空间分析工具集从“看”到“算”如果说实时监测是“看”的话空间分析就是“算”。这个“算”才是GIS应用的价值护城河。我梳理了几个核心分析工具缓冲区分析比如要评估某学校门口50米范围内有哪些停车泊位、交通设施或某路段施工影响200米范围内的绕行道路。这个功能技术门槛低但对交通管理来说实用性极高。叠加分析比如把事故分布图层和道路条件图层叠加找出事故高发路段是否伴随着道路照明不足、标志缺失等问题。叠加分析要求各图层坐标系一致、范围匹配这些在数据准备阶段就要做好。网络分析包括最短路径、服务范围、车辆路径规划等。在应急场景中比如接到警情后最近的警力到达现场有多远、沿途信号灯是否可以优先放行这些都需要网络分析支撑。等时圈分析以某点为圆心计算沿路网不同出行时间5分钟、10分钟、15分钟能够覆盖的范围。这个功能在公交线网规划、急救站点选址、消防站布点中特别有用。我做过一个急救站点选址的模拟分析通过等时圈对比几个候选场址的覆盖差异最终选出的方案在模拟中把急救响应时间缩短了将近20%。这种直观的空间量化结果业务部门非常认。4.3 交通拥堵治理与事故分析贴近业务的GIS应用这个模块是系统真正“走进业务”的关键。拥堵点分析方面我习惯基于实时路况历史数据统计一定时间窗口内比如一个季度各路段拥堵发生的频次、持续时长、平均拥堵指数生成“拥堵热力”。然后再和路网结构叠加看看频繁拥堵的路段是交叉口渠化不足、还是上游交通量超出了路段通行能力。这里最容易被忽略的是时间维度。有些路段只有早高峰拥堵有些是晚高峰有些节假日特别堵仅显示一张平均热力图会掩盖关键信息。所以时间切片功能必须做扎实至少能按小时维度查看不同时间段的拥堵分布再进一步叠加天气数据、大型活动数据寻找拥堵诱因。事故分析方面典型功能是事故多发点识别。把事故记录的位置信息落到路网上用核密度分析方法找出空间上的事故簇集区域。这里的数据问题在于事故台账里记录的位置经常是文字描述比如“XX路XX路口南侧100米”需要先做地理编码转成坐标。如果原始描述不规范地理编码成功率会很低这也是我在前面强调数据校核工作的原因之一。实测下来认真做好数据清洗事故点定位准确率能超过90%后续分析才有参考价值。4.4 综合交通模型与模拟推演让GIS成为“决策沙盘”这个功能属于进阶场景了。当我们积累了足够的历史数据之后就可以做简单的交通模型分析和模拟推演。比如道路施工影响分析某主干道要封闭施工半年GIS平台里可以先模拟封闭后的路网情况用最短路径算法重新计算绕行路线的交通量变化预估哪些周边道路会承受额外压力进而提前制定分流方案和绕行诱导策略。再比如新开公交线路的客流走廊分析利用GIS对现有出行OD数据进行空间聚合找出潜在的高需求走廊比对着人口分布图上拍脑袋科学得多。这个能力一开始不需要做得很复杂可以是“离线分析为主、在线展示结果”的模式也就是后端跑模型前端只负责展示多方案对比。5. 实操过程复盘哪个环节最容易翻车怎么处理5.1 需求调研阶段的关键动作项目启动后我最建议做的事不是急着搭环境而是跟业务部门坐在一起让他们把日常工作中“问得最多的十个问题”列出来。比如“这个路口的拥堵是从哪里排过来的”“为什么这里事故多发”“新开通的道路要配多少公交线路”每个问题对应一个GIS分析功能这就形成了需求池的核心。在这个阶段我踩过最大的坑是“听着业务部门描述来设计功能”。他们说要“实时监测拥堵”如果我们只做了个热力图业务人员会觉得很好看但不解决任何问题。后来我们改成“具体某条路的拥堵历史曲线上游关联分析”业务人员才开始真正用起来。所以必须把业务需求翻译成具体的功能行为和输出产物而不是停留在抽象描述。5.2 开发阶段的核心里程碑从开发节奏上我建议划分这么几个里程碑第一个里程碑是“数据就绪”所有基础数据完成入库、坐标统一、拓扑检查地图服务能稳定发布。这个阶段不写任何业务功能。这个里程碑完不成后面都是空中楼阁。第二个里程碑是“地图可用”地图能加载、图层能控制、要素能查询。这个阶段最重要的不是功能多而是让用户体验到流畅的地图操作。第三个里程碑是“核心分析跑通”把路径分析、缓冲区、叠加分析、等时圈这些核心分析工具做出来先不考虑界面美化把算法结果跑对。这个阶段可以和业务人员一起验收算法正确性。我特别强调“算法验证”这个事因为路径分析结果是否正确需要拿实际路况比对不是看一眼“感觉对了”就行的。第四个里程碑是“业务功能集成”把分析工具和业务场景结合起来形成完整功能模块比如拥堵溯源、事故黑点识别、施工影响分析。这个阶段是前后端联调最多、最容易出bug的阶段要预留足够的时间。第五个里程碑是“性能优化和上线”做并发测试、大图层渲染优化、数据更新验证然后正式上线。性能和稳定性问题通常在真实使用场景才会暴露所以上线后前两周要有开发人员驻场盯问题。5.3 制备原型数据的经验心得在数据不完善的情况下做开发原型数据制备非常关键。我习惯的做法是选取项目范围内一条主干道周边的2-3平方公里区域手工精细化制作路网和设施数据把拓扑关系、属性信息全部补全用这个“样板区”来开发和验证所有功能。功能验证通过后再推广到全域数据。这个做法有几个好处一是数据工作量可控一个精细样板区几天就能做出来二是业务人员在样板区里校验功能时很直观反馈意见比看抽象demo要到位三是样板区的数据质量有保障避免全域数据的各种“脏”问题干扰功能验证。5.4 关于性能的几条实用经验地图类应用的性能问题描述起来就一句话数据量一大渲染和查询就卡。实际的坑远不止这些矢量要素渲染。如果前端直接加载几万条路网线浏览器会直接卡死。解决方案把静态数据发布为矢量瓦片动态数据用聚合显示或分级显示。我实测下来矢量瓦片能把渲染性能提升一个量级。空间查询优化。空间表一定要建空间索引PostGIS里的GIST索引否则一个跨表的空间Join查询可能要几十秒建了索引后毫秒级返回。金字塔缓存。底图瓦片一定要提前预生成缓存不要让用户每次打开地图都等待动态切图。尤其大屏展示场景卡顿会直接拉胯整个汇报效果。大数据量聚合。路况数据是按秒级高频更新的如果前端每次都拉原始数据来渲染根本不现实。后端要做聚合处理比如按5分钟粒度输出路段平均速度前端只渲染聚合结果。6. 常见问题与排查技巧实录系统上线后一定会遇到的6.1 地图错位/图层偏移先查坐标系别查代码地图错位是最常见的现象几乎每个GIS项目上线初期都会遇到。排查的时候优先检查坐标系而不是去翻前端代码。具体路径先确认底图服务是什么坐标系再确认叠加的业务图层是什么坐标系两者不一致就一定会错位。另外也要检查同一个坐标系下的不同数据源因为CGCS2000坐标系下也可能存在不同中央经线的分带跨带数据不转换直接拼接位移可能有几百米。有一个快速验证方法随便选一个位置准确的特征点比如某个地标建筑分别看底图和业务图层中该点的坐标值算一下差值。如果差值稳定且呈固定数值基本就是坐标系/投影参数不一致的问题去处理数据投映关系即可。6.2 路网拓扑断裂路径分析“绕远路”的头号原因路径分析算出来的路线不是绕远就是穿楼绝大多数原因是路网拓扑不连通。排查方法在疑似断裂的地方放大查看看看线段的端点有没有精确相接。有些线段在视觉上是连着的但实际端点之间差了0.001度拓扑关系上就是断的。解决方案有两种一是用数据编辑工具手动捕捉端点适用于数据量小的情况二是编写自动修复脚本根据容差设置将距离足够近的端点吸附合并。更复杂的拓扑断裂比如高架和地面道路的上下层关系则需要人工处理因为空间位置重叠但互不相通是合理的不能简单合并节点。6.3 实时数据延迟检查链路每一环都可能有瓶颈实时数据从源头到前端展示中间链路很长数据源推送→消息队列接收→流式处理→入库→接口服务→前端渲染。每一环都可能产生秒级甚至分钟级延迟。排查思路是分段测时用时间戳标记每段的出入时间确定延迟主要发生在哪一段。最常见的瓶颈在后端入库环节——如果数据量很大但数据库写入没有做批量优化延迟会不断累积。我遇到过某项目实时轨迹数据入库延迟持续增长排查后发现是写入操作没有走批量提交一条条insert数据库连接池被打满。优化成批量写入后延迟恢复正常。6.4 大屏展示卡顿不是性能问题是资源策略问题大屏展示卡顿业务方第一反应是“服务器性能不行”十有八九不是。更多是浏览器渲染资源的策略不当。建议这么处理一是把静态底图切瓦片并开启缓存前端加载走CDN或者浏览器缓存二是动态图层只显示当前视域范围内的数据缩小时自动聚合三是控制刷新频率大屏不需要实时到秒级一般10-30秒刷新一次动态图层即可。另外大屏分辨率通常是4K甚至8K前端分辨率适配做不好地图上的字和图标会糊成一团观感极差。我在项目里被这个问题折腾过后来专门做了DPI适配的专题优化才解决。6.5 几个“玄学”问题的排查经验整理我把实操中积累的高频问题整理成一个速查表现象常见原因处置方法地图拖动卡顿矢量要素过多或底图瓦片未预缓存启用矢量瓦片/预生成金字塔缓存部分图层不显示坐标系不一致或服务发布范围设置错误检查图层元数据、服务配置路径计算异常路网拓扑断裂、转向属性错误做拓扑检查和转向建模空间查询超时缺少空间索引为空间字段创建GIST索引数据更新后地图不刷新浏览器缓存或服务端缓存未失效清理缓存并检查缓存更新策略属性字段为空/乱码数据编码不一致统一字符编码检查导入映射关系7. 复盘心得给即将入坑的同行几句实在话如果你正准备启动一个GIS交通管理项目我个人最想说的几句话技术栈真的不是项目最大的风险数据才是。很多项目死在数据质量上而不是死在代码上。前期多花时间做数据规划、数据清洗、拓扑构建后面会顺畅非常多。别把“空间分析”做成“展示面板”。业务方一开始可能只要求“弄个地图看看”但你要想清楚这个系统的长期价值在哪里。一味堆功能不如把三五个核心分析场景做深做透。我在项目里最大的成就感不是完成了多少功能模块而是业务人员告诉我“以前判断拥堵要看半天报表现在直接打开一张图就知道往哪儿派警力”。第三方组件能少用就少用能换就换。不是说开源组件不好而是要选生态好的、社区活跃的、遇到问题能搜到答案的。交通系统是要长期运维的不是发个论文演示完就结束的。最后一个小技巧做GIS演示的时候一定要准备离线切片包切忌到时候现场网络状态不确定、地图刷不出来再好的功能也翻车。我在某次汇报前一天专门生成了目标区域的离线瓦片包备用结果现场网络果然不给力靠着离线包撑完了全场听众压根没察觉。这种细节关键时刻能救命。数据为王稳定至上分析为本——这十二个字基本就是我这些年做GIS交通应用的全部心得。项目能不能做好不取决于用多酷炫的技术而取决于有没有把每一个空间关系说清楚有没有让地图真正为交通决策创造价值。