Sorg
-
Публикаций
32 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Календарь
Сообщения, опубликованные Sorg
-
-
Ну так объединили город с областью, теперь больше карта - больше пробочной информации. Мне так кажется.
Я не могу понять, о чем здесь спорят. В ветке вроде все Питерцы, в Питере сейчас у всех операторов есть опции по безлимитному интернету за 150-200 руб. в месяц.
Подскажите на билайне, если не сложно
Безлимитный за 150-200 в месяц. -
Проблему решат не фильтры, а достаточное количество реальных датчиков...
А количество реальных датчиков зависит от того как эффективно решены различные проблемы. Замкнутый круг, однако. Надо его где-то разрывать.
-
Повторюсь - пусть уж предложит тогда варианты с разворотом через ДвСпл, под кирпичи и т.д. Может, пользователю и на это пофиг.
Слишком мала целевая аудитория для подобных опций.
Это же капитализм: предложение законом не ограничено, т.е. программа может строить любые маршруты. Весь вопрос в спросе: на превышение скорости есть спрос, на проезд под кирпичи почти нет. Отсюда и реализация.
-
То, что Вы написали, даже не научная фантастика, а утопия. Выше я уже объяснил почему.
То, что я написал - это факт. Типы дорог действительно не решат проблему с перескоростями, разве что частично. Информация о разумной скорости проезда действительно была бы полезна пользователям. И настройки тоже были бы полезны.
А вот то, что вряд ли реализуют - это другой вопрос. Но об я не писал
Этот вопрос вне моей компетенции. -
Как собирать такие данные?
1. Берем данные о скоростях на ребре за определенный период (по сути как для статистики). Далее сортируем и 5-10-20% самых высоких скоростей отбрасываем. Самая высокая из оставшихся скоростей берется как лимит.
Пример: есть скорости 20,25,40,35,100,25,35,20,40,20. Сортируем: 20,20,20,25,25,35,35,40,40,100. Допустим отбрасываем 10%. 10% от 10ти измерений=одно измерение. Отбрасываем одно самое большое измерение: 20,20,20,25,25,35,35,40,40. Итого лимит 40км/ч.
Пример 2: есть скорости 20,25,40,35,30,25,35,20,40,20. Сортируем: 20,20,20,25,25,30,35,35,40,40. Отбрасываем одно самое большое измерение: 20,20,20,25,25,30,35,35,40. Итого лимит опять 40км/ч.
Я думал, совершенно очевидно, что программа (при ее правильной работе) не имеет права предлагать мне сэкономить время за счет нарушения правил.
Маршруты, построенные навигационной программой, законом не регламентированы. Программа выдает те маршруты, которые хочет пользователь (в идеале), а уж соблюдение правил - это не забота программы. Ессно, у пользователя должна быть возможность указать программе строить маршрут с учетом ПДД (всех или части). Но пользователь всяко имеет право узнать маршрут, проложенный с нарушениями ПДД.
-
Бороться с перескоростями через типы дорог - нереально. Дороги одного и того же типа могут иметь сильно разную разумную скорость проезда. Одно дело широкий переулок с запретом стоянки по обеим сторонам, другое - разбитый переулок с припаркованными как попало автомобилями. По первому можно в среднем 40 проехать (с учетом разгонов, торможений и "уступи дорогу"), по второму и 20 страшно, а разрешенная ГИБДД вообще 60.Изначальная идея заключалась в том чтобы получить реальную картину с какой скоростью какое ребро можно проехать. Без учета скоростного режима и чего-либо еще. Чисто механически никого не сбив и не повредив транспортное средство. Такая информация будет очень полезна пользователям. А уж как они будут на основе этой информации строить маршрут - это отдельный вопрос. Могут учитывать скоростной режим и разумную скорость = законопослушный водитель, могут только разумную скорость = незаконопослушный водитель, могут только скоростной режим = законопослушный водитель на тракторе. Эти варианты, ессно, должны быть оформлены настройками в программе.ERER, я исхожу из двух озвученных Joss'ом условий. 1. Периодичность статистики не будет меняться. 2. Борьба с перескоростями будет вестись через введение типов дорог.
Вообще-то специально изложил мысль несколько утрированно, думал так понятнее будет. Смысл в том, что совершенно этой же Вашей фразой можно откомментировать то сообщение, на которое я отвечал.Слишком категорично для того, чтобы быть правильным.
-
Программа должна исходить из реальной ситуации, только так она может быть актуальной. Если исходить из того что в стране полный порядок, никто не нарушает, дороги вовремя чинят и новые строят, благодаря чему нет пробок => СитиГид вообще не нужен.Да это-то понятно. Но исходить изначально из того, что "в стране бардак, так что правила игнорируем, смотрим на окружающих" - неправильно.
Там где нет статистики есть скоростной режим, официально утвержденный. Да и неточности на ребрах, где 5ти автомобилей в день не проезжает, не будут сильно влиять на точность подавляющего большинства маршрутов. Если кого-то будет напрягать - позвонит и решит проблему.timvetrov, кто-то здесь сказал, что не надо? По-моему, последнее время весь спор о том, как правильнее определить этот лимит....Должен сидеть какой-то Вася и придумывать эти лимиты? Привязываться к статистике, которая разбита по времени суток? А как быть с ребрами, где нет или мало датчиков? Тыкать пальцем в небо и придумывать цифру с потолка?
-
1
-
-
Все это будет реально, когда будут типы дорог, а когда будут типы дорог не понадобится upper limit.
Все это реально сделать уже сейчас. А типы дорог даже в ближайшем году никто не обещает.
Это разные спидлимиты. Должен быть отдельно спидлимит по максимально возможной средней скорости на ребре, выше которой данные считаются ложными и округляются до этого максимума. Допустим, в кармане это - 30 км/ч. И должен быть еще спидлимит максимальной (мгновенной) скорости - как раз для контроля скоростного режима.
Да, я так и представлял (полагаю, что и Sorg имел в виду то же самое).
У ребра два атрибута - Скорость_потока и Спид_лимит.
Я имел в виду то, то говорит timvetrov. Т.е. нужно ввести спидлимит, который будет отражать с какой максимальной скоростью можно проехать данное ребро (чисто технически, не рискуя угробить машину или сбить пешеходов). На основе этой информации можно отсеивать ложные скорости (т.е. те, которые выше нашего лимита - это либо сбой в программе, либо carmageddon). Про ограничения, связанные со скоростным режимом я вообще не задумывался, но определенно это отдельный параметр.
Т.е. если по дороге реально можно ехать не быстрее 30, а ГИБДД разрешает 60, то при фильтрации данных нужно использовать именно 30. Если едет быстрее, то просто не верим этому датчику, несмотря на то что нарушения, в принципе, нет.
А если реально можно ехать 100, но знак висит 40, то опять таки для фильтра используем 100, несмотря на то что нарушение есть. И у нас базе на сервере лежит информация что на таком-то ребре висит знак 40, но свободно и дорога хорошая. При расчете маршрута, по идее, можно использовать как 40, так и 100. В идеале должна быть настройка навроде "использовать ограничения скоростного режима". И каждый сам выберет как ему лучше.
-
доходят, читают, просто комментировать все не хватит времени, для этого, в таком случае, надо выделять отдельного человека.
Спасибо за ответ. Очень отрадно.
Нет такого понятия, как допустимая скорость на ребре.
Спасибо за информацию, КО. Но об этом писал уже:
Делается файл со списком ребер, для которых есть индивидуальные ограничения скорости, туда забиваются и сами скорости, те которые 40км/ч. Когда инфа от датчика приходит на сервер программа-фильтр смотрит есть ли ребро в нашем волшебном файле и на основании ограничения из этого файла отбрасывает/корректирует показания датчика. После этого отдает показания основному коду сервера, который работает как обычно.
Собственно полностью реализация расписана.
Есть верхний порог, скорость ограничена им.
Еще раз спасибо, кэп. Только вопрос в том что верхний порог в кармане и на кольцевой все-таки должен быть разным, ИМХО.
В карманах статистика не используется, встроенная скорость занижается.
В моем предложении было о том, что надо не учитывать оперативные данные, а не статистику (хотя и статистику тоже). Чтобы если кто-нибудь пролетел над карманом на самолете в включенным СигиГидом пол-города не ломанулось туда проверять правдивость его скорости.
Тут категорически не согласен. Не все предложенное появляется. То, что появляется - не всегда появляется так быстро, как нам бы всем хотелось. Но некоторые идеи все-таки проходят через сито.
Тут ситуация следующая: есть идея, которую можно реализовать разными способами, но продумывать все сценарии невозможно заранее. Поэтому на форум отправляется общая идея. Разработчики смотрят на идею и видят что реализовать ее как есть не удастся. Далее 2 варианта:
1) разработчики пишут на форуме, что идея в целом неплоха, но реализовать не получится, потому что а), б), в).... Предлагающий думает и находит решение как можно модифицировать задумку для устранения обозначенных проблем. Разработчики реализуют модифицированную идею. PROFIT!
2) разработчики не пишут ничего на форуме. Проходит время. Пользователь видит что нет ни ответа, ни реализации. Придумывает новую идею, но, подумав, не выкладывает ее на форум, а идет к конкурентам.
-
Joss,
[offtop]
Не подумайте что я ради сарказма, но итересно доходят ли идеи и предложения с форума до разработчиков и администрации проекта? Все ли идеи передаются разработчикам/игнорируются? Какие критерии того что разработчики узнают о новой идее на форуме?
По этому поводу на форуме вообще вакуум космический.
[/offtop]
-
Joss,
Вам тоже спасибо за ответ.
То что типы дорог собираются реализовать я в курсе. А тему эту я начал потому что:
а) будут ли типы дорог в следующей версии или нет - нет информации (в смысле точной, слухов-то есть)
б) даже если будут все равно непонятно когда будет следующая версия
в) нормальные маршруты хочется уже сейчас
Я не предлагаю такой костыль в качестве окончательного решения. Естественно должны быть типы дорог. Просто можно уже сейчас без значительных затрат временно решить проблему.
-
Спасибо, выглядит разумно.
Я не знаю, почему так не делают.
Ну может просто не знали что можно вот так просто проблему решить
, а теперь хлопнут себя по лбу и за ночь сделают )) -
Не томи уже, дай ссылку!!!
Не в первый раз уже ищу инфу по теме, но ничего конкретнее, чем "работаем" и "раньше следующей версии точно не будет" не нашел...
-
А как этот вариант применить без разделения ребер (ну, дорог) на ряд категорий.
Для СГ что карман, что городская дорога, что шоссе, что автобан - ребро вне категорий.
Применить очень просто. Делается файл со списком ребер, для которых есть индивидуальные ограничения скорости, туда забиваются и сами скорости, те которые 40км/ч. Когда инфа от датчика приходит на сервер программа-фильтр смотрит есть ли ребро в нашем волшебном файле и на основании ограничения из этого файла отбрасывает/корректирует показания датчика. После этого отдает показания основному коду сервера, который работает как обычно.
По ссылке нет никаких обещаний и объяснений сложностей реализации. Насколько я понял, конвертер карт из формата MP в формат СитиГида теперь корректно понимает типы дорог в формате MP. Во что он их конвертирует и как это все учитывает сам СитиГид - та еще тайна. По крайней мере, ни одного обещания что типы дорог появятся хотя бы в следующей версии нет.
-
Насколько я понимаю, основная проблема как раз и состоит в том, что сейчас все ребра одинаковые, а должны быть разделены на ряд категорий.
Насколько я понимаю ))), разделение дорог на ряд категорий является универсальным решением целого класса проблем. Но, как я уже писал выше, это сложно в реализации, и, если я ничего не пропустил, то никто не обещал что это вообще будет в обозримом будущем. Я предложил альтернативный вариант, не такой универсальный, но зато сильно проще в реализации.
-
Вижу что смысла нет, но поделиться мыслями все-таки хочется. Может пригодятся кому-нибудь.
Копий уже наломано горы о маршрутах по карманам, а воз и ныне там. Все упирается в сложности технической реализации. Вот и пришла мысль как это можно сделать попроще.
Суть вообще примитивна: ограничить максимум скорости в кармане. Скажем, 40км/ч. В статистике, вроде бы, уже и есть нечто подобное. Осталось разобраться с оперативными данными.
Тут несколько вариантов:
1. Не принимать данные от датчика, если скорость выше допустимой на ребре. Это можно либо в коде сервера сделать, либо отдельным приложением обрабатывать входящие данные перед передачей серверу.
2. Ограничивать скорости по ребрам в файле оперативных пробочных данных перед созданием этого файла на сервере. Т.е. даже если кто-то там пролетел 200км/ч в файл пробочных данных все равно писать 40км/ч. Опять же можно в коде сервера или отдельным приложением-фильтром.
3. Забить в карманах в статистике маленькую скорость, скажем 10км/ч и оперативные данные по ним не учитывать совсем. Т.е. опять же на сервере просто не принимать данные от датчиков.
Понятно, что совсем без корректировки ПО не выйдет, но фильтр на входе сервера сделать все-же сильно проще, чем скорректировать клиенты под все ОС. Ну и еще надо перечень ребер с ограничениями сделать к фильтру.
Кроме карманов позволит решить еще и с качеством дорог вопрос, если реализовать вариант 1 или 2.
-
1
-
-
Кстати, если вдруг такой режим появится - было бы неплохо ещё при выборе его разрешать менять маршрут после получения свежих данных не сразу перед поворотом (как сейчас) - а, может быть, не менее, чем за 300 метров.
Опытный водитель может сориентироваться и при изменении маршрута прямо перед манёвром перестроиться, а вот новичок или с буксиром - вряд ли.
Уже не в первый раз вижу такие просьбы и мне вот что непонятно: программа же тебе руль не выворачивает, если не можешь перестроиться как она велит подсказывает - едь дальше как планировал, маршрут перестроится и будет все так как будто у тебя включена опция "не перестраивать маршрут когда я уже стою не в той полосе перед светофором".
-
2
-
-
Ездил с СГ в Крым, маршрут прокладывал без проблем от точки до точки, при проезде границ областей, "завис" на 3-4 секунды и ведет дальше. Честно говоря был удивлен, т.к. читал на форуме что через несколько областей маршрут не кладет. Практика показала что это не так.
Сам не пробовал, но почитав форум становится понятно что некорректно учитываются пробки при прокладке маршрута через несколько карт. Да еще есть проблемы с проездом/объездом городов. В общем, маршрут строится, но далеко не оптимальный (впрочем, тут как повезет).
-
Это прямо-таки ненависть какая-то получается. Из приведённой выше формулы следует, что после Vопт дальнейшее повышение скорости будет ухудшать действие критерия оптимизации. Разве не достаточно свести его значение на НЕТ после определённой Vопт. Зачем ухудшать-то?
Вообще да, что-то я повелся на рассуждения об оптимальной скорости. Если ввести пользовательское ограничение скорости описанное ранее, то оно и будет служить для "нелюбви" к гонкам, т.е. для участков со слишком большой скоростью будет считать по твоей комфортной, а за счет расстояния отбракует гоночные трассы в пользу спокойных и более коротких маршрутов.
-
Но также видно, что он не имеет прогиба посередине (любви к оптимальным скоростям, кстати водители такую любовь имеют).
Поскольку получен простым пропорциональным сложением двух линейных функций. И я предположил, что график будет тоже линейным, хотя точно не знаю.
Может кто-то сможет чуть изменить обсуждаемый алгоритм, и он будет с тем же ползунком, но соответствовать вогнутому графику.
Кстати, не нужно для конкретного авто график расхода топлива строить. График г., кому-то проще считать расходом топлива, кому-то расходом нервов водителя (в сек). В левой части графика больше нервов из-за пробок, в правой - из-за излишне потраченного горючего.
Если кто найдёт лучшую аналогию, причём вычисляемую, буду рад, я лучше не смог найти.
По предложенной на данный момент формуле зависимость критерия оптимизации от скорости будет синяя на графике (t=A*s/v+(1-A)*s).
Т.е. явно винда "нелюбовь" к пробкам, при скорости 0 величина критерия уходит в бесконечность, соответственно в такие места маршрут не будет проложен никогда (что и логично
). При увеличении скорости величина стремится к постоянной, т.е. бОльшая скорость будет оптимальнее в любом случае.Добавить "нелюбовь" к гонкам можно следующим образом t=A*s/v+(1-A)*s+((max(Vопт,v)-Vопт)*k, розовая линия на графике. Vопт - оптимальная скорость, определяет точку где график начинает уходить вверх. k определяет крутизну подъема. Оптимальную скорость, естественно, каждый должен определить для себя сам и должна быть такая настройка, что делать с k непонятно.
-
Именно можно проехать. А вот с какой скоростью поеду - совсем другой вопрос. Если будет острая необходимость сэкономить 10 минут на 50-километровом маршруте по КАД, то я тоже поеду 120+. Но обычно я там еду 90..100, даже если есть возможность лететь быстрее. И поэтому если ставить жёсткое ограничение чуть ниже "номинальной" для себя скорости, на КАД программа будет тянуть только в случае явного выигрыша во времени. Поедешь быстрее - сэкономишь ещё больше.
А вот обратный вариант - на КАДе свободно, и по рассчётам программы при 120 км/ч там реально быстрее, чем через город. Но я там всё равно поеду 90, плюс к моменту моего приближения к нужному съезду там движение уплотнится (а через другой съезд - ещё большая потеря времени).
В предыдущем твоем посте я, видимо, не верно тебя понял. Я решил что ты пишешь про "левые" скорости, поставленные гонщиками с мигалками, т.е. стоит 120 там где реально только 80 можно проехать. Вариант решения про пользовательское ограничение скорости я написал уже в предыдущем своем посте.
-
Точно, выгонят
Так вот, алгоритм предложенный мной в начале этой темы как раз и предназначен для того чтобы не выгоняли
Только он не учитывает ограничения по скорости личные, т.е. если ты по КАД едешь 90 где у СГ стоит 120, то для тебя это возможно будет не оптимальный маршрут.Решение в том чтобы использовать два подхода одновременно. Т.е. оптимальный маршрут должен рассчитываться по формуле f= s/v*(1-А)+ s*А, только скорость на ребре надо брать с ограничениями, т.е. v=min(vсг,vплз). vсг - скорость из пробочных данных, vплз - ограничение скорости, выставленное пользователем.
Объяснить не могу, но интуитивно чувствую, что по-настоящему оптимальный алгоритм должен оптимизировать маршрут под график г).
Оптимальность у каждого своя, кому то надо доехать быстрее невзирая на потраченный бензин и износ деталей автомобиля, кому-то надо доехать, потратив минимум топлива, кому-то просто надо спокойно доехать. По настоящему правильный алгоритм должен дать пользователю выбор что ему важнее и уже исходя из этого строить маршрут. Алгоритм изначально оперирует расстоянием, временем и скоростью, водителю также эти понятия хорошо знакомы, так что проще всего "подружить" алгоритм и водителя можно именно на основе этих понятий. Объяснять алгоритму про расход топлива - весьма непростая задача, да думается и водитель вряд ли сможет построить точный график скорость/расход топлива для своего авто. Так что вариант с оптимизацией по расходу мне кажется сильно сомнительным.
P.S. Вообще покупать автомобиль для того чтобы экономить на топливе - это мне кажется нелогичным. У меня, например, самый экономичный маршрут получается на метро :)
-
Поставь себе максималку 80-90 км/ч и из-за двух минут тебя на КАД не выгонят.
Выгонят. Если по городу будет 10км со скоростью средней 40, а по КАД будет 20км с твоей выставленной 90 - поедешь по КАД. Полторы минуты экономии на 15 минут маршрута и двойное увеличение расстояния.
И тогда может осуществиться мечта многих пользователей - чтоб не тянуло на КАД ради экономии в несколько минут. Для этого просто надо будет поставить себе ограничение чуть меньше, чем твоя "любимая" скорость на КАДе. Тогда СитиГид поведёт туда только в случае реальной экономии времени при движении именно с твоей скоростью, а не как сейчас "если ты пролетишь 130 в час как тот Мазератти с мигалками и сиреной по левому ряду обмигивая всех дальним светом, то сэкономишь целых 6 минут из часового маршрута".
Если на КАД стоит 120, то в 99% случаев там можно без мигалок и обмигивания дальним проехать 120+. Если все кроме "мазератти" едут 80, то и будет стоять там 80 в абсолютном большинстве случаев. Скорость ставится не максимальная, а последняя пришедшая, т.е. почти всегда будет стоять скорость, с которой большинство едет.
В итоге получается оптимальность маршрута по времени/расстоянию и ограничение расчетной скорости - это две отдельные проблемы, которые в некоторых случаях имеют общие симптомы (прокладывание необоснованно длинного маршрута). Соответственно и решать их надо отдельно. Для ограничения расчетной скорости никаких алгоритмов и формул не нужно, просто надо ввести это ограничение и обсуждать даже нечего.
-
Если просто так использовать эту формулу, получится что в положении 50:50 один километр будет оцениваться так же как один час (или одна секунда, или одна минута) - что глупо. В прямую складывать километры с часами нельзя.
В теории относительности интервал считается как l^2=-(ct)^2+s^2.
Т.е. одна секунда сравнивается с расстоянием, которую свет проходит за одну секунду.
Соответственно, формула для автомобиля должна выглядеть как
f=V*t*(A)+s*(1-A),
где V - средняя скорость автомобиля, или просто ожидаемая средняя скорость в городе, например 20 км/ч.
Да, думал об этом и ждал когда кто-нибудь заметит
. А тут прямо с ответом и объяснением, спасибо.
Не отображаются пробки
в Обмен опытом
Опубликовано
Не так давно обновился до версии 5.0, и тут тоже началось. Пропадают пробки нафиг. Причем не сразу, а через произвольное время. "Найден новый маршрут" - и вот уже едем вслепую, пару раз уже заехал в очень неприятные пробки, не поглядел отчего вдруг маршрут новый нашелся. Индикатор связи остается зеленый и в Hictory сплошные Ok. Если руками обновить, то не ругается, но и пробки не появляются. После перезапуска программы пробки чаще всего возвращаются и опять некоторое время работают. Если не перезапускать через некоторое время могут сами вернуться.
Навигатор Explay PN-990. CG5.0. В History, как уже писал, везде Ok.