CN113947908A - 浮动车排队长度计算收费站以及红绿灯实时路况信息技术 - Google Patents
浮动车排队长度计算收费站以及红绿灯实时路况信息技术 Download PDFInfo
- Publication number
- CN113947908A CN113947908A CN202111273967.3A CN202111273967A CN113947908A CN 113947908 A CN113947908 A CN 113947908A CN 202111273967 A CN202111273967 A CN 202111273967A CN 113947908 A CN113947908 A CN 113947908A
- Authority
- CN
- China
- Prior art keywords
- length
- link
- toll station
- traffic light
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/01—Detecting movement of traffic to be counted or controlled
- G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
- G08G1/0108—Measuring and analyzing of parameters relative to traffic conditions based on the source of data
- G08G1/0112—Measuring and analyzing of parameters relative to traffic conditions based on the source of data from the vehicle, e.g. floating car data [FCD]
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
- G07B15/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/01—Detecting movement of traffic to be counted or controlled
- G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
- G08G1/0125—Traffic data processing
- G08G1/0133—Traffic data processing for classifying traffic situation
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/01—Detecting movement of traffic to be counted or controlled
- G08G1/052—Detecting movement of traffic to be counted or controlled with provision for determining speed or overspeed
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/065—Traffic control systems for road vehicles by counting the vehicles in a section of the road or in a parking area, i.e. comparing incoming count with outgoing count
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/09—Arrangements for giving variable traffic instructions
- G08G1/095—Traffic lights
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/09—Arrangements for giving variable traffic instructions
- G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
- G08G1/0968—Systems involving transmission of navigation instructions to the vehicle
- G08G1/0969—Systems involving transmission of navigation instructions to the vehicle having a display in the form of a map
Abstract
本发明公开了浮动车排队长度计算收费站以及红绿灯实时路况信息技术,包括以下步骤:A:外部提供基于月度版地图计算的收费站、红绿灯、地图数据,写入到redis和couchbase,城市信息写入redis;B:收费站制作原则,路链长度限制200米:其他说明,如果当前路链长度不足200米,但是追加下一LINK超过200米,追加下一LINK,如果拓扑长度不足200米,逆向拓扑至第一个分汇流点不进行打断继续拓扑,当路链拓扑中遇到第二个分汇流点则进行打断。本发明具备更能准确的反映出收费站和红绿灯范围内道路的拥堵、缓慢或畅通状态的优点,解决了因过度依赖速度,会导致收费站和红绿灯场景路况状态计算的不是特别准确的问题。
Description
技术领域
本发明涉及智能交通技术领域,具体为浮动车排队长度计算收费站以及红绿灯实时路况信息技术。
背景技术
实时路况针对当今城市交通道路拥堵畅通情况所提出的一个概念,目前实时路况已经是一项成熟的车载智能交通导航技术,实时路况能实时反映区域内交通文字路况,指引最佳、最快捷的行驶路线,提高道路和车辆的使用效率,对于车主来说,最头疼的可能不是只涨不跌的油费,也都不是各种繁琐的保养,反而是日日活在拥堵的道路当中,过着有车比没车更缓慢的生活,而掌握了实时路况,则可以给予车主选择其他道路的主动权,部分车主也会通过交通电台等方式获取交通路况,其实这也是获取实时路况的一种方式,但是与实时交通路况信息相比,就缺乏一种宏观的资讯,很容易刚逃过了一条拥堵的道路,又陷入了另外一条拥堵的道路。
所以随着智能交通的发展,实时掌控路段信息,绕路防堵也逐渐变得必不可少,由于目前的计算实时路况信息的方式是通过GPS回传的旅行时间和距离等信息计算平均速度,再通过当前道路的道路等级和相对应的速度区间得出link的路况状态,但这种方法因为过度依赖速度,但却不使用收费站和红绿灯场景,会导致收费站和红绿灯场景路况状态计算的不是特别准确,为此我们提供了浮动车排队长度计算收费站以及红绿灯实时路况信息技术。
发明内容
本发明的目的在于提供浮动车排队长度计算收费站以及红绿灯实时路况信息技术,具备更能准确的反映出收费站和红绿灯范围内道路的拥堵、缓慢或畅通状态的优点,解决了因过度依赖速度,会导致收费站和红绿灯场景路况状态计算的不是特别准确的问题。
为实现上述目的,本发明提供如下技术方案:浮动车排队长度计算收费站以及红绿灯实时路况信息技术,包括以下步骤:
A:外部提供基于月度版地图计算的收费站、红绿灯、地图数据,写入到redis和couchbase,城市信息写入redis;
B:收费站制作原则,路链长度限制200米:其他说明,如果当前路链长度不足200米,但是追加下一LINK超过200米,追加下一LINK,如果拓扑长度不足200米,逆向拓扑至第一个分汇流点不进行打断继续拓扑,当路链拓扑中遇到第二个分汇流点则进行打断,支持收费站手动维护功能;
C:红绿灯制作原则,路链长度限制350米:当路链长度不满足350米,但追加下一Link,路链长度不足600米,保留下一Link到路链中,长度超过600米,不保留下一Link,当路链长度不满足打断条件,但遇到其他红绿灯,则进行打断,当路链长度不满足打断条件,但遇到收费站点,则进行打断;
D:数据接入:外部将浮动车相关的信息写入到kafka中,匹配,识别扎堆点的条件:扎堆时间大于等于15秒,点对的平均速度小于10,扎堆点的GPS时间距离轨迹退出时间在5分钟以内,排队长度:选择进入收费站后第一个扎堆点到收费站或红绿灯的距离;
E:融合:单车最大排队长度作为该收费站/红绿灯的排队长度,分城市:通过城市信息,将路况信息分城市;
F:发布:有排队长度且高频车辆数大于3的收费站或红绿灯,取所有link最大排队长度和最大高频车辆数,排队长度,重新定义5色状态;
(1)status-1(畅通):queuingDistanceMax>0&&queuingDistanceMax<=30;
(2)status-2(缓慢):queuingDistanceMax>30&&queuingDistanceMax<=70;
(3)status-3(极度缓慢):queuingDistanceMax>70&&queuingDistanceMax<=100;
(4)status-4(拥堵):queuingDistanceMax>100&&queuingDistanceMax<=150;
(5)status-5(极度拥堵):queuingDistanceMax>150。
优选的,所述资源文件:基于外部月度资源文件制作相关配置文件,分别写入对应的redis、Couchbase,数据接入:外部数据源入kafka,属于外部触发。
优选的,所述匹配:实时从kafka拉数据,当有外部数据源写入kafka时,会读取到相关的数据,然后匹配地图信息,计算排队长度相关信息,将计算结果写会kafka。
优选的,所述融合:实时从kafka拉数据,当有匹配数据写入kafka时,会接收到数据,然后将多车融合,计算最后的排队长度信息,写入kafka中。
优选的,所述分组:实时从kafka拉数据,当有融合数据写入kafka时,会接收到数据,通过城市配置信息,将全国路网分城市,写入Couchbase中并向zookeeper指定节点发送通知,Zookeeper:用于数据监听,CouchBase:作为数据仓储以及配置管理。
优选的,所述发布:监听zk指定节点,接收到监听后,计算对应的状态,并向特定节点写通知,共后端服务使用。
优选的,所述Storm:分布式实时大数据处理框架,Kafka:一种高吞吐量的分布式发布订阅消息系统。
优选的,所述Redis:远程字典服务,是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。
与现有技术相比,本发明的有益效果如下:
1、本发明具备更能准确的反映出收费站和红绿灯范围内道路的拥堵、缓慢或畅通状态的优点,解决了因过度依赖速度,会导致收费站和红绿灯场景路况状态计算的不是特别准确的问题。
2、本发明当前收费站车速为0,但通过计算出的排队长度,并不是很长,所以推测状态为畅通,通过结合排队长度得出的道路状态就会不再受限于速度这个属性,当前红绿灯位置车速为0,但通过计算出的排队长度,只有几辆车在等灯,所以推测状态为畅通,同收费站场景通过结合排队长度得出的道路状态就会不再受限于速度,使一些场景更能准确的计算出状态。
附图说明
图1为本发明系统架构图;
图2为本发明配置文件制作流程图;
图3为本发明匹配处理流程图;
图4为本发明发布处理流程图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
请参阅图1-图4,浮动车排队长度计算收费站以及红绿灯实时路况信息技术,包括以下步骤:
A:外部提供基于月度版地图计算的收费站、红绿灯、地图数据,写入到redis和couchbase,城市信息写入redis;
B:收费站制作原则,路链长度限制200米:其他说明,如果当前路链长度不足200米,但是追加下一LINK超过200米,追加下一LINK,如果拓扑长度不足200米,逆向拓扑至第一个分汇流点不进行打断继续拓扑,当路链拓扑中遇到第二个分汇流点则进行打断,支持收费站手动维护功能;
C:红绿灯制作原则,路链长度限制350米:当路链长度不满足350米,但追加下一Link,路链长度不足600米,保留下一Link到路链中,长度超过600米,不保留下一Link,当路链长度不满足打断条件,但遇到其他红绿灯,则进行打断,当路链长度不满足打断条件,但遇到收费站点,则进行打断;
D:数据接入:外部将浮动车相关的信息写入到kafka中,匹配,识别扎堆点的条件:扎堆时间大于等于15秒,点对的平均速度小于10,扎堆点的GPS时间距离轨迹退出时间在5分钟以内,排队长度:选择进入收费站后第一个扎堆点到收费站或红绿灯的距离;
E:融合:单车最大排队长度作为该收费站/红绿灯的排队长度,分城市:通过城市信息,将路况信息分城市;
F:发布:有排队长度且高频车辆数大于3的收费站或红绿灯,取所有link最大排队长度和最大高频车辆数,排队长度,重新定义5色状态;
(1)status-1(畅通):queuingDistanceMax>0&&queuingDistanceMax<=30;
(2)status-2(缓慢):queuingDistanceMax>30&&queuingDistanceMax<=70;
(3)status-3(极度缓慢):queuingDistanceMax>70&&queuingDistanceMax<=100;
(4)status-4(拥堵):queuingDistanceMax>100&&queuingDistanceMax<=150;
(5)status-5(极度拥堵):queuingDistanceMax>150。
资源文件:基于外部月度资源文件制作相关配置文件,分别写入对应的redis、Couchbase,数据接入:外部数据源入kafka,属于外部触发。
匹配:实时从kafka拉数据,当有外部数据源写入kafka时,会读取到相关的数据,然后匹配地图信息,计算排队长度相关信息,将计算结果写会kafka。
融合:实时从kafka拉数据,当有匹配数据写入kafka时,会接收到数据,然后将多车融合,计算最后的排队长度信息,写入kafka中。
分组:实时从kafka拉数据,当有融合数据写入kafka时,会接收到数据,通过城市配置信息,将全国路网分城市,写入Couchbase中并向zookeeper指定节点发送通知,Zookeeper:用于数据监听,CouchBase:作为数据仓储以及配置管理。
发布:监听zk指定节点,接收到监听后,计算对应的状态,并向特定节点写通知,共后端服务使用。
Storm:分布式实时大数据处理框架,Kafka:一种高吞吐量的分布式发布订阅消息系统。
Redis:远程字典服务,是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。
实施例一:
浮动车排队长度计算收费站以及红绿灯实时路况信息技术,包括以下步骤:
A:外部提供基于月度版地图计算的收费站、红绿灯、地图数据,写入到redis和couchbase,城市信息写入redis;
B:收费站制作原则,路链长度限制200米:其他说明,如果当前路链长度不足200米,但是追加下一LINK超过200米,追加下一LINK,如果拓扑长度不足200米,逆向拓扑至第一个分汇流点不进行打断继续拓扑,当路链拓扑中遇到第二个分汇流点则进行打断,支持收费站手动维护功能;
C:红绿灯制作原则,路链长度限制350米:当路链长度不满足350米,但追加下一Link,路链长度不足600米,保留下一Link到路链中,长度超过600米,不保留下一Link,当路链长度不满足打断条件,但遇到其他红绿灯,则进行打断,当路链长度不满足打断条件,但遇到收费站点,则进行打断;
D:数据接入:外部将浮动车相关的信息写入到kafka中,匹配,识别扎堆点的条件:扎堆时间大于等于15秒,点对的平均速度小于10,扎堆点的GPS时间距离轨迹退出时间在5分钟以内,排队长度:选择进入收费站后第一个扎堆点到收费站或红绿灯的距离;
E:融合:单车最大排队长度作为该收费站/红绿灯的排队长度,分城市:通过城市信息,将路况信息分城市;
F:发布:有排队长度且高频车辆数大于3的收费站或红绿灯,取所有link最大排队长度和最大高频车辆数,排队长度,重新定义5色状态;
(1)status-1(畅通):queuingDistanceMax>0&&queuingDistanceMax<=30;
(2)status-2(缓慢):queuingDistanceMax>30&&queuingDistanceMax<=70;
(3)status-3(极度缓慢):queuingDistanceMax>70&&queuingDistanceMax<=100;
(4)status-4(拥堵):queuingDistanceMax>100&&queuingDistanceMax<=150;
(5)status-5(极度拥堵):queuingDistanceMax>150。
资源文件:基于外部月度资源文件制作相关配置文件,分别写入对应的redis、Couchbase,数据接入:外部数据源入kafka,属于外部触发。
匹配:实时从kafka拉数据,当有外部数据源写入kafka时,会读取到相关的数据,然后匹配地图信息,计算排队长度相关信息,将计算结果写会kafka。
融合:实时从kafka拉数据,当有匹配数据写入kafka时,会接收到数据,然后将多车融合,计算最后的排队长度信息,写入kafka中。
分组:实时从kafka拉数据,当有融合数据写入kafka时,会接收到数据,通过城市配置信息,将全国路网分城市,写入Couchbase中并向zookeeper指定节点发送通知,Zookeeper:用于数据监听,CouchBase:作为数据仓储以及配置管理。
发布:监听zk指定节点,接收到监听后,计算对应的状态,并向特定节点写通知,共后端服务使用。
实施例二:
浮动车排队长度计算收费站以及红绿灯实时路况信息技术,包括以下步骤:
A:外部提供基于月度版地图计算的收费站、红绿灯、地图数据,写入到redis和couchbase,城市信息写入redis;
B:收费站制作原则,路链长度限制200米:其他说明,如果当前路链长度不足200米,但是追加下一LINK超过200米,追加下一LINK,如果拓扑长度不足200米,逆向拓扑至第一个分汇流点不进行打断继续拓扑,当路链拓扑中遇到第二个分汇流点则进行打断,支持收费站手动维护功能;
C:红绿灯制作原则,路链长度限制350米:当路链长度不满足350米,但追加下一Link,路链长度不足600米,保留下一Link到路链中,长度超过600米,不保留下一Link,当路链长度不满足打断条件,但遇到其他红绿灯,则进行打断,当路链长度不满足打断条件,但遇到收费站点,则进行打断;
D:数据接入:外部将浮动车相关的信息写入到kafka中,匹配,识别扎堆点的条件:扎堆时间大于等于15秒,点对的平均速度小于10,扎堆点的GPS时间距离轨迹退出时间在5分钟以内,排队长度:选择进入收费站后第一个扎堆点到收费站或红绿灯的距离;
E:融合:单车最大排队长度作为该收费站/红绿灯的排队长度,分城市:通过城市信息,将路况信息分城市;
F:发布:有排队长度且高频车辆数大于3的收费站或红绿灯,取所有link最大排队长度和最大高频车辆数,排队长度,重新定义5色状态;
(1)status-1(畅通):queuingDistanceMax>0&&queuingDistanceMax<=30;
(2)status-2(缓慢):queuingDistanceMax>30&&queuingDistanceMax<=70;
(3)status-3(极度缓慢):queuingDistanceMax>70&&queuingDistanceMax<=100;
(4)status-4(拥堵):queuingDistanceMax>100&&queuingDistanceMax<=150;
(5)status-5(极度拥堵):queuingDistanceMax>150。
资源文件:基于外部月度资源文件制作相关配置文件,分别写入对应的redis、Couchbase,数据接入:外部数据源入kafka,属于外部触发。
匹配:实时从kafka拉数据,当有外部数据源写入kafka时,会读取到相关的数据,然后匹配地图信息,计算排队长度相关信息,将计算结果写会kafka。
融合:实时从kafka拉数据,当有匹配数据写入kafka时,会接收到数据,然后将多车融合,计算最后的排队长度信息,写入kafka中。
Storm:分布式实时大数据处理框架,Kafka:一种高吞吐量的分布式发布订阅消息系统。
Redis:远程字典服务,是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。
实施例三:
浮动车排队长度计算收费站以及红绿灯实时路况信息技术,包括以下步骤:
A:外部提供基于月度版地图计算的收费站、红绿灯、地图数据,写入到redis和couchbase,城市信息写入redis;
B:收费站制作原则,路链长度限制200米:其他说明,如果当前路链长度不足200米,但是追加下一LINK超过200米,追加下一LINK,如果拓扑长度不足200米,逆向拓扑至第一个分汇流点不进行打断继续拓扑,当路链拓扑中遇到第二个分汇流点则进行打断,支持收费站手动维护功能;
C:红绿灯制作原则,路链长度限制350米:当路链长度不满足350米,但追加下一Link,路链长度不足600米,保留下一Link到路链中,长度超过600米,不保留下一Link,当路链长度不满足打断条件,但遇到其他红绿灯,则进行打断,当路链长度不满足打断条件,但遇到收费站点,则进行打断;
D:数据接入:外部将浮动车相关的信息写入到kafka中,匹配,识别扎堆点的条件:扎堆时间大于等于15秒,点对的平均速度小于10,扎堆点的GPS时间距离轨迹退出时间在5分钟以内,排队长度:选择进入收费站后第一个扎堆点到收费站或红绿灯的距离;
E:融合:单车最大排队长度作为该收费站/红绿灯的排队长度,分城市:通过城市信息,将路况信息分城市;
F:发布:有排队长度且高频车辆数大于3的收费站或红绿灯,取所有link最大排队长度和最大高频车辆数,排队长度,重新定义5色状态;
(1)status-1(畅通):queuingDistanceMax>0&&queuingDistanceMax<=30;
(2)status-2(缓慢):queuingDistanceMax>30&&queuingDistanceMax<=70;
(3)status-3(极度缓慢):queuingDistanceMax>70&&queuingDistanceMax<=100;
(4)status-4(拥堵):queuingDistanceMax>100&&queuingDistanceMax<=150;
(5)status-5(极度拥堵):queuingDistanceMax>150。
资源文件:基于外部月度资源文件制作相关配置文件,分别写入对应的redis、Couchbase,数据接入:外部数据源入kafka,属于外部触发。
分组:实时从kafka拉数据,当有融合数据写入kafka时,会接收到数据,通过城市配置信息,将全国路网分城市,写入Couchbase中并向zookeeper指定节点发送通知,Zookeeper:用于数据监听,CouchBase:作为数据仓储以及配置管理。
发布:监听zk指定节点,接收到监听后,计算对应的状态,并向特定节点写通知,共后端服务使用。
Storm:分布式实时大数据处理框架,Kafka:一种高吞吐量的分布式发布订阅消息系统。
Redis:远程字典服务,是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。
综上所述:该浮动车排队长度计算收费站以及红绿灯实时路况信息技术,解决了因过度依赖速度,会导致收费站和红绿灯场景路况状态计算的不是特别准确的问题。
尽管已经示出和描述了本发明的实施例,对于本领域的普通技术人员而言,可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型,本发明的范围由所附权利要求及其等同物限定。
Claims (8)
1.浮动车排队长度计算收费站以及红绿灯实时路况信息技术,其特征在于包括以下步骤:
A:外部提供基于月度版地图计算的收费站、红绿灯、地图数据,写入到redis和couchbase,城市信息写入redis;
B:收费站制作原则,路链长度限制200米:其他说明,如果当前路链长度不足200米,但是追加下一LINK超过200米,追加下一LINK,如果拓扑长度不足200米,逆向拓扑至第一个分汇流点不进行打断继续拓扑,当路链拓扑中遇到第二个分汇流点则进行打断,支持收费站手动维护功能;
C:红绿灯制作原则,路链长度限制350米:当路链长度不满足350米,但追加下一Link,路链长度不足600米,保留下一Link到路链中,长度超过600米,不保留下一Link,当路链长度不满足打断条件,但遇到其他红绿灯,则进行打断,当路链长度不满足打断条件,但遇到收费站点,则进行打断;
D:数据接入:外部将浮动车相关的信息写入到kafka中,匹配,识别扎堆点的条件:扎堆时间大于等于15秒,点对的平均速度小于10,扎堆点的GPS时间距离轨迹退出时间在5分钟以内,排队长度:选择进入收费站后第一个扎堆点到收费站或红绿灯的距离;
E:融合:单车最大排队长度作为该收费站/红绿灯的排队长度,分城市:通过城市信息,将路况信息分城市;
F:发布:有排队长度且高频车辆数大于3的收费站或红绿灯,取所有link最大排队长度和最大高频车辆数,排队长度,重新定义5色状态;
(1)status-1(畅通):queuingDistanceMax>0&&queuingDistanceMax<=30;
(2)status-2(缓慢):queuingDistanceMax>30&&queuingDistanceMax<=70;
(3)status-3(极度缓慢):queuingDistanceMax>70&&queuingDistanceMax<=100;
(4)status-4(拥堵):queuingDistanceMax>100&&queuingDistanceMax<=150;
(5)status-5(极度拥堵):queuingDistanceMax>150。
2.根据权利要求1所述的浮动车排队长度计算收费站以及红绿灯实时路况信息技术,其特征在于:所述资源文件:基于外部月度资源文件制作相关配置文件,分别写入对应的redis、Couchbase,数据接入:外部数据源入kafka,属于外部触发。
3.根据权利要求1所述的浮动车排队长度计算收费站以及红绿灯实时路况信息技术,其特征在于:所述匹配:实时从kafka拉数据,当有外部数据源写入kafka时,会读取到相关的数据,然后匹配地图信息,计算排队长度相关信息,将计算结果写会kafka。
4.根据权利要求1所述的浮动车排队长度计算收费站以及红绿灯实时路况信息技术,其特征在于:所述融合:实时从kafka拉数据,当有匹配数据写入kafka时,会接收到数据,然后将多车融合,计算最后的排队长度信息,写入kafka中。
5.根据权利要求1所述的浮动车排队长度计算收费站以及红绿灯实时路况信息技术,其特征在于:所述分组:实时从kafka拉数据,当有融合数据写入kafka时,会接收到数据,通过城市配置信息,将全国路网分城市,写入Couchbase中并向zookeeper指定节点发送通知,Zookeeper:用于数据监听,CouchBase:作为数据仓储以及配置管理。
6.根据权利要求1所述的浮动车排队长度计算收费站以及红绿灯实时路况信息技术,其特征在于:所述发布:监听zk指定节点,接收到监听后,计算对应的状态,并向特定节点写通知,共后端服务使用。
7.根据权利要求1所述的浮动车排队长度计算收费站以及红绿灯实时路况信息技术,其特征在于:所述Storm:分布式实时大数据处理框架,Kafka:一种高吞吐量的分布式发布订阅消息系统。
8.根据权利要求1所述的浮动车排队长度计算收费站以及红绿灯实时路况信息技术,其特征在于:所述Redis:远程字典服务,是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111273967.3A CN113947908B (zh) | 2021-10-29 | 2021-10-29 | 计算浮动车排队长度的收费站以及红绿灯实时路况信息方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111273967.3A CN113947908B (zh) | 2021-10-29 | 2021-10-29 | 计算浮动车排队长度的收费站以及红绿灯实时路况信息方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113947908A true CN113947908A (zh) | 2022-01-18 |
CN113947908B CN113947908B (zh) | 2022-09-27 |
Family
ID=79337158
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111273967.3A Active CN113947908B (zh) | 2021-10-29 | 2021-10-29 | 计算浮动车排队长度的收费站以及红绿灯实时路况信息方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113947908B (zh) |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012133760A (ja) * | 2010-12-01 | 2012-07-12 | Sumitomo Electric Ind Ltd | 交通信号制御装置及び交通信号制御方法 |
CN103903436A (zh) * | 2012-12-28 | 2014-07-02 | 上海优途信息科技有限公司 | 一种基于浮动车的高速公路交通拥堵检测方法和系统 |
CN103903432A (zh) * | 2012-12-26 | 2014-07-02 | 株式会社日立制作所 | 用于确定路链拥堵状况的设备和方法 |
CN103985261A (zh) * | 2014-04-21 | 2014-08-13 | 东南大学 | 基于车辆排队长度测算的交通信号灯控制方法及系统 |
CN104200672A (zh) * | 2014-08-19 | 2014-12-10 | 北方工业大学 | 基于多传感器融合的交通路口排队长度检测方法及系统 |
CN112802325A (zh) * | 2019-11-13 | 2021-05-14 | 北京百度网讯科技有限公司 | 车辆排队长度检测方法及装置 |
-
2021
- 2021-10-29 CN CN202111273967.3A patent/CN113947908B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012133760A (ja) * | 2010-12-01 | 2012-07-12 | Sumitomo Electric Ind Ltd | 交通信号制御装置及び交通信号制御方法 |
CN103903432A (zh) * | 2012-12-26 | 2014-07-02 | 株式会社日立制作所 | 用于确定路链拥堵状况的设备和方法 |
CN103903436A (zh) * | 2012-12-28 | 2014-07-02 | 上海优途信息科技有限公司 | 一种基于浮动车的高速公路交通拥堵检测方法和系统 |
CN103985261A (zh) * | 2014-04-21 | 2014-08-13 | 东南大学 | 基于车辆排队长度测算的交通信号灯控制方法及系统 |
CN104200672A (zh) * | 2014-08-19 | 2014-12-10 | 北方工业大学 | 基于多传感器融合的交通路口排队长度检测方法及系统 |
CN112802325A (zh) * | 2019-11-13 | 2021-05-14 | 北京百度网讯科技有限公司 | 车辆排队长度检测方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN113947908B (zh) | 2022-09-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109000668B (zh) | 基于车联网的实时智能导航方法 | |
CN102081859B (zh) | 一种公交车到站时间预测模型控制方法 | |
US20230325550A1 (en) | Method, device, equipment for determining test evaluation information and computer storage medium | |
CN104778834A (zh) | 一种基于车辆gps数据的城市道路交通拥堵判别方法 | |
US20090079586A1 (en) | Use of Pattern Matching to Predict Actual Traffic Conditions of a Roadway Segment | |
CN109612488B (zh) | 基于大数据微服务的混合出行方式路径规划系统及方法 | |
CN109859505B (zh) | 高速站点的预警处理方法、装置、服务器和介质 | |
CN107490384A (zh) | 一种基于城市路网的最优静态路径选择方法 | |
Li et al. | Traffic signal timing optimization in connected vehicles environment | |
CN106157621B (zh) | 一种基于数据分析的智能路况管理系统 | |
CN115063978B (zh) | 一种基于数字孪生的公交到站时间预测方法 | |
Yue et al. | Urban traffic bottleneck identification based on congestion propagation | |
CN106971535A (zh) | 一种基于浮动车gps实时数据的城市交通拥堵指数计算平台 | |
CN107945542B (zh) | 基于浮动车技术的城市道路绿波带决策支持方法及终端 | |
Wang et al. | Effects of coordinated formation of vehicle platooning in a fleet of shared automated vehicles: An agent-based model | |
Rapelli et al. | A distributed V2V-based virtual traffic light system | |
CN112669604B (zh) | 城市交通调度方法及装置 | |
CN114578848A (zh) | 一种基于离散点密度与全局规划的无人机巡检路径规划方法 | |
CN113947908B (zh) | 计算浮动车排队长度的收费站以及红绿灯实时路况信息方法 | |
Liu et al. | New generation of smart highway: Framework and insights | |
CN107895502A (zh) | 一种智慧城市智能交通引导系统 | |
Bazzan et al. | ITSUMO: an agent-based simulator for ITS applications | |
Zhuang et al. | Framework of experienced route planning based on taxis' GPS data | |
Hu et al. | Network-wide Traffic Signal Optimization under Connected Vehicles Environment | |
CN114078322B (zh) | 一种公交运行状态评价方法、装置、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |