TMS

Dynamic traffic signal based on traffic density

The problem

Traffic signals, almost everywhere, are what we call a static traffic signal. A predefined timings are set for each of the four sides of a cross-road, and that's how traffic is regulated. The signal timings don't take current traffic density into account. So whatever amount of traffic there is it will still show same timings. This wastes time for the side of road where traffic density is more.

The solution

I propose a system where the signal timings are generated dynamically based on the current traffic conditions(density) and alloted the timings based on that criteria only.

In short, roads with higher traffic density will get more time and high priority, while roads with less traffic densiity will get less time and less priority. Which will result in fair signal timings for everyone. This approach will help clear traffic faster and prevent traffic jams.

The system

Its a Server which will take co-ordinates(Latitude & longitude) of a cross-road. Use those co-ordinates to make a request to the Google Map's server for getting real time traffic data. These traffic density values are processed through an algorithm and dynamic timigs are generated. These timings are sent back to the signal which made the request.

The challenges

Q. First of all, where to get real-time traffic data which is trustworthy and accurate? Ans: Google Maps! But there is a catch. Google doesn't give the traffic data. They provide no API for that.

Q. Then how to get it? Ans: I used a clever technique. As mentioned above Google doesn't give traffic data but they can answer this question, "How much time will it take to go from point A to point B with current traffic conditions?". Imagine that there is a cross-road, and for each of the road there are (imaginary)gates on each side of road at a fixed distance of 200 meters, which will trap the traffic inside. Now our server requests Google's server how much time will it take to go from that imaginary gate to the cross-road. Google's API will respond with the time it takes to travel that 200 meter distance which ultimately takes current traffic conditions into account. These timings will be different for each side and will be based on traffic density of each side of the cross-road. And voila you have your traffic density values.

Algorithm

Once our server gets the traffic density(or traffic timings) from Google, we pass it to our algorith which outputs traffic signal timings.

The algorithm takes three predefined values,

xMid - initial traffic timing (eg. 25 seconds)
xLow - minimum traffic timing (eg. 15 seconds)
xHigh - highest traffic timing (eg. 35 seconds)

Let's assume that the Google responds traffic timings for a cross-road as North-200, East-100, South-50, West-150 for each side of cross-road.

We find mean of these values. Which in this case is 125
Subtract the traffic timings from the mean value. (Find deviation)
Divide by 10 (because its the factor used by google to convert timings.)
Finally add those values to the 'xMid' which is in this case is set to '25'. | Side | Density | Density - Mean | Divide by 10 | Add to xMid | |---|---|---|---|---| | North | 200 | 200 - 125 = 75 | 7.5 | 32.5 | | East | 100 | 100 - 125 = 100 | 10 | 35 | | South | 50 |50 - 125 = -75 | -7.5 | 17.5 | | West | 150 | 150 - 125 = 25 | 2.5 | 27.5 |

The values in the last column are the traffic signal timings generated based on actual traffic density! Note: The xLow & xHigh are taken to ensure that if the timings exceeds certain limit these will be used. For ex. for a certain side the timings alloted are less than xLow, xLow timing will be used instead. This is done to ensure that every side gets atleast some time to clear the traffic.