Роутинг по hw=service

Не требуется до конца - 90% сгодится. Остальное уж костылями доправить можно :wink:

Ведь попытка сформулировать правила для таких service это и есть поиск эвристики.
Пока кроме service на парковке, который не parking_aisle ничего не предлагалось?

Какие еще сервисы на регулярной основе должны рутится?

Мне кажется, что очень длинный service - кандидат на рутинг. Особено если он не вокруг многоэтажки закручен, а ведет на километр-другой вбок от дороги. Но это только конвертор может вычислить — расстояние между первой и последней точкой.
Правда иногда такой длинный service — это просто ошибочно замапленный unclassified, но не всегда. Посему хочется иметь некий валидатор на такие штуки, чтобы посмотреть на них глазками.

Ну да, согласен. Чего-то я замурился маненько…
Тогда и впрямь лучше иметь явный костыль, чтобы удобнее выкидывать, когда надобность отпадет.
Костыль ведь не должен ни разрешать сквозной проезд, ни путать никого чем-то похожим на разрешение, а просто включать в (или выключать из) рутинг(а).
Рутинг-то по сервису сам по себе не возбраняется, просто его больно много.

А зачем отличать АЗС от подъезда к стоянке в контексте обсуждаемой задачи?

Да что за желание понаставить костылей? Нужны конкретные данные - надо добавлять конкретные данные. Никаких эвристик и костылей.

Или хочется решить задачу именно не добавляя данных?

Да по-моему, все, кроме дворовых проездов.

Давайте сразу договоримся не трогать тип дороги ради роутинга - service значит service. А длина сегмента, вообще, не показатель - дорога банально может быть разбита чтобы указать разные surface.

Если решается задача “как выбрать достаточное количество service, нерелевантных для роутинга”, давайте её и решать - тут большой простор для творчества начиная с откусывания листьев небольшой длины, растущих из перекрёстков, продолжая выделением связных подграфов service, не пересекающих более высокие дороги и выкидывание тех из них, у которых наибольшее измерение bbox также небольшое.

А так ли актуальна проблема количества? В Москве service примерно 40% по веям и 30% по нодам. Это далеко не порядки, и если N дорог влезает, а 1.5*N не влезает, как-бы либо не о service надо думать ибо более высокие дороги скоро перестанут влезать, либо надо менять навигатор и спокойно заливать карту со всеми service’ами. В (уже) старый Garmin 60Cx влезает вся Московская область со всеми footway и path без разбиения на мелкие куски.

С другой стороны, можно решать задачу “как выбрать минимум необходимых service”, что намного интереснее и сложнее.

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

Потому что один из них из графа нужно выкинуть, а второй оставить.

Зачем и что это даст?

Это даст роутинг там, где он нужен, и облегчение графа там, где он не требуется.

Выкинув проезды по АЗС ты ничего не облегчишь.

Конечно-конечно, тебе виднее :slight_smile:

Как это дворовые не роутить, а подъезд к дому при точечной адресации?

Эта проблема я так понимаю только СитиГида?
Навтел по этой карте правельно прокладывает маршрут, без всяких костылей.

Может тогда спросить картографов официальных СитиГидовских карт… По ним СитиГид тоже нормально прокладывает, в данной ситуации…

лично для меня дворовые проезды представляют интерес, и не столько для роутинга (хотя бывает грешу сквозным проездом, если пробка), сколько для проезда к нужному подъезду.
Иногда, чтобы к дому проехать нужно знать хитрый маршрут. Вместо выкидывания сервисов, лучше научить людей их правильно мапить. Я например не уверен, что правильно проставляю этот тег.

Посмотрел повнимательнее - имхо, пока проще пойти по первому пути и выбрасывать из роутинга “лишние” highway=service:

  1. service = parking_aisle (главное, не переборщить и не помечать этим тегом въезды-выезды с парковки);
  2. area=yes (исключает многие проезды по заправкам);
  3. layer=-?[1-6] (исключает многоуровневые парковки);
  4. access=no|private (для НН критично, т.к. если нет доступа до ближайшей к пункту назначения дорожки, маршрут будет проложен по прямой).
    Какие еще критерии на основе тегов можно выбрать?

Уже пробовал, без толку. У большинства мусора никаких других тегов нет. Имхо, спасёт только белый список.

Тоже не вариант, в осм аксес-теги принято ставить на барьеры, а не на дороги.

Надо будет поставить, значит.

У нас у большинства нормальных сервисов, по которым нужен роутинг, нет никаких других тегов. И кроме area=yes и проездов по парковке я не знаю ни одного мусора. Да и то с ареа=йес надо будет перепроверять, иногда к ним стыкуются другие дороги со всех сторон, и роутинг порвётся при их исключении.

В каком таком ОСМ?

У буржуинов есть куча частных дорог, обозначенных только знаком, без всяких барьеров. У нас такие тоже встречаются, типа дороги, обозначенные «инвертированным» кирпичом (красным прямоугольником на белом фоне) и надписью «Въезд запрещён» на картонке под ним.

Можно назвать “эвристикой”, а можно и “конкретными данными”.
Раз государство правил/законов не составило, то все наши правила суть эвристика. :wink:

Еще раз уточню, для окончательности прояснения вопроса:
А как же быть со “стволовым дворовым проездом”?
Которые highway=unclassified + living_street=yes?

Раз он дворовый проезд — то сквозного проезда по ПДД быть не должно.
Раз он unclassified, то рутить можно, а запрет сквозного накладывается дополнительным living_street=yes.

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

living_street=yes - это приоритет пешеходов. Никакого отношения к запрету проезда.

/// «инвертированным» кирпичом (красным прямоугольником на белом фоне)

это ты где такое видел? о_О

Да 100500 таких знаков самодельных. Как раз на дорогах, где запретить хочется, а денег на ворота и забор нет. Вот и получается vehicle=private на дорогу.

Вот так:

Или даже так:

По ПДД вообще не знак, но сторож с собакой попрут оттудова.