Расписание электричек — это то, с чего в 2003 году начинался Туту.ру. Сейчас я с гордостью могу сказать, что наше расписание иногда оказывается более точным, чем расписание перевозчика или РЖД, — это потому что мы очень быстро реагируем на обращения пассажиров и имеем эвристики для сравнения разных источников данных и их взаимокоррекций.
Старое бумажное расписание СПб — Оредеж
Началось всё так. Изначально в Интернете не было регулярно обновляемого расписания электричек. Точнее, было «бумажное». Просто сохранить расписание с вокзала или опубликовать то, что обычно размещают в разных брошюрках, — это бесполезно. В расписание вносится большое число временных изменений. Мы поставили цель — сделать регулярно обновляемое расписание.
И хотя вначале всем расписанием занимался один человек, вскоре стало понятно, что нужна команда. Постепенно мы подбирали людей, кому эта тема интересна.
Поначалу было сложно. Когда Туту.ру только рождался, у нас в стране была единая железнодорожная компания, единственный перевозчик. Мы обращались с просьбами давать информацию, но договориться долго не удавалось. Точнее, нам говорили, что вот тут лежит открытое расписание для всех, его берите. Но для вас специально ничего делать не будем. Это вполне понятная позиция, потому что мы хотели выгрузки, которые явно надо было задорого доделывать.
В результате команда стала ездить по вокзалам и фотографировать изменения в расписаниях. Почти каждое утро начинали с объезда 7–9 вокзалов. Так удавалось покрыть Москву. Но далеко не везде были нужные изменения. По отправлению из Москвы — пожалуйста, но вот на Москву — уже нет. По промежуточным станциям получалось, что точность падала. Мы ввели систему сбора сообщений от пассажиров. «Сообщите нам, чтобы помочь другим пассажирам» — этот повод отлично работал, и пассажир, который уже столкнулся с проблемой, сообщал о ней. Это позволяло с помощью ряда математических моделей понять, что происходит, и перестроить расписание либо сделать нужные звонки.
Потом РЖД стали активно развиваться в плане ИТ. Было сделано много очень крутых вещей в принципе, и среди всего прочего докрутили внутренний ресурс с расписанием. Широкой общественности доступно это не было, но данные выгружались на специальный терминал на вокзале.
Тогда к нашим объездам добавилось листание всего интерфейса терминала в поисках расписания. Уходили часы на переписывание расписаний, когда были серьёзные изменения.
Данные в терминале иногда были подозрительными, поэтому зачастую приходилось ездить по станциям и смотреть, как по факту ходили электрички. Например, однажды в терминале была указана электричка Электрогорск — Храпуново, такой маршрут возможен только со сменой кабины, на что времени не было. При проверке было выяснено, что на самом деле электричка идёт с пассажирами только до Есино (а дальше — уже без пассажиров в парк станции Храпуново). Повторные проверки позволили выяснить, что в подобных ситуациях поезд всегда не доезжал одну остановку до станции, указанной в расписании.
Постепенно из наблюдений стали понятны и другие закономерности, и мы начали их учитывать и отображать у нас.
Затем появились пригородные пассажирские компании (например, самая большая ЦППК). А вот пригородным компаниям уже было крайне важно, чтобы пассажиры получали максимум информации про отмены и прочие ситуации, иначе посыпались бы жалобы. Возможно, поэтому договориться о получении информации оказалось гораздо легче.
Внутри структуры РЖД происходит так: специалисты составляют график движения поездов и, если что-то меняется в расписании, отправляют телеграмму по подразделениям и станциям. Раньше это были прямо телеграммы, а теперь — либо телеграммы, либо электронная почта.
Наконец, после серии встреч и переговоров, мы подключились к центральной базе данных пригородных расписаний, а также к данным по фактическому движению поездов (как пригородных, так и дальнего следования). И это очень круто, потому что мы по-прежнему вносим информацию, к примеру, от ЦППК, но есть возможность сверить её со вторым источником — данными РЖД по движению поездов. Бывает, и там и там встречаются ошибки — по одному источнику решить никак нельзя.
При разном характере ошибок вес отдаётся разным источникам. Одна из распространённых ситуаций — бывает, электричка отменена в одну сторону. Если это так, то в другую сторону она вернуться не сможет. Мы это вычисляем часто: ведь поезд в расписании есть, а состава для него по факту нет. Но это не всегда верная матмодель: иногда перевозчик засылает на место состав без пассажиров, чтобы в обратном направлении получалось отработать маршрут. Но отсутствие поезда в расписании, притом что он есть, — это менее существенная ошибка, чем наоборот: объективно вероятность ложноположительного срабатывания около 4%. Обычно поезда всё же не будет. Ещё благодаря внутренним работам перевозчиков и РЖД сейчас такие ситуации с отменами случаются всё реже и реже — это во многом тоже заслуга их ИТ.
Или вот бывают опечатки во времени и номере. По ним тоже довольно просто понять правильный источник: если мы видим сдвиг на час или 10 минут, то знаем, что с высокой вероятностью это опечатка графика РЖД. Графисты рисуют график, а не расписание: там по оси абсцисс шаг — 10 минут, а когда с графика переносится в телеграмму, то на 10 минут легко опечататься.
Вот ещё пример. Есть два поезда Конаково — Москва и обратно. А мы знаем, что там одноколейка с разъездом в Конаковском Мхе и состав останавливается ждать. То есть он просто останавливается, там нет платформы на одном из путей. Это значит, что один из поездов не будет делать высадку-посадку пассажиров, но эта остановка могла быть внесена в базу. Когда мы это увидели, то написали перевозчику. Пришёл ответ: разберёмся. В итоге прислали апдейт: из Москвы будет останавливаться для высадки-посадки, на Москву — нет.
Если это нешаблонная ошибка, то мы ездим на станцию проверять. Да-да, до сих пор гоняем, случается. Буквально пару недель назад у нас был случай в Реутово — там не было понятно, что с путевыми работами, будет или нет поезд, работники не ответили. А от этого зависело, с какой платформы пойдёт состав. Ездили, смотрели, по какому пути пойдут поезда. Пошли не там, как было в данных от перевозчика, соответственно, внесли изменения в модель.
Естественно, мы тоже ошибаемся. Например, модуль анализа фактического движения сигнализирует, если электричка идёт с опережением. Случай в Подольске — там была ситуация, которую мы выявили, пока смотрели свою ошибку. Оказалось, ошибки-то и нет: были технические проблемы, и электрички дальше Щербинки ехать не могли. Станция тоже не могла принять составы. Соответственно, железная дорога отправила составы (которые должны были ехать до Подольска, постоять там и потом обратно в Москву) сразу в Москву с опережением расписания до первой станции. То есть туда, где можно надолго поставить состав, т. е. до Курского вокзала. У нас система это заметила и оперативно отразила на сайте.
Ну а вот так выглядит результат нашей работы:
А так отображаются изменения:
Скорее всего, эти таблички знакомы вам так же, как примерно половине жителей Москвы: если вы смотрели расписание электропоезда в Рунете, то, скорее всего, попадали именно на наше.
Старое бумажное расписание СПб — Оредеж
Началось всё так. Изначально в Интернете не было регулярно обновляемого расписания электричек. Точнее, было «бумажное». Просто сохранить расписание с вокзала или опубликовать то, что обычно размещают в разных брошюрках, — это бесполезно. В расписание вносится большое число временных изменений. Мы поставили цель — сделать регулярно обновляемое расписание.
И хотя вначале всем расписанием занимался один человек, вскоре стало понятно, что нужна команда. Постепенно мы подбирали людей, кому эта тема интересна.
Поначалу было сложно. Когда Туту.ру только рождался, у нас в стране была единая железнодорожная компания, единственный перевозчик. Мы обращались с просьбами давать информацию, но договориться долго не удавалось. Точнее, нам говорили, что вот тут лежит открытое расписание для всех, его берите. Но для вас специально ничего делать не будем. Это вполне понятная позиция, потому что мы хотели выгрузки, которые явно надо было задорого доделывать.
В результате команда стала ездить по вокзалам и фотографировать изменения в расписаниях. Почти каждое утро начинали с объезда 7–9 вокзалов. Так удавалось покрыть Москву. Но далеко не везде были нужные изменения. По отправлению из Москвы — пожалуйста, но вот на Москву — уже нет. По промежуточным станциям получалось, что точность падала. Мы ввели систему сбора сообщений от пассажиров. «Сообщите нам, чтобы помочь другим пассажирам» — этот повод отлично работал, и пассажир, который уже столкнулся с проблемой, сообщал о ней. Это позволяло с помощью ряда математических моделей понять, что происходит, и перестроить расписание либо сделать нужные звонки.
Потом РЖД стали активно развиваться в плане ИТ. Было сделано много очень крутых вещей в принципе, и среди всего прочего докрутили внутренний ресурс с расписанием. Широкой общественности доступно это не было, но данные выгружались на специальный терминал на вокзале.
Тогда к нашим объездам добавилось листание всего интерфейса терминала в поисках расписания. Уходили часы на переписывание расписаний, когда были серьёзные изменения.
Данные в терминале иногда были подозрительными, поэтому зачастую приходилось ездить по станциям и смотреть, как по факту ходили электрички. Например, однажды в терминале была указана электричка Электрогорск — Храпуново, такой маршрут возможен только со сменой кабины, на что времени не было. При проверке было выяснено, что на самом деле электричка идёт с пассажирами только до Есино (а дальше — уже без пассажиров в парк станции Храпуново). Повторные проверки позволили выяснить, что в подобных ситуациях поезд всегда не доезжал одну остановку до станции, указанной в расписании.
Постепенно из наблюдений стали понятны и другие закономерности, и мы начали их учитывать и отображать у нас.
Затем появились пригородные пассажирские компании (например, самая большая ЦППК). А вот пригородным компаниям уже было крайне важно, чтобы пассажиры получали максимум информации про отмены и прочие ситуации, иначе посыпались бы жалобы. Возможно, поэтому договориться о получении информации оказалось гораздо легче.
Внутри структуры РЖД происходит так: специалисты составляют график движения поездов и, если что-то меняется в расписании, отправляют телеграмму по подразделениям и станциям. Раньше это были прямо телеграммы, а теперь — либо телеграммы, либо электронная почта.
Наконец, после серии встреч и переговоров, мы подключились к центральной базе данных пригородных расписаний, а также к данным по фактическому движению поездов (как пригородных, так и дальнего следования). И это очень круто, потому что мы по-прежнему вносим информацию, к примеру, от ЦППК, но есть возможность сверить её со вторым источником — данными РЖД по движению поездов. Бывает, и там и там встречаются ошибки — по одному источнику решить никак нельзя.
При разном характере ошибок вес отдаётся разным источникам. Одна из распространённых ситуаций — бывает, электричка отменена в одну сторону. Если это так, то в другую сторону она вернуться не сможет. Мы это вычисляем часто: ведь поезд в расписании есть, а состава для него по факту нет. Но это не всегда верная матмодель: иногда перевозчик засылает на место состав без пассажиров, чтобы в обратном направлении получалось отработать маршрут. Но отсутствие поезда в расписании, притом что он есть, — это менее существенная ошибка, чем наоборот: объективно вероятность ложноположительного срабатывания около 4%. Обычно поезда всё же не будет. Ещё благодаря внутренним работам перевозчиков и РЖД сейчас такие ситуации с отменами случаются всё реже и реже — это во многом тоже заслуга их ИТ.
Или вот бывают опечатки во времени и номере. По ним тоже довольно просто понять правильный источник: если мы видим сдвиг на час или 10 минут, то знаем, что с высокой вероятностью это опечатка графика РЖД. Графисты рисуют график, а не расписание: там по оси абсцисс шаг — 10 минут, а когда с графика переносится в телеграмму, то на 10 минут легко опечататься.
Вот ещё пример. Есть два поезда Конаково — Москва и обратно. А мы знаем, что там одноколейка с разъездом в Конаковском Мхе и состав останавливается ждать. То есть он просто останавливается, там нет платформы на одном из путей. Это значит, что один из поездов не будет делать высадку-посадку пассажиров, но эта остановка могла быть внесена в базу. Когда мы это увидели, то написали перевозчику. Пришёл ответ: разберёмся. В итоге прислали апдейт: из Москвы будет останавливаться для высадки-посадки, на Москву — нет.
Если это нешаблонная ошибка, то мы ездим на станцию проверять. Да-да, до сих пор гоняем, случается. Буквально пару недель назад у нас был случай в Реутово — там не было понятно, что с путевыми работами, будет или нет поезд, работники не ответили. А от этого зависело, с какой платформы пойдёт состав. Ездили, смотрели, по какому пути пойдут поезда. Пошли не там, как было в данных от перевозчика, соответственно, внесли изменения в модель.
Естественно, мы тоже ошибаемся. Например, модуль анализа фактического движения сигнализирует, если электричка идёт с опережением. Случай в Подольске — там была ситуация, которую мы выявили, пока смотрели свою ошибку. Оказалось, ошибки-то и нет: были технические проблемы, и электрички дальше Щербинки ехать не могли. Станция тоже не могла принять составы. Соответственно, железная дорога отправила составы (которые должны были ехать до Подольска, постоять там и потом обратно в Москву) сразу в Москву с опережением расписания до первой станции. То есть туда, где можно надолго поставить состав, т. е. до Курского вокзала. У нас система это заметила и оперативно отразила на сайте.
Ну а вот так выглядит результат нашей работы:
А так отображаются изменения:
Скорее всего, эти таблички знакомы вам так же, как примерно половине жителей Москвы: если вы смотрели расписание электропоезда в Рунете, то, скорее всего, попадали именно на наше.