[Iwan]

В різних темах неодноразово порушували питання необхідності виконання якісної аналітики реального пасажирського трафіку для проектування маршрутів поїздів. Настала пора відкрити відповідну тему та систематизовано накопичувати пропозиції щодо якісної (з високою репрезентативністю) аналітики реального пасажирського трафіку.

Деякі свіжі цитати:

Якби були квитки з можливістю пересадки (чи інші механізми, що дозволяють прив'язати наступний квиток до попереднього), то причетні могли б бачити хто на що пересідає і зважали б на такі речі. Поки цього немає, вони не бачать кореляції між посуненням графіка на пізніше та зменшенням трафіку на Дніпро. Єдине, що можуть побачити кореляцію між посуненням і зменшення попиту на цей же рейс.

Механизм есть - у них же есть имя-фамилия пассажира, погрешность на полных тёзок-однофамильцев есть, но, думаю, ей можно пренебречь

Не сработает.
Если вас зовут Бронислав Ибаддулахоаич Задорожный-Алкогошвилли, то возможно.
А если Иван Петренко или Боян Стоянов, то нет.
Получится, что Боян Стоянов проехал на ЭПК из Мукачево во Львов, а через несколько часов из Киева в Полтаву. Был ли это один и тот же Боян, который на самолете перелетел или это два Бояна? Это хороший вопрос. Поэтому нужен однозначный идентификатор, типа номера паспорта, для этих целей.

Повний ідентифікатор типа паспорта все-таки небажаний з дуже багатьох інших міркувань; зокрема, але не тільки -- це було б жахливо незручно, коли планує їхати разом група помірно знайомих людей, котрі не дуже хочуть ні давати один одному під запис свої паспортні дані, ні збиратися єдино заради того, щоб купити квитки.

Вже неоднократно пропонувалося: враховуючи чим далі, тим більший відсоток тих, хто купляє квитки онлайн, можна і треба дописати у софт можливість окремо вказувати пункти, між якими треба купити конкретні квитки з урахуванням існуючого розкладу та інших обставин, і окремо -- пункти, котрі є справжніми стартом та фінішем з урахуванням усіх пересадок. Бо таким чином можна врахувати сумні ситуації, коли маршрутка на 200км є фідером, а суто на основі аналізу лише дійсних залізничних квитків, навіть якщо вони по паспорту -- ні.

Само собою, ця можливість повинна бути можливістю, а не обов'язком, ну і це треба б зробити так, щоб ті, хто вказують таку додаткову інформацію, не надто програвали тим, хто не вказує, у швидкості купівлі. Бо інакше якраз щодо ситуацій, коли квитки розбирають швидко,  будуть найгірші дані. Що явно погано.

... і окремо -- пункти, котрі є справжніми стартом та фінішем з урахуванням усіх пересадок. Бо таким чином можна врахувати сумні ситуації, ...

То я таке пропонував, але це не знайшло підтримки на форумі. Щодо швидкості - це заповнити два опційних вікна: обрати станцію реального виїзду та станцію реального прибуття (якщо вони відрізняються від станцій у квитку).
Це займе кілька секунд - добровільна участь в опитуванні, якщо це так можна назвати. Тоді буде видно яку частину трафіка закриває конкретний квиток та будувати на цьому якусь аналітику. Безумовно не всі пасажири користуються Букінгом, проте частка тих, що користуються досить вагома, і в деякій мірі ці дослідження будуть репрезентативні. Принаймні, можна буде стверджувати, "якщо бачимо цікавий трафік, то він дійсно є", проте не навпаки "якщо пасажири не показують трафік, а активісти,бабці,студенти його вимагають, то ми це проігноруємо". Є й інша обставина - немає гарантії того, що не почнуть писати якісь вигадки на кшталт "Гданськ - Маріуполь". Проте, вирішення досить просте і не вимагає нічого надзвичайного.

Для збору інформації про справжні пасажиропотоки краще орієнтуватися не на станції, а на міста/селища і ще запитувати про
Тобто після покупки квитка в букінгу виводити вікно в стилі:
-----
Допоможіть нам покращити розкад потягів
Ваша поїздка розпочалася з міста ______ (випадаючий список з підказками по мірі введення)
Кінцевим пунктом є  _____
Час відправлененя потяга   (Влаштовує) - (хотілося б раніше на одну годину) - (хотілося б пізніше на одну годину)
Я б хотів бачити на цьому маршруті швидший потяг навіть якщо він буде дорожчим ()
Мені більше зотілося б купити квиток і їхати в (сидячому вагоні)-(плацкарті)-(купе)-(люксі)
Я скористався цим потягом тільки тому що на потяг №____ не було квитків на вибрану дату
Як часто ви подорожуєте по цьому маршруту (менше 5 разів на рік) - (5-15 разів на рік) - (більше 15 раз на рік)
Кнопка [Відправити Ваші побажання й продовжити], що буде активна не залежно від того чи введені відповіді в поля
-----
Таке можна прикрутити до букінгу щоб в базу також включався й маршрут квитка і час покупки, але не особисті дані пасажира і зберігати в окрему БД - десь на тиждень роботи програмісту.

Получится, что Боян Стоянов проехал на ЭПК из Мукачево во Львов, а через несколько часов из Киева в Полтаву. Был ли это один и тот же Боян, который на самолете перелетел или это два Бояна? Это хороший вопрос. Поэтому нужен однозначный идентификатор, типа номера паспорта, для этих целей.

Такое явные ситуации, где тезки ехали в разных частях страны, легко найти и отключить при формировании какого-то сводного отчета. А все остальное с небольшой долей погрешности можно анализировать. Только все равно от такого анализа будет в целом немного толку - многие едут с пересадкой автобус - дальний поезд или пригородный поезд - дальний поезд, и по таким путешественникам статистику не соберешь никак. А то УЗ как сделает вывод, что из Павлограда в Киев никто не ездит - и попробуй потом их переубедить.

Выше в сообщении как раз говорится об анализе фактических мест начала и конца поездки

Механизм есть - у них же есть имя-фамилия пассажира, погрешность на полных тёзок-однофамильцев есть, но, думаю, ей можно пренебречь

Такой механизм есть только для билетов купленных онлайн, из кассы ФИ не сохраняется. И то, это лишь текстовое поле в базе, что бы его анализировать - необходимо "пилить", в чем нет смысла.

Якби були квитки з можливістю пересадки (чи інші механізми, що дозволяють прив'язати наступний квиток до попереднього), то причетні могли б бачити хто на що пересідає і зважали б на такі речі. Поки цього немає, вони не бачать кореляції між посуненням графіка на пізніше та зменшенням трафіку на Дніпро. Єдине, що можуть побачити кореляцію між посуненням і зменшення попиту на цей же рейс.

Є набагато ефективніша технологія з використанням масивів big data - відслідковуються проходження сім-карт мобільних операторів через певні базові станції. Таким чином транспортну аналітику збирають в розвиненому світі вже біля 10-15 років.

Я особисто мав справу з мобільними операторами, вони готові співпрацювати, якщо УЗ чи УЗШК мало б бажання.

[Iwan]

Якби були квитки з можливістю пересадки (чи інші механізми, що дозволяють прив'язати наступний квиток до попереднього), то причетні могли б бачити хто на що пересідає і зважали б на такі речі. Поки цього немає, вони не бачать кореляції між посуненням графіка на пізніше та зменшенням трафіку на Дніпро. Єдине, що можуть побачити кореляцію між посуненням і зменшення попиту на цей же рейс.

Є набагато ефективніша технологія з використанням масивів big data - відслідковуються проходження сім-карт мобільних операторів через певні базові станції. Таким чином транспортну аналітику збирають в розвиненому світі вже біля 10-15 років.

Я особисто мав справу з мобільними операторами, вони готові співпрацювати, якщо УЗ чи УЗШК мало б бажання.

Це найбільш неінвазивна технологія з т.з. втручання в приватне життя, яка дає найбільш повне та загальне розуміння про рух SIM-карт та їх власників-пасажирів. Однак, з цих геоданих не завжди можна витягнути інформацію про (фрагмент допису від Volodymyr):

Ваша поїздка розпочалася з міста ______ (випадаючий список з підказками по мірі введення)
Кінцевим пунктом є  _____
Час відправлененя потяга   (Влаштовує) - (хотілося б раніше на одну годину) - (хотілося б пізніше на одну годину)
Я б хотів бачити на цьому маршруті швидший потяг навіть якщо він буде дорожчим ()
Мені більше зотілося б купити квиток і їхати в (сидячому вагоні)-(плацкарті)-(купе)-(люксі)
Я скористався цим потягом тільки тому що на потяг №____ не було квитків на вибрану дату
Як часто ви подорожуєте по цьому маршруту (менше 5 разів на рік) - (5-15 разів на рік) - (більше 15 раз на рік)

Частково це зумовлено, наприклад, тривалим часом пересадки з якого не завжди можна зробити належний висновок про "транзитність пункту" чи про два окремі маршрути через пункт.
Тому, як на мене, доцільно поєднувати ці два методи. Точніше, поєднати/інтегрувати їх один до одного не вдасться, а от використовувати паралельно - цілком реально.

Для збору інформації про справжні пасажиропотоки краще орієнтуватися не на станції, а на міста/селища і ще запитувати про
Тобто після покупки квитка в букінгу виводити вікно в стилі:
-----
Допоможіть нам покращити розкад потягів
....
Кнопка [Відправити Ваші побажання й продовжити], що буде активна не залежно від того чи введені відповіді в поля
-----
Таке можна прикрутити до букінгу щоб в базу також включався й маршрут квитка і час покупки, але не особисті дані пасажира і зберігати в окрему БД - десь на тиждень роботи програмісту.

Для більшої зрозумілості для пасажира пропоную дві кнопки:
[Вислати мої побажання] [Я не маю побажань або ігнорую можливість їх подання]
Це дозволить блокувати висилання побажань при некомплектному заповненні анкети (відсутності обов'язкових даних) та можливість внести виправлення.

[logist]

Ответ на этот вопрос должна давать система продажи билетов (для этого она должна уметь продавать билеты с пересадками, и/или отдельно билетную часть, учитывать пригородные перевозки постанционно, а так же фиксировать продажи "по клиентно", и т.д. и т.п.). Именно такую систему должна разрабатывать УЗ если хочет получать реальную аналитику, а она вряд ли этого захочет.
Все вот эти опросы и прочее, что не базируется на реальных продажах - детский сад, который нужен только для поговорить.

[Iwan]

Именно такую систему должна разрабатывать УЗ если хочет получать реальную аналитику, а она вряд ли этого захочет.

Цього не вдалося досягнути попередньому очільнику УЗ, в якого "єдиний квиток" та "термінали самообслуги" були ключовими завданнями до кінця 2017 року. Зараз причетні середньої та низової ланки з полегшенням зітхнули, бо не доведеться так аврально вирішувати це питання... можна зачекати ще 12 років. Після вчорашньої події ця тема, дійсно, залишається "только для поговорить".

[www3]

На мою думку питання не стільки в очільнику, а в самій "армійській" системі радянсько-царського типу УЗ і, як наслідок, роботі цієї самої середньо-нижньої ланки. Саме тому в незалежності від очільника, Фастів возить пасажирів 6вагонними поїздами 1979р.в. (та молодшими), Харків возить 8-10 вагонними електричками 1962 р.в. за дитячими тарифами, а Придніпровська залізниця вигадує космічні тарифи на приміські перевезення.  Туди ж КВР вагонів під час якого начетбо вагон і з кондиціонером та вікна від дощу не протікають, але тільки швидкість менше 15кмгод і можна повіситися. Аналітика, ремонти, організація роботи - це те, що залежить від від місцевого керівництва, а воно повсюду продовжує вікові традиції часів Клавдія Немішаєва нажаль...

[Iwan]

... продовжує вікові традиції часів Клавдія Немішаєва нажаль...

На той час це були передові методи, але, дійсно, вічно вони такими бути не можуть.
Не раз у розмові з причетними вони апелюють до "кореспонденції" з ПДС на ДП і кажуть "Ми не бачимо, щоб пасажири по ІФ пересідали на ДП", а я кажу: "Пасажири не настільки бідні чи тупі, щоб 3 години чекати на дизель із дерев'яними лавками, щоб потім ще кілька годин їхати в Яремче... їх забирають нелегальні маршрутки і швидко довозять в гори, одразу під готель". Це говорять кабінетні причетні, які ні разу не приїжджали 43 до ІФ. Такі ж справи у багатьох інших місцинах... і це все тепер ускладнилося тим, що скоротили локальних пасажирників, які особливо нічим не сприяли, але хоча б володіли інформацією про реальний стан речей.

[Iwan]

Ну ось нарешті МЕРТ впритул наблизилося до реалізації проекту з відстеження пасажиропотоків (турпотоків):

Мобільні оператори погодилися щоквартально надавати МЕРТ дані про турпотоки
https://news.finance.ua/ua/news/-/417618/mobilni-operatory-pogodylysya-shhokvartalno-nadavaty-mert-dani-pro-turpotoky

Голови компаній найбільших мобільних операторів України “Киевастар”, “Vodafone Україна” і Lifecell підписали меморандум з Міністерством економічного розвитку і торгівлі (МЕРТ) про надання статистичних даних щодо динаміки туристичних потоків.

Як повідомляється на сайті МЕРТ, меморандум передбачає надання щоквартальних статистичних даних про кількість зареєстрованих абонентів мобільного зв’язку, які перебували більше доби за межами відповідної області, а також про динаміку в’їзного туризму – іноземних абонентів мобільного зв’язку в роумінгу.

Крім того, мобільні оператори погодилися передавати дані про кількість українських громадян, зареєстрованих абонентів мобільного зв’язку, які виїхали за кордон, та середню тривалість перебування туристів в області.

Як підкреслює міністерство, компанії повинні надавати інформацію виключно в зведеному і знеособленому вигляді.

Можна зробити так, щоб аналогічні (більш пристосовані до аналітики залізничних перевезень) дані отримувала УЗ та грамотно використовувала для своєї аналітики.

[logist]

Можна зробити так, щоб аналогічні (більш пристосовані до аналітики залізничних перевезень) дані отримувала УЗ та грамотно використовувала для своєї аналітики.

Міграції між райцентрами достатньо, але... Поки ми маємо таку ситуацію з менеджментом УЗ, ніхто у здравому умі не буде йти на такий аналіз.

[Iwan]

Необхідно активно задіювати дієві механізми нагинання "менеджменту" УЗ.... хоча це вимагає багато зусиль від активістів.