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

Не, ты так и не понял :slight_smile:
Проблема-то не в этом. А как раз в том, что:

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

Так в том-то и проблема, что все service практически и есть destination! Сравните описание service и описание в ПДД “прилегающих территорий”. Заправки, дворы, парковки, внутри предприятий…

Просто народ хочет рутить и по destination! По парковкам, которые тоже не для транзита строятся. Но софт не тянет и/или не доделан.
И под годым флагом “мы не провоцируем пользователей на нарушение ПДД!” все service убирают чохом.

Любая попытка частично разрешить рутинг по service — это костыли для обхода проблем в современных программах.

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

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

А вот проблема “прореживания” графа — гораздо серьезней.

  • Или надо всё разметить: “это включаем, а это нет”. А поскольку по умолчанию хочется-таки не включать, то разметка получается “это включаем принудительно”.
  • Или накрутить кучу эвристики: “сервис на парковке - можно рутить” т.п. и размечать уже осмысленные категории - парковки и т.п.

Во как повернулась проблема :slight_smile: В Garmin можно сказать в этом плане относительно нормально, сервисы в большинстве своем объезжает, что не объезжает иногда лечится маленьким maxspeed_practical, destination или не лечится совсем, а тут только помог бы какой-нибудь routed_garmin=no :slight_smile: В разрезе появления костыльной точечной адресации в автосборке service (читай дворовый проезды) очень полезны, да и основные крупные вендоры начали прорисовку дворовых проездов на навигационных картах.

если положить, что все service по умолчанию access=destination, то логичным тегом обозначит обратное есть уже существующий access=yes

Oстается быстренько допилить конверторы и закрывать тему, ибо тема собственно была о том, “как обозначить?”

Вообще-то, я только что написал как это можно сделать. Если ты предлагаешь разбить service на подкатегории, то я несогласен - если highway и так уже разбиты весьма размыто и вызывают кучу вопросов, то здесь никаких сколько-нибудь чётких границ вообще не видно. Например, предложенные service=alley|driveway вообще чуть ли не совпадают, ставят их мало - в итоге, озвученных проблем это не решает. Зато вместо того чтобы гадать, alley это или driveway, можно поставить вполне конкретный vehicle=destination, причём иметь для этого стимул ибо это сразу означает запрет умникам объезжать пробки по твоему двору. Если не хватает access, есть/могут быть другие свойства.

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

“Громадное время”, кроме того что его не всегда возможно прикрутить, негативно сказывается на правильности расчетного времени доезда.

Если я правильно понимаю driveway это фактически тупик, подъезд, а alley это как раз что-то типа наших местных дворовых проездов с living_street=yes, а в приведенном выше районе, эти теги используются вовсю, но что-то я сомневаюсь в их правильности, однозначно надо подрихтовать страницу с service исключив неоднозначности и добавив дворовые проезды.

Громадное время нехорошо в том числе и по той причине что начнутся артефакты типа “объедем весь квартал только потому что с другой стороны ехать по дворовому проезду на метр меньше”. Изменять дефолтный access для service как-то тоже весьма костыльно.

Если дорога идёт мимо одного дома к другому это alley или driveway? Если дорога U-образная - это alley или driveway? Если блок посередине поставили или убрали? И т.д.
Сколько раз уже убеждались, что надо отмечать конкретные осязаемые признаки, а не “ну вроде-бы ближе к этому; хотя не…”.

Вот-вот, непонятно, кто объяснит ху из ху, судя по тому что driveway рендерится уже в мапнике, оно менее значимое?

Ну то что driveway менее значимый очевидно, но что есть driveway, а что alley для большей части дворовых проездов неясно совершенно (и не будет никогда по той простой причине что большая часть проездов является и тем и тем), более того - из этих признаков нельзя понять никаких конкретных свойств. Я за vehicle=destination - это позволит отмечать конкретное однозначне свойство, на которое, более того, можно будет ориентироваться для решения обоих озвученных проблем; также не потребуется вводить никаких assumptioon’ов и вытекающих отсюда ошибок.

Да ну?? И как же мне отличить проезд по заправке от подъезда к стоянке супермаркета? По access=destination??

Так что все-таки по поводу “access=yes” для отмены дефолтного для service “access=destination”?

Нормальненький костыль, не визуализируется и никому не мешает.
Или vehicle=yes, как вернее?

wowik, нужен не костыль, а некая идейная основа, которая позволит отличать “важные” служебные проезды от “неважных”. Иначе закончится тем что его поставят на все дороги, и его придется отключить.

Во-вторых, access=yes/vehicle=yes значит просто, что данная дорога открыта для общего пользования (остутствует шлагбаум, знак движение закрытоб …), с учетом присущих для данного типа дорог ограничений, каковыми для service является запрет транзитного рутинга.

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

Это и есть написание неких эвристических правил. Я тоже за это.

  1. Так как не надо перелопачивать все города и веси.
  2. А уж если эвристика будет врать, то только там уже разруливать в ручном режиме vehicle=destination/yes

Поэтому я и предлагаю это как прозрачный костыль.
Формально он ничего не меняет, а конвертору подсказка.
Если написано “масло”, то рутить нельзя, если написано “масло масляное”, то можно.

При любом раскладе свои любимые проезды по дворам народ раскрасит :wink: , хоть костылями, хоть по “идейной основе”

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

Сам думай, к обсуждаемой задаче это никак не отностится.

Ничего нормального. Всё как обычно с вводом лишних assumption’ов - местячково, автоматически наводняет карту ошибками по причине того, что на service никто никогда не ставил access=yes и просто зло.

И эвристики никогда ничего до конца не решали. Запрещён сквозной проезд - значит так и должно быть написано.

Вообще-то по теме именно это и есть смысл обсуждать. Потому что с access-ами никаких проблем нет.

Не требуется до конца - 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”, что намного интереснее и сложнее.