frolfomich
-
Публикаций
28 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Календарь
Сообщения, опубликованные frolfomich
-
-
Все-таки полезнее была бы функция именно заблаговременного предупреждения(секунда за 15) о приближении к нас. пункту. А то эту роль у меня сейчас жена выполняет)) Потому как гайцы караулят именно у начала нас. пункта - и если вас ситигид предупредит о превышении при въезде' date=' уже будет поздно.
[/quote']
А разве знак начало населенного пункта на белом фоне не является одновременно и указателем снижения предельно допустимой скорости до 60 км/ч?
-
Мне кажеться более полезным была бы настраиваемая функция предупреждения о снижении/увеличении предела разрешенной скорости. Такая функция есть в iGO и очень удобна. Предупреждения происходят звуковым сигналом, который настраивается, и выводом соответсвующего знака в специальной области экрана. Сигналы для понижения и повышения естественно разные
-
В пользу статистики,
Маршрут: СПБ, Выборгское->Энгельса->Б.Сампсониевский->Литейный
Так вот есть наблюдение, что разница выезда в 10~15 минут дает примерно 20~40 минут общего времени проезда. Т.е. если выехать в 06:45 время близится к 20 мин. (в зависимости от времени года, летом меньше). А если выехать уже в 07:00 - 07:15 то время уже идет к 40 мин. Не говоря уже о том если тем же маршрутом ехать после 08:00 там и час можно потратить.
По-моему на статистику очень похоже. ;-)
Более того, если например провести эксперимент и сделать несколько снимков карты в одно и то же время в рабочие дни недели, осмелюсь утверждать, что пробки будут примерно на тех же местах.
-
Субъективность быстроты СГ, по-моему вполне объяснима, вы проезжаете большее растояние с большей скоростью. Однако время, остается почти постоянным!
Ценность алгоритма в универсальности! Оптимизировать можно либо по времени, либо по растоянию и, кмк, от карты мало зависит. Основная ошибка СГ, с моей точки зрения, считать незакрашенные улицы проезжаемыми. Используя TomTom или iGO пользователь всегда на 60-70 проценов работает головой, т.е. вспоминает что там ВПЕРЕДИ было вчера и как лучше проехать ДАЛЬШЕ. СГ имеет только то что ЗДЕСЬ и думает как это ЗДЕСЬ объехать. В результате постоянная оптимизация по растоянию/времени в совокупности с ОПЫТОМ (статисикой) водителя дает лучший результат. Думаю ОПЫТ это то что нужно научится использовать СГ.
-
Я так думаю в следующей версии СГ должен появится рейтинг пользователей или степень доверия к публикуемой ими информации. А то у себя у дома наставят ДПС/ДТП чтобы выезжать/парковаться было удобно.
Мне кажеться "Ремонт дороги" тоже был бы не лишним. Сейчас это сервис обкатывается израильтянами waze по-моему называется
Мне кажется было бы логичнее перенести этот сервис в "Дорожная обстановка" и назвать "Сообщить о" вместо Сообщения->исходящие, было бы логичнее
-
Может пробки так как они сейчас рисуются, вообще оставить только в 2D?!
А для 3D над дорогой повесить маркер (как в google/maps) или знак? И отображать его при приближении в зависимости от масштаба?
-
Пользуясь СГ с матюками около 1 года, предложил бы команде СГ выделить сервисы: картографии, пробок, и собственно навигатора, в отдельные самостоятельные продукты-фирмы. Тогда многим стало бы жить легче. Если немного подумать, то станет ясно почему, я бы под навигатор СГ низачто бы не подписался.
П.С. Ничего личного
-
Вот последнее предложение (до запятой) и объясняет все. Предыдущие 6 пунктов исправятся как только кол-во датчиков будет соответствующим.
Мне казалось что простота использования и качество программы предопределяет количество пользователей а не наоборот.
-
Не нравится:
- то что при движении по маршруту просмотр вперед идет только до конца следующего ребра без учета моей скорости и скорости потока на последующих ребрах. Б.Сампосниевский - Энгельса в час пик... будете ехать по синусоиде по всем близлежащим закоулочным пробкам по которым еще не проехали датчики
- то что нет учета реальной скорости проезда. Разбитая дорога, припаркованные автомашины (Центр города в рабочие дни)
- то что отправление инф. о пробке идет с определенной постоянной переодичностью и не зависит от скорости движения.
- то что запрос-подтверждение отсылки инфы о пробке выходит независимо от того помечено ребро ранее или нет, ненужное дублирование
- то что объезд пробки намертво зашит в СГ. Я не могу выбрать расстояние объезда или отказаться от него (без пересчета маршрута)
- то что непонятно сколько хранится информация по пробке, (я подозреваю что его изменить нельзя)
- недостаточное кол-во датчиков движения, говорит о том что спец. службы не могут/не хотят интегрировать систему в свои информационные средства.
-
ТМС в силу описанных, а также других ограничений в принципе не может дать такую пробочную картину, которую дает СГ.
ТМС - технология вчерашнего дня. Даже несмотря на то, что её внедряют в Москве
ТМС - это средство сбора и хранения дорожной информации, и приведено здесь только как основа для описания алгоритма. Если у СГ есть своя, замечательно, давайте обсуждать алгоритм
-
Собственно, по Питеру можно ездить всецело полагаясь на СГ.Я ему доверяю уже почти полгода как.
Наверное, если повезет, и в районах ваших перемещений двигаются множество датчиков СГ можно доверять. Однако не всем везет
-
Спасибо за совет, галочку нашел, "одной проблемой стало меньше" © бородатый анекдот ;-)
-
Согласен. Что СГ дает картину, хотя и не совсем достоверную. Но вот воспользоваться этой картиной в полном объеме не получается. Видеть карту и ехать по ней, несколько разные вещи, на мой взгляд. Т.е. я хочу сказать что если бы покрытие дорог в СГ стремилось к 100% и рядом сидел штурман с большим экраном, наверное маршрут был бы близок к идеальному
-
В данном случае имеется ввиду тип записи, а ее характеристики описывются дополнительными полями. Мне казалось что направления и длительности будет достаточно. Наверное вы правы можно добавить еще и Average speed.
-
Вряд ли сумма продажи лицензий возместит время простоя в пробках ;-)
Вот если бы нашлась контора способная поднять TMC в Питере, как это сделано в Европе и начинает внедряться в Москве... даже за абон. плату бы подписался.
-
Спасибо за подсказку
Кратчайшему - имелось ввиду в общечеловеческом смысле, а не в контексте СГ. В настройках СГ стоит "Оптимальный". Версия СГ последняя на момент написания.
Перед перекретском - когда вдруг совпадет период обновления. Это может произойти и в процессе движения (неожиданный поворот)
-
Чтобы быть более конструктивным в своей критике СГ предлагаю коллективному разуму разработать приемлемый/примерный алгоритм обработки пробочной информации. От себя могу предложить для затравки следующее:
Термины:
TMC record:
-
SEVERITY
-
critical
-
major
-
minor
-
-
CODE – код стандартного
события (01 – пробка; 02 – ремонт дороги; 03 - Регулировщик и т.д.)
-
DESCRIPTION – краткое
описание события (may be null and ignored)
-
LOCATION RECORD:
-
LOCATION POINT (координаты точки)
-
- и/или -
-
INDEX ребра дороги (при привязке к карте)
-
-
DIRECTION (С,Ю,В,З и т.д. /
или 0-360 грд.)
DURATION
- AVERAGE SPEED
-
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
(ближайшие по времени/длительности,
положению и направлению).
Агоритм прокладки
маршрута.
-
Строится базовый
маршрут исходя из настроек (Краткий,
простой, оптимальный, быстрый).
-
Определяется следующее
ближайшее ребро (несколько ребер, на
сколько метров смотреть вперед
определяется в настройках и/или исходя
из скорости движения) маршрута
-
отправляется запрос
на Server
-
Server не ответил
– переход к п.5
-
получен ответ сервера
- переход к п. 4
-
-
Анализ полученных
данных
-
Впереди пробка в
требуемом направлении? (есть TMC record)
-
ДА - Предупредить
пользоавтеля (звук. сигнал)
-
Вывести пользователю
инфо: Длинна пробки, средняя скорость
потока, продолжительность и прочее
-
предложить объезд:
100м, 500м, 1 км, 5 км, 15 км, 25 км (<длинна
объезда зависит от протяженности
пробки> - предложенное значение
(первое) выбирается автоматом по
прошествии 30 сек. - настраивается)
-
пользователь
подтвердил объезд -
-
ДА - перейти к п.1 исключив объезжаемый участок из прокладки маршрута (При этом переходе необходимо
учитывать ков-во переходов пп. 1 –
4.2 и в зависимости от него увеличивать
длинну объезда)
-
НЕТ -перейти к п.5
-
-
-
-
НЕТ- переход к п.5
-
-
переход к.5
-
-
отслеживание круса
и скорости движения по маршруту
-
скорость меньше
разрешенной
-
ДА - проверить
последнюю отправленную TMC record
-
проверить актульность
TMC record
-
Если текущее
положение скорость соответсвуют
отправленной записи (скорость та же,
позиция в ходит в область DIRECTION,
DURATION) – переход к п. 5
-
Если текущее
положение не входит в область TMC
record или ее нет
-
Спросить пользователя
о подтверждении пробки (по возможности
все поля заполнить автоматом корме
протяженность и длитеьность)
-
заполнить TMC record
и отправить на сервер.
-
Получить ответ.
И обновленный список TMC records
-
переход к п.4
-
-
переход к п.5
-
-
-
НЕТ – Проверить не
подходит ли КОНЕЦ обработанного/известного
РЕБРА маршрута
-
ДА - конец ребра
-
Проверить – Конец
маршрута
-
ДА – сообщить
пользователю. выход
-
НЕТ – переход к
п.2
-
-
-
НЕТ – переход к
п. 5
-
-
-
P.S. Please ignore this post in case it would be stupid for you.
-
-
Вчера установил анти-рекорд 2 часа 40 минут. От м. Балтийская до м. Озерки Питер. Собрал все пробки какие только можно с 17:30 по 20:10.
По пустому городу (07:00) такой маршрут занимает не более 35 мин.
В обычный день, не дождь и не Эконом. форум, 1 час 30 мин. - простояв честно все пробки по кратчайшему маршруту.
Вопрос: Как двигаться по кратчайшему маршруту используя пробочную информацию, а не по синусоиде из пробки в пробку? Т.е. не делать петли если они все равно будут по времени дольше ежели стоять в пробке прямо? Мало того что это удлинняет маршрут, так еще и утомляет дико (перестроения из пробки в пробку).
Как заставить СГ оповещать о его пересчете маршрута? Например, стоишь в правом ряду для поворота на право на светофоре (со стрелкой в право), а СГ после очередного update пробок тихо перепрокладывает маршрут прямо...
-
А вот еще интересный вопрос, двигаясь по маршруту с учетом пробок, на сколько ребер просчитывается объезд пробки? А то очень часто предлагается совершить П-образный маневр по прилегающей к маршруту траектории чтобы объехать пробку и выйти на участок в 20-50м до следующей пробки
Я так подозреваю в учет принимается одно-два ближайших ребра. Иначе бы кнопку "объезд" "нажимала" бы сама программа.
Как пример, если представить пр. Энгелса в районе м.Урельная в сторону от центра, то очень часто СГ предлагает свернуть на Гаврскую чтобы объехать пробку до Скобелевского и вернутся обратно по Рашетова, хотя далее от светофора на подъем опять пробка и ее уже никак не объехать. Не говоря уже о том что между Гаврской и Рашетова улочки узкие и время движения по ним равнозначно движению по пробке а то и больше. В этом случае уж если свернули на Гаврскую логичнее было бы искать выезд на Тореза, а не возвращаться на Энгельса черз 80-100м.
Ссылка на крту из примера: http://maps.mail.ru/#x=30.323103973194247&y=60.01952108835951&z=16&mode=map&fullscreen=true&jams=true
-
frolfomich, оно не SG, оно CG.
А так конечно понятно.
испавил, надеюсь на такую же скурпулезность в подходе к исправлению ошибок в CityGuide программе ;-)
-
Вид пробок можно настроить.
Остальное уже предлагалось в том или ином виде, и существует, как правило, в других программах. К СитиГИДу надо привыкать - не всё в нём гладко, но всё идёт к этому.Дык в том то и дело что в других программах сущетсвует, однако в Питере они (др. программы) безполезны без пробок ИМХО
-
Хорошо бы также выучить название программы
Вы еще на нее молится заставьте
мне кажется вполне понятно о какой программе идет речь
-
Привет, Всем!
Появилось желание поделится своими первыми впечатлениями от использования CityGuide. Хотелось бы чтобы на этот отзыв обратили внимание разработчики/дизайнеры интерфейса CityGuide.
Я имею достаточно большой опыт общения с навигационными программами начиная от OziExplorer и ГИС Russa кончая последними версиями TT и iGO и не только лабораторный, но и так сказать, в полевых условиях приобретенный. Это и повседневные поездки по городу СПб, за город и за грницу (в основном Европа)
Прежде всего хочу поблагодарить разработчиков за столь нужную и полезную программу, а особенно за traffic jams сервис. Поскольку я в Питере относительно недавно, использовние CityGuide значительно облегчает перемещение по городу. К примеру, недалее как вчера при проезде города от пл. Победы до Выборгского шоссе затратил на путешествие всего 1.25 часа хотя обычно на этот маршрут уходит не менее двух-двух с половиной (недавно в городе), если ехать не по КАДу как совершенно правильно предлагает по началу CityGuide. Специально поехал через центр чтобы устроить проверку.
Итак, в поездке в час пик через центр города программа проявила себя вполне достойно. Попав всего в 3 пробки нигде не стоял более 15 мин. Средняя скорость составила 25-30 км/ч. Однако появились некоторые замечания/предложения по поводу улучшения интерфейса программы, которыми хотелось бы поделится с разработчиками CityGuide.
Первое, когда следуешь по маршруту, особенно в режиме "перспектива" информацию о пробках луше выводить как-нибудь подругому нежели прямо на карте, например можно использовать знак рекомендуеммая скорость под знаком следующего маневра с указаниме дситанции действия знака. Текущий вид очень затрудняет видимость направления маршрута. Например если представить пл. Мужества (круговое движение) то увидеть, что потребуется 3-й съезд с круга при подъезде к круговому движению (за 50-100 м, масштаб 62м) практически невозможно.
Второе, Повороты которые указаны стрелками на линии маршрута не читаемы в "перспективе", их можно было бы увеличить по длинне в 2 или даже 3 раза и выделить тенью ("поднять") над линией.
При подъезде к дорожной развязке/перекрестку хотелось бы чтобы отображение развязки/перекрестка находилось в центре экрана и было видно по возможности целиком (покрайней мере та его часть по которой прходит маршрут). Сейчас массштаб и положение на экране выбирается, на мой взгляд не очень корректно.
Если до следующего маневра более 1 км., CityGuide об этом скромно умалчивает, хотелось бы чтобы он проговаривал: "двигайтесь прямо более 2 км" или что то подобное.
Хотелось бы иметь подсказку при перестроении по полосам в виде знака "движение по полосам" потому что сообщений "держитесь правее/левее" на наших некоторых развязках бывает недостаточно.
Хотелось бы иметь знак показывающий текущее ограничение скорости, а так же предупреждения о ее превышении (может просто не еще нашел нужной галочки).
Еще раз хочу поблагодарить за хорошую программу, и попросить извинений у форума если мои замечания неоднократно здесь упоминались. Надеюсь так же что CityGuide будет и дальше радовать своих пользователей своим развитием и качеством.
Пожелание введения новых функций в СГ.
в Развитие навигационного сервиса СитиГИД
Опубликовано