March 4, 2013 at 09:08Public transport in a mobile phone
Now in many cities there are services that show the movement of public transport on the map. Our Barrow is no exception. Here is just one problem: to see where the buses go, you need a computer or at least a powerful smartphone that can download the entire map. If you travel a lot around the city, then the maximum that you have at hand is a regular phone on which there can be no talk of any card.
Therefore, last year we created a service that turns information about the movement of buses into a regular text format, which is quite accessible for any average phone or smartphone. Under the cut, I’ll talk about the main stages of development.
It all starts with a dream. Many (including myself) would like not to waste their time at the stops, peering out their favorite bus. Especially in 30 degree frost. Especially when two of the five buses on the route suddenly (!!) broke down.
It would be nice at that moment to look at the phone where your bus is traveling. Perhaps not art about um wait and easier to drive with a transfer? Or, on the contrary, do not jump into the first bus you get, but wait a little, but leave for the one that will drive as needed. Or (aerobatics) to plan the way out of the house so that you do not stand at the stop at all.
Of course, in our city there is a map on which buses ride in real time. But the attempts to open it in my (rather old) smartphone ended in nothing - he does not pull it. Then a reasonable thought occurred to me - what if we convert the data from the card into plain text? Something like this:
b. Solnechny -> 1st microdistrict
X 537 EU: KZKT -> --- Deli Sunday
1st microdistrict -> b. Solnechny
X 446 KE: ATS No. 6> ---- 5th microdistrict
on the final
X 442 KE: 1st microdistrict final
After all, all that we, in fact, need to know is the direction of the bus, between which stops each is located, and, perhaps, the license plate is still useful. It turns out that there is not much information - any phone will pull it. Naturally, the volume of mobile traffic is also an important factor - in this case, it is also minimal.
Thus, we need a service that would be able to turn the position of buses on the map into text.
To develop the algorithm, of course, we need the initial data: stops (coordinates, names) and the routes themselves (coordinates of all segments). Connections of stops with routes, segments with driving directions, etc. were made. All put in MySQL tables.
In the beta version, the algorithm was the simplest: take the geo-point corresponding to the bus, find the sql query to which of the route segments it is closest to. Further along the segment, we restore the stops between which the bus is traveling, and the direction of its movement. The idea is good, but practice has shown that it works only for cubic buses in a vacuum. In reality, buses begin to "jump" from one direction to the opposite, and vice versa. This is connected, as you might guess, with real road traffic - detours, intersections, U-turns and the like.
After about a month, the algorithm was finalized. We noticed that GPS trackers, in addition to coordinates, also give the current direction of movement (azimuth). Roughly speaking, azimuth is the angle between the north direction and the arrow characterizing the location of the bus. If we add this information to our first algorithm, then it will turn out much better. Indeed, even taking into account all the "wobbles" of the bus, its azimuth cannot change by more than 50-60 degrees from the actual direction of movement. Now we can quite accurately determine where and where each bus goes.
Determination of the azimuth of the bus:
Naturally, we could not help but verify the accuracy of our algorithm. Generally speaking, for a perfect check, we would have to ride the buses, and then look on the phone right or not, the direction is determined. Therefore, we went a little indirect way.
Suppose that two people, after a short period of time, made one request for the same route. Obviously, in such a short space, not a single bus will have time to change direction in the opposite direction (we exclude those that are on the final). If our algorithm shows that one of the buses suddenly changed direction, then this is a calculation error.
Based on this logic, we made a script that went through all the accumulated data. Data pairs were taken that were separated by no more than 2 minutes. On different routes of such pairs it turned out from three hundred to several thousand. The calculated accuracy (number of errors / total number of pairs) turned out to be pretty good - 94-98%. As you can see, the algorithm sometimes still crashes, but for the current level it is quite enough. In addition, we recommend users to make 2-3 requests to exclude such anomalies.
In terms of interface, the recommendations are pretty typical. After some time, we transferred everything to twitter botstrap to be readable on any device - from the simplest phones to powerful tablets.
The route number is driven directly into the address bar, or you can select the link on the page where all the routes are indicated in a row (it’s more convenient for someone). On the page itself, only the update buttons. Nothing extra.
Interface (viewing on the desktop):
In addition, an ICQ bot operates that provides similar answers. It is enough to send him the number of the route of interest.
Currently, the attendance of the service is 100-150 people per day, each of which makes 6-8 requests. Perhaps, for some, these figures will seem small, but they are achieved without any investment in advertising. In addition, many points still require a “file-tuning” to make the service as useful to people as possible. In the first place we put quality, not traffic.
On the tastiest thing in the end ...
Now, "mobile buses" formed the basis of the diploma that one of our students makes. The essence of the diploma is quite interesting: according to information on bus traffic, calculate traffic jams in the city, and based on traffic jams, give recommendations on which of the routes is best to get from point A to point B. It seems to me that this is extremely important at the present time, and not only to passengers, but also to motorists, and to all those who are heavily dependent on traffic conditions (taxis, food delivery, company transport, etc.). Closer to May, we’ll see what we get - we’ll try to unsubscribe at the hub
Morning traffic jams in Kurgan (February 14 data):
Well, of course, we are open for discussionif you want to implement something similar in your city. Stop wasting your time at the stops, let's better spend it on something more useful! :-)
PS Frequently asked question
- Why not make an android application?
- It’s possible to make an application, but this is secondary. The main task we are solving is to learn how to convert geodata to text format. As soon as we learn how to do this, the format for outputting information will already become a matter of technology. It is possible through the browser, it is possible through the ICQ bot, it is possible through the jabber, it is possible through the application ...
Therefore, last year we created a service that turns information about the movement of buses into a regular text format, which is quite accessible for any average phone or smartphone. Under the cut, I’ll talk about the main stages of development.
Dream
It all starts with a dream. Many (including myself) would like not to waste their time at the stops, peering out their favorite bus. Especially in 30 degree frost. Especially when two of the five buses on the route suddenly (!!) broke down.
It would be nice at that moment to look at the phone where your bus is traveling. Perhaps not art about um wait and easier to drive with a transfer? Or, on the contrary, do not jump into the first bus you get, but wait a little, but leave for the one that will drive as needed. Or (aerobatics) to plan the way out of the house so that you do not stand at the stop at all.
Action plan
Of course, in our city there is a map on which buses ride in real time. But the attempts to open it in my (rather old) smartphone ended in nothing - he does not pull it. Then a reasonable thought occurred to me - what if we convert the data from the card into plain text? Something like this:
b. Solnechny -> 1st microdistrict
X 537 EU: KZKT -> --- Deli Sunday
1st microdistrict -> b. Solnechny
X 446 KE: ATS No. 6> ---- 5th microdistrict
on the final
X 442 KE: 1st microdistrict final
After all, all that we, in fact, need to know is the direction of the bus, between which stops each is located, and, perhaps, the license plate is still useful. It turns out that there is not much information - any phone will pull it. Naturally, the volume of mobile traffic is also an important factor - in this case, it is also minimal.
Thus, we need a service that would be able to turn the position of buses on the map into text.
Algorithms
To develop the algorithm, of course, we need the initial data: stops (coordinates, names) and the routes themselves (coordinates of all segments). Connections of stops with routes, segments with driving directions, etc. were made. All put in MySQL tables.
In the beta version, the algorithm was the simplest: take the geo-point corresponding to the bus, find the sql query to which of the route segments it is closest to. Further along the segment, we restore the stops between which the bus is traveling, and the direction of its movement. The idea is good, but practice has shown that it works only for cubic buses in a vacuum. In reality, buses begin to "jump" from one direction to the opposite, and vice versa. This is connected, as you might guess, with real road traffic - detours, intersections, U-turns and the like.
After about a month, the algorithm was finalized. We noticed that GPS trackers, in addition to coordinates, also give the current direction of movement (azimuth). Roughly speaking, azimuth is the angle between the north direction and the arrow characterizing the location of the bus. If we add this information to our first algorithm, then it will turn out much better. Indeed, even taking into account all the "wobbles" of the bus, its azimuth cannot change by more than 50-60 degrees from the actual direction of movement. Now we can quite accurately determine where and where each bus goes.
Determination of the azimuth of the bus:
Check accuracy
Naturally, we could not help but verify the accuracy of our algorithm. Generally speaking, for a perfect check, we would have to ride the buses, and then look on the phone right or not, the direction is determined. Therefore, we went a little indirect way.
Suppose that two people, after a short period of time, made one request for the same route. Obviously, in such a short space, not a single bus will have time to change direction in the opposite direction (we exclude those that are on the final). If our algorithm shows that one of the buses suddenly changed direction, then this is a calculation error.
Based on this logic, we made a script that went through all the accumulated data. Data pairs were taken that were separated by no more than 2 minutes. On different routes of such pairs it turned out from three hundred to several thousand. The calculated accuracy (number of errors / total number of pairs) turned out to be pretty good - 94-98%. As you can see, the algorithm sometimes still crashes, but for the current level it is quite enough. In addition, we recommend users to make 2-3 requests to exclude such anomalies.
Interface
In terms of interface, the recommendations are pretty typical. After some time, we transferred everything to twitter botstrap to be readable on any device - from the simplest phones to powerful tablets.
The route number is driven directly into the address bar, or you can select the link on the page where all the routes are indicated in a row (it’s more convenient for someone). On the page itself, only the update buttons. Nothing extra.
Interface (viewing on the desktop):
In addition, an ICQ bot operates that provides similar answers. It is enough to send him the number of the route of interest.
Statistics
Currently, the attendance of the service is 100-150 people per day, each of which makes 6-8 requests. Perhaps, for some, these figures will seem small, but they are achieved without any investment in advertising. In addition, many points still require a “file-tuning” to make the service as useful to people as possible. In the first place we put quality, not traffic.
Development plan
On the tastiest thing in the end ...
Now, "mobile buses" formed the basis of the diploma that one of our students makes. The essence of the diploma is quite interesting: according to information on bus traffic, calculate traffic jams in the city, and based on traffic jams, give recommendations on which of the routes is best to get from point A to point B. It seems to me that this is extremely important at the present time, and not only to passengers, but also to motorists, and to all those who are heavily dependent on traffic conditions (taxis, food delivery, company transport, etc.). Closer to May, we’ll see what we get - we’ll try to unsubscribe at the hub
Morning traffic jams in Kurgan (February 14 data):
Well, of course, we are open for discussionif you want to implement something similar in your city. Stop wasting your time at the stops, let's better spend it on something more useful! :-)
PS Frequently asked question
- Why not make an android application?
- It’s possible to make an application, but this is secondary. The main task we are solving is to learn how to convert geodata to text format. As soon as we learn how to do this, the format for outputting information will already become a matter of technology. It is possible through the browser, it is possible through the ICQ bot, it is possible through the jabber, it is possible through the application ...