“Не рендерится” и “не помогает” - это не проблемы базы.
Это именно что проблемы базы: объекты, имеющие разное практическое значение, обозначены одинаково.
Дык я про то и говорю - если сквозной проезд запрещён, надо ставить vehicle=destination и не придумывать routed=yes и подобые костыли.
Это было бы так, если бы дороги не делились на сегменты. А vehicle=destination на сегменте - это уже ошибка
Дык destination может быть в любой точке связного графа из таких дорог, не?
Конечно, не, теги-то мы вешаем на конкретный объект, и отражать они должны свойства этого конкретного объекта
Ну тогда смысла в access=destination вообще никакого нет. Альтернативы? Объединять в отношение или вешать тэги на landuse?
Альтернатива - осознать наконец, что для роутинга нужна не просто “карта дорог”, а “карта публичных маршрутов”, и придумать способы обозначать эти маршруты. Благо, классификация основных дорог для этого и так неплохо заточена, но на граничных случаях, типа этих же сервисов, начинается уже ерунда.
На пешеходстве это, кстати, ещё сильнее проявляется
Это набор слов. Давай что-нибудь поконкретнее.
Вот ещё. Сам думай
Не мешки ворочать, да? 
Меня лично абсолютно устраивает отсутствие маловнятных лишних тэгов на service, и роутинг по всем дорогам.
А остальных нет, они предпочитают просто выкинуть сервисы. Собственно, о чём эта тема и есть.
Ну это пока лучший вариант на фоне конкретно костыльного routed= и попытке что-то гадать на основе неврятных признаков.
Было озвучено две проблемы - сквозной роутинг и количество дорог. Второй вообще никак не решается, потому что большая часть service это таки дворовые проезды, и как их не обозначай, если не влезает придётся выкидывать всё. А первый, всё-таки - vehicle=destination. Таки да, он отражает свойство конкретного сегмента в том, что по нему можно проехать не далее чем в “зону destination”. То, что она определена весьма расплывчато - дело десятое, однако и на роутинг это замечательно ложится, и при неумении элементарно выкидывается, решая заодно вторую проблему.
Не, ты так и не понял 
Проблема-то не в этом. А как раз в том, что:
То есть сам по себе service - это вся мелочь, сваленная в кучу. И хотя для роутинга часть этой мелочи довольно важна, вычленить её из этой кучи нет никакой возможности
Так в том-то и проблема, что все service практически и есть destination! Сравните описание service и описание в ПДД “прилегающих территорий”. Заправки, дворы, парковки, внутри предприятий…
Просто народ хочет рутить и по destination! По парковкам, которые тоже не для транзита строятся. Но софт не тянет и/или не доделан.
И под годым флагом “мы не провоцируем пользователей на нарушение ПДД!” все service убирают чохом.
Любая попытка частично разрешить рутинг по service — это костыли для обхода проблем в современных программах.
Пользователи некоторых программ периодически просят “стратегически важные” service включить в рутинг, и добиваются этого у своих картостроителей, хотя все service ранее были выкинуты под упомянутым выше флагом.
Как мне кажется, проблема запрета транзита может быть решена наложением громадного времени проезда таких дуг, что не требует больших переделок конверторов. Да и огромных проблем с честным просчетом ситуации в навигационной программе я не вижу. Собственно то же штраф, только он по определению должен забивать всё остальное.
А вот проблема “прореживания” графа — гораздо серьезней.
- Или надо всё разметить: “это включаем, а это нет”. А поскольку по умолчанию хочется-таки не включать, то разметка получается “это включаем принудительно”.
- Или накрутить кучу эвристики: “сервис на парковке - можно рутить” т.п. и размечать уже осмысленные категории - парковки и т.п.
Во как повернулась проблема В Garmin можно сказать в этом плане относительно нормально, сервисы в большинстве своем объезжает, что не объезжает иногда лечится маленьким maxspeed_practical, destination или не лечится совсем, а тут только помог бы какой-нибудь routed_garmin=no В разрезе появления костыльной точечной адресации в автосборке service (читай дворовый проезды) очень полезны, да и основные крупные вендоры начали прорисовку дворовых проездов на навигационных картах.
если положить, что все service по умолчанию access=destination, то логичным тегом обозначит обратное есть уже существующий access=yes
Oстается быстренько допилить конверторы и закрывать тему, ибо тема собственно была о том, “как обозначить?”
Вообще-то, я только что написал как это можно сделать. Если ты предлагаешь разбить service на подкатегории, то я несогласен - если highway и так уже разбиты весьма размыто и вызывают кучу вопросов, то здесь никаких сколько-нибудь чётких границ вообще не видно. Например, предложенные service=alley|driveway вообще чуть ли не совпадают, ставят их мало - в итоге, озвученных проблем это не решает. Зато вместо того чтобы гадать, alley это или driveway, можно поставить вполне конкретный vehicle=destination, причём иметь для этого стимул ибо это сразу означает запрет умникам объезжать пробки по твоему двору. Если не хватает access, есть/могут быть другие свойства.
Не по умолчанию, а по определению. С тем же успехом можно некоторые, особо продвинутые, дороги поднять до unclassified.
“Громадное время”, кроме того что его не всегда возможно прикрутить, негативно сказывается на правильности расчетного времени доезда.
Если я правильно понимаю driveway это фактически тупик, подъезд, а alley это как раз что-то типа наших местных дворовых проездов с living_street=yes, а в приведенном выше районе, эти теги используются вовсю, но что-то я сомневаюсь в их правильности, однозначно надо подрихтовать страницу с service исключив неоднозначности и добавив дворовые проезды.