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

Конечно, не, теги-то мы вешаем на конкретный объект, и отражать они должны свойства этого конкретного объекта

Ну тогда смысла в access=destination вообще никакого нет. Альтернативы? Объединять в отношение или вешать тэги на landuse?

Альтернатива - осознать наконец, что для роутинга нужна не просто “карта дорог”, а “карта публичных маршрутов”, и придумать способы обозначать эти маршруты. Благо, классификация основных дорог для этого и так неплохо заточена, но на граничных случаях, типа этих же сервисов, начинается уже ерунда.

На пешеходстве это, кстати, ещё сильнее проявляется

Это набор слов. Давай что-нибудь поконкретнее.

Вот ещё. Сам думай

Не мешки ворочать, да? :slight_smile: Меня лично абсолютно устраивает отсутствие маловнятных лишних тэгов на service, и роутинг по всем дорогам.

А остальных нет, они предпочитают просто выкинуть сервисы. Собственно, о чём эта тема и есть.

Ну это пока лучший вариант на фоне конкретно костыльного routed= и попытке что-то гадать на основе неврятных признаков.
Было озвучено две проблемы - сквозной роутинг и количество дорог. Второй вообще никак не решается, потому что большая часть service это таки дворовые проезды, и как их не обозначай, если не влезает придётся выкидывать всё. А первый, всё-таки - vehicle=destination. Таки да, он отражает свойство конкретного сегмента в том, что по нему можно проехать не далее чем в “зону destination”. То, что она определена весьма расплывчато - дело десятое, однако и на роутинг это замечательно ложится, и при неумении элементарно выкидывается, решая заодно вторую проблему.

Не, ты так и не понял :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??