重新配置net文件命后Reload之后，就可以看到效果了。
SUMO使用教程（五）
再来讨论一下SUMO仿真需要的文件。官方资料给的图：
从根部往上看，用于仿真的需要rou.xml文件和net.xml文件。而net.xml文件则由上面四种文件产生。分别是nod，edg，typ，con，各自的含义就是node，edge，type，connection。
node和edge之前都讲过了，type也比较简单，就是对edge的类型做个一个封装，这样的话描述就比较简单了。至于connection，就是车道合并的规则。SUMO默认是向右合并。也就是说，当三车道变成二车道的时候，右对齐，左边两个车道变成一个车道。当然啦，并不是所有的道路都是右对齐的，所以就有了这一文件的产生。 举个例子：
这样就可以实现L2公路与L12公路连接的时候，0车道和0,1车道对齐。
当然啦，这四个文件并不是必须的，比如type文件可以内置在edge里面，当然，当公路条数比较多而且很多参数一样的时候这样会比较麻烦。con文件既然有默认的选项，当然就不是必须的了。 有了四个文件，我们怎么一气呵成生成net文件呢？
in fact，写这样一个配置文件就可以了，文件的后缀名是.netc.cfg
netconvert –c XXXX.netc.cfg
最后，只要敲一下这样命令行，让netconvert执行这个配置文件就可以成功生成net.xml文件了。
SUMO使用教程（六）
今天一直在设置SUMO中的交通灯，但是官方文档对具体配置文件的编辑说的很详细，但是怎么导入到其中就一笔带过了，根据上下文猜测，数次尝试也不行，最后曲线救国，毕竟所有的网路信息，包括交通信号灯的默认设置信息都在里面，所以直接修改net.xml文件或许可以实现。 果不其然，在测试的net文件中，发现了下面这样一段代码：
很显然，这一段就是对node5节点上的交通信号灯的完全描述。
tlLgic节点中id就是node的id，所以说，交通信号灯其实适合node一一对应的。type就是交通信号灯的属性，是动态的还是静态的。动态的就是用API接口利用Phyton编程实现。这里我面用静态的。programID这个就是这段交通信号灯硬编码的id，也就是说，其实交通信号灯在仿真过程中是可以改变的，而就是根据这个programID来确定需要改变的方向。offset就是这段编码启动的时间。 接下来就是phase这个子标签了。
一个十字路口的红路灯的每一个不同情况都叫做一个相位，所有的相位按照顺序合在一起就是一个周期，所以说，对交通信号灯编辑，本质上就是编辑各个相位，并对其进行组合和时间设置（duration）. 从上往下我们依次观察每一个相位如下：
改变相位时长（duration）就可以改变红绿灯改变的速率。改变相位状态，就可以控制每个相位信号灯的不同通行状况。
SUMO使用教程 - 图文
