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

[frolfomich]

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

Термины:

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.

[YoGun]

Такое надо патентовать и за деньги продавать. Уникальный метод будет.

[frolfomich]

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

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

[sergeyastakhov]

01 – пробка

 

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

 

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

[frolfomich]

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

[d C G]

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

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

[frolfomich]

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

[KonTur]

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

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

 

[Spectre]

 

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

 

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

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

[frolfomich]

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

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

 

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

[frolfomich]

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

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

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

[KonTur]

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

 

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

[KonTur]

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

 

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

 

[sergeyastakhov]

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

 

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

[Spectre]

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

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

 

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

 

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

 

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

[d C G]

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

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

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

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

[Шпрот]

d C G

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

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

 

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

[frolfomich]

Не нравится:

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

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

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

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

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

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

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

[KonTur]

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

[d C G]

А как вы относитесь к предложению введения ползунка

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

[YoGun]

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

 

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

 

[frolfomich]

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

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

[KonTur]

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

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

 

[Шпрот]

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

 

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

 

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

 

Печально.

[AstroJohn]

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