Разработчикам PocketGPS Pro

[Alligator.]

Ну так вопрос не про граф, а про источники информации.

Если я правильно понимаю, то источники информации 77.ru - это некоторое количество (пусть не очень маленькое, но мне кажется, что не такое уж и большое) людей, присылающих информацию о пробках, которые они встретили.

В таком случае, как мне кажется, всегда останется много улочек, по которым информации нет. Вы не согласны?

[VctOs]

В таком случае, как мне кажется, всегда останется много улочек, по которым информации нет. Вы не согласны?

Согласен.
А Вы можете предложить способ, который позволяет в реальном времени отслеживать все сегменты графа?
Автоматические датчики, конечно, это хорошо потому что объективно.
Для справки: в графе, используемом в PocketGPS Pro только территория Москвы состоит из примерно 160 тыс. сегметов.
Сейчас в УГАИ приходят сигналы от порядка 400 автоматических датчиков (преимущественно внутри Садового). Также существует опытный сегмент Вессолинка на МКАДе.
Еще для отслеживагия каждого из сегментов требуется ни много ни мало 159650 датчиков. Установка каждого датчика обходится городской казне порядка $10000. Итого требуется $1'596'500'000 только на установку, без каналов связи и прочей инфраструктуры. Даже если эксплуатация каждого датчика будет стоить $10 в месяц, на круг это будет составлять $1'600'000 или $19.2млн в год.
По состоянию на конец прошлого века город вложил в СТАРТ порядка $10млн. На сегодня эта сумма может составлять $15-20 млн, напомню в итоге мы за эти деньги имеем в работе порядка 400 датчиков.
Это с одно стороны.
С другой стороны у нас есть порядка 4 млн. автомобилей, и я полагаю реальным при соответствующей PR поддержке проекта и наличии реальной отдачи для каждого водителя вовлечь 10% водителей в работу по сбору данных. Имея 400000 агентов и хорошую корреляционную модель вполне можно отследить ситуацию "на каждой улочке". Но это то-же к сожалению нельзя сделать бесплатно или за счет "внутренних ресурсов" - такая система требует как минимум немаленького call-центра, а его эксплуатация - немаленьких затрат. Но это требует в сотни раз меньших капитальных затрат, поэтому это реальнее.
В том числе существуют способы сэкономить раз в 10 на call-центре, но по любому нужно несколько милионов долларов, чтобы это реализовать. Причем это должны быть реальные деньги, доходящие до реальных исполнителей.

[Alligator.]

Уважаемый VctOs,

Я же собственно и начал с того, что скоростные датчики не могут контролировать все улицы

Моя мысль была в том, что:
- если есть большая улица
- на ней есть пробка
- к этой улице (посередине известной пробки) примыкает маленькая улочка, по которой нет информации

=> то на этой маленькой улочке тоже можно автоматом поставить пробку (при выезде на большую улицу на которой есть известная пробка).

Ну и ещё старая идея, которую я давно высказывал, что можно собирать автоматически с помощью PocketGPS (естественно, с согласия пользователя) информацию о скорости его движения.
Тогда имея достаточно мощный сервер, наверное, можно построить неплохую модель (которая сможет отличить скорость движения в пробке от случайно остановившегося автомобиля или от водителя, который ищет нужный дом и потому едет 10 км/час и т.д.)...

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

[VctOs]

Моя мысль была в том, что:

Я Вашу мысль, собственно, и с первого раза оценил и в последнем своем сообщении расширил и обобщил, обозвав "хорошей корреляционной моделью".

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

Ну и ещё старая идея, которую я давно высказывал, что можно собирать автоматически с помощью PocketGPS

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

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

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

[Alligator.]

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

Поэтому я и предложил для начала один простой случай, который можно реализовать. Имхо ресурсов КПК должно хватить, хотя естественно эту фичу надо сделать опциональной.

Что же касается более продвинутой модели, то конечно круто поставить большой сервер, копить статистику по пробкам, выявлять закономерности, придумывать умные алгоритмы для прогнозирования пробок и т.д.
Но я считаю себя реалистом, поэтому предполагаю, что в ближайшее время это не будет сделано.
Хотя была бы интересная НИР ...

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

Можно сделать это отдельным програмным продуктом, который будет работать совместно с PocketGPS.
В этом случае пользователи, которые будут его скачивать и устанавливать, будут отдавать себе отчёт, что они делают, и делать это добровольно (или не делать).
Будет не так похоже на "закладку"...

[Пикс]

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

[VctOs]

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

Для того затруднения, которое бывает каждый день на Башиловке перед Ленинградкой - IMHO, любой способ удачный, в т.ч. через двойную сплошную и бордюрный камень если позволяет проходимость. По сегменту показываемоме как "затрудненное движение, (МКАД, ТТК, радиальные шоссе и проспекты) – до 40 км/ч" реальная среднедневная скорость составляет километров 5 в час (объезжаемый сегмент это самое "горлышко" сущевской пробки как раз в этом месте поток с ТТК сливается с потоком с Ленинградки, уже к въезду в тоннель скорость потока возрастает раза в полтора).

Ну а если предлагаемый маневр запрещен - куда писать, Вы знаете.

[Пикс]

См. картинку. Программа почему-то хочет дать круг вокруг квартала для того, чтобы подъехать к дому, мимо которого проходит маршрут.

[VctOs]

См. картинку. Программа почему-то хочет дать круг вокруг квартала для того, чтобы подъехать к дому, мимо которого проходит маршрут.

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

[Пикс]

На перекрестке с Ткацкой улицей выдается ошибочная подсказка "поворот направо". Еду прямо.

[Alligator.]

См. картинку. Программа почему-то хочет дать круг вокруг квартала для того, чтобы подъехать к дому, мимо которого проходит маршрут.

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

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

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

[OldRaven]

Позволю себе предложение явно относящееся к ядру .

Пользуюсь, и не безуспешно, Бета версией с картой 0412. В ней реализован алгоритм перепрокладки маршрута после загрузки пробок. Но есть одно "замечание" - маршрут перепрокладывается от точки старта до точки финиша (естественно через промежуточные). Если "новый маршрут" серьезно отличается от "старого" вы оказываетесь в дурацком положении - новый маршрут может оказаться ОЧЕНЬ далеко от текущей точки. А вы оказываетесь в виду пробки и для решения "проблемы" вынуждены пользоваться функцией ВОССТАНОВИТЬ маршрут, которая работает от ТЕКУЩЕЙ позиции.
Мне кажется что функция перепрокладки после загрузки пробок должна быть заменена на функцию ВОССТАНОВЛЕНИЯ ОТ ТЕКУЩЕГО ПОЛОЖЕНИЯ.

[Пикс]

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

[OldRaven]

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

Уважаемый Пикс, внимательно прочитайте мой пост. Мне не удобно пользоваться ДВУМЯ функциями вообще и Автопрокладкой в частности. Я предложил доработать конкретную функцию чтобы ОНА работала без "глюков".
А за предложение - Спасибо

[Пикс]

Еще когда просто ткнуть стайлусом в карту и выбрать команду "Удалить закладку", то в этом случае пропадет закладка из списка, которая находится ближе всех к данному участку карты.