Перейти к содержанию
GPS навигатор СитиГИД

Пробки, алгоритм. Тема для обсуждения ;-)


Рекомендуемые сообщения

Чтобы быть более конструктивным в своей критике СГ предлагаю коллективному разуму разработать приемлемый/примерный алгоритм обработки пробочной информации. От себя могу предложить для затравки следующее:

Термины:

TMC record:

  1. SEVERITY

    1. critical

    2. major

    3. minor

  2. CODE – код стандартного

    события (01 – пробка; 02 – ремонт дороги; 03 - Регулировщик и т.д.)

  3. DESCRIPTION – краткое

    описание события (may be null and ignored)

  4. LOCATION RECORD:

    1. LOCATION POINT (координаты точки)

    2.  - и/или -

    3. INDEX ребра дороги (при привязке к карте)

  5. DIRECTION (С,Ю,В,З и т.д. /

    или 0-360 грд.)

  6. DURATION

  7.  AVERAGE SPEED

  8. DIVERSION ADVICE (объезд -

    location record (список) – промежуточная/виртуальная

    точка маршрута) may be null and ignored

SOURCE – истоник TMC события.

SERVER – Транслятор TMC

событий

RECEIVER – получатель TMC

события

Алгоритм взаимодействия SOURCE-SERVER-RECEIVER: (критично время от публикации SOURCE'ом TMC,  до ее доступности для RECEIVER, чем меньше тем лучше)

Source передает информацию

в виде TMC record на Server. Сервер проверяет

актуальность сообщения (по времени и

наличию/отсутсвию в базе), и распространяет

подписчикам (Receiver) полученную информацию. Server управляет списком TMC reсords на основе их Duration, severity и т.д.

По аналогии с RSS. Receiver

подписывается на рассылку TMC в виде RSS

Receiver запрашивает систему

сообщая: последнюю datetime обновления,

направление движения, скорость или

требуемый промежуток времени (зависит

от скорости подъезда к началу ребра) и

фильтр (начальная и конечная точка

маршрута/список интересующих дорог/сектор круга координат). На основании

этих данных сервер подготавливает

список произошедших событий

затрагивающих/интересующих Receiver'a

(ближайшие по времени/длительности,

положению и направлению).

Агоритм прокладки

маршрута.

  1. Строится базовый

    маршрут исходя из настроек (Краткий,

    простой, оптимальный, быстрый).

  2. Определяется следующее

    ближайшее ребро (несколько ребер, на

    сколько метров смотреть вперед

    определяется в настройках и/или исходя

    из скорости движения) маршрута

  3. отправляется запрос

    на Server

    1. Server не ответил

      – переход к п.5

    2. получен ответ сервера

      - переход к п. 4

  4. Анализ полученных

    данных

    1. Впереди пробка в

      требуемом направлении? (есть TMC record)

      1. ДА - Предупредить

        пользоавтеля (звук. сигнал)

        1. Вывести пользователю

          инфо: Длинна пробки, средняя скорость

          потока, продолжительность и прочее

        2. предложить объезд:

          100м, 500м, 1 км, 5 км, 15 км, 25 км (<длинна

          объезда зависит от протяженности

          пробки> - предложенное значение

          (первое) выбирается автоматом по

          прошествии 30 сек. - настраивается)

          1. пользователь

            подтвердил объезд -

            1. ДА - перейти к п.1 исключив объезжаемый участок из прокладки маршрута (При этом переходе необходимо

              учитывать ков-во переходов пп. 1 –

              4.2 и в зависимости от него увеличивать

              длинну объезда)

            2. НЕТ -перейти к п.5

      2. НЕТ- переход к п.5

    2. переход к.5

  5. отслеживание круса

    и скорости движения по маршруту

    1. скорость меньше

      разрешенной

      1. ДА - проверить

        последнюю отправленную TMC record

        1. проверить актульность

          TMC record

          1. Если текущее

            положение скорость соответсвуют

            отправленной записи (скорость та же,

            позиция в ходит в область DIRECTION,

            DURATION) – переход к п. 5

          2. Если текущее

            положение не входит в область TMC

            record или ее нет

            1. Спросить пользователя

              о подтверждении пробки (по возможности

              все поля заполнить автоматом корме

              протяженность и длитеьность)

            2. заполнить TMC record

              и отправить на сервер.

            3. Получить ответ.

              И обновленный список TMC records

            4. переход к п.4

          3. переход к п.5

      2. НЕТ – Проверить не

        подходит ли КОНЕЦ обработанного/известного

        РЕБРА маршрута

        1. ДА - конец ребра

          1. Проверить – Конец

            маршрута

            1. ДА – сообщить

              пользователю. выход

            2. НЕТ – переход к

              п.2

        2. НЕТ – переход к

          п. 5

---

P.S. Please ignore this post in case it would be stupid for you.

Ссылка на сообщение
Поделиться на другие сайты

Вряд ли сумма продажи лицензий возместит время простоя в пробках ;-)

Вот если бы нашлась контора способная поднять TMC в Питере, как это сделано в Европе и начинает внедряться в Москве... даже за абон. плату бы подписался.

Ссылка на сообщение
Поделиться на другие сайты

01 – пробка

 

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

 

В СГ нету пробок как таковых, есть данные о скорости проезда участка.
Ссылка на сообщение
Поделиться на другие сайты

В данном случае имеется ввиду тип записи, а ее характеристики описывются дополнительными полями. Мне казалось что направления и длительности будет достаточно. Наверное вы правы можно добавить еще и Average speed.

Ссылка на сообщение
Поделиться на другие сайты

ТМС в силу описанных, а также других ограничений в принципе не может дать такую пробочную картину, которую дает СГ.

ТМС - технология вчерашнего дня. Даже несмотря на то, что её внедряют в Москве smiley36.gif

Ссылка на сообщение
Поделиться на другие сайты

Согласен. Что СГ дает картину, хотя и не совсем достоверную. Но вот воспользоваться этой картиной в полном объеме не получается. Видеть карту и ехать по ней, несколько разные вещи, на мой взгляд. Т.е. я хочу сказать что если бы покрытие дорог в СГ стремилось к 100% и рядом сидел штурман с большим экраном, наверное маршрут был бы близок к идеальному

Ссылка на сообщение
Поделиться на другие сайты

Собственно, по Питеру можно ездить всецело полагаясь на СГ.

Я ему доверяю уже почти полгода как.

 
Ссылка на сообщение
Поделиться на другие сайты

 

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

 

В СГ нету пробок как таковых, есть данные о скорости проезда участка.

Увы и ах! Далеко не всегда. Актуальная пробочная информация есть далеко не всегда. И решение проблемы уже давно придумано, но пока с прокладкой маршрутов все еще серьезные проблемы, несмотря на то, что данные о пробках формируются, вроде, по более прогрессивной технологии, чем ТМС. :(
Ссылка на сообщение
Поделиться на другие сайты

Собственно, по Питеру можно ездить всецело полагаясь на СГ.

Я ему доверяю уже почти полгода как.

 

Наверное, если повезет, и в районах ваших перемещений двигаются множество датчиков СГ можно доверять. Однако не всем везет :(

Ссылка на сообщение
Поделиться на другие сайты

ТМС в силу описанных, а также других ограничений в принципе не может дать такую пробочную картину, которую дает СГ.

ТМС - технология вчерашнего дня. Даже несмотря на то, что её внедряют в Москве smiley36.gif

ТМС - это средство сбора и хранения дорожной информации, и приведено здесь только как основа для описания алгоритма. Если у СГ есть своя, замечательно, давайте обсуждать алгоритм

Ссылка на сообщение
Поделиться на другие сайты

Наверное' date=' если повезет, и в районах ваших перемещений двигаются множество датчиков СГ можно доверять. Однако не всем везет :([/quote']

 

Ну, насколько я понял, мы ездим по одному городу. И я давно уже не попадал в глухие пробки о которых бы СГ не знал. Наверное в консерватории надо что-нибудь поправить Wink
Ссылка на сообщение
Поделиться на другие сайты

ТМС - это средство сбора и хранения дорожной информации' date=' и приведено здесь только как основа для описания алгоритма. Если у СГ есть своя, замечательно, давайте обсуждать алгоритм[/quote']

 

А что вам не нравится в текущем алгоритме?

 
Ссылка на сообщение
Поделиться на другие сайты

Актуальная пробочная информация есть далеко не всегда. И решение проблемы уже давно придумано' date=' но пока с прокладкой маршрутов все еще серьезные проблемы, несмотря на то, что данные о пробках формируются, вроде, по более прогрессивной технологии, чем ТМС. :([/quote']

 

Что вы носитесь с этой статистикой как с писаной торбой? "Серебряной пули нет". В последний месяц я очень редко стоял в пробках, которые можно было бы отнести к постоянным и которые бы отразились в статистике. Зато вдоволь настоялся в спонтанных пробках связаных с ремонтами, авариями или приездом шишек, и которые при этом отсутствовали в СГ.
Ссылка на сообщение
Поделиться на другие сайты

Дело в том, что этот подход действительно работает! Работает отлично и реально может улучшить прокладку маршрутов в отдаленных местах (например в небольших городках в областях. Райцентры и мельче - прокладка маршрутов через них в большинстве своем - тихий ужас. Статистика эту проблему решает.

Ежедневные глухие пробки, в которые ни один датчик не суется, о которых СГ не знает и потому упорно ведет в них.

 

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

 

Это у вас в Питере, может быть, куча маршрутов, а у нас в дефолте обычно два-три варианта маршрутов, а "благодаря" мелким местным объездикам или не нарисованным глобальным пробкам, о которых знает водитель, но не знает СГ, программа не дает нам информации о том какой же из двух-трех существующих глобальных маршрутов выбрать.

 

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

панацеи не существует, но это реально простой и одновременно универсальный алгоритм

Есть такой алгоритм - повышение массовости СГ.

И это намного важнее сложных логистически и технически вещей, которые позволят

улучшить прокладку маршрутов в отдаленных местах (например в небольших городках в областях

Ссылка на сообщение
Поделиться на другие сайты

d C G

Есть такой алгоритм - повышение массовости СГ.
И это намного важнее сложных логистически и технически вещей

Это не означает, что не нужно двигаться дальше по улучшению алгоритма по прокладке маршрута.

 

А как вы относитесь к предложению введения ползунка, влияющего на вшитые индексы на карте в теме Средней скорости для рёбер?
Ссылка на сообщение
Поделиться на другие сайты

Не нравится:

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

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

- то что отправление инф. о пробке идет с определенной постоянной переодичностью и не зависит от скорости движения.

- то что запрос-подтверждение отсылки инфы о пробке выходит независимо от того помечено ребро ранее или нет,  ненужное дублирование

- то что объезд пробки намертво зашит в СГ. Я не могу выбрать расстояние объезда или отказаться от него (без пересчета маршрута)

- то что непонятно сколько хранится информация по пробке, (я подозреваю что его изменить нельзя)

- недостаточное кол-во датчиков движения, говорит о том что спец. службы не могут/не хотят интегрировать систему в свои информационные средства.

Ссылка на сообщение
Поделиться на другие сайты

Вот последнее предложение (до запятой) и объясняет все. Предыдущие 6 пунктов исправятся как только кол-во датчиков будет соответствующим.

Ссылка на сообщение
Поделиться на другие сайты


Резко отрицательно.

 

Жаль... Хотелось бы какую-нибудь настройку - индексы менять или стоимость поворотов, или ещё что-нибудь. Что бы каждый мог под свой темперамент подобрать... Хотя это усложнит "разбор полётов" в случае чего.

 
Ссылка на сообщение
Поделиться на другие сайты

Вот последнее предложение (до запятой) и объясняет все. Предыдущие 6 пунктов исправятся как только кол-во датчиков будет соответствующим.

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

Ссылка на сообщение
Поделиться на другие сайты

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

Касательно ваших "не нравится" - почитайте форум еще несколько дней.

 
Ссылка на сообщение
Поделиться на другие сайты

Резко отрицательно.

 

Собственно, на этом можно заканчивать дискуссии и по "Индексу Шпрота", и про статистические индексы на дорогах.

 

Насколько я понял, цель данного проекта - приближение к 100% достоверным индексам, а для этого нужно очень много "датчиков".

 

Печально.
Ссылка на сообщение
Поделиться на другие сайты

C таким подходом, боюсь, количество датчиков может сильно упасть, а не увеличиться. Не вижу смысла пользоваться ситигидом в часы пик - только от дороги отвлекает глупейшими маршрутами. Раньше просто выключал звук и не обращал внимания, дабы побыть датчиком, теперь даже не включаю, чтоб аккумулятор девайса не сажать зазря. Максимум - смотрю индексы на десктоп-версии перед выездом. И то, редко, ибо и так все ясно:)

Ссылка на сообщение
Поделиться на другие сайты
Гость
Эта тема закрыта для публикации ответов.
×
×
  • Создать...