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

FlyForward

Пользователи
  • Публикаций

    20
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные FlyForward

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

    З.Ы. Троллей не уважаю.

  2. Вот и 3.8 упала там с выше...

    Не буду писать всё, напишу пока что сильнее всего раздражает: МЕНЮ.

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

    Во-вторых "системность" меню весьма размазана. Например, автомасштаб включается не в пункте настройки, а в картах. Логично? ИМХО, не очень.

    В-третьих, меню на карте ужасно. Кнопки мелковаты, часто путаница то ли я кнопку нажал, а то финиш маршрута хочу показать. Имхо, правильный вариант при нажатии на пустом месте на карте - или финиш маршрута (доп промежуточная точка, etc) или выход в меню. Чтобы выйти в меню нужно так прицелится... а стилуса то за рулём нет...

    Кажется, что по пёстрости используемой цветовой палитры авторы хотят догнать iGo старых версий. Неправильные ориентиры у Вас товарищи, TomTom в этом плане более правильный маяк! (у него вообще лучший интерфейс, ИМХО из всех что я видел, но вот с пробками у него проблемы :) )

  3. Одна поправка: СГ не ставит "1" - они появляются только если Вы нажали кнопку "Объезд"' date=' причём локально у Вас.
    [/quote']

    А что ставится если я проехал плечо со средней скоростью меньше 1км/ч?

    Ещё очень хочется сказать про светофоры. Вернее про их отсутсвие в СитиГиде. При наличии на перекрёстке светофора я бы добавлял +15(и сделать это время изменяемым) секунд ко времени проезда этого перекрёстка.

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

    В начале сделать просто наличие светофора на перекрёстке. Потом можно добавить информацию насчёт приоритетов на этом перекрёстке. Типа с одной стороны зелёный держиться на 50% больше чем с боковой по отношению к этой. Светофоры, которые расположены не на перекрёстках тоже будут учитываться, будут раставлены дополнительные перекрёстки на которые съезжаются всего две дороги :) Автоматически слегка подрастёт точность пробочной информации.

    Альтернативное решение - прекратить с порочной практикой установки на карте в обоих направлениях одинаковой скорости на плече. С одной стороны плеча может быть светофор, а с другой безсветофорной перекрёсток без левого поворота. И скорости проезда плеча в разных направлениях будут отличаться. Наверняка такая статистика у команды СитиГида есть. Интересно, как ей воспользуются. Вариантов куча, со статистикой, наверное, будет виднее. Но факт остаётся фактом: текущую ситуацию с этим вопросом просто так оставлять нельзя.

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

    Ну и на последок ещё одно пожелание. Уже чисто к картам. Чтобы избавится от проблемы запрещенных левых поворотов на магистралях и дорогах приближенных к ним, нужно делать такие дороги не простыми двухсторонними дорогами, а двумя односторонними. Сразу проблема решится автоматически. Сейчас это мене актуально стало, но всё равно проблема нет нет, да и появится. На многих дорогах ставят разделительный барьер между дорогами. Даже в случае экстренных маршрутов повернуть налево на таких дорогах нельзя.

  4. Не знаю ли, упоминалась ли эта тема ранее (в ближайших темах её не нашёл). Решил выложить свои мысли по поводу алгоритма просчета маршрута. Навело на желание написать тестирование навигационных систем в конце декабря. Хотя и раньше были мысли похожие, но тут уже явно стало. Вобщем так:

    Сервис СитиГида с пробками и его алгоритм мне очень нравится. Кроме одного момента. Назову его "Суперпробка". Объясню на примере, что это такое. Это когда проезжаешь 20м за час. Было у меня такое. Час пик, трамваи.. вобщем на второй Бауманской улице от техничекого переулка до улицы радио. Маршрут проложен был по ней (оптимальный).. типа на плече 3км/ч... но плёвое растояние, да? так вот ехал я его час. Информацию о скорости на нём я сначала передал 5км/ч... (мониторил для интереса)... как выехал там стало 1км/ч... хотя реальная скорость была в 50 раз меньше!!!! (20м за 1 час) - целые значения скорости в "суперпробках" зло. Аналогичная ситуация часто бывает на Люблинской улице в сторону Волгоградского проспекта. Тоже пару раз там вставал (ехал с Юных Ленинцев). Хотя типа пробка известна (на карте она есть) маршрут из-за целых показателей скорости (а Люблинка едет ОООООЧЕНЬ медленно в утренний час пик) идёт через неё. На Волгоградском проспекте показатели скорости аналогичные (на карте), но в реальности там проехать можно в 3 раза быстрее (засекал).

    И именно в эту пробку попал СитиГид на тестировании :) Прошу обратить на это своё внимание уважаемым разработчикам. Мой рецепт - или вводить нецелые показатели скорости (на плече скорость может упать до 0.02км/ч - собственный опыт, а ситигид передаст 1км/ч... разница в 50 раз!!!!) или вводить отдельную тему для таких суперпробок. Какое решение правильное - нужно думать, я склоняюсь к первому, хотя это увеличит трафик (целые скорости передавать менее накладно). Мне нравятся изящные математические решения. Буду рад за конструктивный диалог.

  5. Известный производитель навигационного оборудования и ПО, нидерландская компания TomTom, предложила открытый стандарт для обмена пространственными данными, OpenLR.

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

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

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

    Пока что доступна подробная документация о формате, методах кодирования и декодирования данных. В скором времени TomTom собирается выпустить библиотеку для работы с OpenLR под лицензией GPLv2.

    http://www.opennet.ru/opennews/art.shtml?num=23346

  6. Движение в сторону интерфейса Томтома продолжается - и это есть гуд, нечего стесьняться. На этот раз появилось сворачивание програмы и прокрутка пальцем. Одобрям-с :)

    Но томтом грузится чутка быстрее... с чем это связанно... может уже с тем, что у него в картах уже проиндексированны заранее все объекты? ;)

     

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

     

    Смс сервис - интересненько и свежо, посмотрим как оно приживётся. Вот различие фаворитов и закладок пока не понял, хотя ими не пользуюсь... неудобно как-то...

     

    А в остальном правильной дорогой идёте, товарищи! Главное то, ничего хорошего не портите. Мелкие улучшения - залог правильной эволюции.
  7. В Ночь с 9.03.2008 на 10.03.2008 использовал программу CityGuide. А вот трека своего не вижу :(

     

    Когда попылся посмотреть трек, заметил ещё баг: сегодня 10.03.2008 при просмотре треков за 1 день, мне почему-то показывает трек за 05.03.2008...
    FlyForward2008-03-10 16:55:31
×
×
  • Создать...