Качество дорог, объезд по карманам и мож еще что. Предложение

[Sorg]

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

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

Суть вообще примитивна: ограничить максимум скорости в кармане. Скажем, 40км/ч. В статистике, вроде бы, уже и есть нечто подобное. Осталось разобраться с оперативными данными.

Тут несколько вариантов:

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

2. Ограничивать скорости по ребрам в файле оперативных пробочных данных перед созданием этого файла на сервере. Т.е. даже если кто-то там пролетел 200км/ч в файл пробочных данных все равно писать 40км/ч. Опять же можно в коде сервера или отдельным приложением-фильтром.

3. Забить в карманах в статистике маленькую скорость, скажем 10км/ч и оперативные данные по ним не учитывать совсем. Т.е. опять же на сервере просто не принимать данные от датчиков.

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

Кроме карманов позволит решить еще и с качеством дорог вопрос, если реализовать вариант 1 или 2.

[timvetrov]

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

Поэтому универсальная максимальная скорость (которая существует и составляет 120) хороша для трассы, но для кармана (да и для города) не годится.

Поэтому и датчики учитываются все, в том числе и из карманов. И так далее. Короче говоря, без категоризации ребер ничего не выйдет.

[Sorg]

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

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

[timvetrov]

Я предложил альтернативный вариант

А как этот вариант применить без разделения ребер (ну, дорог) на ряд категорий.

Для СГ что карман, что городская дорога, что шоссе, что автобан - ребро вне категорий.

1. Не принимать данные от датчика, если скорость выше допустимой на ребре.

Допустимая скорость (то есть максимальная для датчика) для всех ребер одинаковая (120 км/ч). Ее нельзя сделать 40 на одном ребре, 60 - на другом, 80 - на третьем.

2. Ограничивать скорости по ребрам в файле оперативных пробочных данных перед созданием этого файла на сервере.

См. выше.

3. Забить в карманах в статистике маленькую скорость, скажем 10км/ч и оперативные данные по ним не учитывать совсем. Т.е. опять же на сервере просто не принимать данные от датчиков.

Как СГ поймет, что датчик едет по карману, если все ребра одинаковы? Учитываются данные со всех ребер, потому что все ребра для СГ одинаковые.

[vovicom]

Sorg, почитайте форум, и Вам станет понятно, что обещали, и что проще в реализации.....

[Sorg]

А как этот вариант применить без разделения ребер (ну, дорог) на ряд категорий.

Для СГ что карман, что городская дорога, что шоссе, что автобан - ребро вне категорий.

Применить очень просто. Делается файл со списком ребер, для которых есть индивидуальные ограничения скорости, туда забиваются и сами скорости, те которые 40км/ч. Когда инфа от датчика приходит на сервер программа-фильтр смотрит есть ли ребро в нашем волшебном файле и на основании ограничения из этого файла отбрасывает/корректирует показания датчика. После этого отдает показания основному коду сервера, который работает как обычно.

Sorg, почитайте форум, и Вам станет понятно, что обещали, и что проще в реализации.....

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

Изменено 11 октября, 2011 пользователем Sorg

[vovicom]

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

поиск рулит.......

[Sorg]

Не томи уже, дай ссылку!!!

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

[timvetrov]

Применить очень просто. Делается файл со списком ребер, для которых есть индивидуальные ограничения скорости, туда забиваются и сами скорости, те которые 40км/ч. Когда инфа от датчика приходит на сервер программа-фильтр смотрит есть ли ребро в нашем волшебном файле и на основании ограничения из этого файла отбрасывает/корректирует показания датчика. После этого отдает показания основному коду сервера, который работает как обычно.

Спасибо, выглядит разумно.

Я не знаю, почему так не делают.

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

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

Хотя карманофилия и перескорости - это большая проблема, т.к. из-за этого СГ иногда прокладывает маршрут неверно.

Классический пример - "магический" карман на Народной.

[Sorg]

Спасибо, выглядит разумно.

Я не знаю, почему так не делают.

Ну может просто не знали что можно вот так просто проблему решить , а теперь хлопнут себя по лбу и за ночь сделают ))

[Joss]

Sorg,

спасибо за Ваши предложения, мы реализуем это через типы дорог.

[Sorg]

Joss,

Вам тоже спасибо за ответ.

То что типы дорог собираются реализовать я в курсе. А тему эту я начал потому что:

а) будут ли типы дорог в следующей версии или нет - нет информации (в смысле точной, слухов-то есть)

б) даже если будут все равно непонятно когда будет следующая версия

в) нормальные маршруты хочется уже сейчас

Я не предлагаю такой костыль в качестве окончательного решения. Естественно должны быть типы дорог. Просто можно уже сейчас без значительных затрат временно решить проблему.

Изменено 12 октября, 2011 пользователем Sorg

[Sorg]

Joss,

[offtop]

Не подумайте что я ради сарказма, но итересно доходят ли идеи и предложения с форума до разработчиков и администрации проекта? Все ли идеи передаются разработчикам/игнорируются? Какие критерии того что разработчики узнают о новой идее на форуме?

По этому поводу на форуме вообще вакуум космический.

[/offtop]

Изменено 2 ноября, 2011 пользователем Sorg

[Joss]

Sorg

доходят, читают, просто комментировать все не хватит времени, для этого, в таком случае, надо выделять отдельного человека.

Ну вот даже по Вашим предложениям:

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

Нет такого понятия, как допустимая скорость на ребре.

2. Ограничивать скорости по ребрам в файле оперативных пробочных данных перед созданием этого файла на сервере. Т.е. даже если кто-то там пролетел 200км/ч в файл пробочных данных все равно писать 40км/ч. Опять же можно в коде сервера или отдельным приложением-фильтром.

Есть верхний порог, скорость ограничена им.

3. Забить в карманах в статистике маленькую скорость, скажем 10км/ч и оперативные данные по ним не учитывать совсем. Т.е. опять же на сервере просто не принимать данные от датчиков.

В карманах статистика не используется, встроенная скорость занижается.

[IШIN]

Нет такого понятия, как допустимая скорость на ребре.

Надеюсь, что это пока нет. Согласен с Sorg, что это нужно (ввести атрибут для ребра speedlimit). Во-первых, резко снизится влияние ошибок типа "перескорости". Во-вторых, появится возможность ввести функцию "контроль превышения". А если эти спидлимиты будут правиться корректурами - то вообще супер. "Алло, Это СитиГид? На таком-то участке поставили знаки 40, понизьте скорость пожалуйста".

итересно доходят ли идеи и предложения с форума до разработчиков и администрации проекта? По этому поводу на форуме вообще вакуум космический.

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

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

Изменено 2 ноября, 2011 пользователем IШIN

[Sorg]

доходят, читают, просто комментировать все не хватит времени, для этого, в таком случае, надо выделять отдельного человека.

Спасибо за ответ. Очень отрадно.

Нет такого понятия, как допустимая скорость на ребре.

Спасибо за информацию, КО. Но об этом писал уже:

Делается файл со списком ребер, для которых есть индивидуальные ограничения скорости, туда забиваются и сами скорости, те которые 40км/ч. Когда инфа от датчика приходит на сервер программа-фильтр смотрит есть ли ребро в нашем волшебном файле и на основании ограничения из этого файла отбрасывает/корректирует показания датчика. После этого отдает показания основному коду сервера, который работает как обычно.

Собственно полностью реализация расписана.

Есть верхний порог, скорость ограничена им.

Еще раз спасибо, кэп. Только вопрос в том что верхний порог в кармане и на кольцевой все-таки должен быть разным, ИМХО.

В карманах статистика не используется, встроенная скорость занижается.

В моем предложении было о том, что надо не учитывать оперативные данные, а не статистику (хотя и статистику тоже). Чтобы если кто-нибудь пролетел над карманом на самолете в включенным СигиГидом пол-города не ломанулось туда проверять правдивость его скорости.

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

Тут ситуация следующая: есть идея, которую можно реализовать разными способами, но продумывать все сценарии невозможно заранее. Поэтому на форум отправляется общая идея. Разработчики смотрят на идею и видят что реализовать ее как есть не удастся. Далее 2 варианта:

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

2) разработчики не пишут ничего на форуме. Проходит время. Пользователь видит что нет ни ответа, ни реализации. Придумывает новую идею, но, подумав, не выкладывает ее на форум, а идет к конкурентам.

[timvetrov]

Надеюсь, что это пока нет. Согласен с Sorg, что это нужно (ввести атрибут для ребра speedlimit). Во-первых, резко снизится влияние ошибок типа "перескорости". Во-вторых, появится возможность ввести функцию "контроль превышения". А если эти спидлимиты будут правиться корректурами - то вообще супер. "Алло, Это СитиГид? На таком-то участке поставили знаки 40, понизьте скорость пожалуйста".

Это разные спидлимиты. Должен быть отдельно спидлимит по максимально возможной средней скорости на ребре, выше которой данные считаются ложными и округляются до этого максимума. Допустим, в кармане это - 30 км/ч. И должен быть еще спидлимит максимальной (мгновенной) скорости - как раз для контроля скоростного режима.

[IШIN]

Да, я так и представлял (полагаю, что и Sorg имел в виду то же самое).

У ребра два атрибута - Скорость_потока и Спид_лимит.

Скорость потока учитывается (как сейчас оно и есть), когда нет статистики и пробкоданных.

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

Например, на некоем ребре в городе лимит 60, а скорость потока 30 (улочка неширокая, да еще и с выездом под "уступи").

Тогда, если даже по ней пронесется джигит на 150 (или эта скорость возникнет в результате бага), то "в зачет" пойдет не 120 (как сейчас), а 60. Это существенно снизит ошибку. И даже если проедут пять таких джигитов, все равно скорость на ребре не превысит законного предела.

Второй момент - есть два варианта маршрута. Оба в городе, ограничение везде 60. Обе дороги пустые, но одна чуть пустее/прямее. Зато она длиннее в полтора раза.

По более длинной дороге пронесся датчик со скоростью 120. По короткой - со скоростью 60.

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

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

А урезать данные датчика до "скорости потока" (или еще какой-то средневзвешенной) по-моему не стоит.

Разве что усреднять, как это сделано сейчас по самим датчикам (если я правильно понял Joss-а)/

То есть - нет датчиков - используется статистика или скорость потока. Проехал датчик - используется среднее от скорости датчика и статистики (или скорости потока).

Проехал второй - берется среднее двух(трех, ...) датчиков. тогда и информация будет более актуальной, и "перескоростей" будет меньше.

ИМХО

Изменено 2 ноября, 2011 пользователем IШIN

[Joss]

Все это будет реально, когда будут типы дорог, а когда будут типы дорог не понадобится upper limit.

[timvetrov]

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

Все это будет реально, когда будут типы дорог, а когда будут типы дорог не понадобится upper limit.

Т.е., видимо, будут еще подтипы городских улиц. Мне кажется, что спидлимит - более гибкое решение.

Ведь проблема в том, что есть улицы, где при всем желании нельзя проехать даже со средней скоростью 40 км/ч, а есть такие, где средняя скорость 70-80 и выше вполне реальна. Разница в два раза! И все они относятся к городским улицам, на всех них распространяется ограничение 60 км/ч.

То есть, скоростной режим определяется типом дороги (населенный пункт), а спидлимит нужен для оценки данных от датчиков.

Изменено 2 ноября, 2011 пользователем timvetrov

[Sorg]

Все это будет реально, когда будут типы дорог, а когда будут типы дорог не понадобится upper limit.

Все это реально сделать уже сейчас. А типы дорог даже в ближайшем году никто не обещает.

Это разные спидлимиты. Должен быть отдельно спидлимит по максимально возможной средней скорости на ребре, выше которой данные считаются ложными и округляются до этого максимума. Допустим, в кармане это - 30 км/ч. И должен быть еще спидлимит максимальной (мгновенной) скорости - как раз для контроля скоростного режима.

Да, я так и представлял (полагаю, что и Sorg имел в виду то же самое).

У ребра два атрибута - Скорость_потока и Спид_лимит.

Я имел в виду то, то говорит timvetrov. Т.е. нужно ввести спидлимит, который будет отражать с какой максимальной скоростью можно проехать данное ребро (чисто технически, не рискуя угробить машину или сбить пешеходов). На основе этой информации можно отсеивать ложные скорости (т.е. те, которые выше нашего лимита - это либо сбой в программе, либо carmageddon). Про ограничения, связанные со скоростным режимом я вообще не задумывался, но определенно это отдельный параметр.

Т.е. если по дороге реально можно ехать не быстрее 30, а ГИБДД разрешает 60, то при фильтрации данных нужно использовать именно 30. Если едет быстрее, то просто не верим этому датчику, несмотря на то что нарушения, в принципе, нет.

А если реально можно ехать 100, но знак висит 40, то опять таки для фильтра используем 100, несмотря на то что нарушение есть. И у нас базе на сервере лежит информация что на таком-то ребре висит знак 40, но свободно и дорога хорошая. При расчете маршрута, по идее, можно использовать как 40, так и 100. В идеале должна быть настройка навроде "использовать ограничения скоростного режима". И каждый сам выберет как ему лучше.

Изменено 3 ноября, 2011 пользователем Sorg

[timvetrov]

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

Золотые слова!

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

[IШIN]

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

То есть обЪезжать Шкапина по тротуару.

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

Я против. Программа должна предполагать исключительно законные действия юзеров.

[timvetrov]

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

Я тоже так считаю.

То есть, СГ должен обрезать все незаконные скорости до законных.

Т.е. пронесся кто-то по Окрябрьской набережной 120 км/ч - учитывать как 60.

Пронесся кто-то по шоссе 160 км/ч - учитывать как 90. И так далее.

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

А гонщики и так свое наверстают. Да им и СГ не нужен, если взять хороший разгон, можно любую пробку растолкать.

Изменено 4 ноября, 2011 пользователем timvetrov

[niber]

Я тоже так считаю.

То есть, СГ должен обрезать все незаконные скорости до законных.

Т.е. пронесся кто-то по Окрябрьской набережной 120 км/ч - учитывать как 60.

Пронесся кто-то по шоссе 160 км/ч - учитывать как 90. И так далее.

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

А гонщики и так свое наверстают. Да им и СГ не нужен, если взять хороший разгон, можно любую пробку растолкать.

Я уже года два назад пытался такую мысль огласить, но... Петрушка в том, что по следам в 120 по городу я те же 120 не поеду, а буду чухать от силы 80. Поэтому потрачу времени в 1.5-2 раза больше. А при таком раскладе этот маршрут для меня ну совсем не оптимальный, а вот проложенный по следам 60-80, который еще и в пару раз короче - оптимальный.