Тема: Проблемы при расчете остановок после обновления
Коллеги, приветствую!
Не так давно мы столкнулись с нулевыми значениями времени остановок объектов при формировании отчета (т. е. остановки есть, но среди них довольно нередко попадаются нулевые по длительности - как в таблицах, так и при наведении курсора мыши на маркер остановки). По итогам общения с техподдержкой выяснилось, что "...было решено длительность остановки, которая определяется по одному сообщению с нулевой скоростью, выводить с нулевой длительностью, т.к. наверняка определить длительность остановки по одному сообщению не представляется возможным. Для того, чтобы избежать таких ситуаций, могу предложить вам увеличить частоту отправки сообщений, это позволит более точно детектировать временные интервалы как движения, так и состояний остановки или стоянки".
Поясню, что наши приборы настроены таким образом, что передача очередного сообщения в движении осуществляется в соответствии с изменением состояния ТС (изменение скорости, курса), т. е. достаточно актуальные. При этом предусмотрено, что в статическом состоянии прибор передает данные с частотой 5 или 10 минут. В итоге получается, что вывод в отчет остановок по таким объектам по старой схеме стал невозможным, т. к. при остановке до 5 минут при таких настройках пройдет, увы, только одно сообщение.
Кто из моих клиентов пал жертвой прогресса?
1. Организации, занимающиеся вывозом ТБО. По характеру работы транспортное средство объезжает дворы с мусорными баками, останавливаясь у каждого на время 3-4 минуты. Учитывая характер настроек прибора и особенности нового алгоритма определения остановок - эти остановки теперь доказать невозможно. В итоге мой клиент имеет проблемы со своими заказчиками.
2. Организации, осуществляющие городские пассажирские перевозки, которым стало невозможно доказать проверяющим (при рассмотрении жалоб пассажиров), что автобусы действительно останавливаются на всех необходимых остановках.
Вместе с тем для нас является нежелательным изменение частоты отправки сообщений, поскольку в этом случае придется настраивать прибор бездумно на отправку сообщений раз в 5-10 секунд, что создаст неоправданно высокий трафик и затруднения при формировании отчетов за большие промежутки времени. Там, где раньше отчет был бы мог сформирован, при многократном увеличении объема сообщений, может возникнуть превышение таймаута формирования отчета. Также это неприемлемое решение с точки зрения целей оптимизации объема передаваемого GPRS-трафика.
Также специалистами техподдержки было отмечено, что данное новшество было внедрено в целях повышения точности расчета пробега. В свою очередь хочу сообщить, что вопросы, касающиеся пробега (особенно при условии наличия на ТС ДУТ) - являются практически последними в рейтинге самых актуальных пользовательских вопросов (после вопросов отсутствия связи, показаний ДУТ и конфигураций треков). Но и не спорю с тем, что это моя специфика, а где-то считают иначе. И вместе с тем, на мой взгляд логично, что команда Gurtam, претендуя на звание компании с мировым именем, должна быть готовой к тому, что в любом уголке мира, куда они зайдут, их потенциальные партнеры будут рассчитывать на соответствие продукта в том числе и их специфике.
В связи с этим резюме: я только за новшества! Хотя в данном случае нововведение не только не отразилось благоприятным образом на нашей работе, не прошло незамеченным, а наоборот, значительно усложнило нашу работу. Вследствие этого я предлагаю компромиссный вариант - внести дополнительные настройки в свойства объекта, позволяющие администратору/пользователю определить, по какому алгоритму будет выполняться расчет пробега и остановок для конкретно взятого объекта. Прошу учесть и то, что если говорить о влиянии алгоритма расчета времени остановок на точность расчета пробега, то уж точно в данном ключе нельзя один и тот же алгоритм использовать одновременно для легковых и большегрузных машин.
Предложенный Вашими специалистами вариант с использованием виртуальных датчиков (для выявления фактов остановок на их уровне) также не нашел понимания у пользователей, поскольку нет возможности отметить их наглядно на треке, как это делают встроенные маркеры, использование же в этом случае опции "цвет трека по датчику", вызывает больше вопросов и, как следствие, недоверия со стороны заказчиков.
Прошу рассмотреть мое предложение! А также интересует мнение партнеров из других регионов по этому вопросу.
speed.wlp