Мониторинг общественного транспорта

По первому пункту могу предложить следующие варианты:
• Госномер Т/С можно содержать в произвольных полях. Тогда он будет виден во всплывающей подсказке, т.е. заходить в свойства объекта не надо, чтобы его лицезреть.
• Как обходной путь, можно создать под каждый объект прицеп, именем которого будет госномер, и назначить один раз все прицепы на нужные объекты. Тогда в панели мониторинга можно будет вывести имя прицепа рядом с именем объекта.

Ну и, наконец, не совсем ясно, зачем нужно называть объекты именами маршрутов. Ведь в Вашем мобильном приложении для пассажиров наверняка можно указать, чтобы программа подставляла всегда вместо имен объектов имена маршрутов. 

P.S. Делаю сплит в отдельную тему, т.е. мониторинг общественного транспорта и мониторинга индивидуальных пассажиров — это разные вещи.

levindv, спасибо за интересные идеи. Да, действительно, локатор с отображением маршрутов и объектов (с именами, заменёнными на имена маршрутов) был бы очень похож на сервис для пассажиров, но всё равно он бы не отвечал полностью всем потребностям. Поэтому мы давно осознали необходимость разработки отдельного решения для общественного транспорта, чем мы и занимаемся, собственно.

Я занёс в систему маршруты, которые состоят из нескольких точек, я внёс расписания для этих маршрутов и создал рейс. Но проблема в том что любой автопарк а особенно пассажирский, он требует обязательного соблюдения расписания и если например машина сломалась, водитель заболел или любая другая причина, необходимо назначать на следующий день другую машину и когда автопарк состоит из большого количества машин, то количество таких перестановок может возрастать особенно в зимний период, когда автобус не заводится при температуре -25, а водители болеют чаще. Поэтому часто или постоянно есть факт ручного управления.
И тут в Wialon возникает проблема: автобус за день может делать 20 рейсов начиная в 5 утра и заканчивая в 23. А теперь представим что нужно поменять машину на завтра на 20 рейсах. Оператору необходимо создать 20 новых рейсов и удалить 20 старых! По количеству кликов и вводу текста это огромное количество операций. Даже если была возможность менять рейс, то так как сегодня существующий рейс может быть не закончен, то изменение существующего рейса приведет к нарушению прохождения точек на сегодняшний день, поэтому нужно создавать новый рейс для каждого расписания.

У автопарка  есть понятие «Выпуск» - это некая группа рейсов, на которые они назначают конкретную машину. Причем в 20% случаев эти выпуски состоят из нескольких маршрутов на которые переходит машина в течении дня. Например в случае, когда маршрут едет в час пик в производственную часть города, в которой нет пассажиропотока днём. Поэтому днём на этих маршрутах курсирует меньше машин и часть машин переходит на другие маршруты с большим пассажиропотоком.
Группировка расписаний в некие группы решает такую проблему, так как позволяет несколькими кликами на конкретный день переназначить один раз машину, которая заменит назначенную, но в данный момент через Wialon это нужно делать ровно столько раз сколько расписаний создано для этого маршрута. Также в Wialon нет отдельного списка рейсов, есть только возможность просмотреть существующие рейсы, что создает еще большее количество операций. Усложняет ситуацию также то, что когда я захожу в маршрут, то я вижу просто список расписаний и мне нужно среди них при изменении некой группы расписаний выбрать именно те которые назначены на конкретную машину, а так как например по одному маршруту для курсирования транспорта например каждые 10 минут нужно назначить на этот маршрут к примеру 5-7 машин то и количество расписаний должно быть под каждую машину – то есть к примеру для  20 рейсов каждой машины это 100-140 расписаний.
Можно было б сделать маршрут состоящий из всех точек целого дня, но тогда не было б понятно а по каким реальным пассажирским маршрутам ездят машины.

Вывод: любая задача с циклическими перевозками по одним и тем же маршрутам требует слишком большого количества операций при оперативных изменениях в виду большого количества расписаний из-за цикличности маршрута.
Помогите ((((

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

levindv, я полагаю akkros имеет в виду не отказ от создания маршрутов, а отказ от автоматического создания рейсов по предзаданным расписаниям. Рейсы могут быть созданы вручную, скажем, за полчаса до положенного начала, или за час, 3 часа, день и т.д. В этом есть как бы задача диспетчера.

alex_gps, мы сейчас работаем над новым решением (аппом), предназначенным конкретно для контроля маршрутов пассажирского транспорта. Разработка увидит свет в этом году.

Ну зачем отказываться от автоматизации? Можно ведь использовать метки, привязанные к рейсам, как путевой лист: водитель получил документы в диспетчерской, вместе с ними и метку. Далее назначение на маршрут по метке.

levindv, несколько слов о том, как это планируется делать в новой системе.

У маршрута есть множество расписаний (05:05, 05:33, 05:47, 06:01, ... 00:13), которые должны быть выполнены.
Диспетчер или иное ответственное лицо назначает объекты для выполнения этих расписаний (рейсов). Это может быть сделано за неделю, за 3 дня, за день до начала рейса, за час или даже уже после начала рейса.
Если объект был назначен ошибочно (или если машина сломалась), переназначить другой объект на этот рейс можно в пару кликов.

Это отвечает на Ваш вопрос?

levindv, мы же вроде говорили о новой системе, правильно?
В ней все рейсы одного объекта на день будут показаны на одном экране, и не надо никуда 28 раз переходить. Переназначение доступно из одного места.

Уже было написано выше, что все рейсы одного объекта на указанную дату можно будет видеть на одном экране.

Мы рассматриваем возможность массовых операций типа "снять объект со всех рейсов на остаток дня", но пока ничего точного не могу сказать по этому поводу. Возможно переназначение надо будет делать вручную для каждого рейса индивидуально. Прошу обратить внимание, что это не влечет за собой удаление рейсов и создание новы, а просто замена одного объекта на другой в несолько кликов.

Весомых аргументов в пользу группировки расписаний я всё-таки не вижу здесь.

не думаю что в моем случае уместно говорить о частности, а не о правиле.
водитель здесь не причём, вопрос того как четко он соблюдает график не рассматривается вообще. Вопрос динамичности изменений в виду различных обстоятельств и возможности системой гибко менять объекты.
Суть автоматизированной системы управления не только в автоматизации выполнения заданных параметров, а и возможность гибкого изменения. Если бы система предполагала для создания маршрута заполнения текстового файла со структурированными данными, на заполнение которого понадобилось бы для одного рейса 5 минут, то многие б писали: сделайте автоматическое заполнение файла, ведь это можно сделать автоматически. Но в данной ситуации реально в переписке нет практиков пассажирских перевозок, поэтому трудно оценить глобальность песца, который  приходит при необходимости снять с одного маршрута и назначить с другого объекты на 20 расписаний суточного цикла рейсов, которые находятся в общем списке рейсов. Есть правда мысль именовать их согласно выпуску..но даже в этом случае нет возможности группового назначения расписаний на один объект. в свойствах объект нет такой вкладки где можно было б зажать шифт и выбрать расписания и дату для назначения объекта на них

это интересно, но сильно ограничена функция снять на остаток дня. может можно сделать чекбокс на каждом расписании, чтобы можно было поставить где нужно чек боксы и выбрать действие например по снятию или удалению объекта с выбранных расписаний...или что-то типа того..
Когда я увидел стандартный функционал Wialon, то я подумал, что он решает эти задачи и ы принципе так и есть если б пассажирские перевозки не имели понятия "выпуска транспортного средства", которыми оперируют диспетчеры. Они не сильно смотрят сколько там рейсов за день у объекта. Они говорят: машина номер ХХХ сломана, работать завтра по выпуску №05 не сможет, нужно на выпуск №5 назначить машину YYY и так как они сейчас привыкли к назначению машины на выпуск несколькими кликами, сказать им что давайте теперь будете в 20 расписаниях менять объект.
------------------------------------------
по группировке может можно и без этого, но не понятно как различать одним взглядом расписания предназначеныые на одном маршруте для пяти разных объектов. попробуйте взглянуть на это глазами пользователя, которые не хочет заглядывать в тетрадку и смотреть какое расписание для какого объекта

levindv
Вы опять смешали всё в "кучу". С троллейбусами все на много проще - он ни куда не уедет  от проводов и у диспетчера больше времени отреагировать на не штатную ситуацию. И заранее известно какой троллейбус по какому маршруту завтра поедет.
А маршрутка совсем другое.
С ними  я вижу ситуацию по другому: есть какой то план рейсов и на них назначать в порядке живой очереди объекты.
Ведь у транспортного предприятия в договоре с заказчиком прописано обеспечить интервал движения не реже столько то минут.
И какая машина в какой последовательности пойдет ни кого не "колышет" самое главное выполнение задания.
Но это то же не панацея. Есть ещё час пик. И бригадир на месте решает сколько машин отправить в данную минуту, чтоб вывести всех пассажиров. И могут по одному расписанию уйти две машины в место одной. С этим как быть? Поэтому я и говорю может быть только постфактум контроль.

Давайте по порядку.
Маршруты у Вас созданы. Так? Расписания на них тоже созданы. Так? Осталось создать рейсы и назначить на них водителей/объекты. Так?
Ну попробуйте сделать уведомления на все машины, работающие на линии "Параметр в сообщении-тип контроля Текстовая маска-создать рейс". В качестве параметра - параметр датчика, идентифицирующий метку. Попробуйте, "поиграйтесь" с параметрами и настройками уведомления, и должно все получиться. Можно попробовать на карте для тахографа, если под рукой нет считывателей и меток.

В такой ситуации очень трудно создать расписание движения и контролировать его, ибо нет системы координат в которой должен работать транспорт.
Идея в том, чтобы транспорт двигался по расписанию и для этого есть всё что нужно кроме гибкости управления рейсами для большого количества расписаний - всё) на город более 20 000 расписаний при интервале 10 минут, при 17 часовом графике курсирования машины, при 300 машинах.

Ещё дополнительная печаль в том, что при ручном создании рейса не поддерживаются переменные и нет галочки брать имя автоматически из маски во вкладке Имя рейса. Поэтому каждый раз при создании большого количества рейсов нужно вводить какое-то интуитивно понятное имя с названием расписания, маршрута и датой, если эти атрибуты не использовать, то отличать рейсы друг от друга будет проблематично.
Можно было б использовать автоматическое создание рейсов, но тогда в них нужно было б добавлять объект завтрашнего дня, но если это сделать до того как сегодняшний рейс завершен, то система будет думать что назначение объекта произошло также и на сегодняшний день и когда объект назначенный на завтра войдет в первую контрольную точку, то рейс будет начат, но не будет закончен по причине того что объект завтрашнего дня сегодня ездит по другому маршруту. Поэтому единственный путь это создание рейсов на каждый день отдельных с необходимостью заполнения атрибута имени, времени действия рейса и датой рейса.
При групповом назначении можно было б указывать эти атрибуты один раз для тех расписаний завтрашнего дня, которые относятся к одному и тому же объекту и назначать этот объект, но заполнение даже один раз на группу рейсов имени по маске занимает всё равно много времени, например "Выпуск 08 25.02.17". При этом такое название не сможет быть воспринято системой нормально без наличия сущности группы рейсов, так как автоматически не сможет дать имя каждому рейсу для каждого расписания. Имя тогда должно было автоматически формироваться по маске Выпуск 08 %DATE% %SCHEDULE% и в рейсах появлялось бы к примеру 20 рейсов на 20 расписаний.

ну уж извиняйте что дважды не понравилось))
идея с метками скорее всего рабочая, правда нужны устройства считывающее эти метки. Но как я уже написал, она более сложная и требующая соблюдения некой дисциплины и отсутствия путаницы водителей/ В схеме, которая используется Wialon нет меток, так как можно обойтись без них создавая расписания и отслеживая их соблюдение - мне эта схема подходит, но она пока не автоматизирует некоторые операции, которые являются неотъемлемой частью процесса пассажирских маршрутных перевозок.
И чтобы больше было понятно в чём есть потребность автоматизации, я описываю здесь несколько рутинных процессов, надеясь и веря что на них обратят внимание)

право выбора нельзя забрать)
Но рациональность в том, что если водителя нужна заставлять ездить по расписанию, то одна проблема это лучше чем добавляющаяся к ней проблема учёта чёрных меток и технического оснащения машин считывателями.
Учитывая, что есть надежды, что Wialon Hosting руками волшебников обретёт расширенные возможности для пассажирских перевозок и будет как-то решена проблема большого количества рейсов, то можно будет попробовать и вам отказаться от меток, если вы их используете)

И все же не пойму что Вы подразумеваете по словом "автоматизация"? Для меня, например, это контроль и управление по созданному алгоритму и получаемым данным без дальнейшего участия диспетчера.

Да, согласен, ваш метод может работать и я понимаю, что можно видеть соблюдение пост фактум. Правда не совсем понимаю как технически вы реализовали отчетность по посещаемости...просто отчетом по вхождению в геозоны без создания расписаний и рейсов?

В любом случае пост фактум - это метод кнута и диктатуры. А хочется нести добро водителям, а не штрафы, хочется помочь им соблюдать график и чтобы при малейшем отставании его уведомить в смартфон...и чтобы он понимал, что нужно немного изменить скорость посещения точек..в этом кстати мобильное приложение тоже было б хорошо доработать, чтобы в нём была сущность маршрута и звуковое уведомление при отклонении или при нарушении скорости, правил эко драйвинга. текстовыми оповещениями уведомлять не так удобно, так как отвлекает сильнее, а приятным женским голосом сказать гораздо приятнее. Текстом можно через мобильные уведомления, но ещё надо тестировать, можно ли не указывать там рейсы, а то опять-таки не реально, так как они меняются постоянно.
Цель ИТ - удобство и радость для людей и не хочется, никого наказывать...только добро, только помощь..

тогда в система называлась - система КОНТРОЛЯ. а так система мониторинга - мониторь и дествуй..хочешь оповещай проактивно, чтобы не скорректироваться, а хочешь расчленяй тело водителей. Всё зависит от того какие чувства руководят человеком)) инструмент не панацея - панацея то как ты её используешь.
" а 1% брака в планировании хватит что бы разосраться....СМС с опозданием, пред сгорел ....и система дает сбой. Это как концепты в авто...а в серию только подешевле (технологичнее)" - ну никто не говорит о том, что не будет ошибок, но если уменьшить влияние человеческого фактора  например как писалось выше, решить проблему аавтоматического создания большого количества рейсов, для большого количества расписаний, то и повода для брани не будет. А если говорить про техническое оснащение, то конечно если у вас оборудование плохое и выходит из строя периодически, то здесь хоть проактивно, хоть постфакктум результата не будет.

.... но если уменьшить влияние человеческого фактора  например как писалось выше, решить проблему аавтоматического создания большого количества рейсов, для большого количества расписаний, то и повода для брани не будет.

.....молодой исЧо наверное...

ну вот тогда давайте будут убирать из "ядра" те функции, которые нужны вам))))

Поддерживаю, проблема с группировкой рейсов в выпуски актуальна и не решена в данный момент, что затрудняет эффективное использование в задаче контроля общественного транспорта.

levindv
Если Вам действительно нужна данная "фишка".
Откройте голосование. Наберете нужное количество голосов.
Тогда Гуртам либо вас аргументировано "пошлет" или ответит когда будет воплощена данная "фишка".

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

kazintersoft те элементарные возможности, которые описываются в данной теме, хорошо бы иметь в базовом ядре.
Тем более, что доработка функционала минимальна - группировка расписаний и назначение объекта сразу на группу расписаний и тут же все перевозчики общественного транспорта перейдут на Wialon, потому что всё остальное в нём есть для пассажирских перевозок.
А сейчас любая пассажирская транспортная компания не может сказать водителю, что сегодня он едет по группе расписаний номер 16, которая включает в себя 2 рейса по маршруту №4 и 3 рейса по маршруту №5 и легким движением руки назначает объект на эту группу, что автоматически формирует рейсы на завтра.

Конечно можно создать ядро в котором будет только карта с объектами, а всё остальное будет реализовано какими-то внешними программами партнёров, но Wialon является не только ядром для собственных разработок, но и рабочим инструментом для пользователя, который претендует на самодостаточность. И когда будет добавлена группировка, о которой много писалось в этой теме не только мной, но и другими пользователями, которые хотят видеть этот  функционал в Wialon, тогда перевозчики пассажиров не смогут найти минусов в Wialon для своих задач

levindv

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