Проблемы при расчете остановок после обновления

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

Максим, рекомендации были озвучены выше, методы "борьбы" с ситуацией также - если у вас есть еще варианты, каким образом именно Wialon может помочь решить задачу и они еще не рассматривались нами - пожалуйста, опишите ваше предложение тут или создайте новую тему и мы обязательно рассмотрим.

Мое, чисто субъективное мнение, в системе рассчитывать время остановок по старому, а в мобильном клиенте по новому. Я думаю, что если можно сделать этот расчет с помощью датчика, то можно внедрить этот датчик по умолчанию и считать на карте именно по нему.
так как гораздо сложнее объяснить клиенту почему у него на карте куча остановок по 0 секунд и что реальное время нужно смотреть в таблице, чем обьяснить почему пробег в моб. клиенте отличается  от системы..

lexer - "в системе рассчитывать время остановок по старому, а в мобильном клиенте по новому. " это то, что написано в моем посте под спойлером. "Я думаю, что если можно сделать этот расчет с помощью датчика, то можно внедрить этот датчик по умолчанию и считать на карте именно по нему" - датчик это то, что регулируется сервисами УЗ, следовательно может монетизироваться, следовательно создаваться автоматически нами не будет. Можем с вами обсудить дополнительно на телематике, если желаете.

MDenis "Нужно переделать или вернуть, время остановки определяется не  верно." - если у вас есть предложение, которое мы ранее не обсуждали (см. мой пост на предыдущей странице), то пожалуйста, опишите примерно в контексте
- что именно предлагаете
- как реализовать (т.е. логику сейчас и после)

"Есть где остановки были более 0 сек. Это видно по сообщениям." - а мне, например в том же массиве видно, что сейчас все считается логично. Причины были озвучены там же, где и описание того, что обсуждалось. На всякий случай оставлю ссылку, чтобы не потерялась - http://forum.gurtam.com/viewtopic.php?p … 18#p117718

Следует отметить, что для фиксации длительности стоянки необходимо получить от объекта не менее 2 сообщений со скоростью ниже минимальной скорости движения.
Для единичных сообщений будет N/A

https://docs.wialon.com/ru/hosting/cms/ … dvizhenija

+1

Из за чего сыр-бор?
Посмотрите в отчеты, сколько бы ни было по времени остановок при любых настройках детектора поездок, все равно все время отчета, например сутки складываются из времени в движении (это поездки) и времени стоянок (не остановок). Сколько ни напиши в отчете в таблице Остановки, сумма все равно не изменится, это потому что Остановки включены в Поездки. Так давайте в отчетах в хостинге напишем в таблице Остановки столько, сколько всем и надо, то есть так же, как и было, от единственного с нулевой до следующего со скоростью, а алгоритмы расчета пробега пусть работают по-новому.
Что этому мешает?

serd, это не противоречит пункту 5. ("добавление" времени между сообщением "стоит" и "едет" и туда и туда - в сутках станет больше времени, чем 24 часа), поскольку время остановки является содержимым времени в движении

логика этого поведения ясна и с этим тяжело что-то сделать, но можно сделать два изменения:
1. вместо N/A писать Остановка меньше Х секунд, но тогда конечно система должна понимать какие интервалы отправки данных и здесь есть вероятность ошибки (а может если всё продумать и нет вероятности)
2. сделать опцию, которая убирает N/A остановки, если конечно N/A срабатывает только при маленьком времени остановки.
3. Сделать возможность указывать какой интервал простоя является остановкой, тогда тот у кого выставлен интервал отправки позиции каждые 10 секунд может указать что остановка это более 20 секунд, чтобы успеть получить два события

Интересно кстати что будет если поставить оправку данных каждую секунду)) - не будет N/A?

levindv , дайте, пожалуйста, на подробности на support@gurtam.com - доступ, объект, отчет, интервал. Может там таки два сообщения пришли с дельтой в 3 секунды?

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

alek Добрый день!
Просьба дать обратную связь:
- https://forum.gurtam.com/viewtopic.php? … 96#p126796
- https://forum.gurtam.com/viewtopic.php? … 04#p175704

Добрый день!

Хотелось бы разделить свой ответ на несколько частей:

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

2. Касательно предложенных ранее вариантов:

Предложенные вами варианты - это старые способы опрделения времени остановки. Причины, которые повлекли за собой изменения алгоритма были описаны ранее (https://forum.gurtam.com/viewtopic.php? … 18#p117718), к ним мы возвращаться не будем, равно как и не будем сейчас пересматривать принятое по этому вопросу решение. Новых существенных вводных, которые бы позволили пересмотреть алгоритм, сформировать принципиально новый подход к этому вопросу, нет. Каждый раз мы будем сталкиваться с тем, что будут возникать кейсы, требующие каждый раз изменения логики.

3. Мы провели анализ обращений в техническую поддержку. За последние три года, которые работает текущий алгоритм, нам удалось найти менее 10 запросов, что означает, что проблема не острая, при этом у пользователей нет несогласий с алгоритмом, а, скорее, им просто необходимо объяснение, почему остановки отображаются с нулевой длительностью в отчетах и на карте.

4. Также вы и сами знаете, что решение этого вопроса существует. Как и говорилось ранее, реальное время остановки получается с помощью увеличения интенсивности поступления данных.

Если не хотите, чтобы на карте и в отчете отражались 0 и н/д соответственно, то вы можете настроить соответствующую фильтрацию и скрыть их.

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