掌桥专利:专业的专利平台
掌桥专利
首页

一种车辆类型检测方法及装置

文献发布时间:2023-06-19 18:53:06


一种车辆类型检测方法及装置

技术领域

本申请涉及数据分析处理领域,尤其涉及一种车辆类型检测方法及装置。

背景技术

随着交管部门对于过车数据采集系统越来越完善,基于过车数据进行大数据分析受到了交管部门的极大关注。通过过车数据,分析车辆的出行特征并进行分类,能够了解当前城市交通的通行情况,以便于及时发现问题并做出预案。

但是,当前的技术中,对车辆的分类监控依赖实体标签,或者在限定场景中布设多种硬件设备,实施复杂。

发明内容

本申请实施例提供了一种车辆类型检测方法及装置,用以解决车辆分类依赖实体标签且适用场景受限的问题。

第一方面,本申请实施例提供了一种车辆类型检测方法,包括:

获取设定时长内的过车数据,所述过车数据用于表征车辆经过设定区域内的监测口的情况;

根据所述过车数据确定待检测车辆在所述设定时长内的多条出行路径,每条出行路径是根据所述待检测车辆所经过的至少两个监测口的过车数据生成的;

当所述多条出行路径中的相似路径的数量大于设定阈值时,确定所述待检测车辆为通勤车辆;

其中,第一出行路径与第二出行路径为所述多条出行路径中的任两条相似路径,第一出行路径与所述第二出行路径的始发点相同,所述第一出行路径与所述第二出行路径的终止点相同。

基于上述方案,在进行车辆类型检测时,基于过车数据确定待检测车辆在所述设定时长内的多条出行路径,根据多条出行路径中的相似路径的数量确定所述待检测车辆为通勤车辆。过车数据是通过路口路段的卡口设备和/或电警电子监控设备获取的,并非通过实体标签获得待检测车辆的过车数据,能够提高车辆检测的便捷性和实用性。

在一些实施例中,所述多条出行路径中监测口的数量小于数量阈值。

在一些实施例中,第一出行路径与所述第二出行路径除所述始发点和终止点外,还包括至少一个相同的监测口。示例性地,所述多条出行路径中监测口的数量大于数量阈值。基于上述方案,通过多个监测口来确定相似路径,使得确定相似路径的准确度提高。

在一些实施例中,所述设定时长包括N天,所述多条出行路径产生的时间均为工作日。

在一些实施例中,所述多条出行路径中任一条出行路径包括的相邻两个监测口的监测时间间隔小于时间间隔阈值。

基于上述方案,根据待检测车辆的过车数据确定该车辆在设定时长内的多条出行路径,通过设置时间间隔阈值,可以提高确定出行路径的准确性,进而提高车辆类型检测的准确性。

第二方面,本申请实施例提供的一种车辆类型检测方法,包括:

获取设定时长内的过车数据,所述过车数据用于表征车辆经过设定区域内的监测口的情况;

根据所述过车数据获得待检测车辆的多条出行路径,每条出行路径是根据所述待检测车辆所经过的至少两个监测口的过车数据生成的;

根据所述多条出行路径确定所述待检测车辆在设定区域产生设定行为模式的次数占所述出行路径的数量的比例,所述设定行为模式为在所述设定区域停留、在所述设定区域出现或者在所述设定区域经过;

当所述比例满足设定区域对应的车辆类型的判断条件时,确定所述待检测车辆的车辆类型为所述设定区域对应的车辆类型。

基于上述方案,通过过车数据获得待检测车辆的多条出行路径,根据多条出行路径确定所述待检测车辆在设定区域产生设定行为模式的次数占所述出行路径的数量的比例,确定待检测车辆的车辆类型。该方案可以对多种车辆类型进行检测分类,避免了使用场景受限的问题,且根据电子监控设备获取过车数据,提高了车辆检测的实用性。

在一些实施例中,所述车辆类型包括过境车、购物车、家长车、高频出行车以及外地车中的一项或者多项。

基于上述方案,可以通过所述方法对多种类型车辆进行检测分类,使用场景不受限,提高方案的实用性。

在一些实施例中,所述车辆类型为过境车,所述过境车对应的设定区域为行政区域,所述设定行为模式为在所述行政区域出现;或者,

所述车辆类型为购物车,所述购物车对应的设定区域为商场,所述设定行为模式为在所述商场停留;或者,

所述车辆类型为家长车,所述家长车对应的设定区域为学校,所述设定行为模式为在所述学校经过;或者,

所述车辆类型为高频出行车,所述高频出行车对应的设定区域为行政区域,所述设定行为模式为在所述行政区域内出现;或者,

所述车辆类型为外地车,所述外地车对应的设定区域为行政区域,所述设定行为模式为在所述行政区域内出现。

通过上述方案,在不同区域内,根据不同的车辆类型,对车辆进行不同的行为模式设置,适用于多种场景。

在一些实施例中,根据所述多条出行路径确定所述待检测车辆在设定区域产生设定行为模式的次数占所述出行路径的数量的比例,包括:

根据所述多条出行路径中产生时段位于车辆类型对应的统计时段的至少一条出行路径,确定所述待检测车辆在设定区域产生设定行为模式的次数占所述出行路径的数量的比例。

基于上述方案,通过待检测车辆在设定区域产生设定行为模式的次数占所述出行路径的数量的比例确定待检测车辆的类型,通过配置不同行为模式及次数占比,能够对车辆进行精确地类型检测,提高了检测的精确度。

第三方面,本申请实施例提供了一种车辆类型检测装置,包括:

获取模块,用于获取设定时长内的过车数据,所述过车数据用于表征车辆经过设定区域内的监测口的情况;

处理模块,用于根据所述获取模块获取的所述过车数据确定待检测车辆在所述设定时长内的多条出行路径,每条出行路径是根据所述待检测车辆所经过的至少两个监测口的过车数据生成的;在确定所述多条出行路径中的相似路径的数量大于设定阈值时,确定所述待检测车辆为通勤车辆;

其中,第一出行路径与第二出行路径为所述多条出行路径中的任两条相似路径,第一出行路径与所述第二出行路径的始发点相同,所述第一出行路径与所述第二出行路径的终止点相同。

在一些实施例中,第一出行路径与所述第二出行路径除所述始发点和终止点外,还包括至少一个相同的监测口。

在一些实施例中,所述设定时长包括N天,所述多条出行路径产生的时间均为工作日。

在一些实施例中,所述多条出行路径中任一条出行路径包括的相邻两个监测口的监测时间间隔小于时间间隔阈值。

在一些实施例中,处理模块,具体用于根据监测时间对过车数据进行筛选,在对过车数据进行设定区域的数据筛选后,根据统计时段,需要对过车数据再次筛选,然后对过车数据进行过车数据合并,生成待检测车辆的出行路径。

在一些实施例中,处理模块,具体用于统计每条出行路径的起点、重点的次数,确认高频起点、高频终点。处理模块对每条路径进行循环统计,确定参照路径,所述参照路径的起点为高频起点,重点为高频终点,且路径中的点位数量最多。

在一些实施例中,处理模块,用于多条出行路径与参考路径进行相似路径学习,当多条路径不能与参考路径进行相似路径学习时,与参考路径以外的路径进行相似路径学习,并将相似路径加入相似路径包。

在一些实施例中,处理模块,具体用于计算待检测车辆的出行率、相似路径包中相似路径数量及相似路径占比。其中,所述出行率为车辆出行的天数占设定时长的比例,相似路径为第一出行路径与第二出行路径除了相同的起点与终点外,至少还有一个共同的监测口;计算相似路径占比,所述相似路径占比为相似路径数量与总出行路径数量的比值。当相似路径占比大于设定阈值时,确定待检测车辆为通勤车辆。

第四方面,本申请实施例提供了另一种车辆类型检测装置,包括:

获取模块,用于获取设定时长内的过车数据,所述过车数据用于表征车辆经过设定区域内的监测口的情况;

处理模块,用于根据所述获取模块获取的过车数据确定待检测车辆的多条出行路径,每条出行路径是根据所述待检测车辆所经过的至少两个监测口的过车数据生成的;根据所述多条出行路径确定所述待检测车辆在设定区域产生设定行为模式的次数占所述出行路径的数量的比例,所述设定行为模式为在所述设定区域停留、在所述设定区域出现或者在所述设定区域经过;当所述比例满足设定区域对应的车辆类型的判断条件时,确定所述待检测车辆的车辆类型为所述设定区域对应的车辆类型。

在一些实施例中,所述车辆类型包括过境车、购物车、家长车、高频出行车以及外地车中的一项或者多项。

在一些实施例中,所述车辆类型为过境车,所述过境车对应的设定区域为行政区域,所述设定行为模式为在所述行政区域经过;或者,

所述车辆类型为购物车,所述购物车对应的设定区域为商场,所述设定行为模式为在所述商城停留;或者,

所述车辆类型为家长车,所述家长车对应的设定区域为学校,所述设定行为模式为在所述学校出现;或者,

所述车辆类型为高频出行车,所述高频出行车对应的设定区域为行政区域,所述设定行为模式为在所述行政区域内出现;或者,

所述车辆类型为外地车,所述外地车对应的设定区域为行政区域,所述设定行为模式为在所述行政区域内出现。

在一些实施例中,处理模块,在根据所述多条出行路径确定所述待检测车辆在设定区域产生设定行为模式的次数占所述出行路径的数量的比例,具体用于:

根据所述多条出行路径中产生时段位于车辆类型对应的统计时段的至少一条出行路径,确定所述待检测车辆在设定区域产生设定行为模式的次数占所述出行路径的数量的比例。

在一些实施例中,处理模块,还用于根据监测时间对过车数据进行筛选,在对过车数据进行设定区域的数据筛选后,根据统计时段,需要对过车数据再次筛选,然后对过车数据进行过车数据合并,生成待检测车辆的出行路径。

第五方面,被申请实施例提供了一种车辆类型检测装置,包括:存储器以及处理器;

存储器,用于存储程序指令;

处理器,用于调用所述存储器中存储的程序指令,按照获得的程序执行第一方面或者第二方面所述的车辆类型检测方法。

第六方面,本申请实施例提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机指令,当所述计算机指令在计算机上运行时,使得计算机执行第一方面或者第二方面所述的车辆类型检测方法。

另外,第三方面至第六方面中任一种实现方式所带来的技术效果可参见第一、二方面不同实现方式所带来的技术效果,此处不再赘述。

图1为本申请实施例提供的一种车辆类型检测方法的系统架构示意图;

图2为本申请实施例提供的一种车辆类型检测方法的流程图;

图3为本申请实施例提供的一种电子监控设备在路口路段的布置位置示意图;

图4为本申请实施例提供的一种通勤车的车辆类型检测方法的流程图;

图5为本申请实施例提供的一种基于出行路径确定通勤车辆的流程图;

图6为本申请实施例提供的另一种车辆类型检测方法的流程图;

图7为本申请实施例提供的一种车辆类型检测方法的装置示意图;

图8为本申请实施例提供的另一种车辆类型检测方法的装置示意图。

具体实施例

下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。

图1示例性的示出了本申请实施例所适用的一种系统架构,该系统架构可以包括一个或者多个服务器100,该服务器100可以包括处理器110、通信接口120和存储器130。

其中,通信接口120用于路口路段的卡口和电警等电子监控设备进行通信,收发路口路段的卡口和电警等电子监控设备传输的信息,实现通信。

处理器110是服务器100的控制中心,利用各种接口和路线连接整个服务器100的各个部分,通过运行或执行存储在存储器130内的软件程序/或模块,以及调用存储在存储器130内的数据,执行服务器100的各种功能和处理数据。可选地,处理器110可以包括一个或多个处理单元。

存储器130可用于存储软件程序以及模块,处理器110通过运行存储在存储器130的软件程序以及模块,从而执行各种功能应用以及数据处理。存储器130可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序等;存储数据区可存储根据业务处理所创建的数据等。此外,存储器130可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

需要说明的是,上述图1所示的结构仅是一种示例,本发明实施例对此不做限定。

本实施例提供了一种车辆类型检测方法,图2示例性的示出了车辆类型检测方法的流程,该流程可由一种车辆类型检测方法的装置执行,该装置可以位于如图1所示的服务器100内,比如可以是处理器,也可以是该服务器100,后续描述时以服务器100为例进行说明,为了便于描述,后续对服务器100的描述不再示例数字标示。

201,获取设定时长内待检测车辆的过车数据。

其中,过车数据用于表征车辆经过设定区域内的监测口的情况。监测口也可以称为监测点位,或者简称为点位。示例性地,过车数据可以包括待检测车辆的监测口、监测时间或者车牌号码等中的一项或者。

在本申请实施例中,将路口路段的卡口设备或者电警等电子监控设备作为获取过车数据的监测口,过车数据是通过路口路段的卡口和电警等电子监控设备采集的。电警或者卡口设备可以包括感应检测器和电警检测器,其中感应检测器一般布设于距离停止线30m的位置,该感应检测器的检测数据一般包括入口道的车流量(过车数据)、占有率,数据输出间隔为一个信号周期。电警检测器一般布设在每个交叉口各方向的入口道,电警应为集成了卡口功能的多功能电警,可以实现逢车必拍功能。多功能电警一般布设于距离停车线18-23m的位置,其输出数据为通过停车线的各车辆的车牌号与通过时间,数据输出间隔为一个信号周期。一些实施例中,参见图3所示,示例性描述电子监控设备在路口路段的布置位置。

电警或者卡口设备监测到的过车数据包括若干车辆的过车数据,本申请实施例可以针对每个车辆进行分类。本申请实施例对车辆分类进行描述时,仅以待检测车辆为例进行说明。

一些实施例中,设定时长可以是一周、半个月、一个月、三个月、N周等等。

202,根据过车数据生成待检测车辆在所述设定时长内的多条出行路径。其中,每条出行路径是根据所述待检测车辆所经过的至少两个监测口的过车数据生成的。

一些实施例中,服务器在确定待检测车辆的出行路径之前,可以基于所针对的检测车辆的类型对待检测车辆的过车数据过滤清洗。比如在确定待检测车辆是否为通勤车时,可以过滤掉非早晚出行时间段的过车数据,以及非工作日的过车数据等等。

在一些实施例中,服务器在确定待检测车辆的出行路径之前,还可以对过车数据进行数据筛选,删除异常数据,或者对过车数据进行补位。

示例性地,在对过车数据进行数据筛选时,可以根据待检测车辆号码对每辆待检测车辆进行过车数据的筛选,生成每辆待检测车辆对应的出行数据。

示例性地,异常数据可以包括如下一种或者多种:

(1)设定时长内不在所述待检测车辆的出行路径中所有可能点位内的过车数据,比如在过车数据中出现了不在两个相邻点位之间的过车数据,该过车数据为异常数据。

(2)对应点位的过车数据的时间不在与其相邻的两个点位过车数据的时间间隔内的过车数据。

(3)重复出现在同一个点位的过车数据。

一些实施例中,当待检测车辆在某个点位拥有多个过车数据时,可以根据与该点位相邻的两个点位的过车时间删除异常数据。该异常数据出现的原因可能是路口路段的卡口设备及电警等电子监控设备错误识别车牌号码等等。

一些实施例中,当待检测车辆的出行数据中两个相邻的点位之间还存在另外一个点位,而待检测车辆在该点位没有过车数据时,还可以进行过车数据补位,补充该点位的过车数据。

一些实施例中,服务器可以根据过车数据进行待检测车辆的出行分析,可以包括每次待检测车辆出行起始时间、起始地点、目的地时间、目的地地址、经过的出行经过的监测点位。比如,服务器可以收集待检测车辆8周的过车数据,分析每周中每天的出行路径。经过分析获得的出行路径可以采用链表数据形式记录下来以获得出行链路数据。例如,出行链路数据可以包括{号牌号码,号牌类型,开始时间,结束时间,路径轨迹}。示例性地,确定的出行路径中每条出行路径中相邻两个监测点位的检测时间时间间隔小于时间间隔阈值,比如30分钟、或者60分钟等等。基于此,在确定出行路径时,服务器可以在确定出行链路之后,根据出行链路的开始时间、结束时间以及监控口的邻接情况确定待检测车辆的每两条出行链路之间是否可以合并。比如一条出行链路的开始时间与另一条出行链路的结束时间的时间差小于60分钟,并且一条出现链路的结束位置是另一条出行链路的开始位置,可以将两条出行链路合并为一条出行链路。

203,根据出行路径,分析待检测车辆在设定区域内的出行特征,根据出行特征确定待检测车辆的车辆类型。

车辆类型,比如可以包括通勤车、过境车、购物车、家长车、高频出行车或者外地车等等。

通勤车,为工作日早晚高峰时段内,在经常固定路径上行驶的车辆。示例性地,本申请可以根据设定时长内,比如连续两个月的出行相似路径占比来确定车辆是否为通勤车。

过境车,为设定时长内经常经过设定区域的车辆。比如,经过某个设定区域的次数较多或者经过某个设定区域的路线较多。

购物车,一般为设定时长内在非工作日情况下在商圈区域停留的时间较长的车辆。

家长车,设定时长内在工作日的上学和放学时间段经常出现在学校区域的车辆。

高频出行车,或者称为非低频车,在设定区域出行的次数较多。

外地车,经常在设定区域出现的外地号牌车辆。

进一步地,服务器可以根据车辆的出行特征,判断待检测车辆是否满足车辆类型的判断条件,确定待检测车辆的车辆类型。本实施例通过收集待检测车辆的过车数据,获得待检测车辆的出行路径,对待检测车辆的出行路径进行出行特征分析,判断待检测车辆的车辆类型。本申请采用的是通过已有的电子监控设备获得车辆的出行数据,不需要设置实体标签对车辆进行分类,且应用场景不受限制,可应用于多种场合。

基于上述描述,为了便于理解本申请的实施例,如图4所示,提供了一种通勤车的车辆类型检测方法的流程:

401-402,参见201-202,此处不再赘述。

403,当所述多条出行路径中的相似路径的占比大于设定阈值时,确定所述待检测车辆为通勤车辆。当两条出行路径,至少存在始发点相同、终止点(或者简称为终点)相同时,可以认为两条出行路径为相似路径。比如第一出行路径与第二出行路径为多条出行路径中的任两条相似路径,则第一出行路径与第二出行路径的始发点相同,第一出行路径与第二出行路径的终止点相同。所述相似路径占比可以理解为相似路径数量与总出行路径数量的比值。

一些实施例中,在确定多条出行路径中的相似路径时,可以结合出行路径中包括的监测点位数量来分成两组出行路径。针对两组出行路径分别确定是否满足通勤车辆的条件。第一组为,出行路径中包括的监测点数量大于数量阈值的路径。第二组为出行路径中包括的监测点数量小于或者等于数量阈值的路径。

一种可能的实施方式中,在确定通勤车辆类型时,根据出行路径中包括的监测点位数量来分成两组出行路径,对两组出行路径分别确定是否满足通勤车辆的条件,具体可以通过如下方式,例如,参见图5所示。

501,获取待检测车辆的多条出行路径中属于第一组的出行路径,确定待检测车辆的出行率。

在确定出行率大于出行率阈值1时,继续执行502,否则,执行506。

其中,出行率是指待检测车辆的出行天数和设定时间内工作日天数的比值。当所述比值大于设定阈值时,说明待检测车辆在设定时长内出行的天数满足通勤车的条件。在计算待检测车辆的出行天数时,如果某一天检测到该待检测车辆的出行路径,则确定该待检测车辆在该天出行。

比如,出行率阈值1为30%,则在确定待检测车辆在设定时长内的出行率大于30%,则继续执行502。

502,确定参照路径。

示例性地,服务器统计各个出行路径中相同起点和相同终点的数量,以确定高频起点、高频终点。高频起点为统计待检测车辆的每条出行路径中起点次数最多的起点,高频终点为统计待检测车辆的每条出行路径中终点次数最多的终点。服务器根据确定的高频起点和高频终点进一步确定参照路径。其中,参照路径可以为起点为高频起点、终点为高频终点,且路径中点位数量最多的路径。

503,与参照路径进行相似路径学习,进行相似路径学习的条件为:两条路径的起始M1个点位中,至少有N1个点位相同,且结束的M2个点位中至少有N2个点位相同,其中,M1、N1、M2和N2均为正整数,且M1大于N1,M2大于N2。比如在两条路径的起始3个点位中,至少有1个点位相同,且结束3个点位中至少有1个点位相同,则该两条路径为相似路径。

一些实施例中,当某个出行路径与参照路径相似时,可以将该相似路径放入该参照路径的相似路径包。

504,对于不满足503的出行路径,与参照路径以外的出行路径进行相似路径学习,进行相似路径学习的方法与503步骤类似,此处不再赘述。

505,统计相似路径数量及占比,根据相似路径的最大数量确定待检测车辆是否为通勤车。

示例性地,服务器可以统计每个相似路径包中出行路径的数量,若某个相似路径包的出行路径的数量占出行路径总数量的比例大于设定阈值时,确定该待检测车辆为通勤车辆。

506,获取待检测车辆的多条出行路径中属于第二组的出行路径,确定待检测车辆的出行率。

在确定出行率大于出行率阈值1时,继续执行506,否则,该待检测车辆不为通勤车。

507,从属于第二组的出行路径中确定相似路径占比,根据相似路径占比,确定待检测车辆是否为通勤车辆。确定相似路径时可以采用与502-504类似的方式,此处不再赘述。

一些实施例中,数量阈值可以是3。则在执行507时,可以直接统计具有相同起点和相同终点的出行路径。当有相同起点和相同重点的出行路径的最大数量占比大于设定阈值时,则确定该待检测车辆为通勤车辆。

如下结合实施例对除通勤车以外的其他类型的车辆的检测方式进行描述。参见图6,为本申请实施例提供的另一种车辆类型检测方法流程图,具体包括:

601,服务器收集设定时长内设定区域的待检测车辆的过车数据。

关于过车数据的描述,参见图3对应的示例中的描述,此处不再赘述。

一些实施例中,设定时长可以为N天,设定区域可以为行政区、商场、或者学校等区域。

在获取过车数据后,服务器可以先对过车数据进行数据筛选,删除异常数据,或者对过车数据进行补位。具体可以参见202中相关描述,此处不再赘述。

602,根据过车数据以及本次检测的车辆类型生成待检测车辆的出行路径。

一些实施例中,服务器可以根据本次检测的车辆类型,从过车数据中筛选中符合该车辆类型的出行时间条件的过车数据。比如,针对家长车,筛选出的过车数据的时间位于早晚高峰的时间段中。

603,根据待检测车辆的行为模式,判断待检测车辆的车辆类型。

根据待检测车辆的出行路径确定所述待检测车辆在设定区域产生设定行为模式的次数和/或占比,所述占比为设定行为模式的次数与所述出行路径比值,所述设定行为模式包括如下至少一种:在所述设定区域经过、在所述设定区域停留或者在所述设定区域出现。

在一种可能的实现方式中,车辆类型为过境车,过境车的设定区域为行政区,该类型车辆的行为模式可以是在行政区域经过。作为一种举例,以过境车统计的设定时长为30天为例,即统计30天内的过车数据,参见表1所示。然后可以根据车牌号码对过车数据进行数据筛选,删除异常数据,或者进行过车数据补位,形成对应车辆的出行路径;并对符合合并要求的至少两条出行路径合并为一条出行路径。确定该车辆的多条出行路径中经过行政区的出行路径的数量占比,占比达到阈值3时,确定待检测车辆为过境车。例如,阈值3可以为50%。具体可参见表1。

表1

在另一种可能的实现方式中,车辆类型为购物车,购物车的设定区域为商场,该类型车辆的行为模式可以是在商场区域停留。作为一种举例,参见表1,以购物车统计的设定时长为12周为例,即统计12周内的过车数据。然后可以根据车牌号码对过车数据进行数据筛选,删除异常数据,或者进行过车数据补位,形成对应车辆的出行路径。针对购物车在对过车数据进行数据筛选时,可以选择非工作日的过车数据,并根据筛选出的过车数据确定出行路径。一些实施例中,还可以先确定出行路径,然后从确定的出行路径中筛选出非工作日的出行路径,用于进一步确定待检测车辆是否为购物车。一些实施例中,还可以对符合合并要求的至少两条出行路径合并为一条出行路径。进一步地,可以确定该车辆的多条出行路径包括的终点或者起点是商场区域,并且确定在商场区域停留的周占比。其中,周占比为该车辆在商场区域停留的周数与统计时长内总周数的比值。服务器可以在确定该车辆在商场区域停留的周占比达到阈值4时,确定该车辆为购物车。例如,阈值4可以为60%。

在又一种可能的实现方式中,车辆类型为家长车,家长车的设定区域为学校,该类型车辆的行为模式可以是在学校区域出现。作为一种举例,参见表1,以家长车统计的设定时长为30天为例,即统计30天内的过车数据。然后可以根据车牌号码对过车数据进行数据筛选,删除异常数据,或者进行过车数据补位,形成对应车辆的出行路径。针对家长车在对过车数据进行数据筛选时,可以选择工作日的过车数据,并根据筛选出的过车数据确定出行路径。一些实施例中,还可以先确定出行路径,然后从确定的出行路径中筛选出工作日(或者工作日的早晚放学时间段)的出行路径,用于进一步确定待检测车辆是否为家长车。进一步地,可以对符合合并要求的至少两条出行路径合并为一条出行路径。进一步地,可以确定该车辆的多条出行路径中在学校区域出现的次数,次数达到阈值5时,确定该车辆为家长车。例如,阈值5可以为20。

在另一种可能的实现方式中,车辆类型为高频出行车,高频出行车的设定区域为行政区,该类型车辆的行为模式可以是在行政区域出现。作为一种举例,参见表1,以高频出行车统计的设定时长为60天为例,即统计60天内的过车数据。然后可以根据车牌号码对过车数据进行数据筛选,删除异常数据,或者进行过车数据补位,形成对应车辆的出行路径。可选的,可以对符合合并要求的至少两条出行路径合并为一条出行路径。确定该车辆多条出行路径中经过行政区的出行路径的数量,即确定该车辆在行政区出现的次数。如果确定该车辆在行政区出现的次数达到阈值6时,确定待检测车辆为高频出行车。例如,阈值6可以为50。

在另一种可能的实现方式中,车辆类型为本地使用的外地车(简称为外地车),外地车的设定区域为行政区,该类型车辆的行为模式可以是在行政区域出现。作为一种举例,以外地车统计的设定时长为30天为例,即统计30天内的过车数据。然后可以根据车牌号码对过车数据进行数据筛选,删除异常数据,或者进行过车数据补位,形成对应车辆的出行路径。该车牌号码为外地车牌号。可选地,对符合合并要求的至少两条出行路径合并为一条出行路径。根据该车辆的多条出行路径确定该车辆在行政区出现的次数,如果次数达到阈值7时,则确定该车辆为本地使用的外地车。例如,阈值7可以为15。或者,确定该车辆的多条出行路径中在行政区出现的天数和设定时长包括的天数的比值,比值达到阈值8时,确定待检测车辆为外地车。例如,设定阈值8可以为55%。

在一些实施例中,在针对待检测车辆类型后,可以对保存该待检测车辆与车辆类型标签的关联关系。例如,可以采用持久化表名的格式保存关联关系。关联关系可以是车辆的车牌号码与类型标签的关联关系。需要说明的是,同一辆车可以仅有一个类型标签,还可以具有多个类型标签。比如通勤车还可以是家长车。

本申请实施例中通过对通勤车辆的检测,有利于识别通勤干道,进而可以针对通勤干道进行重点管理,减少出现早晚高峰拥堵的情况。通过对家长车的检测,有助于在特殊情况下向家长车发送通知,或者在某学校区域发生家长车聚集时,可以及时提供预警,以便于学校区域的交通管理。节假日和非工作日的商场区域车流量大时,通过对购物车辆的检测,可以在商场区域内购物车占比达到阈值时提前给关联该商场的购物车发送通知消息或建议,可以及时疏散车流量,达到减少拥堵的目的。通过对过境车辆的检测,可以在过境车识别的区域内发生特殊情况时,对该区域的过境车发出通知消息,避免拥堵加剧的情况发生。

基于相同的技术构思,图7示例性的示出了本申请实施例提供的一种车辆类型检测方法的装置600的结构,该装置可以执行图2、图3或者图4所示的车辆类型检测方法的流程,该装置可以位于图1所示的服务器100内,也可以是该服务器100。

如图7所示,该装置具体包括:

获取模块701,用于获取设定时长的待检测车辆的过车数据,所述过车数据包括待检测车辆的监测口、监测时间及车牌号码。

处理模块702,用于根据所述获取模块701获取的所述过车数据确定待检测车辆在所述设定时长内的多条出行路径,每条出行路径是根据所述待检测车辆所经过的至少两个监测口的过车数据生成的;在确定所述多条出行路径中的相似路径的数量大于设定阈值时,确定所述待检测车辆为通勤车辆。

其中,第一出行路径与第二出行路径为所述多条出行路径中的任两条相似路径,第一出行路径与所述第二出行路径的始发点相同,所述第一出行路径与所述第二出行路径的终止点相同。

在一些实施例中,第一出行路径与所述第二出行路径除所述始发点和终止点外,还包括至少一个相同的监测口。

在一些实施例中,所述设定时长包括N天,所述多条出行路径产生的时间均为工作日。

在一些实施例中,所述多条出行路径中任一条出行路径包括的相邻两个监测口的监测时间间隔小于时间间隔阈值。

基于相同的技术构思,图8示例性的示出了本申请实施例提供的另一种车辆类型检测方法的装置800的结构,该装置可以执行图6所示的车辆类型检测方法的流程,该装置可以位于图1所示的服务器100内,也可以是该服务器100。

如图8所示,该装置具体包括:

获取模块801,用于获取设定时长内的过车数据,所述过车数据用于表征车辆经过设定区域内的监测口的情况。

处理模块802,用于根据所述获取模块获取的过车数据确定待检测车辆的多条出行路径,每条出行路径是根据所述待检测车辆所经过的至少两个监测口的过车数据生成的;根据所述多条出行路径确定所述待检测车辆在设定区域产生设定行为模式的次数占所述出行路径的数量的比例,所述设定行为模式为在所述设定区域停留、在所述设定区域出现或者在所述设定区域经过;当所述比例满足设定区域对应的车辆类型的判断条件时,确定所述待检测车辆的车辆类型为所述设定区域对应的车辆类型。

在一些实施例中,所述车辆类型包括过境车、购物车、家长车、高频出行车以及外地车中的一项或者多项。

在一些实施例中,所述车辆类型为过境车,所述过境车对应的设定区域为行政区域,所述设定行为模式为在所述行政区域经过;或者,

所述车辆类型为购物车,所述购物车对应的设定区域为商场,所述设定行为模式为在所述商城停留;或者,

所述车辆类型为家长车,所述家长车对应的设定区域为学校,所述设定行为模式为在所述学校出现;或者,

所述车辆类型为高频出行车,所述高频出行车对应的设定区域为行政区域,所述设定行为模式为在所述行政区域内出现;

所述车辆类型为外地车,所述外地车对应的设定区域为行政区域,所述设定行为模式为在所述行政区域内出现。

在一些实施例中,处理模块802,在根据所述多条出行路径确定所述待检测车辆在设定区域产生设定行为模式的次数占所述出行路径的数量的比例,具体用于:

根据所述多条出行路径中产生时段位于车辆类型对应的统计时段的至少一条出行路径,确定所述待检测车辆在设定区域产生设定行为模式的次数占所述出行路径的数量的比例。

基于相同的技术构思,本申请实施例还提供了一种车辆类型检测装置,包括:

存储器,用于存储程序指令;

处理器,用于调用存储器中存储的程序指令,按照获得的程序执行上述车辆类型检测方法。

基于相同的技术构思,本申请实施例还提供了一种计算机可读非易失性存储介质,包括计算机可读指令,当计算机读取并执行计算机可读指令时,使得计算机执行上述基于过车数据的车辆类型检测方法。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

相关技术
  • 一种轨道交通车辆接地检测装置及检测方法
  • 一种基于加速度传感器车辆检测装置及方法
  • 一种车辆自身姿态检测方法和装置
  • 一种驾驶疲劳检测方法、装置及车辆
  • 一种自动驾驶车辆的控制命令检测方法和装置
  • 一种车辆行驶轨迹类型检测方法及装置
  • 一种车辆行驶轨迹类型检测方法及装置
技术分类

06120115723451