Автоматическая расстановка maxspeed:practical

А откуда тогда брать если не с треков?

Имхо, оптимально было бы за maxspeed:practical брать скорость, которую не превышало 75-80% участников движения (квантиль 0.75-0.8).
Но пока открытой технологии привязки треков к веям нет, это всё только мечты…

Мне кажется, использовать тег явно не по назначению, это вандализм.
maxspeed:practical - это ограничение скорости сверху, связанное не со знаками, а с дорожными условиями (качество покрытия, малый радиус поворота и пр.) Использовать ее для указания СРЕДНЕЙ скорости, значит, вносить намеренную дезинформацию в базу.
Это получается как в анекдоте: “туалетной бусаги нет, но могу предложить наждачную”.
Ну нельзя пихать нечто несуразное в “чужой” тег под предлогом того, что для этого нет подходящегол тега. Лучше внести уникальный тег, а пока по нему идет обсуждение, заполнять его. Если результат будет отличаться от первоначального предположения, в случае уникального тега его можно будет переобозначить ботом, а что делать, если информация внесена не св тот тег? Как потом отличить актуальную информацию от дезинформации?

andriano, перечитайте внимательно процитированное вами.

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

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

О боже мой.

Я думаю, это будет первый: +9.(9)км/ч к максималке у нас бесплатно, как известно :slight_smile:

Может обсудим как бы нам так сопоставить треки с веями? Возможно в отдельной теме.

А что конкретно хочется? Сделать map matching? Есть простые алгоритмы, типа банального весового алгоритма Greenfeld-а. Но его легко сбить с толку на карманах. Есть посложнее, с учётом разрешённого роутинга или использованием динамической коррекции… Всё зависит от объёма обсчитываемых данных, точности исходных данных и требуемой точности результата.

Хотелось бы по имеющейся базе треков (в осм) присвоить каждому ребру maxspeed:practical. Желательно при этом учитывать запреты (т.е. система предполагает что трек соответствует разрешенному маршруту).

А что это за алгоритмы, где про них почитать?

Это целое семейство алгоритмов, разрабатывали товарищи из универов на гранты. Вот работы по этой теме, которые я полгода назад выудил в интернете:

  1. An Introduction to Map Matching for Personal Navigation Assistants
    David Bernstein and Alain Kornhauser, August 1996

  2. Road Reduction Filtering Using GPS
    George Taylor, Geoffrey Blewitt, May 2000

  3. GPS positioning using map-matching algorithms
    George Taylor, Jamie Uff and Adil Al-Hamadani, 2001

  4. Road Reduction Filtering for GPS-GIS Navigation
    George Taylor & Co, 2001

  5. Matching GPS Observations to Locations on a Digital Map.
    Joshua S. Greenfeld, 2002

  6. A general map matching algorithm for transport telematics applications
    Mohammed A. Quddus & Co, 2003

  7. A Weight-based Map Matching Method in Moving Objects Databases
    Huabei Yin, Ouri Wolfson, 2004

  8. A Three-step General Map Matching Method in the GIS
    J. Zhou and R. Golledge, 2004

  9. Map Matching Algorithm and Its Application
    Lianxia Xi, Quan Liu, Minghua Li, Zhong Liu, 2007

  10. Map Matching algorithm using interval analysis and Dempster-Shafer theory
    Ghalia Nassreddine, Fahed Abdallah, Thierry Denoeux, 2009

Это неполный список, есть и другие (можно найти по ссылкам в этих работах). У Quddus [6] есть небольшой обзор достоинств/недостатков разных алгоритмов на 2003 год.
PDF-ки легко ищутся в google по названию.

Мы у себя в программе использовали модификацию алгоритма Greenfeld-а (описан в [5]), это один из простейших, но далеко не самый точный.

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

И все таки не стоит расставлять автоматически. Вот, например дорога. Текущий maxspeed - 50, выставленный в этом году из-за реконструкции, большинство же треков вдоль него - сделаны до ограничения и показывают нормальные скорости от 70 до 110. Сгенерировав по ним некий maxspeed:practical мы не получим правильного текущего maxspeed:practical…

Идея богата! Но, к примеру, взять МКАД : иногда там едут 130-140, при чём весь поток в 4м и 5м ряду, а иногда он амыкается пробкой в 5-20 км/ч… что в этом случае? Я не думаю, что юзеры стоя в пробках будут озадачивать себя выключением лога

Да, тут какой-то стат. анализ должен быть. В принципе, на достаточно большой выборке и окажется, что средняя скорость по МКАДу километров 60 в час. Только говорить надо не о maxspeed:practical, a что-то вроде expected_speed, т.е. наиболее ожидаемой скорости трезвого и вменяемого человека на легковом автомобиле.

Более сложный подход - разделять движение по периодам, в сутках (час пик - дневной спад - час пик - ночь), и в неделе (будни-выхи), но попробуйте это всё навигатору объяснить =/

оффтоп: от maxspeed:practical вообще чем-то непонятным попахивает в наших условиях, что-то вроде “я проеду по этому подобию дороги на 60 км/час” - “а я на 80 км/час” - “ну и езжай”

Н у что значит попробуй объяснить. Пробочные сервисы именно этои делают. Просто в OSM такого нет и пока я не слышал об открытом для использования пробкосервисе.

Ну вот ты и пришел к идее пробковорота. Добро пожаловать в покетгис :smiley:

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

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