WO2022107193A1 - 渋滞判定方法、渋滞判定装置、及び渋滞判定プログラム - Google Patents

渋滞判定方法、渋滞判定装置、及び渋滞判定プログラム Download PDF

Info

Publication number
WO2022107193A1
WO2022107193A1 PCT/JP2020/042760 JP2020042760W WO2022107193A1 WO 2022107193 A1 WO2022107193 A1 WO 2022107193A1 JP 2020042760 W JP2020042760 W JP 2020042760W WO 2022107193 A1 WO2022107193 A1 WO 2022107193A1
Authority
WO
WIPO (PCT)
Prior art keywords
congestion
mesh
sudden
traffic jam
traffic
Prior art date
Application number
PCT/JP2020/042760
Other languages
English (en)
French (fr)
Inventor
亜紀 林
夕貴 横畑
崇洋 秦
皓平 森
和昭 尾花
Original Assignee
日本電信電話株式会社
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to JP2022563264A priority Critical patent/JP7485080B2/ja
Priority to US18/036,865 priority patent/US20230410644A1/en
Priority to PCT/JP2020/042760 priority patent/WO2022107193A1/ja
Publication of WO2022107193A1 publication Critical patent/WO2022107193A1/ja

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/0125—Traffic data processing
    • G08G1/0133—Traffic data processing for classifying traffic situation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • 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
    • 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
    • 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/0116—Measuring and analyzing of parameters relative to traffic conditions based on the source of data from roadside infrastructure, e.g. beacons
    • 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/0129—Traffic data processing for creating historical data or processing based on historical data
    • 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/0137—Measuring and analyzing of parameters relative to traffic conditions for specific applications
    • G08G1/0141—Measuring and analyzing of parameters relative to traffic conditions for specific applications for traffic information dissemination

Definitions

  • the disclosed technology relates to a traffic jam judgment method, a traffic jam judgment device, and a traffic jam judgment program.
  • Non-Patent Document 1 there is a technique for estimating the behavior of a vehicle using an image taken by a fixed camera (see, for example, Non-Patent Document 1).
  • the appropriate user here is, for example, a user whose living area is a chronically congested area, and the appropriate notification is a notification of the sudden occurrence of traffic congestion. That is, it is not necessary to notify the user whose area where the chronic congestion occurs is within the living area, and it is preferable to notify only the occurrence of the sudden congestion.
  • the disclosed technique has been made in view of the above points, and an object thereof is to provide a traffic jam determination method, a traffic jam determination device, and a traffic jam determination program capable of determining whether or not a traffic jam has occurred suddenly. And.
  • the congestion determination method is a congestion determination method in a congestion determination device including an acquisition unit and a determination unit, and the acquisition unit determines a congestion determination target area. Whether the occurrence of traffic congestion is sudden based on the total number of vehicles acquired for each mesh and each unit time that are virtually divided, and based on the acquired total number of vehicles for each mesh and unit time. Whether or not it is determined for each mesh.
  • the traffic jam determination device is an acquisition unit that acquires the total number of automobiles for each mesh in which the traffic jam determination target area is virtually divided and for each unit time. And, based on the acquired number of units for each mesh and each unit time, a determination unit for determining whether or not the occurrence of traffic congestion is sudden is provided for each mesh.
  • the traffic jam determination program acquires and acquires the total number of automobiles for each mesh and each unit time in which the area to be determined for congestion is virtually divided. Based on the total number of vehicles for each mesh and each unit time, the computer is made to determine whether or not the occurrence of traffic congestion is sudden for each mesh.
  • the weighted habit level calculated by SRBM for each traffic jam detected once, and the traffic jam habit level calculated by RBM after detecting all 15 traffic jams It is a figure which shows the result of having calculated the correlation coefficient of for all meshes. It is a figure which shows the change of the weight when the weighted congestion habit degree is calculated.
  • Some of the traffic jams that occur on the roadway occur only in a specific lane due to reasons such as the entrance of the facility or waiting for a traffic light.
  • the head position cannot be seen from the position at the end of the traffic jam, and it may not be known whether the vehicle should line up in the traffic jam or whether it is okay to overtake from another lane.
  • the time required to reach the destination increases and unnecessary congestion occurs.
  • the calculation cost when estimating the position where the traffic jam occurs is high.
  • the communication cost for uploading captured image data from a general vehicle to a server is also high.
  • traffic congestion by lane There are two types of traffic congestion by lane: traffic congestion by lane that occurs periodically and traffic congestion by lane that occurs suddenly. It is considered that the periodic congestion has a time dependence such as repeated occurrence on a specific day of the week or a time zone. Congestion that often occurs on a specific day but is not necessarily biased in the time zone, congestion that often occurs in a specific time zone but is not biased in the day and occurs every day, and always occurs without dependence on the day or time zone Which time axis the traffic jam that occurs, such as the traffic jam that occurs, depends strongly on the place where the traffic jam occurs.
  • congestion in the right and left turn lanes of arterial roads tends to occur during the morning and evening rush hours, waiting for warehousing in commercial facilities tends to occur on weekends and holidays, and congestion in the confluence lanes of expressways and general roads always occurs due to signal cycles, etc.
  • sudden lane-specific traffic jams include accidents, injured people, and other obstacles that block the lane, events such as bargains at commercial facilities and new store openings, and special drive-through demand due to the Korona-ka. Some are due to changes in habits.
  • Patent Documents 1 and 2 are used as a method for quickly and centrally indexing whether an event that has occurred is sudden or chronic by considering a plurality of time axes such as a day of the week and a time zone at the same time. There is a technology of disclosure in.
  • Patent Document 1 Japanese Patent Application Laid-Open No. 2015-153088
  • Patent Document 2 Japanese Patent Application Laid-Open No. 2016-91040
  • the user's location information is used to comprehensively consider a plurality of time axes as to how sudden or chronic a visit to a certain visiting place is. Calculate the indexed "habit level”.
  • Patent Document 1 When the technique disclosed in Patent Document 1 is applied to deal with the problems (1) and (2) above in traffic jam detection, there are the following problems, respectively.
  • the index for the event itself that the visit was made is calculated as the habit level, not the index accompanying the visit. Specifically, the visit probability for each place is calculated only for a specific user, and the visit probability of the visited place for which the habit level is to be calculated is suddenly higher than the visit probability of other places. Is calculated as the degree of habit.
  • FIG. 1 shows an example of the visit probability for each place calculated by the technique disclosed in Patent Document 1. Further, the formula for calculating the habit level R (l, u, t) disclosed in Patent Document 1 is expressed by the following formula.
  • the place l refers to a mesh in which a traffic jam determination target area is virtually divided, and is therefore referred to as a mesh l below.
  • the mesh can be, for example, a square area having a length and width of 100 m, but the size and shape of the mesh are not limited to this.
  • ⁇ (u, tk ) is the weight of the time zone tk for the user u.
  • ⁇ (u, tk) is the average of the visit probabilities of the user u on the time axis k and the time zone tk .
  • ⁇ (u, tk) is the standard deviation of the visit probability for all meshes of the user u on the time axis k and the time zone tk .
  • the habit level is calculated as an index showing how sudden the "visit probability" for the visited place is compared to other places, but in the traffic jam detection, the previous "visit probability" of the same mesh is calculated. It is necessary to calculate an index showing how much the total number of units on the time axis for which the index is to be calculated suddenly increases compared to the "total number of units”. Therefore, the technique disclosed in Patent Document 1 cannot be applied as it is.
  • the total habit level is calculated by weighting the habit level calculated on each time axis with an appropriate specific weight.
  • This weight ⁇ (u, tk ) is calculated by the following equation considering how many visits the user u has recorded in the same time zone including other places.
  • N (u, tk ) is the total number of visits to all places by the user u in the time zone tk.
  • the above equation (2) cannot be used as it is because it is desired to calculate an index showing how suddenly the total number of units is suddenly increased regardless of the user u.
  • the index indicating the degree of suddenness of the total number of vehicles in the traffic congestion detection is referred to as a total sudden index or SIMM (Suddenness Index Calculation Method).
  • SIMM Suddenness Index Calculation Method
  • the habit level on a plurality of time axes is calculated based on the number of occurrences and the probability of occurrence of the event so far. Also for this, since the probability of the event occurrence itself is calculated for each user, not the habit based on the size of the number such as "total number", the degree of suddenness of the aggregated value such as the aggregated sudden index is calculated. It cannot be used for the purpose.
  • a total sudden index is calculated for each mesh based on the total number of units totaled for each mesh. This makes it possible to simplify the subsequent processing of acquiring captured image data taken by an automobile existing in an area where congestion is occurring and detecting congestion by analyzing the captured image data.
  • the log data acquired for the traffic jam detection is calculated.
  • the habit level is calculated in consideration of past GPS log data such as taxis and past traffic congestion history by road and section although there is no data for each lane.
  • the occurrence of chronic traffic congestion is not notified to users whose living area is the area where the traffic congestion is occurring, and is notified only to users whose living area is outside the living area. do. In this way, the notification target of the occurrence of the congestion may be switched depending on whether the occurrence of the congestion is sudden or chronic.
  • FIG. 2 is a block diagram showing an example of the hardware configuration of the congestion determination device 10 according to the present embodiment.
  • the congestion determination device 10 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, a storage 14, an input unit 15, a display unit 16, and a communication. It has an interface (I / F) 17.
  • the configurations are connected to each other via a bus 18 so as to be communicable with each other.
  • the CPU 11 is a central arithmetic processing unit that executes various programs and controls each part. That is, the CPU 11 reads the program from the ROM 12 or the storage 14, and executes the program using the RAM 13 as a work area. The CPU 11 controls each of the above configurations and performs various arithmetic processes according to the program stored in the ROM 12 or the storage 14. In the present embodiment, the ROM 12 or the storage 14 stores a traffic jam determination program for determining whether or not the traffic jam is sudden.
  • the ROM 12 stores various programs and various data.
  • the RAM 13 temporarily stores a program or data as a work area.
  • the storage 14 is composed of an HDD (Hard Disk Drive) or an SSD (Solid State Drive), and stores various programs including an operating system and various data.
  • the input unit 15 includes a pointing device such as a mouse and a keyboard, and is used to perform various inputs to the own device.
  • the display unit 16 is, for example, a liquid crystal display and displays various information.
  • the display unit 16 may adopt a touch panel method and function as an input unit 15.
  • the communication interface 17 is an interface for the own device to communicate with another external device.
  • a wired communication standard such as Ethernet (registered trademark) or FDDI (Fiber Distributed Data Interface)
  • a wireless communication standard such as 4G, 5G, or Wi-Fi (registered trademark) is used. ..
  • a general-purpose computer device such as a server computer or a personal computer (PC) is applied to the congestion determination device 10 according to the present embodiment.
  • FIG. 3 is a block diagram showing an example of the functional configuration of the congestion determination device 10 according to the present embodiment.
  • the traffic jam determination device 10 includes an acquisition unit 21, a determination unit 22, and a notification unit 23 as functional configurations.
  • Each functional configuration is realized by the CPU 11 reading the congestion determination program stored in the ROM 12 or the storage 14, expanding it into the RAM 13, and executing the program.
  • the acquisition unit 21 acquires the total number of automobiles for each mesh and each unit time in which the area to be determined for congestion is virtually divided. The total number is acquired from the log database 31 provided in the server 30.
  • the log database 31 is a database showing the correspondence between the mesh ID, which is an identification code representing the mesh, the date and time, the day of the week, and the total number of automobiles aggregated in the mesh.
  • the server 30 collects own vehicle position information (latitude / longitude) transmitted from a GPS device such as a connected car traveling in a congestion determination target area and a vehicle equipped with a connection function to the Internet, and sequentially updates the log database 31. do.
  • the traffic jam determination device 10 may have the function of the server 30. Further, the server 30 may acquire the satellite image and analyze the image to aggregate the number of automobiles for each mesh and sequentially update the log database 31.
  • the server 30 converts the latitude and longitude represented by the vehicle position information received from the connected car into a mesh ID, and totals the total number of vehicles for each mesh ID and each unit time. Then, the mesh ID, the total number of units, the date and time, and the information of the day of the week are registered in the log database 31. The server 30 sequentially updates the log database 31.
  • the unit time can be set to, for example, 10 seconds, but is not limited to this.
  • the date and time is expressed as, for example, "YYYY / mm / dd HH: MM: SS".
  • YYYY represents a year
  • "mm” represents a month
  • "dd” represents a day
  • "HH” represents an hour
  • "MM” represents a minute
  • "SS” represents a second. ..
  • the day of the week is represented by, for example, "0" to "6" from Monday to Sunday.
  • the size and shape of the mesh can be, for example, a square of 100 m ⁇ 100 m, but the size and shape are not limited to this.
  • the total number of vehicles may be totaled based on the number of vehicles detected by the beacon installed on the road, instead of totaling based on the vehicle position information collected from the connected car.
  • the determination unit 22 determines for each mesh whether or not the occurrence of traffic congestion is sudden, based on the acquired number of units for each mesh and each unit time. Specifically, the determination unit 22 calculates a total sudden index based on the total number of units for each mesh and unit time, and determines whether or not the occurrence of traffic congestion is sudden based on the calculated total sudden index.
  • the notification unit 23 notifies the user of the occurrence of traffic congestion.
  • the aggregate sudden index will be explained below.
  • a total sudden index based on the total number of vehicles is defined instead of the visit probability.
  • the aggregated sudden index R (l, t) is defined by the following equation.
  • C (l, t) represents the total number of meshes l for which the total sudden index R (l, t) is to be calculated at the date and time t.
  • FIG. 4 shows an example of the total number of units C (l, t) calculated for each location.
  • ⁇ (tk, l) represents the standard deviation of the total number of units on the time axis k including the date and time t.
  • ⁇ (tk, l) is a weight in the time zone t k of the time axis k for the mesh l, and is expressed by the following equation.
  • T (t k , l) indicates the total number of times the mesh l is totaled in the time zone t k .
  • ⁇ indicates the reliability of the time axis.
  • a threshold value for the number of units for counting the number of aggregations. For example, when the threshold value is 10 or more, the number of times that the aggregation result of 10 or more is obtained is stored in T (tk, l ). In the time zone tk in which the aggregated sudden index is to be calculated, it is possible to increase the reliability of the time axis in which the number of learnings is large when congestion occurs to some extent, and to strongly consider it when calculating the final aggregated sudden index.
  • the reliability among the time axes of various particle sizes can be increased.
  • the value of the sudden index calculated on the time axis that can be created can be strongly considered.
  • the degree of suddenness can be output by adopting. For example, it can be said that the time axis considering only the day of the week is a coarser time axis than the time axis such as "Monday 13:00" considering the day of the week and the time zone.
  • the above value used for calculating the aggregated sudden index R (l, t) is a value that does not consider all users u, and is detected at the same place per unit time regardless of the user. It is a value related to the number of cars.
  • the weight ⁇ (tk, l) does not need to consider all meshes l unlike the above equation (2), so the calculation of the aggregated sudden index R ( l , t). Can be performed independently for each mesh l. Therefore, when it is necessary to calculate the aggregated sudden index in many places such as traffic jam detection, the calculation cost can be reduced.
  • the aggregated sudden index C (l, t) is not so large, but the standard deviation ⁇ (tk, l) is small, and the aggregated number C ( l , t) is the average ⁇ (tk, l ) of the aggregated number. If it is larger than, the aggregated sudden index R (l, t) becomes large.
  • FIG. 5 is a flowchart showing an example of the flow of the traffic jam determination process by the traffic jam determination program according to the present embodiment.
  • the traffic jam determination process by the traffic jam determination program is realized by the CPU 11 of the traffic jam determination device 10 writing the traffic jam determination program stored in the ROM 12 or the storage 14 into the RAM 13 and executing the process.
  • step S100 the CPU 11 acquires the total number C (l, t) for each mesh l and for each unit time from the log database 31.
  • step S102 the CPU 11 calculates the average ⁇ (tk, l ) and the standard deviation ⁇ (tk, l ) of the total number of units for each mesh l and each time zone tk.
  • step S104 the CPU 11 calculates the weight ⁇ (tk, l ) for each mesh l and each time zone tk. Specifically, the total number T (t k , l ) of the total number of mesh l in the time zone tk is calculated. In addition, the number of aggregations in the time zone t'k , which is the most aggregated in the entire time axis of the time zone t k , for each mesh l. Is calculated. Then, the weight ⁇ (tk, l ) is calculated for each mesh l and each time zone tk by the above equation (4).
  • steps S102 and S104 do not have to be executed every time.
  • the processes of steps S102 and S104 may be executed every predetermined time or every time the acquisition of the total number of units is executed a predetermined number of times.
  • step S106 the CPU 11 calculates the aggregated sudden index at the current time t for each mesh l according to the above equation (3) based on the calculation results of steps S100 to S104.
  • step S108 whether or not the CPU 11 has a mesh l equal to or greater than the threshold value among all the mesh l aggregated sudden indicators R (l, t) calculated in step S106, that is, sudden congestion occurs. It is determined whether or not there is a mesh l. Then, when there is a mesh l whose total sudden index R (l, t) is equal to or higher than the threshold value, the process proceeds to step S110, and when there is no mesh l whose total sudden index R (l, t) is equal to or higher than the threshold value, the process proceeds to step S100. do.
  • the threshold value is set in advance to a value at which it is highly likely that sudden congestion has occurred if the aggregated sudden index R (l, t) is equal to or higher than the threshold value.
  • step S110 the CPU 11 acquires photographed image data from a car existing in the mesh l whose total sudden index R (l, t) is equal to or higher than the threshold value, that is, the mesh l in which sudden congestion occurs.
  • the captured image data may be acquired via the server 30 or may be acquired directly from the automobile.
  • the captured image data may be a moving image or a still image.
  • the CPU 11 analyzes the captured image data acquired in step S112 using a known analysis method to specify the congestion range and specify the head position of the congestion.
  • the reason for specifying the head position of the traffic jam is that the captured image of the head position of the traffic jam may record the cause of the traffic jam.
  • specifying the head position of a traffic jam is an example, and is not limited to this. That is, it suffices to identify a captured image in which the cause of the congestion may be recorded.
  • the boundary where the density of the vehicle changes may be specified as the cause of the congestion. Boundaries where the density of vehicles changes include, for example, the position of the accident vehicle, the construction site, and the like.
  • step S114 the CPU 11 notifies the user by transmitting the captured image data of the head position of the traffic jam specified in step S112 and the position information indicating the traffic jam range.
  • the user to be notified may be all users, or may be only users in a predetermined area centered on a mesh in which sudden congestion occurs.
  • the predetermined area can be, for example, an area within a radius of several hundred meters or a few kilometers around a mesh in which sudden congestion occurs, but the area is not limited to this.
  • the captured image data of the mesh l whose total sudden index R (l, t) is equal to or higher than the threshold value is acquired for each mesh l, and the captured image data at the head position of the congestion and the congestion range are represented. Notify by sending location information to the user. As a result, the calculation cost for analyzing the captured image data can be suppressed.
  • the present invention is not limited to this.
  • the aggregated sudden index R (l, t) is given a priority so that the higher the priority is, the aggregated sudden index R (l, t) is small and the priority of acquiring the captured image data is low.
  • the captured image data may be acquired and the processes of steps S110 to S114 may be executed.
  • the threshold value in step S108 the case where a predetermined value is used has been described, but the present invention is not limited to this.
  • the threshold value may be automatically determined by using a method such as a ROC (Receiving Operating Characteristic) curve.
  • ROC Receiveiving Operating Characteristic
  • the maximum value may be normalized to 1.0, the minimum value to ⁇ 1.0, and the like. This makes it possible to generalize the determination of the threshold value.
  • the aggregated sudden index may be used for other processing.
  • the aggregated sudden index may be used as one of the parameters when determining the route to the destination.
  • the aggregated sudden index calculated based on the aggregated number of automobiles may be used as an evaluation for city planning. Places where traffic jams occur suddenly may cause temporary congestion due to sudden causes such as accidents, but there are also cases where new traffic jams occur due to the opening of new roads or new facilities. be. In particular, places where the aggregated sudden index increases once and then decreases will cause new chronic congestion due to changes in road conditions, so personnel for increasing lanes and rearranging vehicles It is considered necessary to take measures such as splitting.
  • the destination of the aggregated sudden index is not limited to the evaluation of traffic congestion. For example, by applying it to the statistics of the flow of people, it is possible to detect places where people are suddenly crowded, and use it to determine where to assign police officers for personnel reduction and to guide the flow of people to other places. Can be done.
  • the aggregated sudden index to the transmission amount of the network, it is possible to extract the phenomenon that the transmission amount suddenly increases or decreases when considering multiple time axes, which is useful for detecting the failure of network devices. Conceivable. Similarly, it can be applied to power consumption, etc.
  • the functional configuration of the traffic jam determination device 10 according to the second embodiment is the same as that of the traffic jam determination device 10 shown in FIG. 3 described in the first embodiment, but the processing of each part is different.
  • the content and processing content of the data acquired from the server 30 by the acquisition unit 21 are different.
  • the server 30 includes a log database 31A and a locus information database 32.
  • the log database 31A includes, in addition to the contents of the log database 31 described in the first embodiment, a user ID for identifying the user u representing the vehicle that has transmitted the vehicle position information to the server 30.
  • track information database 32 track information representing past travel tracks recorded by a vehicle such as a taxi equipped with a GPS device is stored in the same format as the log database 31A for the number of a plurality of vehicles, that is, for a plurality of users. It has been recorded.
  • the acquisition unit 21 acquires the total number of automobiles for each mesh and each unit time. It should be noted that the detected traffic jam information may be acquired. Further, the acquisition unit 21 further acquires the locus information of the automobile from the locus information database 32.
  • the determination unit 22 calculates the degree of congestion habit based on the congestion occurrence probability calculated based on the total number of units for each mesh and each unit time. For example, the congestion habit level is calculated based on the congestion occurrence probability calculated based on the case where the total number of units is larger than a certain number for each mesh and each unit time, or when the congestion for each lane is detected by image processing. Then, the determination unit 22 calculates the locus habit degree based on the passage probability based on the locus information, calculates the weighted congestion habit degree based on the weight of the congestion habit degree, the locus habit degree, and the locus habit degree, and calculates the weighted congestion habit degree. Based on the calculated weighted congestion habit, it is determined whether the occurrence of congestion is sudden or chronic.
  • the determination unit 22 increases the weight of the locus habit degree as the number of meshes for which the congestion habit degree has not been calculated increases.
  • the cost for detecting the traffic jam is high. Therefore, it is considered that the number of meshes for which the degree of congestion habit has not been calculated increases, and the effect of the technique of the present disclosure becomes large.
  • the notification unit 23 notifies only users who meet the predetermined criteria of the occurrence of traffic congestion.
  • the predetermined standard is that when the occurrence of traffic congestion is chronic, the predetermined area including the mesh in which the chronic congestion occurs is a user who is out of the living area.
  • FIG. 7 is a flowchart showing an example of the flow of the traffic jam determination process by the traffic jam determination program according to the present embodiment.
  • the traffic jam determination process by the traffic jam determination program is realized by the CPU 11 of the traffic jam determination device 10 writing the traffic jam determination program stored in the ROM 12 or the storage 14 into the RAM 13 and executing the process.
  • step S200 the CPU 11 acquires the locus information from the locus information database 32 of the server 30.
  • step S202 the CPU 11 calculates the locus habit degree using the method disclosed in Patent Document 1 based on the locus information acquired in step S200. That is, the locus habit degree R1 (l, t) is calculated by the above equation (1). However, here, the user u is not distinguished, and the locus habit degree R1 (l, t) is calculated for all users.
  • tk) to the mesh l across all users in the time zone tk is calculated for each mesh l and for each time zone tk, respectively.
  • the average ⁇ ( tk ) of the passing probability for all the mesh l across all the users in the time zone tk is calculated for each time zone tk.
  • the standard deviation ⁇ ( tk ) of the passing probability for all meshes across all users in the time zone tk is calculated for each time zone tk .
  • the total value N ( u , tk ) of the number of passages of all places by crossing all users in the time zone tk is calculated for each time zone tk.
  • step S204 the CPU 11 acquires the total number of units C (l, t) for each mesh l and each unit time or the presence or absence of congestion from the log database 31A.
  • step S206 the CPU 11 determines whether or not there is a mesh l in which the total number of units C (l, t) is equal to or greater than the threshold value.
  • the threshold value is set to a value at which it can be determined that there is a high possibility that congestion has occurred in the mesh l. Then, if there is a mesh l whose total number C (l, t) is equal to or greater than the threshold value, the process proceeds to step S208, and if there is no mesh l whose total number C (l, t) is equal to or greater than the threshold value, the process proceeds to step S204. Further, when the traffic jam detection result by the image processing of the captured image data is input, the process proceeds to step S208 if there is one or more traffic jam detection results, and the process proceeds to step S204 if there is no traffic jam detection result.
  • step S208 log data is transmitted to the server 30 from the user u whose total number C (l, t) is equal to or greater than the threshold value, that is, from the mesh l whose total number C (l, t) is equal to or greater than the threshold value.
  • the photographed image data is acquired from the user u of the automobile.
  • step S210 the CPU 11 analyzes the captured image data acquired in step S208 to specify the congestion range and specify the head position of the congestion, as in step 112 of FIG.
  • step S212 the CPU 11 calculates the congestion habit degree R2 (l, t) for each mesh l according to the above equation (1) based on the log data registered in the log database 31A.
  • the user u is not distinguished, and the congestion habit degree R2 (l, t) is calculated for all users.
  • tk) represents the probability of occurrence of congestion.
  • the calculation of the congestion habit degree R2 (l, t) is the same as the calculation of the locus habit degree R1 (l, t) in step S202 except that the log data registered in the log database 31A is used, so the description is omitted. do.
  • step S214 the weighted habit degree R3 (l, t) is calculated by the following equation based on the locus habit degree R1 (l, t) calculated in step S202 and the congestion habit degree R2 (l, t) calculated in step S212. calculate.
  • R3 (l, t) R2 (l, t) + R1 (l, t) x ⁇ ... (5)
  • ⁇ is a weight and is expressed by the following equation.
  • c is a correlation coefficient between the locus habit degree R1 (l, t) and the congestion habit degree R2 (l, t).
  • M is a mesh l for which the congestion habit degree R2 (l, t) has not been calculated, that is, the number of vehicles exceeding the threshold is not detected, or the congestion is not detected by the congestion detection by the image, and the congestion habit degree R2.
  • (L, t) is the number of mesh l for which the calculation has not been performed.
  • a and b are constants.
  • the weighted habit degree R3 (l, t) becomes the congestion habit degree R2 (l, t) as the difference between the locus habit degree R1 (l, t) and the congestion habit degree R2 (l, t) becomes smaller.
  • the influence of the locus habit degree R1 (l, t) is larger than that. Further, the larger the number M of the undetected mesh l, the greater the influence of the locus habit degree R1 (l, t) as compared with the congestion habit degree R2 (l, t).
  • the weighted habit degree R3 (l, t) is normalized to level 1 to 10 and the like. It may be divided into levels as follows.
  • the mesh l for which the congestion habit degree R2 (l, t) is calculated has increased to some extent
  • the mesh l for which the congestion habit degree R2 (l, t) has not been calculated is set by setting the constant a to a large value.
  • the influence of the number M may be suppressed. That is, the influence of the locus habit degree R1 (l, t) may be reduced.
  • the constant b if the correlation coefficient C between the locus habit degree R1 (l, t) and the congestion habit degree R2 (l, t) is small, or if the number of log data is too small, the constant b is set to 1. It may be set to a value less than or equal to a value so that the weight ⁇ becomes small. That is, the influence of the locus habit degree R1 (l, t) may be reduced.
  • step S216 the CPU 11 determines whether or not there is a mesh l in which chronic congestion has occurred. Specifically, it is determined whether or not the weighted habit degree R3 (l, t) calculated in step S214 is equal to or higher than a predetermined threshold value. When the weighted habit degree R3 (l, t) is equal to or higher than the threshold value, the threshold value is set to a value at which it can be determined that the congestion occurring at the mesh l and the time t is likely to be chronic.
  • step S217 if there is a mesh l in which chronic congestion occurs, that is, if there is a mesh in which the weighted habit level R3 (l, t) is equal to or higher than the threshold value, the process proceeds to step S217.
  • the process proceeds to step S218.
  • step S217 the CPU 11 provides the captured image data of the head position of the traffic jam specified in step S210 and the position information indicating the traffic jam range in a predetermined area including the mesh in which the chronic traffic jam is occurring is out of the living area. Notify by sending to user u. That is, the occurrence of chronic congestion is not notified to the user u whose area including the mesh where chronic congestion is occurring is within the living area.
  • the predetermined area can be an area within a radius of several hundred meters or a radius of several kilometers around a mesh in which chronic congestion is occurring, but the area is not limited to this.
  • step S2128 the CPU 11 notifies both the user outside the living area and the user within the living area that a sudden traffic jam has occurred.
  • Whether or not a predetermined area including a mesh in which chronic congestion occurs is within the living area may be determined based on, for example, the habit level calculated by the method described in Patent Document 1, or location information. The determination may be made based on the distance from the home position estimated based on the history of the current location to the current location.
  • the weighted congestion habit degree R3 (l, t)
  • the predetermined area including the area does not notify the users in the living area of the occurrence of traffic congestion. As a result, it is possible to suppress notification of the occurrence of unnecessary traffic congestion.
  • the traffic jam that occurs is sudden, all users are notified regardless of whether the user is in the living area or out of the living area. This is because sudden traffic jams are not recognized by users in the living area and are likely to cause an accident.
  • the calculated weighted congestion habit may be used for other processing.
  • the weighted congestion habit may be used as one of the parameters for determining the route to the destination.
  • a weighted congestion habit may be used in the process of outputting.
  • the log data used when calculating the degree of congestion habit for example, information in a database that stores congestion information common to all lanes on one side, not for each lane, may be used. Further, when it is desired to investigate not only the log data of the traffic jam but also the visit tendency of the user in the newly started location information recording service, it is conceivable to utilize the visit tendency in another similar service as external information.
  • the calculation method of the habit degree disclosed in Patent Document 1 is RBM (Regular Behavior Massage), the calculation method of the aggregated sudden index in the first embodiment is SIMM as described above, and the weighted habit in the second embodiment.
  • the method for calculating the degree is referred to as SRBM (Small-start Regular Behavior Measure).
  • the following taxi GPS log data was used as the trajectory information.
  • the mesh was a square mesh with a length and width of about 110 m.
  • FIG. 8 shows a graph showing the bias of the time zone of the above GPS log data.
  • the horizontal axis represents time and the vertical axis represents the number of logs.
  • FIG. 9 shows a graph showing the bias of the day of the week in the GPS log data.
  • the horizontal axis represents the day of the week and the vertical axis represents the number of logs.
  • the bias in the number of logs was small in both the time zone and the day of the week.
  • FIG. 10 shows a graph of the number of logs showing the number of log data for each mesh.
  • FIG. 10 is a plot of the number of logs of each mesh in descending order of the number of logs. As shown in FIG. 10, it was found that 90% of the GPS log data was collected in the top 10 meshes.
  • RBM Since RBM was devised as a method assuming human check-in log, RBM considers whether it is possible to adapt to continuous log data acquired by the GPS device installed in the car, or whether the car is congested. We confirmed whether there is a habit that depends on multiple time axes. From the GPS log data for 10 cars, the passing probability was calculated without distinguishing which car's log data was used. Originally, in the second embodiment, the place where the total number of units exceeds the threshold value is input, or the place where the traffic jam is detected by the image processing of the captured image data is input, but only 10 units have GPS log data. Because of this, first, the habit level by RBM was calculated based on whether or not the taxi passed through each mesh based on the GPS log data.
  • FIG. 11 shows the result of applying RBM to the GPS log data of the taxi. It was classified by the average value of the habit level in each mesh. There are places with high habits scattered around Musashino City, Tokyo, which is the home of the taxi company, and places with low habits that show sudden visits as the distance from Tokyo increases. Was confirmed.
  • FIG. 12 shows a plot of only the places where the habit level was particularly high, that is, the places where people were chronically passed. It was found that there was chronic traffic congestion at stations and parks in Tokyo, which are considered to be naps and waiting areas.
  • Lid 3873 (Ebisu Park) also has a large number of logs in the time zone after the last train on Friday and before the first train on Monday, and both tend to be peculiar to taxis that run with the aim of acquiring customers during the time when trains are not operating. It is thought that it represents.
  • RBM is effective in indexing whether traffic congestion is chronic or sudden from the trajectory information obtained by GPS.
  • SIMM The validity of SIMM was confirmed using the GPS log data of the taxi.
  • FIG. 14 shows the distribution of the aggregated sudden index calculated by SIMM.
  • FIG. 14 is a plot of the aggregated sudden index of all meshes in descending order of the aggregated sudden index. Since the total sudden index of all meshes is 0 in the first total, there are many totals in which the total sudden index is exactly 0.
  • the aggregated sudden index is a positive value, that is, the aggregated number is suddenly larger than usual
  • the aggregated sudden index is a negative value
  • the aggregated number is suddenly smaller than usual. It may be. It can be seen that there are more cases where the total number is suddenly larger than usual than when the total number is suddenly smaller than usual, and the total number suddenly decreases in places where there is chronic congestion. It turns out that there are few.
  • FIG. 15 plots the transition of the aggregated sudden index and the number of logs for the three places where the aggregated sudden index was the highest.
  • Top1 (1 near International Christian University (ICU)) is a place where the number of logs is not usually large, and it was confirmed that the total sudden index became the maximum when the number of logs suddenly became 50 or more.
  • the aggregated statistical information includes the average ⁇ (tk, l ) of the aggregated number in the above equation (3), the standard deviation ⁇ (tk, l ) of the aggregated number, and the weight ⁇ (tk, l ). Is.
  • FIG. 16 shows the calculated total sudden index divided into eight levels and plotted on a map for 160 locations where the total sudden index was 1.0 or more.
  • the marks are superimposed and displayed. As shown in FIG. 16, it was confirmed that the roads with a large number of lanes were concentrated especially near the intersection. This is consistent with places where traffic congestion is likely to occur.
  • the meshes that were actually congested were detected manually in the area near Odaiba, and 121 meshes that were actually congested were detected.
  • the adoption rate of chronic congestion meshes that we want to exclude from the processing target of acquisition and analysis of captured image data is low, and the purpose is to target only sudden congestion as the target of acquisition and analysis of captured image data. It was confirmed that the matching results were obtained.
  • the degree of traffic congestion habits detected manually was calculated using RBM, and the top 50% of the traffic congestion habits were regarded as chronic traffic jams and the bottom 50% were regarded as sudden traffic jams.
  • FIG. 18 shows the results when static aggregate statistical information calculated using only the GPS log data in the first half of the 66 days was used.
  • the results of FIG. 18 differ from the case of FIG. 17 only in the use of static aggregated statistics.
  • FIG. 19 shows the result of calculating the congestion habit degree using RBM for a mesh whose total sudden index calculated using GPS log data for the latter half 33 days is equal to or higher than the threshold value.
  • Congestion habits were divided into 8 levels. The four meshes circled were excluded when calculating the congestion habit because the aggregated sudden index was less than the threshold value, but these were excluded due to the high congestion habit due to RBM and chronic congestion. Therefore, it was confirmed that it meets the purpose of acquiring and analyzing captured image data only for meshes whose aggregated sudden index is equal to or higher than the threshold value.
  • the constant a when calculating the weighted habit degree was set to 1 because the number of times of traffic jam detection was small. Further, the constant b was changed in 0.5 increments between 0 and 3. When the constant b is 0, the locus habit degree is not taken into consideration, so that it is the same as the case where the congestion habit degree is calculated by RBM.
  • the first four traffic jams are compared with the case where the constant b is set to 0, that is, the locus habit degree is not taken into consideration. It was confirmed that there was a high correlation until the detection of. If the value of the constant b is made too large, the correlation with the degree of congestion habit due to RBM becomes slightly low in the latter half, so it is considered that 0.5 is the most appropriate constant b.
  • FIG. 21 shows the change in the weight ⁇ when the weighted congestion habit degree is calculated. As shown in FIG. 21, it was confirmed that the weight was increased so that the influence of the locus habit degree was increased in the initial stage when the number of times of detecting congestion was small.
  • a car and a traffic jam have been described as an example, but the present invention is not limited to this.
  • humans may be used instead of automobiles, and the density of people may be used instead of traffic jams.
  • the density of people may be used instead of traffic jams.
  • an image taken by a mobile device represented by a smartphone may be used, or an image posted on SNS at a corresponding position and time may be used.
  • information such as mobile spatial statistics may be used to acquire the density of people.
  • various processors other than the CPU may execute the congestion determination process executed by the CPU reading the software (program) in the above embodiment.
  • a processor in this case a PLD (Programmable Logic Device) whose circuit configuration can be changed after manufacturing an FPGA (Field-Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or the like for specifying an ASIC.
  • An example is a dedicated electric circuit or the like, which is a processor having a circuit configuration designed exclusively for it.
  • the congestion determination process may be executed by one of these various processors, or a combination of two or more processors of the same type or different types (for example, a plurality of FPGAs and a combination of a CPU and an FPGA). Etc.).
  • the hardware-like structure of these various processors is, more specifically, an electric circuit in which circuit elements such as semiconductor elements are combined.
  • the congestion determination program is stored (installed) in the storage in advance, but the present invention is not limited to this.
  • the program is stored in a non-temporary medium such as a CD-ROM (Compact Disk Read Only Memory), a DVD-ROM (Digital Versaille Disk Online Memory), and a USB (Universal Serial Bus) memory. It may be provided in the form. Further, the program may be downloaded from an external device via a network.
  • a non-temporary storage medium that stores a program that can be executed by a computer to execute a traffic jam determination process.
  • the traffic jam determination process is Acquire the total number of automobiles for each mesh and unit time that virtually divides the area to be judged for traffic congestion. Based on the acquired number of units for each mesh and each unit time, it is determined for each mesh whether or not the occurrence of traffic congestion is sudden.
  • Non-temporary storage medium is Acquire the total number of automobiles for each mesh and unit time that virtually divides the area to be judged for traffic congestion. Based on the acquired number of units for each mesh and each unit time, it is determined for each mesh whether or not the occurrence of traffic congestion is sudden.
  • Congestion judgment device 21 Acquisition unit 22 Judgment unit 23 Notification unit 30 Server 31, 31A Log database 32 Trajectory information database

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Analytical Chemistry (AREA)
  • Chemical & Material Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Traffic Control Systems (AREA)

Abstract

渋滞判定装置は、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得する取得部と、取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する判定部と、を含む。

Description

渋滞判定方法、渋滞判定装置、及び渋滞判定プログラム
　開示の技術は、渋滞判定方法、渋滞判定装置、及び渋滞判定プログラムに関する。
　画像を用いて渋滞の推定を行う試みは古くからなされている。例えば、固定カメラで撮影された画像を用いて車両の挙動を推定する技術がある（例えば非特許文献１参照）。
　車両の挙動を利用することで渋滞の発生個所を推定できる可能性がある。しかしながら広範な範囲を対象としようとする場合、多くのカメラを設置する必要があり、カメラから画像の処理を行うための演算装置まで画像若しくは符号化データを伝送する必要もある。
　また、単に画像を処理するだけでは渋滞が発生していることや渋滞の発生要因を推定することができても、推定した事項を適切なユーザに適切な通知をすることは難しい。ここでいう適切なユーザとは、例えば慢性的に渋滞が発生するエリアが生活圏内であるユーザであり、適切な通知とは、突発的な渋滞の発生の通知である。すなわち、慢性的に渋滞が発生するエリアが生活圏内であるユーザに対しては慢性的な渋滞の発生を通知する必要はなく、突発的な渋滞の発生のみ通知することが好ましい。
"都市高速道路における画像解析手法を用いた渋滞発生メカニズムの詳細分析", http://www.ce.it-chiba.ac.jp/atrans/ronbun/akahane/2007/2007%20tosi%20kousokudouro.pdf
　開示の技術は、上記の点に鑑みてなされたものであり、発生した渋滞が突発的か否かを判定することができる渋滞判定方法、渋滞判定装置、及び渋滞判定プログラムを提供することを目的とする。
　上記目的を達成するために、本開示の一態様に係る渋滞判定方法は、取得部及び判定部を備えた渋滞判定装置における渋滞判定方法であって、前記取得部が、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、前記判定部が、取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する。
　更に、上記目的を達成するために、本開示の一態様に係る渋滞判定装置は、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得する取得部と、取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する判定部と、を備える。
　更に、上記目的を達成するために、本開示の一態様に係る渋滞判定プログラムは、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定することをコンピュータに実行させる。
　開示の技術によれば、発生した渋滞が突発的か否かを判定することができる。
場所毎の訪問確率の一例を示す図である。 第１実施形態に係る渋滞判定装置のハードウェア構成の一例を示すブロック図である。 第１実施形態に係る渋滞判定装置の機能構成の一例を示すブロック図である。 場所毎の集計台数の一例を示す図である。 第１実施形態に係る渋滞判定処理のフローチャートである。 第２実施形態に係る渋滞判定装置の機能構成の一例を示すブロック図である。 第２実施形態に係る渋滞判定処理のフローチャートである。 ＧＰＳログデータの時間帯の偏りを表すグラフである。 ＧＰＳログデータの曜日の偏りを表すグラフである。 メッシュ毎のログデータの数を表すログ数のグラフである。 タクシーのＧＰＳログデータに対してＲＢＭを適用した結果を示す図である。 慢性的に通行された場所を示す図である。 習慣度が高かった場所の曜日及び時間帯の偏りを表すグラフである。 ＳＩＣＭで算出した集計突発指標の分布を示す図である。 集計突発指標が最も高かった３か所について、集計突発指標及びログ数の変遷をプロットした図である。 集計突発指標が１．０以上であった１６０箇所について、算出された集計突発指標を８段階にレベル分けして地図上にプロットした図である。 動的な集計統計情報を用いて集計突発指標をメッシュ毎に算出した場合における、実際に渋滞が発生していたメッシュに対する採用率及び計算コストの削減率を示す図である。 静的な集計統計情報を用いて集計突発指標をメッシュ毎に算出した場合における、実際に渋滞が発生していたメッシュに対する採用率及び計算コストの削減率を示す図である。 後半３３日間のＧＰＳログデータを用いて算出した集計突発指標が閾値以上のメッシュについてＲＢＭを用いて渋滞習慣度を算出した結果を示す図である。 お台場において検知された１５個の渋滞に対して、渋滞を１回検出する毎にＳＲＢＭにより算出した重み付き習慣度と、１５個の渋滞全てを検知した後にＲＢＭにより算出した渋滞習慣度と、の相関係数を全メッシュについて算出した結果を示す図である。 重み付き渋滞習慣度を算出した際の重みの変化を示す図である。
　以下、開示の技術の実施形態の一例を、図面を参照しつつ説明する。なお、各図面において、同一又は等価な構成要素及び部分には同一の参照符号を付与している。また、図面の寸法比率は、説明の都合上誇張されており、実際の比率とは異なる場合がある。
＜渋滞検知の概要＞
　車道で発生する渋滞の中には施設の入口や信号待ち等の理由により特定車線でのみ発生するものがある。このような渋滞が発生している際に、渋滞の末尾の位置からは先頭位置が見えず、その渋滞に自車が並ぶべきか、別車線から追い越してもよいかが分からないケースが発生する。このようなケースが増加すると、目的地までの所要時間が増加したり、無駄な混雑が発生したりするという問題がある。
　このような問題を解決するため、車載カメラで撮影された撮影画像（例えば動画像）の撮影画像データ及びＧＰＳ（Ｇｌｏｂａｌ　Ｐｏｓｉｔｉｏｎｉｎｇ　Ｓｙｓｔｅｍ）による位置情報を用いて、道路上の特定車線における自動車の渋滞発生位置（先頭及び末尾）を推定し、運転者にその情報を通知することが考えられるが、以下のような問題がある。
（１）撮影画像データを使用するため、渋滞発生位置を推定する際の計算コストが高くなる。また、一般車から撮影画像データをサーバにアップロードする通信コストも高くなる。
（２）自動車を運転するユーザに渋滞が発生していることを通知する場合、慢性的に渋滞が発生するエリアが生活圏内とするユーザに対しても繰り返し通知してしまうため、不要な通知の回数が増加し、ユーザの満足度が低くなる可能性がある。
　上記（１）の問題に対しては、撮影画像データを用いて渋滞発生位置を推定するエリアを、突発的な渋滞が発生しているエリアに限定することが考えられる。これにより、例えば施設の入口等のように繰り返し同じ原因で渋滞が発生するエリアに対しては渋滞発生位置を推定する処理を省略することで計算コストを抑えることができる。
　上記（２）の問題に対しては、渋滞が発生しているエリアが生活圏内であるユーザに対しては、慢性的な渋滞の発生については通知せず、突発的な渋滞の発生についてのみ通知することにより、ユーザの満足度が向上すると考えられる。
　レーン別渋滞には周期的に発生するレーン別渋滞と突発的に発生するレーン別渋滞がある。周期的に発生する渋滞には特定の曜日や時間帯に繰り返し発生する等の時間依存性があると考えられている。特定の曜日に発生することが多いが時間帯は必ずしも偏っていない渋滞、特定の時間帯に発生することが多いが曜日に偏りはなく毎日発生する渋滞、曜日や時間帯依存性がなく常に発生する渋滞等、発生する渋滞が、どの時間軸に強く依存するかは渋滞が発生する場所によって異なる。例えば、幹線道路の右左折レーンの渋滞は朝夕のラッシュ時に起きやすい、商業施設への入庫待ちは土日祝日に起きやすい、高速道路と一般道路の合流レーンの渋滞は常時、信号周期起因等で起きやすいなどの周期性があり、これらは周期性から予測可能であるといえる。一方、突発的に発生するレーン別渋滞には、事故や故障者等車線をふさぐ障害が発生しているもの、商業施設のバーゲンや新規開店などイベント起因のもの、コロナ禍によるドライブスルー特需など日常習慣の変化によるものなどがある。これらは予測不能かつ事故誘発可能性が高いため、複数の自動車から重点的に映像等の撮影画像データを収集して分析する必要があり、また、渋滞が発生しているエリアが生活圏内であるユーザに対しても渋滞の発生を通知する必要がある。従って、曜日や時間帯等の様々な時間軸を総合的に考慮した上で、発生した渋滞が突発的であるか慢性的であるかを指標化する必要がある。この時、指標は時間軸別に求めるのではなく、どの渋滞の撮影画像データを収集すべきかを判断できるように一元化する必要がある。加えて、渋滞情報はなるべくリアルタイムに通知する必要があるため、渋滞の慢性／突発性の判定も高速に実施する必要があり、Ａｕｔｏ　Ｅｎｃｏｒｄｅｒなどの複雑なモデルを用いた異常値検出を適用することは難しい。
　曜日や時間帯等の複数の時間軸を同時に考慮して、発生した事象が突発的であるか慢性的であるかを高速に一元化された形で指標化する方法として、下記特許文献１、２に開示の技術がある。
（特許文献１）特開２０１５－１５３０８８号公報
（特許文献２）特開２０１６－９１０４０号公報
　特許文献１に開示された技術では、ユーザの位置情報を用いて、或る訪問場所への訪問がどの程度突発的であるか慢性的であるかを、複数の時間軸を総合的に考慮して指標化した「習慣度」を算出する。
　特許文献１に開示された技術を、渋滞検知における上記（１）、（２）の問題点の対応のために適用すると、それぞれ以下のような問題がある。
　まず、上記（１）に関する問題について説明する。
　上記特許文献１に開示された技術は、元々人間の行動を対象としていることもあり、訪問に付随する指標ではなく、訪問があったという事象そのものに対する指標を習慣度として算出している。具体的には、特定のユーザに限定して場所別の訪問確率を算出し、その中で習慣度を算出したい訪問場所の訪問確率が他の場所の訪問確率に比べてどの程度突発的であるかを習慣度として算出している。
　図１に、特許文献１に開示の技術で算出される場所毎の訪問確率の一例を示す。また、特許文献１に開示された習慣度Ｒ（ｌ，ｕ，ｔ）を算出する式は次式で表される。
Figure JPOXMLDOC01-appb-I000001
　・・・（１）
　ここで、ｋは、曜日（ｋ＝１）、時間帯（ｋ＝２）、曜日及び時間帯（ｋ＝３）、時間考慮無し（ｋ＝４）の時間軸の種類を示すパラメータである。
　ｔｋは、習慣度の算出対象の時間帯を示す。例えば、ｋ＝２であり、習慣度の算出対象の時間帯が１３時台の場合には、ｔ２＝１３と表される。
　Ｐ（ｌ｜ｕ，ｔｋ）は、時間帯ｔｋにおけるユーザｕの場所ｌへの訪問確率である。場所ｌは、本実施形態では渋滞の判定対象領域を仮想的に分割したメッシュをいうので、以下ではメッシュｌと称する。メッシュは、例えば縦横が１００ｍの正方形の領域とすることができるが、メッシュのサイズ及び形状はこれに限られるものではない。
　なお、Ｐ（ｌ｜ｕ，ｔｋ）に関して次式が成り立つ。
Figure JPOXMLDOC01-appb-I000002
　　　
　ω（ｕ，ｔｋ）は、ユーザｕについての時間帯ｔｋの重みである。
　μ（ｕ，ｔｋ）は、時間軸ｋ、時間帯ｔｋのユーザｕの全メッシュに対する訪問確率の平均である。
　σ（ｕ，ｔｋ）は、時間軸ｋ、時間帯ｔｋのユーザｕの全メッシュに対する訪問確率の標準偏差である。
　これに対し、渋滞検知の場合には、或る１台の自動車が特定のメッシュを訪問したという事象ではなく、特定のメッシュにおいて存在が検知された自動車の単位時間当たりの集計台数に対して突発的か否かを指標化する必要がある。
　特許文献１では、訪問場所に対する「訪問確率」が他の場所に比べてどの程度突発的であるかを示す指標として習慣度を算出しているが、渋滞検知では、同じメッシュのこれまでの「集計台数」に比べて、指標を算出したい時間軸における集計台数がどの程度突発的に多くなっているかを表す指標を算出する必要がある。従って、特許文献１に開示の技術をそのまま適用することはできない。
　特許文献１では、各時間軸において算出した習慣度を適切な比重で重み付けすることで総合的な習慣度を算出している。この重みω（ｕ，ｔｋ）は、ユーザｕが同じ時間帯に他の場所を含めてどの程度の訪問数を記録しているかが考慮された次式により算出される。
Figure JPOXMLDOC01-appb-I000003
　　　・・・（２）
　ここで、Ｎ（ｕ，ｔｋ）は、時間帯ｔｋにおけるユーザｕによる全場所の訪問回数の合計値である。
Figure JPOXMLDOC01-appb-I000004

は、ユーザｕが時間軸ｋの全時間帯の中で最も多く訪問を記録した時間帯ｔｋ’における全場所の訪問回数の合計値である。
　渋滞検知においては、ユーザｕに関係無く、集計台数がどの程度突発的に多くなっているかを表す指標を算出したいことから、上記（２）式をそのまま用いることはできない。以下、渋滞検知において集計台数の突発度合いを示す指標を集計突発指標又はＳＩＣＭ（Ｓｕｄｄｅｎｎｅｓｓ　Ｉｎｄｅｘ　Ｃａｌｃｕｌａｔｉｏｎ　Ｍｅｔｈｏｄ）と呼ぶ。また、広範囲の場所に対して集計突発指標を算出する場合、集計突発指標自体の計算コストを抑える必要がある中で、上記（２）式のように、全場所の訪問回数を算出することは、メッシュ毎に独立して集計突発指標を算出できなくなるため避ける必要がある。
　上記特許文献２に開示の技術では、或る事象が存在した時に、その事象のこれまでの発生回数及び発生確率に基づいて複数の時間軸における習慣度を算出する。これについても、「集計台数」のような数の大小に基づく習慣性ではなく、事象発生そのものの確率をユーザ毎に算出しているため、集計突発指標のような集計値の突発度合いを算出するという目的で用いることはできない。
　次に、上記（２）に関する問題について説明する。
　ユーザへの渋滞発生の通知の有無を判定するために、発生した渋滞が突発的であるか慢性的であるかを判定する場合、渋滞が発生したという事象そのものに対する習慣度を算出すればよいため、特許文献１に開示された技術の適用が考えられる。
　上記（１）においては、渋滞が発生したかどうかを検出する前に、集計台数から集計突発指標を算出する必要があるが、上記（２）においては、渋滞を公知の方法で検出した後で、その渋滞が突発的であるか慢性的であるかを判定すればよいためである。
　しかしながら、実際は車線別の渋滞検知は計算コスト等が高コストであること、渋滞検知結果のサンプル数が少ない初期段階では、算出される習慣度の精度が問題となる。
　以上より、第１実施形態では、上記（１）の問題を解決するため、各メッシュで集計した集計台数に基づいて集計突発指標をメッシュ毎に算出する。これにより、その後の処理である渋滞が発生しているエリアに存在する自動車によって撮影された撮影画像データの取得及び撮影画像データの解析による渋滞検知の処理を簡略化することができる。
　また、第２実施形態では、上記（２）の問題を解決するため、発生した渋滞が突発的であるか慢性的であるかを習慣度として算出するが、渋滞検知のために取得したログデータの数が少ない初期の段階では、タクシー等の過去のＧＰＳログデータや、レーン別のデータは存在しないが道路及び区間別の過去の渋滞履歴なども考慮して習慣度を算出する。そして、慢性的な渋滞の発生については、渋滞が発生しているエリアを生活圏としているユーザに対しては通知せず、渋滞が発生しているエリアが生活圏外であるユーザに対してのみ通知する。このように、発生している渋滞が突発的であるか慢性的であるかに応じて、渋滞発生の通知対象を切り替えてもよい。
＜第１実施形態＞
　図２は、本実施形態に係る渋滞判定装置１０のハードウェア構成の一例を示すブロック図である。
　図２に示すように、渋滞判定装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）１３、ストレージ１４、入力部１５、表示部１６、及び通信インタフェース（Ｉ／Ｆ）１７を備えている。各構成は、バス１８を介して相互に通信可能に接続されている。
　ＣＰＵ１１は、中央演算処理ユニットであり、各種プログラムを実行したり、各部を制御したりする。すなわち、ＣＰＵ１１は、ＲＯＭ１２又はストレージ１４からプログラムを読み出し、ＲＡＭ１３を作業領域としてプログラムを実行する。ＣＰＵ１１は、ＲＯＭ１２又はストレージ１４に記憶されているプログラムに従って、上記各構成の制御及び各種の演算処理を行う。本実施形態では、ＲＯＭ１２又はストレージ１４には、渋滞が突発的か否かを判定するための渋滞判定プログラムが格納されている。
　ＲＯＭ１２は、各種プログラム及び各種データを格納する。ＲＡＭ１３は、作業領域として一時的にプログラム又はデータを記憶する。ストレージ１４は、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）又はＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）により構成され、オペレーティングシステムを含む各種プログラム、及び各種データを格納する。
　入力部１５は、マウス等のポインティングデバイス、及びキーボードを含み、自装置に対して各種の入力を行うために使用される。
　表示部１６は、例えば、液晶ディスプレイであり、各種の情報を表示する。表示部１６は、タッチパネル方式を採用して、入力部１５として機能しても良い。
　通信インタフェース１７は、自装置が他の外部機器と通信するためのインタフェースである。当該通信には、例えば、イーサネット（登録商標）若しくはＦＤＤＩ（Ｆｉｂｅｒ　Ｄｉｓｔｒｉｂｕｔｅｄ　Ｄａｔａ　Ｉｎｔｅｒｆａｃｅ）等の有線通信の規格、又は、４Ｇ、５Ｇ、若しくはＷｉ－Ｆｉ（登録商標）等の無線通信の規格が用いられる。
　本実施形態に係る渋滞判定装置１０には、例えば、サーバコンピュータ、パーソナルコンピュータ（ＰＣ：Personal Computer）等の汎用的なコンピュータ装置が適用される。
　次に、図３を参照して、渋滞判定装置１０の機能構成について説明する。
　図３は、本実施形態に係る渋滞判定装置１０の機能構成の一例を示すブロック図である。
　図３に示すように、渋滞判定装置１０は、機能構成として、取得部２１、判定部２２、及び通知部２３を備えている。各機能構成は、ＣＰＵ１１がＲＯＭ１２又はストレージ１４に記憶された渋滞判定プログラムを読み出し、ＲＡＭ１３に展開して実行することにより実現される。
　取得部２１は、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得する。集計台数は、サーバ３０が備えるログデータベース３１から取得する。
　ログデータベース３１は、メッシュを表す識別符号であるメッシュＩＤ、日時、曜日、メッシュ内で集計された自動車の集計台数の対応関係を表すデータベースである。
　サーバ３０は、渋滞の判定対象領域を走行するコネクテッドカー等のＧＰＳ装置及びインターネットへの接続機能を備えた自動車から送信された自車位置情報（緯度経度）を収集し、ログデータベース３１を逐次更新する。なお、サーバ３０の機能を渋滞判定装置１０が備えても良い。また、サーバ３０は、衛星画像を取得して画像解析することにより、メッシュ毎に自動車の台数を集計し、ログデータベース３１を逐次更新してもよい。
　サーバ３０は、コネクテッドカーから受信した自車位置情報が表す緯度経度をメッシュＩＤに変換して、メッシュＩＤ毎及び単位時間毎に自動車の集計台数を集計する。そして、メッシュＩＤ、集計台数、日時、曜日の情報をログデータベース３１に登録する。サーバ３０は、ログデータベース３１を逐次更新する。なお、単位時間は、例えば１０秒等に設定できるが、これに限られるものではない。
　日時は、例えば「ＹＹＹＹ／ｍｍ／ｄｄ　ＨＨ：ＭＭ：ＳＳ」のように表される。ここで、「ＹＹＹＹ」は年を表し、「ｍｍ」は月を表し、「ｄｄ」は日を表し、「ＨＨ」は時間を表し、「ＭＭ」は分を表し、「ＳＳ」は秒を表す。また、曜日は例えば月曜日から日曜日までを「０」～「６」で表す。
　また、メッシュのサイズ及び形状は、例えば１００ｍ×１００ｍの正方形とすることができるが、これに限られるものではない。
　なお、集計台数は、コネクテッドカーから収集した自車位置情報に基づいて集計するのではなく、道路上に設置されたビーコンで検出された自動車の数に基づいて集計してもよい。
　判定部２２は、取得したメッシュ毎及び単位時間毎の集計台数に基づいて、渋滞の発生が突発的か否かをメッシュ毎に判定する。具体的には、判定部２２は、メッシュ毎及び単位時間毎の集計台数に基づいて集計突発指標を算出し、算出した集計突発指標に基づいて渋滞の発生が突発的か否かを判定する。
　通知部２３は、渋滞の発生をユーザに通知する。
　以下、集計突発指標について説明する。
　渋滞検知においては、自動車の集計台数が通常に比べて突発的に多くなっているか否かを判定するために、訪問確率ではなく集計台数に基づく集計突発指標を定義する。集計突発指標Ｒ（ｌ，ｔ）は、次式により定義される。
Figure JPOXMLDOC01-appb-I000005
　　　・・・（３）
　ここで、ｔｋは、集計突発指標Ｒ（ｌ，ｔ）の算出対象の時間軸ｋで分類した時の時間帯や曜日などの時間情報を示す。例えば、ｋ＝２であり、集計突発指標Ｒ（ｌ，ｔ）の算出対象の時間帯が１３時台の場合には、ｔ２＝１３と表される。
　Ｃ（ｌ，ｔ）は、集計突発指標Ｒ（ｌ，ｔ）を算出したいメッシュｌの日時ｔにおける集計台数を表す。図４に、場所毎に算出した集計台数Ｃ（ｌ，ｔ）の一例を示す。
　μ（ｔｋ，ｌ）は、メッシュｌについての日時ｔが含まれる時間軸ｋにおける集計台数の平均を表す。例えば、日時ｔが１３時３分であり、ｋ＝２であった場合、ｔ２＝１３である。従って、μ（ｔ２，ｌ）は、メッシュｌの１３時台の集計台数の平均を表す。
　同様に、σ（ｔｋ，ｌ）は、日時ｔが含まれる時間軸ｋにおける集計台数の標準偏差を表す。
　ω（ｔｋ、ｌ）は、メッシュｌについての時間軸ｋの時間帯ｔｋにおける重みであり、次式で表される。
Figure JPOXMLDOC01-appb-I000006
　　・・・（４）
　ここで、Ｔ（ｔｋ，ｌ）は、時間帯ｔｋにおけるメッシュｌの集計台数の集計回数を示す。
Figure JPOXMLDOC01-appb-I000007

は、メッシュｌについて時間帯ｔｋの全時間軸の中で最も多く集計された時間帯ｔ’ｋにおける集計回数を表す。このように、集計回数が多い時間軸ほど重みが大きくなる。
　また、ωは時間軸の信頼度を示す。なお、集計回数の時間帯や曜日によるばらつきが少なく、１日を通して常に１台以上は車両が存在するようなデータを用いる際には、集計回数をカウントする台数に閾値を設けることも考えられる。例えば、閾値を１０台以上とする場合、１０台以上の集計結果を得た回数をＴ（ｔｋ，ｌ）に格納する。集計突発指標を算出したい時間帯ｔｋにおいて、ある程度混雑発生時の学習回数が多い時間軸の信頼度を高くして、最終的な集計突発指標の算出時に強く考慮することが可能となる。単なる集計結果に比べて混雑発生時の集計結果はサンプル数が少ないため、周期的な混雑発生を学習できている時間軸の信頼度を強くすることで、様々な粒度の時間軸のうち、信頼できる時間軸で算出された突発指標の値を強く考慮できる。粒度の異なる複数の時間軸を用意して、それぞれから算出された集計突発指標の重み付き線形和を出力することにより、混雑発生時の学習が不十分でも一元化された指標を用いた突発度合いの判定が可能になる。特にコネクテッドカーの普及初期においては、混雑発生時にコネクテッドカーの割合が低いと正しく周期的混雑が判別できない場合があるため、本開示ではそのような場合においても、学習データが少なければより粗い時間軸を採用することで突発度合いを出力することができる。例えば曜日および時間帯を考慮した「月曜日１３時台」のような時間軸に比べ、曜日だけを考慮した時間軸は粗い時間軸と言える。
　上記（１）式と異なり、集計突発指標Ｒ（ｌ，ｔ）の算出に用いる上記の値は全てのユーザｕを考慮しない値であり、ユーザに関係なく、単位時間当たりに同一場所で検知された自動車の台数に関する値となっている。
　なお、上記（４）式に示すように、重みω（ｔｋ，ｌ）は上記（２）式と異なり全メッシュｌを考慮しなくてよいため、集計突発指標Ｒ（ｌ，ｔ）の算出をメッシュｌ毎に独立して行うことができる。このため、渋滞検知のように多くの場所で集計突発指標を算出する必要がある場合、計算コストを削減することができる。
　上記（３）式より、集計台数Ｃ（ｌ，ｔ）が、集計台数の平均μ（ｔｋ，ｌ）より大きい場合は、集計突発指標Ｒ（ｌ，ｔ）は０より大きい値となり、平均μ（ｔｋ，ｌ）との差が大きいほど集計突発指標Ｒ（ｌ，ｔ）の値も大きくなる。また、集計台数Ｃ（ｌ，ｔ）のばらつきを表す標準偏差σ（ｔｋ，ｌ）が大きい場合は、集計台数Ｃ（ｌ，ｔ）が平均μ（ｔｋ，ｌ）と比べて大きかったとしても、集計突発指標Ｃ（ｌ，ｔ）はそれほど大きくならないが、標準偏差σ（ｔｋ，ｌ）が小さく、集計台数Ｃ（ｌ，ｔ）が集計台数の平均μ（ｔｋ，ｌ）よりも大きい場合は、集計突発指標Ｒ（ｌ，ｔ）は大きくなる。
　次に、図５を参照して、本実施形態に係る渋滞判定装置１０の作用について説明する。
　図５は、本実施形態に係る渋滞判定プログラムによる渋滞判定処理の流れの一例を示すフローチャートである。渋滞判定プログラムによる渋滞判定の処理は、渋滞判定装置１０のＣＰＵ１１が、ＲＯＭ１２又はストレージ１４に記憶されている渋滞判定プログラムをＲＡＭ１３に書き込んで実行することにより、実現される。
　ステップＳ１００では、ＣＰＵ１１が、ログデータベース３１からメッシュｌ毎及び単位時間毎の集計台数Ｃ（ｌ，ｔ）を取得する。
　ステップＳ１０２では、ＣＰＵ１１が、集計台数の平均μ（ｔｋ，ｌ）及び標準偏差σ（ｔｋ，ｌ）をメッシュｌ毎及び時間帯ｔｋ毎に算出する。
　ステップＳ１０４では、ＣＰＵ１１が、メッシュｌ毎及び時間帯ｔｋ毎に重みω（ｔｋ，ｌ）を算出する。具体的には、時間帯ｔｋにおけるメッシュｌの集計台数の集計回数Ｔ（ｔｋ，ｌ）を算出する。また、メッシュｌ毎に、時間帯ｔｋの全時間軸の中で最も多く集計された時間帯ｔ’ｋにおける集計回数
Figure JPOXMLDOC01-appb-I000008

を算出する。そして、上記（４）式により、メッシュｌ毎及び時間帯ｔｋ毎に重みω（ｔｋ，ｌ）を算出する。
　なお、ステップＳ１０２、Ｓ１０４の処理は、毎回実行しなくてもよい。例えば、予め定めた時間毎又は集計台数の取得を予め定めた回数実行する毎にステップＳ１０２、Ｓ１０４の処理を実行するようにしてもよい。
　ステップＳ１０６では、ＣＰＵ１１が、ステップＳ１００～Ｓ１０４の算出結果に基づいて、上記（３）式によりメッシュｌ毎に現在時刻ｔにおける集計突発指標を算出する。
　ステップＳ１０８では、ＣＰＵ１１が、ステップＳ１０６で算出した全てのメッシュｌの集計突発指標Ｒ（ｌ，ｔ）のうち、閾値以上のメッシュｌが有るか否か、すなわち、突発的な渋滞が発生しているメッシュｌが有るか否かを判定する。そして、集計突発指標Ｒ（ｌ，ｔ）が閾値以上のメッシュｌが有る場合はステップＳ１１０へ移行し、集計突発指標Ｒ（ｌ，ｔ）が閾値以上のメッシュｌが無い場合はステップＳ１００へ移行する。なお、閾値は、集計突発指標Ｒ（ｌ，ｔ）が閾値以上であれば、突発的な渋滞が発生している可能性が高いと考えられる値に予め設定される。
　ステップＳ１１０では、ＣＰＵ１１が、集計突発指標Ｒ（ｌ，ｔ）が閾値以上のメッシュｌ、すなわち突発的な渋滞が発生しているメッシュｌに存在する自動車から撮影画像データを取得する。撮影画像データは、サーバ３０経由で取得してもよいし、直接自動車から取得してもよい。なお、撮影画像データは、動画像でもよく静止画像でもよい。
　ステップ１１２では、ＣＰＵ１１が、ステップＳ１１２で取得した撮影画像データを公知の解析手法を用いて解析して渋滞範囲を特定し、渋滞の先頭位置を特定する。渋滞の先頭位置を特定するのは、渋滞の先頭位置の撮影画像には、渋滞が発生している原因が記録されている可能性があるためである。なお、渋滞の先頭位置を特定するのは一例であり、これに限られない。すなわち、渋滞が発生している原因が記録されている可能性がある撮影画像を特定できればよく、例えば渋滞が発生している原因として車両の密度が変化する境界等を特定してもよい。車両の密度が変化する境界としては、例えば事故車の位置や工事現場等が挙げられる。
　ステップＳ１１４では、ＣＰＵ１１が、ステップＳ１１２で特定した渋滞の先頭位置の撮影画像データ及び渋滞範囲を表す位置情報をユーザに送信することにより通知する。これにより、ユーザは渋滞範囲の位置と共に渋滞発生の原因を認識することができる。なお、通知するユーザは全てのユーザでもよいし、突発的な渋滞が発生しているメッシュを中心とした予め定めたエリア内のユーザのみでもよい。予め定めたエリアは、例えば突発的な渋滞が発生しているメッシュを中心として半径数百メートル以内又は数キロメートル以内のエリアとすることができるが、これに限られるものではない。
　このように、本実施形態では、メッシュｌ毎に集計突発指標Ｒ（ｌ，ｔ）が閾値以上のメッシュｌの撮影画像データのみを取得し、渋滞の先頭位置の撮影画像データ及び渋滞範囲を表す位置情報をユーザに送信することにより通知する。これにより、撮影画像データの解析のための計算コストを抑えることができる。
　なお、本実施形態では、集計突発指標Ｒ（ｌ，ｔ）が閾値未満のメッシュｌの撮影画像データを取得しない場合について説明したが、これに限られない。例えば、集計突発指標Ｒ（ｌ，ｔ）が大きくなるほど優先順位が高くなるように優先順位を付与し、集計突発指標Ｒ（ｌ，ｔ）が小さく、撮影画像データの取得の優先順位が低い場合でも、撮影画像データの解析等の処理に余裕がある場合には、撮影画像データを取得し、ステップＳ１１０～Ｓ１１４の処理を実行するようにしてもよい。
　また、ステップＳ１０８の閾値については、予め定めた値を用いる場合について説明したが、これに限られない。例えば、ＲＯＣ（Ｒｅｃｅｉｖｅｒ　Ｏｐｅｒａｔｉｎｇ　Ｃｈａｒａｃｔｅｒｉｓｔｉｃ）カーブ等の手法を用いて閾値を自動で決定してもよい。この場合、集計突発指標Ｒ（ｌ，ｔ）に上限及び下限はないので、最大値を１．０、最小値を－１．０等のように正規化してもよい。これにより、閾値の決定を一般化することができる。
　なお、本実施形態では、集計突発指標が閾値以上のメッシュが有る場合にユーザに通知する場合について説明したが、算出した集計突発指標を他の処理に用いても良い。例えば自動車のルート探索処理において、目的地までのルートを決定する際のパラメータの１つとして集計突発指標を用いてもよい。
　また、自動車の集計台数に基づいて算出した集計突発指標を都市計画のための評価として用いてもよい。突発的に渋滞が発生した場所は、事故など突発的な原因で一時的な混雑を引き起こしている場合もあるが、新規道路や新規施設の開店などで新しく渋滞が発生するようになった場合もある。特に集計突発指標が一度大きくなってからやがて減少していくような場所は、道路状況の変化により新たに慢性的な渋滞を引き起こすような場所であるため、車線を増やす、車両整理のための人員を割くなどの対応が必要であると考えられる。
　加えて集計突発指標の活用先は渋滞の評価に限られない。例えば人流の統計情報に対して適用させることで突発的に人が密になっている場所を検知し、人員整理の警察官をあてがう先の決定や人流の他の場所への誘導に使用することができる。また、ネットワークの伝送量に集計突発指標を適用すると、複数の時間軸を考慮した時に突発的に伝送量が増えたり減ったりする現象を抽出することができ、ネットワーク装置の故障検知にも役立つと考えられる。同様に電力消費量などにも適用が可能であり、例えば老人独居家庭で急激に消費量が増えた時には機械の誤動作を疑ったり、急激に減った時には体調の異変を疑ったりという活用も考えられる。このように複数の時間軸における周期性が想定されて、「量」を記録する時系列のログデータ全般に集計突発指標を適用することが可能であり、特に異常値を取った学習データが不足している場合に、指標の計算を広範囲に対して高速に行いたい時に効果を大きく発揮すると期待される。
＜第２実施形態＞
　第２実施形態について説明する。なお、第１実施形態と同一部分には同一符号を付し、詳細な説明は省略する。
　図６に示すように、第２実施形態に係る渋滞判定装置１０の機能構成は、第１実施形態で説明した図３に示す渋滞判定装置１０と同一構成であるが、各部の処理が異なる。まず、取得部２１が、サーバ３０から取得するデータの内容及び処理内容が異なる。
　サーバ３０は、ログデータベース３１Ａ及び軌跡情報データベース３２を備える。
　ログデータベース３１Ａは、第１実施形態で説明したログデータベース３１の内容に加えて、自車位置情報をサーバ３０へ送信した自動車を表すユーザｕを識別するためのユーザＩＤを含む。
　軌跡情報データベース３２には、例えばＧＰＳ装置を搭載したタクシー等の自動車によって記録された過去の走行軌跡を表す軌跡情報が、ログデータベース３１Ａと同じフォーマットで複数の自動車の台数分、すなわち複数のユーザ分記録されている。
　取得部２１は、メッシュ毎及び単位時間毎に、自動車の集計台数を取得する。なお、検知済みの渋滞情報を取得してもよい。また、取得部２１は、自動車の軌跡情報を軌跡情報データベース３２から更に取得する。
　判定部２２は、メッシュ毎及び単位時間毎に集計台数に基づいて算出した混雑発生確率に基づいて渋滞習慣度を算出する。例えば、メッシュ毎及び単位時間毎に集計台数が一定よりも多かった場合又は画像処理によりレーン別渋滞が検知された場合に基づいて算出した混雑発生確率に基づいて渋滞習慣度を算出する。そして、判定部２２は、軌跡情報に基づいて、通過確率に基づく軌跡習慣度を算出し、渋滞習慣度、軌跡習慣度、及び軌跡習慣度の重みに基づいて重み付き渋滞習慣度を算出し、算出した重み付き渋滞習慣度に基づいて渋滞の発生が突発的か慢性的かを判定する。
　判定部２２は、例えば渋滞習慣度が未算出のメッシュの数が多いほど、軌跡習慣度の重みを大きくする。特に渋滞発生確率の算出に集計台数が閾値以上となっているかどうかではなく、撮影画像データの画像処理によって検知された渋滞の先頭及び末尾の情報を使用した場合、渋滞の検出にはコストが大きくかかるため、渋滞習慣度が未算出のメッシュが多くなり、本開示の技術の効果が大きくなると考えられる。また、集計台数が閾値以上になっているかどうかで渋滞を判定したとしても、コネクテッドカーの普及初期から普及拡大中の時期の場合、必ずしも渋滞の発生を集計台数の情報から検知できるとは限らないので、渋滞習慣度が未算出のメッシュが出てくる可能性がある。
　通知部２３は、渋滞の発生を、予め定めた基準を満たすユーザにのみ通知する。例えば予め定めた基準は、渋滞の発生が慢性的な場合は、慢性的な渋滞が発生しているメッシュを含む予め定めたエリアが生活圏外のユーザである。
　次に、図７を参照して、本実施形態に係る渋滞判定装置１０の作用について説明する。
　図７は、本実施形態に係る渋滞判定プログラムによる渋滞判定処理の流れの一例を示すフローチャートである。渋滞判定プログラムによる渋滞判定の処理は、渋滞判定装置１０のＣＰＵ１１が、ＲＯＭ１２又はストレージ１４に記憶されている渋滞判定プログラムをＲＡＭ１３に書き込んで実行することにより、実現される。
　ステップＳ２００では、ＣＰＵ１１が、軌跡情報をサーバ３０の軌跡情報データベース３２から取得する。
　ステップＳ２０２では、ＣＰＵ１１が、ステップＳ２００で取得した軌跡情報に基づいて、軌跡習慣度を上記特許文献１に開示された手法を用いて算出する。すなわち、上記（１）式により軌跡習慣度Ｒ１（ｌ，ｔ）を算出する。ただし、ここではユーザｕを区別せず、全ユーザ共通で軌跡習慣度Ｒ１（ｌ，ｔ）を算出する。
　具体的には、軌跡情報に基づいて、時間帯ｔｋにおける全ユーザ横断のメッシュｌへの通過確率Ｐ（ｌ｜ｔｋ）を、メッシュｌ毎及び時間帯ｔｋ毎にそれぞれ算出する。
　また、時間帯ｔｋの全ユーザ横断の全メッシュｌに対する通過確率の平均μ（ｔｋ）を、時間帯ｔｋ毎に算出する。
　また、時間帯ｔｋの全ユーザ横断の全メッシュｌに対する通過確率の標準偏差σ（ｔｋ）を、時間帯ｔｋ毎に算出する。
　また、時間帯ｔｋにおける全ユーザ横断による全場所の通過回数の合計値Ｎ（ｕ，ｔｋ）を、時間帯ｔｋ毎に算出する。
　また、全ユーザ横断で時間帯ｔｋの全時間帯の中で最も多く通過を記録した時間帯ｔｋ’における全場所の通過回数の合計値
Figure JPOXMLDOC01-appb-I000009

を時間帯ｔｋ毎に算出する。
　そして、上記（１）式により軌跡習慣度Ｒ１（ｌ，ｔ）をメッシュｌに算出する。
　ステップＳ２０４では、ＣＰＵ１１が、ログデータベース３１Ａからメッシュｌ毎及び単位時間毎の集計台数Ｃ（ｌ，ｔ）又は渋滞発生の有無を取得する。
　ステップＳ２０６では、ＣＰＵ１１が、集計台数Ｃ（ｌ，ｔ）が閾値以上のメッシュｌ有るか否かを判定する。閾値は、集計台数Ｃ（ｌ，ｔ）が閾値以上の場合は、そのメッシュｌで渋滞が発生している可能性が高いと判断できる値に設定される。そして、集計台数Ｃ（ｌ，ｔ）が閾値以上のメッシュｌが有る場合はステップＳ２０８へ移行し、集計台数Ｃ（ｌ，ｔ）が閾値以上のメッシュｌが無い場合はステップＳ２０４へ移行する。また、撮影画像データの画像処理による渋滞検知結果を入力とする場合には、渋滞検知結果が１件以上有る場合はステップＳ２０８へ移行し、１件もない場合はステップＳ２０４へ移行する。
　ステップＳ２０８では、集計台数Ｃ（ｌ，ｔ）が閾値以上のメッシュｌに存在していたユーザｕ、すなわち集計台数Ｃ（ｌ，ｔ）が閾値以上のメッシュｌからログデータをサーバ３０に送信した自動車のユーザｕから撮影画像データを取得する。
　ステップＳ２１０では、ＣＰＵ１１が、図５のステップ１１２と同様に、ステップＳ２０８で取得した撮影画像データを解析して渋滞範囲を特定し、渋滞の先頭位置を特定する。
　ステップＳ２１２では、ＣＰＵ１１が、ログデータベース３１Ａに登録されたログデータに基づいて、上記（１）式により渋滞習慣度Ｒ２（ｌ，ｔ）をメッシュｌ毎に算出する。ただし、ここではユーザｕを区別せず、全ユーザ共通で渋滞習慣度Ｒ２（ｌ，ｔ）を算出する。この場合、Ｐ（ｌ｜ｔｋ）は、混雑発生確率を表す。渋滞習慣度Ｒ２（ｌ，ｔ）の算出は、ログデータベース３１Ａに登録されたログデータを用いる点を除いてステップＳ２０２の軌跡習慣度Ｒ１（ｌ，ｔ）の算出と同様であるので説明は省略する。
　ステップＳ２１４では、ステップＳ２０２で算出した軌跡習慣度Ｒ１（ｌ，ｔ）及びステップＳ２１２で算出した渋滞習慣度Ｒ２（ｌ，ｔ）に基づいて重み付き習慣度Ｒ３（ｌ，ｔ）を次式により算出する。
Ｒ３（ｌ，ｔ）＝Ｒ２（ｌ，ｔ）＋Ｒ１（ｌ，ｔ）×α　　　・・・（５）
　上記（５）式においてαは重みであり、次式で表される。
α＝ｃ×Ｍ１／ａ×ｂ　　　　・・・（６）
　ここで、ｃは、軌跡習慣度Ｒ１（ｌ，ｔ）と渋滞習慣度Ｒ２（ｌ，ｔ）との相関係数である。Ｍは、渋滞習慣度Ｒ２（ｌ，ｔ）が未算出のメッシュｌ、すなわち、閾値以上の台数が検知されていない、又は、画像による渋滞検知で渋滞が検出されておらず、渋滞習慣度Ｒ２（ｌ，ｔ）が算出されていないメッシュｌの数である。ａ、ｂは定数である。
　上記（６）式より、相関係数ｃが大きいほど、すなわち軌跡習慣度Ｒ１（ｌ，ｔ）と渋滞習慣度Ｒ２（ｌ，ｔ）との差が小さいほど重みαは大きな値となる。また、渋滞習慣度が未算出のメッシュｌの数Ｍが多いほど、重みαは大きな値となる。
　従って、重み付き習慣度Ｒ３（ｌ，ｔ）は、軌跡習慣度Ｒ１（ｌ，ｔ）と渋滞習慣度Ｒ２（ｌ，ｔ）との差が小さいほど、渋滞習慣度Ｒ２（ｌ，ｔ）と比べて軌跡習慣度Ｒ１（ｌ，ｔ）の影響が大きくなる。また、未検知のメッシュｌの数Ｍが多いほど、渋滞習慣度Ｒ２（ｌ，ｔ）と比べて軌跡習慣度Ｒ１（ｌ，ｔ）の影響が大きくなる。
　なお、ログデータの数が少ない場合は、重み付き習慣度Ｒ３（ｌ，ｔ）のばらつきが大きくなる傾向があるため、重み付き習慣度Ｒ３（ｌ，ｔ）を正規化してレベル１～１０等のようにレベル分けするようにしてもよい。
　また、渋滞習慣度Ｒ２（ｌ，ｔ）を算出したメッシュｌがある程度増加してきた場合は、定数ａを大きな値に設定することにより、渋滞習慣度Ｒ２（ｌ，ｔ）が未算出のメッシュｌの数Ｍの影響を抑えるようにしてもよい。すなわち、軌跡習慣度Ｒ１（ｌ，ｔ）の影響が小さくなるようにしてもよい。
　また、定数ｂについても、軌跡習慣度Ｒ１（ｌ，ｔ）と渋滞習慣度Ｒ２（ｌ，ｔ）との相関係数Ｃが小さい場合、ログデータの数が少なすぎる場合は、定数ｂを１未満の値に設定し、重みαが小さくなるようにしてもよい。すなわち、軌跡習慣度Ｒ１（ｌ，ｔ）の影響が小さくなるようにしてもよい。
　ステップＳ２１６では、ＣＰＵ１１が、慢性的な渋滞が発生しているメッシュｌが有るか否かを判定する。具体的には、ステップＳ２１４で算出した重み付き習慣度Ｒ３（ｌ，ｔ）が予め定めた閾値以上であるか否かを判定する。閾値は、重み付き習慣度Ｒ３（ｌ，ｔ）が閾値以上の場合は、そのメッシュｌ及び時刻ｔで発生している渋滞が慢性的である可能性が高いと判断できる値に設定される。
　そして、慢性的な渋滞が発生しているメッシュｌが有る場合、すなわち重み付き習慣度Ｒ３（ｌ，ｔ）が閾値以上のメッシュが有る場合は、ステップＳ２１７へ移行する。一方、慢性的な渋滞が発生しているメッシュｌが無い場合、すなわち、重み付き習慣度Ｒ３（ｌ，ｔ）が閾値以上のメッシュが無い場合は、ステップＳ２１８へ移行する。
　ステップＳ２１７では、ＣＰＵ１１が、ステップＳ２１０で特定した渋滞の先頭位置の撮影画像データ及び渋滞範囲を表す位置情報を、慢性的な渋滞が発生しているメッシュを含む予め定めたエリアが生活圏外であるユーザｕに送信することにより通知する。すなわち、慢性的な渋滞が発生しているメッシュを含むエリアが生活圏内であるユーザｕに対しては慢性的な渋滞の発生は通知しない。なお、予め定めたエリアは、慢性的な渋滞が発生しているメッシュを中心として半径数百メートル以内又は半径数キロメートル以内のエリア等とすることができるが、これに限られるものではない。
　ステップＳ２１８では、ＣＰＵ１１が、突発的な渋滞が発生していることを生活圏外のユーザ及び生活圏内の両方のユーザに通知する。
　慢性的な渋滞が発生しているメッシュを含む予め定めたエリアが生活圏内であるか否かは、例えば特許文献１記載の方法により算出した習慣度に基づいて判定してもよいし、位置情報の履歴に基づいて推定した自宅の位置から現在地までの距離に基づいて判定してもよい。
　このように、重み付き渋滞習慣度Ｒ３（ｌ，ｔ）に基づいて、発生した渋滞が慢性的か突発的かを判定し、慢性的であった場合には、渋滞が発生しているメッシュを含む予め定めたエリアが生活圏内のユーザには渋滞の発生を通知しない。これにより、不要な渋滞発生の通知を抑制することができる。一方、発生した渋滞が突発的だった場合は、ユーザが生活圏内か生活圏外かによらず、全ユーザに通知する。突発的な渋滞は生活圏内のユーザも認識しておらず、事故を誘発する可能性が高いためである。
　なお、本実施形態では、重み付き渋滞習慣度が閾値以上のメッシュが有る場合に、そのメッシュを含む予め定めたエリアを生活圏外とするユーザに慢性的な渋滞の発生を通知する場合について説明したが、算出した重み付き渋滞習慣度を他の処理に用いても良い。例えば自動車のルート探索処理において、目的地までのルートを決定する際のパラメータの１つとして重み付き渋滞習慣度を用いてもよい。
　また、算出した重み付き渋滞習慣度と、算出した日時と、メッシュＩＤと、を記録しておき、日時及びメッシュＩＤを入力すると、そのメッシュＩＤのメッシュで発生した渋滞が慢性的か突発的かを出力する処理に重み付き渋滞習慣度を用いても良い。
　なお、渋滞習慣度を算出する際に用いるログデータとしては、例えばレーン別でない片側全車線共通の渋滞情報を蓄積しているデータベースの情報を用いてもよい。また、渋滞のログデータだけでなく、新規に開始された位置情報記録サービスにおけるユーザの訪問傾向を調べたい時に、別の類似サービスにおける訪問傾向を外部情報として活用することも考えられる。
＜実施例＞
　開示の技術の実施例について説明する。
　なお、以下では、特許文献１に開示の習慣度の算出手法をＲＢＭ（Ｒｅｇｕｌａｒ　Ｂｅｈａｖｉｏｒ　Ｍｅａｓｕｒｅ）、第１実施形態における集計突発指標の算出手法を前述したようにＳＩＣＭ、第２実施形態における重み付き習慣度の算出手法をＳＲＢＭ（Ｓｍａｌｌ－ｓｔａｒｔ　Ｒｅｇｕｌａｒ　Ｂｅｈａｖｉｏｒ　Ｍｅａｓｕｒｅ）と称する。
（軌跡情報の概要）
　軌跡情報として、以下のタクシーのＧＰＳログデータを使用した。
期間：２０１７年１１月２７日から２０１８年１月３１日までの６６日間
台数：タクシー１０台分
総ログ数：２，７５７，００３
メッシュ数：４７，１４６
　なお、ＧＰＳログデータの緯度経度については、小数点以下４桁以降を丸めて小数点以下３桁までを有効桁数とした。メッシュは、縦横が約１１０ｍの正方形のメッシュとした。
　図８には、上記のＧＰＳログデータの時間帯の偏りを表すグラフを示した。横軸は時間を表し、縦軸はログ数を表している。また、図９には、上記のＧＰＳログデータの曜日の偏りを表すグラフを示した。横軸は曜日を表し、縦軸はログ数を表している。図８、９に示すように、時間帯及び曜日の何れにおいてもログ数の偏りは少なかった。
　また、図１０には、メッシュ毎のログデータの数を表すログ数のグラフを示した。図１０は、ログ数が多い順に各メッシュのログ数をプロットしたものである。図１０に示すように、上位１０メッシュに全体の９０％のＧＰＳログデータが集まっていることが分かった。
（ＲＢＭの妥当性評価）
　ＲＢＭは人間のチェックインログを想定した手法として考案されたものであるため、自動車が搭載するＧＰＳ装置によって取得された連続的なログデータへの適応が可能か、自動車の渋滞について、ＲＢＭが考慮する複数の時間軸に依存する習慣性があるか、について確認した。１０台分のＧＰＳログデータから、どの自動車のログデータであったかを区別せずに通過確率を算出した。本来、第２実施形態では集計台数が閾値以上となった場所を入力したり、撮影画像データの画像処理で検知された渋滞発生場所を入力したりするが、１０台分しかＧＰＳログデータがなかったこともあり、まずはＧＰＳログデータに基づきタクシーが各メッシュを通過したか否かによりＲＢＭによる習慣度を算出した。
　図１１には、タクシーのＧＰＳログデータに対してＲＢＭを適用した結果を示す。各メッシュにおける習慣度の平均値で分類した。タクシー会社の本拠地である東京都武蔵野市付近と都内に習慣度の高い場所が点在していること、都内から離れていくほど突発的な訪問を示す習慣度の低い場所が存在していることが確認できた。
　図１２には、習慣度が特に高かった場所、すなわち慢性的に通行された場所のみをプロットしたものを示す。駅や仮眠・待機場所と考えられる都内の公園等で慢性的な渋滞があったことが分かった。
　図１３には、ログ数は少ないが、習慣度が特に高かった場所の曜日及び時間帯の偏りを表すグラフを示した。メッシュＩＤであるＬｉｄ＝３６７４の場所（千歳船橋駅）は、金曜日の深夜のログ数が多く、曜日及び時間帯に偏りが多いことが分かる。
　Ｌｉｄ＝３８７３の場所（恵比寿公園）も金曜日の終電後及び月曜日の始発前の時間帯のログ数が多く、何れも電車が運行していない時間帯の顧客獲得を狙って走行するタクシー特有の傾向を表していると考えられる。
　このように、単なるログ数を考慮するだけではなく、ＲＢＭにより複数の時間軸を考慮した習慣度を算出することにより、必ずしもログ数は多くないものの、曜日や時間帯の偏りが大きい場所を特定できることが確認できた。
　また、ＧＰＳによる軌跡情報から渋滞が慢性的であるか突発的であるかを指標化するのにＲＢＭが有効であることが分かった。
（ＳＩＣＭの妥当性評価）
　タクシーのＧＰＳログデータを用いて、ＳＩＣＭの妥当性を確認した。
　本来は各メッシュの単位時間当たりの集計台数を入力として突発的な渋滞を判定するが、タクシー１０台分のＧＰＳログデータを用いてＳＩＣＭの妥当性を評価するにあたり、１０分毎のメッシュ内のＧＰＳログデータのログ数をＳＩＣＭの入力とした。
　渋滞が発生しているメッシュでは、そのメッシュに自動車が留まる時間が長くなり、定期的に取得するＧＰＳログデータのログ数が増加するため、簡易的にＳＩＣＭの妥当性を評価するためにＧＰＳログデータのログ数を用いて評価した。
　ＧＰＳログデータを１０分毎に集計した際の集計回数は９，２５８回であった。また、全メッシュでの延べ集計回数、すなわち集計突発指標の算出回数は１，０１６，０２４回であった。
　図１４には、ＳＩＣＭで算出した集計突発指標の分布を示した。図１４は、集計突発指標が高い順に全メッシュの集計突発指標をプロットしたものである。初回の集計では全メッシュの集計突発指標は０であるため、集計突発指標が丁度０となっている集計が多い。また、集計突発指標がプラスの値の場合、すなわち通常より集計台数が突発的に多くなっている場合もあれば、集計突発指標がマイナスの値の場合、すなわち通常より集計台数が突発的に少なくなっている場合もある。通常より集計台数が突発的に少ない場合よりも、通常より集計台数が突発的に多い場合の方が多いことが分かり、慢性的に渋滞が発生している場所で突発的に集計台数が減ることは少ないことが分かる。
　図１５には、集計突発指標が最も高かった３か所について、集計突発指標及びログ数の変遷をプロットした。Ｔｏｐ１（国際基督教大学（ＩＣＵ）付近１）は、ログ数が普段は多くない場所であり、急にログ数が５０以上となった時に集計突発指標が最大となったことが確認できた。また、その後もログ数が４０以上となったタイミングが２回あるが、ログ数が増大した３回目のタイミングでは、ログ数が増大した２回目のタイミングよりもログ数が多いにも関わらず、集計突発指標はそれほど大きくないことが分かる。突発的に集計突発指標が大きくなる結果が何回か出ると、集計突発指標が大きいことがそこまで珍しいことではなくなるため、ＳＩＣＭによる集計突発指標の算出結果は妥当と言える。
　同様に、Ｔｏｐ２（国際基督教大学（ＩＣＵ）付近２）、Ｔｏｐ３（初台駅付近）の場所についても、通常よりも集計台数が突発的に増加した際に集計突発指標が大きくなっていて、意図通りの結果が出ていることが確認できた。
　次に、静的な集計統計情報を用いて集計突発指標を算出した場合の計算コストの削減効果について説明する。なお、集計統計情報は、上記（３）式における集計台数の平均μ（ｔｋ，ｌ）、集計台数の標準偏差σ（ｔｋ，ｌ）、及び重みω（ｔｋ、ｌ）を含む情報である。
　６６日間のうち前半の３３日間のＧＰＳログデータを用いて集計統計情報を作成し、後半の３３日間については、作成した静的な集計統計情報を用いて集計突発指標を算出した場合の計算時間は１．９０秒であった。一方、６６日間全てにおいて毎回集計統計情報を更新した動的な集計統計情報を用いて集計突発指標を算出した場合の計算時間は６．３７秒であった。静的な集計統計情報を用いて集計突発指標を算出することにより、計算コストを抑えることができることを確認した。また、渋滞情報を高速にユーザに伝えるためには画像処理対象の撮影画像データを優先付けする処理自体も高速に実施する必要があるが、Ａｕｔｏ　Ｅｎｃｏｒｄｅｒなどのモデルを用いて異常値検出を行う場合に比べても高速に優先付けが実現できることが確認できた。
　図１６には、集計突発指標が１．０以上であった１６０箇所について、算出された集計突発指標を８段階にレベル分けして地図上にプロットしたものを示す。なお、同じメッシュで集計突発指標を複数回算出した場合はマークを重ねて表示している。図１６に示すように、車線数の多い道路の、特に交差点付近に集中していることが確認できた。これは渋滞が発生しやすい場所と合致している。
　図１７には、動的な集計統計情報を用いて集計突発指標をメッシュ毎に算出した場合において、集計突発指標が０より大きいメッシュを採用した場合と、集計突発指標が０以上のメッシュを採用した場合と、集計突発指標が－０．５より大きいメッシュを採用した場合と、の各々の場合における、実際に渋滞が発生していたメッシュに対する採用率及び計算コストの削減率を示した。
　なお、実際に渋滞が発生したメッシュの検出は、お台場付近のエリアにおいて人手で行い、実際に渋滞が発生している１２１個のメッシュを検出した。
　集計突発指標が０より大きいメッシュを採用した場合、計算コストのお台場における削減率は８２．２％であり、突発的な渋滞があったメッシュについては１００％採用されていることが分かる。
　また、集計突発指標が０以上のメッシュを採用した場合、集計突発指標が－０．５以上のメッシュを採用した場合の何れにおいても、計算コストの削減率は少し減るものの、突発的な渋滞があったメッシュの全てが採用されている。
　一方、撮影画像データの取得及び解析の処理対象から外したい慢性的な渋滞のメッシュの採用率は低くなっており、突発的な渋滞のみを撮影画像データの取得及び解析の対象にするという目的に合致した結果が得られていることが確認できた。なお、人手で検知した渋滞の渋滞習慣度についてはＲＢＭを用いて算出し、渋滞習慣度の値が上位５０％を慢性的な渋滞、下位５０％を突発的な渋滞とした。
　図１８には、６６日間のうち前半のＧＰＳログデータのみを用いて算出した静的な集計統計情報を用いた場合の結果を示した。図１８の結果は、静的な集計統計情報を用いたことだけが図１７の場合と異なる。
　図１８に示すように、集計突発指標が０より大きいメッシュだけを採用すると、突発的な渋滞のメッシュの採用率は８５．７％に下がったが、集計突発指標が０以上のメッシュを採用すれば、突発的な渋滞のメッシュの１００％が採用され、計算コスト削減率はお台場で３７．７％、全地域で６５．２％であった。
　このように、静的な集計統計情報を用いて計算コストを抑えた場合でも、突発的な渋滞の判定の精度はそれほど低下しないことが確認できた。
　図１９には、後半３３日間のＧＰＳログデータを用いて算出した集計突発指標が閾値以上のメッシュについてＲＢＭを用いて渋滞習慣度を算出した結果を示す。渋滞習慣度は８段階にレベル分けした。なお、丸で囲まれた４か所のメッシュについては集計突発指標が閾値未満であるため渋滞習慣度を算出する際に除外されたが、これらはＲＢＭによる渋滞習慣度が高く慢性的な渋滞であったため、集計突発指標が閾値以上のメッシュについてのみ撮影画像データの取得及び解析を行うという目的に合致することが確認できた。
（ＳＲＢＭの妥当性評価）
　図２０に、お台場において検知された１５個の渋滞に対して、渋滞を１回検出する毎にＳＲＢＭにより算出した重み付き習慣度と、１５個の渋滞全てを検知した後にＲＢＭにより算出した渋滞習慣度と、の相関係数を全メッシュについて算出した結果を示す。
　なお、重み付き習慣度を算出する際の定数ａは、渋滞検知回数が少ないため１とした。また、定数ｂは、０～３の間で０．５刻みに変化させた。定数ｂが０の場合は、軌跡習慣度が考慮されないので、ＲＢＭにより渋滞習慣度を算出した場合と同じである。
　図２０に示すように、定数ｂを０より大きい値の何れに設定した場合も、定数ｂを０とした場合、すなわち軌跡習慣度を考慮しなかった場合に比べて、最初の４個の渋滞が検知されるまでの間で高い相関があることが確認できた。定数ｂの値を大きくし過ぎると、後半でＲＢＭによる渋滞習慣度との相関が若干低くなるため、定数ｂは０．５が最も適切であると考えられる。
　図２１には、重み付き渋滞習慣度を算出した際の重みαの変化を示す。図２１に示すように、渋滞検知回数が少ない初期の段階において軌跡習慣度の影響が大きくなるように重みが大きくなっていることが確認できた。
　ＳＲＢＭを用いて重み付き渋滞習慣度を算出することにより、渋滞検知回数が少ない初期の段階においても、渋滞検知結果が十分に得られた後にＲＢＭで算出した渋滞習慣度に近い値が得られることが確認できた。
　上記実施形態は、本開示の構成例を例示的に説明するものに過ぎない。本開示は上記の具体的な形態には限定されることはなく、その技術的思想の範囲内で種々の変形が可能である。
　例えば、上記実施形態では、自動車及び渋滞を例に説明したが、これに限定されるものではない。例えば、自動車に代えて人間を、渋滞に代えて人の密度を用いてもよい。このように構成することで、例えば突発的に人の密度が高くなっている領域や人の密度が低くなっている領域を所定の条件を満たすユーザに通知することで、例えば人の密度が低いタイミングで外出をするといった意思決定の助けになることが想定される。
　密度が高くなる画像は、例えばスマートフォンに代表されるモバイルデバイスで撮影された画像を使ってもいいし、該当する位置・時間にＳＮＳに投稿された画像を用いてもよい。人の密度を取得するために前述した手段以外にモバイル空間統計などの情報を用いてもよい。
　なお、上記実施形態でＣＰＵがソフトウェア（プログラム）を読み込んで実行した渋滞判定処理を、ＣＰＵ以外の各種のプロセッサが実行してもよい。この場合のプロセッサとしては、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）等の製造後に回路構成を変更可能なＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ　Ｌｏｇｉｃ　Ｄｅｖｉｃｅ）、及びＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）等の特定の処理を実行させるために専用に設計された回路構成を有するプロセッサである専用電気回路等が例示される。また、渋滞判定処理を、これらの各種のプロセッサのうちの１つで実行してもよいし、同種又は異種の２つ以上のプロセッサの組み合わせ（例えば、複数のＦＰＧＡ、及びＣＰＵとＦＰＧＡとの組み合わせ等）で実行してもよい。また、これらの各種のプロセッサのハードウェア的な構造は、より具体的には、半導体素子等の回路素子を組み合わせた電気回路である。
　また、上記実施形態では、渋滞判定プログラムがストレージに予め記憶（インストール）されている態様を説明したが、これに限定されない。プログラムは、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ　Ｄｉｓｋ　Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、ＤＶＤ－ＲＯＭ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｋ　Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、及びＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）メモリ等の非一時的（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ）記憶媒体に記憶された形態で提供されてもよい。また、プログラムは、ネットワークを介して外部装置からダウンロードされる形態としてもよい。
　以上の実施形態に関し、更に以下の付記を開示する。
（付記項１）
　メモリと、
　前記メモリに接続された少なくとも１つのプロセッサと、
　を含み、
　前記プロセッサは、
　渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、
　取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する、
　ように構成されている渋滞判定装置。
（付記項２）
　渋滞判定処理を実行するようにコンピュータによって実行可能なプログラムを記憶した非一時的記憶媒体であって、
　前記渋滞判定処理は、
　渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、
　取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する、
　非一時的記憶媒体。
１０   渋滞判定装置
２１   取得部
２２   判定部
２３   通知部
３０   サーバ
３１、３１Ａ  ログデータベース
３２   軌跡情報データベース

Claims (8)

  1. 　取得部及び判定部を備えた渋滞判定装置における渋滞判定方法であって、
    　前記取得部が、渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、
    　前記判定部が、取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する、
    　渋滞判定方法。
  2. 　前記判定部が、前記メッシュ毎及び前記単位時間毎の前記集計台数に基づいて集計突発指標を算出し、算出した前記集計突発指標に基づいて前記渋滞の発生が突発的か否かを判定する、
    　請求項１記載の渋滞判定方法。
  3. 　前記取得部が、自動車の軌跡情報を更に取得し、
    　前記判定部が、前記メッシュ毎及び前記単位時間毎に前記集計台数に基づいて算出した混雑発生確率に基づいて渋滞習慣度を算出し、前記軌跡情報に基づいて、通過確率に基づく軌跡習慣度を算出し、前記渋滞習慣度、前記軌跡習慣度、及び前記軌跡習慣度の重みに基づいて重み付き渋滞習慣度を算出し、算出した前記重み付き渋滞習慣度に基づいて前記渋滞の発生が突発的か慢性的かを判定する、
    　請求項１記載の渋滞判定方法。
  4. 　前記判定部が、前記渋滞習慣度が未算出の前記メッシュの数が多いほど、前記軌跡習慣度の重みを大きくする、
    　請求項３記載の渋滞判定方法。
  5. 　前記渋滞判定装置は通知部を備え、
    　前記通知部が、前記渋滞の発生を、予め定めた基準を満たすユーザにのみ通知する、
    　請求項３又は請求項４記載の渋滞判定方法。
  6. 　前記予め定めた基準を満たすユーザは、渋滞の発生が慢性的な場合は、前記慢性的な渋滞が発生している前記メッシュを含む予め定めたエリアが生活圏外のユーザである、
    　請求項５記載の渋滞判定方法。
  7. 　渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得する取得部と、
    　取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する判定部と、
    　を備えた渋滞判定装置。
  8. 　渋滞の判定対象領域を仮想的に分割したメッシュ毎及び単位時間毎に、自動車の集計台数を取得し、
    　取得した前記メッシュ毎及び単位時間毎の前記集計台数に基づいて、渋滞の発生が突発的か否かを前記メッシュ毎に判定する
    　ことをコンピュータに実行させるための渋滞判定プログラム。
PCT/JP2020/042760 2020-11-17 2020-11-17 渋滞判定方法、渋滞判定装置、及び渋滞判定プログラム WO2022107193A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2022563264A JP7485080B2 (ja) 2020-11-17 2020-11-17 渋滞判定方法、渋滞判定装置、及び渋滞判定プログラム
US18/036,865 US20230410644A1 (en) 2020-11-17 2020-11-17 Congestion judgment method, congestion judgment device, and congestion judgment program
PCT/JP2020/042760 WO2022107193A1 (ja) 2020-11-17 2020-11-17 渋滞判定方法、渋滞判定装置、及び渋滞判定プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/042760 WO2022107193A1 (ja) 2020-11-17 2020-11-17 渋滞判定方法、渋滞判定装置、及び渋滞判定プログラム

Publications (1)

Publication Number Publication Date
WO2022107193A1 true WO2022107193A1 (ja) 2022-05-27

Family

ID=81708523

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/042760 WO2022107193A1 (ja) 2020-11-17 2020-11-17 渋滞判定方法、渋滞判定装置、及び渋滞判定プログラム

Country Status (3)

Country Link
US (1) US20230410644A1 (ja)
JP (1) JP7485080B2 (ja)
WO (1) WO2022107193A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016224621A (ja) * 2015-05-28 2016-12-28 富士通株式会社 走行軌跡の解析支援プログラム、装置、及び方法
JP2018055208A (ja) * 2016-09-27 2018-04-05 本田技研工業株式会社 交通障害リスク表示装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016224621A (ja) * 2015-05-28 2016-12-28 富士通株式会社 走行軌跡の解析支援プログラム、装置、及び方法
JP2018055208A (ja) * 2016-09-27 2018-04-05 本田技研工業株式会社 交通障害リスク表示装置

Also Published As

Publication number Publication date
US20230410644A1 (en) 2023-12-21
JP7485080B2 (ja) 2024-05-16
JPWO2022107193A1 (ja) 2022-05-27

Similar Documents

Publication Publication Date Title
ES2373336T3 (es) Evaluación de condiciones de tráfico de carretera utilizando datos de fuentes móviles de datos.
US10490078B1 (en) Technology for providing real-time route safety and risk feedback
US7706965B2 (en) Rectifying erroneous road traffic sensor data
Abdel-Aty et al. Crash risk assessment using intelligent transportation systems data and real-time intervention strategies to improve safety on freeways
Ahsani et al. Quantitative analysis of probe data characteristics: Coverage, speed bias and congestion detection precision
JP5491104B2 (ja) 交通状況解析装置、交通状況解析プログラム及び交通状況解析方法
US20140340242A1 (en) Method for Providing Parking Information on Free Parking Spaces
US11508022B1 (en) Method and apparatus for utilizing estimated patrol properties and historic patrol records
JP2023184590A (ja) 情報処理装置
Vanajakshi Estimation and prediction of travel time from loop detector data for intelligent transportation systems applications
Chepuri et al. Travel time reliability analysis on selected bus route of mysore using GPS data
JP4240309B2 (ja) 旅行時間提供方法、装置及びプログラム
WO2022107193A1 (ja) 渋滞判定方法、渋滞判定装置、及び渋滞判定プログラム
Pirc et al. Using the robust statistics for travel time estimation on highways
Sharma et al. Performance-based operations assessment of adaptive control implementation in Des Moines, Iowa
JP3933127B2 (ja) 旅行時間予測方法、装置及びプログラム
US11781883B1 (en) Method and apparatus for utilizing estimated patrol properties and historic patrol records
Wang et al. An empirical evaluation of the loop detector method for travel time delay estimation
Samal et al. Speedpro: A predictive multi-model approach for urban traffic speed estimation
Hayashi et al. Prioritization of Lane-based Traffic Jam Detection for Automotive Navigation System utilizing Suddenness Index Calculation Method for Aggregated Values
Hayashi et al. Prioritization of Lane-Specific Traffic Jam Detection for Automotive Navigation Framework Utilizing Suddenness Index and Automatic Threshold Determination
Abedini A Machine-Learning Framework for Clustering and Calibration of Roadway Performance Models with Application in the Large-Scale Traffic Assignment
Harsha et al. Impact of Side Friction on Travel Time Reliability of Urban Public Transit
Zhang Exploring the Potentials of Using Crowdsourced Waze Data in Traffic Management: Characteristics and Reliability
Murrugarra et al. The effect of consistency in estimating link travel times: A data fusion approach

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20962357

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022563264

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 18036865

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20962357

Country of ref document: EP

Kind code of ref document: A1