Где обсуждалось и кем?! В wiki четко написано - устаревший.
Конкретизировать можете (в блоги никаких предложений не было написано кроме фраз типа “ты не прав”)? Для входа в зоопарк существует barrier=gate, и не важно через арку, или калитку.
ЗЫ: Я не являюсь носителем английского языка, но уверен, что разницу те люди понимают прекрасно.
По законодательству можно не только подъезды рассматривать как часть дома, но и отмостки. Но мы их почему-то не рисуем
Если мне нужно вывести на карту навигатора что-нибудь нетрадиционное я не делаю никаких костылей, а уж тем более не засоряю данные собственными тегами. Надо просто сделать для себя конфиг для навитела, в котором прописать все что душе угодно. И раз уж навител не поддерживает подъезды, тогда пусть он сочетание building=entrance + ref=1 переводит в дома, но только конвертером и только для себя.
Не умеет. Подписи точек подъезда в карте есть, но они видны только в mp, в навигаторе не отображаются. Городить у каждого подъезда адресуемые надписи… наверное, можно, но загромоздит ужасно.
Это не так. Если в здании есть подъезды, НН приведет к точке дороги, ближайшей к первой точке подъезда в списке (на скриншоте с домом 70/8, кстати, видно, что маршрут заканчивается у 4-го подъезда - он первый в списке в mp).
Если подъездов в здании нет - маршрут закончится на точке дороги, ближайшей к первой вершине полигона здания.
Навигация “до подъезда” в НН работает корректно только в случае, когда в здании ровно один подъезд. Не требуйте от него большего
UPD: еще раз, систематизированно:
Если точка финиша - точка с произвольными координатами или POI, указатель финиша устанавливается в указанных координатах/POI, конечной точкой маршрута будет точка дороги, ближайшая к указанным координатам/POI.
Если точка финиша - полигон и у полигона обозначены точки подъезда, указатель финиша устанавливается в геометрическом центре полигона, а конечной точкой маршрута будет точка дороги, ближайшая к первой точке подъезда.
Если точка финиша - полигон без точек подъезда, указатель финиша устанавливается в геометрическом центре полигона, а конечной точкой маршрута будет точка дороги, ближайшая к первой вершине полигона.
Попробовал - они всегда отображаются поверх автобусных остановок с теми же координатами. Автобусная остановка, соответственно, визуально не видна. В поиске участвуют, разумеется, обе.
Если такой вариант отображения не отпугивает - добавлю в паблик.
Конфиг не поддерживает функции конъюнкции и дизъюнкции?
Т.е можно начхать на все рекомендации и будем заниматься творчеством? И если некомпетентность предложения была очевидной, почему не предприняли направленных действий по отклонению данного предложения? (вопросы риторические)
Тут не спрашивается “кто как любит”, вопрос стоит : “как надо”.
Хорошо. Под entrance = yes я понимаю дверной проём в стене для входа с улицы в здание, и выхода из здания на улицу. Меня как пользователя этого проёма интересует только, как я могу найти вход, войти и выйти. Обслуживанием здания я заниматься не собираюсь.
Вопрос для всех противников принятой схемы: Что Вы понимаете под building = entrance: навес над крыльцом, лестничные клетки с лестничными маршами (или что-то в отдельности), - мне до сих пор не понятно. И как тогда понимать совместное использование с тегом wheelchair = yes? (если в wiki нет пандусов, это не значит, что они никому не нужны - проглядели просто write-only-википисателями :P).
Вот я и говорю: чтобы обозначить подъезд, надо прописать точке на контуре дома теги building=entrance + ref=#.
Только так при конвертации в навител они будут конвертироваться в “подъезды” в том виде, в котором их понимает навител. Если этих тегов не будет, или они будут в неправильной точке - не будет и подъезда.
Желающие могут внести это в вики.
ЗЫ.
Кстати, точки entrance=main при конвертации в навител тоже используются, только совсем для других вещей: они определяют место расположения POI для полигональных объектов.
chnav, речь не о том, что это невозможно сделать, а о том, что это плохая идея.
“Подъезд” и “вход” достаточно ортогональные вещи, чтобы обозначаться по-разному.
Тем более что теги не конфликтующие
dimuzz, имеет ли конфиг возможность проверки значений ключей (тегов) с использованием логических операторов AND и OR? Если да, то можно отключить генерацию второй точки. Я не знаю структуру конфига, но на псевдоязыке можно записать так:
Ну зачем людей в заблуждение вводите? Ведь прекрасно знаете, что карты Navitel связаны с данными OSM конфигом. Что в конфиге будет, то будет и на карте Navitel.
Тогда скорее асимптотичы (нет у них общего назначения). Но это не самое главное. Если бы интересовали именно подъезды, их можно было бы просто рисовать по привычной схеме убив 2-х зайцев. Так может правильней подъезды отношениями отмечать?! Если бы захотели и открыли типы домов в поисковике, то, возможно с удивлением, обнаружили подъезды, у которых 2 двери рядом: 1-я вход в подъезд, 2-я ведёт в техническое помещение без окон. Не понимаю (да и Вы не желаете объяснять), зачем обозначать в полигоне номера квартир, если к ним ведёт конкретная дверь. Но и дверь Вас в виде точки не устраивает, её нужно обозначить как подъезд.
Информация для размышления, кому не сложно прочитать с открытыми глазами: Почему номер подъезда пишут на крыльце, а номера квартир над входом в здание (или на входной двери)?!
На том и становимся (раз Вам не интересны мои ссылки). По этой теме я Вам ссылку в указанный блог направил
Можно, но это испортит поиск, когда нужно найти остановку конкретного вида транспорта. У многих остановок trolleybus=yes и bus=yes присутствуют одновременно и терять все виды транспорта, кроме одного, не хотелось бы.
Вариант с конвертацией остановки нескольких видов транспорта в общее POI “Остановка общественного транспорта” тоже не очень хорош. В этом случае сначала потребуется поискать в остановках троллейбуса, а потом отдельно в “остановках общественного транспорта”.
Возможно, наложение POI будет меньшим из зол.