The schedule of electric trains is what started Tutu.ru in 2003. Now I can proudly say that our schedule sometimes turns out to be more accurate than the schedule of the carrier or Russian Railways - this is because we very quickly react to the appeals of passengers and have heuristics to compare different data sources and their corrections.
Old paper timetable St. Petersburg - OredezhIt all started like this. Initially, the Internet did not have a regularly updated schedule of trains. More precisely, it was "paper". Simply saving the schedule from the station or publishing what is usually placed in various brochures is useless. A large number of temporary changes are made to the schedule. We set a goal - to make a regularly updated schedule.
And although at first the whole schedule was handled by one person, it soon became clear that we needed a team. Gradually, we selected people who are interested in this topic.
At first it was difficult. When Tutu.ru was just born, we had a single railway company in our country, the only carrier. We made requests to give information, but it was not possible to agree for a long time. More precisely, we were told that here lies an open timetable for everyone, take it. But we will not do anything for you. This is a completely understandable position, because we wanted to unload, which obviously had to be expensive to finish.
As a result, the team began to travel around the stations and photograph changes in schedules. Almost every morning they started with a detour of 7–9 stations. So managed to cover Moscow. But not all were the necessary changes. On departure from Moscow - please, but now to Moscow - no longer. By intermediate stations, it turned out that the accuracy fell. We have introduced a system for collecting messages from passengers. “Tell us to help other passengers” - this occasion worked perfectly, and the passenger who had already encountered a problem reported it. This allowed using a number of mathematical models to understand what was happening and rebuild the schedule or make the necessary calls.
Then Railways began to actively develop in terms of IT. A lot of very cool things were done in principle, and among other things they screwed up an internal resource with a schedule. It was not available to the general public, but the data were uploaded to a special terminal at the station.
Then to our detours we added scrolling through the entire interface of the terminal in search of a timetable. It took hours to rewrite schedules when there were major changes.
The data in the terminal was sometimes suspicious, so it was often necessary to drive around the stations and watch the trains go in fact. For example, once an electric train Elektrogorsk - Khrapunovo was indicated in the terminal, such a route is possible only with a change of cab, for which there was no time. When checking, it was found out that in fact the train goes with passengers only to Yoshino (and then - without passengers to the park of Khrapunovo station). Repeated checks made it possible to find out that in such situations the train always did not make one stop to the station indicated in the schedule.
Gradually, other patterns became clear from the observations, and we began to take them into account and display them with us.
Then came the suburban passenger companies (for example, the largest CPPK). But for suburban companies, it was already extremely important that passengers receive maximum information about cancellations and other situations, otherwise complaints would fall down. Perhaps that is why it was much easier to arrange information.
Inside the structure of the Russian Railways, it happens like this: the experts draw up a train schedule and, if something changes in the schedule, they send a telegram to the subunits and stations. Previously, these were direct telegrams, and now they are either telegrams or e-mail.
Finally, after a series of meetings and negotiations, we connected to the central database of suburban timetables, as well as to data on the actual train traffic (both suburban and long-distance trains). And this is very cool, because we are still entering information, for example, from the CPPK, but it is possible to verify it with the second source - the data of the Russian Railways on the movement of trains. It happens, and there and there errors are found - it is impossible to solve it by one source.
With a different nature of the error weight is given to different sources. One of the most common situations is that an electric train is canceled in one direction. If this is so, then she cannot return to the other side. We often calculate this: there is a train in the schedule, but there is no composition for it in fact. But this is not always the right model: sometimes a carrier sends a train without passengers to a place so that the route can be worked in the opposite direction. But the absence of a train in the schedule, despite the fact that it exists, is a less significant error than vice versa: objectively, the probability of a false positive response is about 4%. Usually the train will not be there. Thanks to the internal work of the carriers and Russian Railways, now such situations with cancellations happen less and less - this is also largely due to their IT.
Or here are typos in time and number. Using them is also quite simple to understand the correct source: if we see a shift by an hour or 10 minutes, then we know that with high probability this is a typo in the Russian Railways' schedule. Graphists draw a graph, not a timetable: there is a 10-minute step along the abscissa, and when transferred from a graph to a telegram, it is easy to seal up for 10 minutes.
Here is another example. There are two trains Konakovo - Moscow and back. And we know that there is a single track with a crossing in Konakovo Mkhe and the train stops waiting. That is, it just stops, there is no platform on one of the paths. This means that one of the trains will not disembark passengers, but this stop could have been entered into the base. When we saw it, we wrote to the carrier. The answer came: let's figure it out. As a result, an update was sent: it will stop from Moscow for a landing-landing, not to Moscow.
If this is a non-template error, then we go to the station to check. Yes, yes, we still drive, it happens. Just a couple of weeks ago, we had a case in Reutovo - it wasn’t clear that with the travel work, whether or not there would be a train, the workers didn’t respond. And it depended on which platform the lineup would go from. We drove, watched the way the trains would go. Went wrong there, as was the data from the carrier, respectively, made changes to the model.
Naturally, we are also mistaken. For example, the module of the analysis of the actual movement signals if the train goes ahead. The case in Podolsk - there was a situation that we identified while watching our mistake. It turned out there were no mistakes: there were technical problems, and Shcherbinka could not go further. The station also could not accept trains. Accordingly, the railway sent trains (which were supposed to go to Podolsk, stand there and then back to Moscow) immediately to Moscow, ahead of schedule to the first station. That is, where you can put the train for a long time, that is, to the Kursk railway station. Our system noticed this and promptly reflected it on the site.
Well, here is the result of our work:
And so the changes are displayed:
Most likely, these signs are familiar to you as well as about half of Moscow residents: if you looked at the schedule of the electric train on the Runet, then you most likely fell on ours.