Еще об адресах

А я ничего плохого в адресации точек POI, как самостоятельных объектов не вижу, аля вывески на магазинах, на каждой вывеске или контактах фирмы на сайте тоже есть адрес, причем бывает и не редко, он отличается от адреса дома, строением там или дробью, или еще какой неправильной мелочью. И многие ли сервисы умеют вытаскивать адрес из полигона на точку? Или, например, сдвинули дом по подложке, а пара точек выехало за границу, кто за этим следить будет? Мы же не только к идеальной нормальной форме БД стремимся, в конце концов.

Если не умеют - пусть учатся. В перспективе адрес на доме ничем не хуже адреса на POI (потому как он есть). А лучше тем, что адреса (включая все разночтения с дробями и прочим) будут в одном месте, и будут работать для всех точек сразу, и дублирования нет. Хотя вообще говоря для POI имеет смысл юридический адрес указывать.

Кто двигает, разумеется.

Я, и не только я, хочу видеть адрес точки при поиске сейчас, а не когда кто-то чему-то научится.

А что здесь поддерживать, название улицы поди не часто меняется?

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

Так допилите поиск. Я в мапнике тоже хочу 3D здания, но я же не пририсовываю зданиям стены в проекции.

Надо в очередной раз напоминать почему люди хотят обозначать улицы relation’ами, сколько реально адресов обозначено в Москве и сколько при этом правильно?

извините, но я а) не буду перелопачивать тысячи собранных poi, добавляя им адрес, только потому что какая-то сомнительная программа не умеет вытаскивать адреса из содержащих их домов; б) не вижу смысла проставлять адреса для poi, потому что это всё усложняет и вносит избыточность, что мне, как программисту, работающему с базами данных и ценящему нормализацию, мозолит глаз.

Тогда присутствие в географических названичях слов “улица”, “остров” и т.д. должно просто бесить, ибо чудовищный косяк с точки зрения нормализации БД! Я этот явный мусор в названия не пишу, однако чуствую, что вменяемого рендера, который будет дописывать эти префиксы автоматически ожидать не стоит.
Не могу судить на 100% уверенно, но подозреваю, что индексирование точек POI посредством нахождения полигона, в котором они расположены требует существенно больших вычислительных затрат в сравнении с вульгарным строковым индексом. Впрочем, если ступни программиста покоятся на тёплом ящике с бездонными вычислительными ресурсами, тогда да, волноваться не о чем. Абсолютное большинство и не волнуется. Не оттого ли все геоинформационные приложения, работающие на мобильных платформах в плане быстродействия - унылое говно?

Абсолютно ничего не теряем, напротив, получаем взамен внятную и однообразную структуру данных, а не “в лес - по дрова”. Ставим POI и туда заносим все необходимое. Даже с точкит зрения рендера есть удобства - сохраняется номер здания на карте.
Вам не кажется, что архитектурное сооружение и организация, которая это сооружение использует суть разные вещи и эта разница должна имет отражение в структуре БД?
С точки зрения лени проблем не вижу, ибо редактировать POI намного удобнее. Их, как минимум, сразу видно в редакторе, а building - чёрный ящик. Пока не ткнёшь мышом, не ясно есть там чего или нет.
Опять же, если эффективному менагеру захочется внести свой “ООО Лабеан” в OSM, то весьма желательно подсунуть ему редактор POI типа этого: http://ae.osmsurround.org/ae/index чтоб он не перся самостоятельно править теги на buldinge, как говорится, “во избежании…”

Территорию больниц/детсадов при помощи POI и тегов на здании отмечать не собираюсь. Для этого есть другие средства.

Если один пишет “Строителей” другой “Строителей улица”, третий “Строителей ул.”, то, конечно, не получится. Ибо это уже не БД, а бордель. (Что мы и имеем в реальности.) Тем не менее, небольшие города обычно делаются “в одну харю” и там вполне можно соблюдать жесткие и однозначные правила адресации.

Однообразную - да, а вот на счёт внятности - не согласен.

Нифига подобного. Сразу видно только то для чего есть соответствующая иконка у редактора (по крайней мере в JOSM). Как только ставишь тег, который редактор не знает (например тот же office) - получаешь просто точку. “Пока не ткнёшь мышом, не ясно есть там чего или нет.”. А здания с тегами, известными редактору так же отличаются, так что не вижу особой разницы.

Какие именно?

На небольших объёмах хорошо работают даже самые кривые и примитивные алгоритмы. Хороший алгоритм тем и отличается, что его относительно легко и удобно масштабировать.

Вся Россия, и уж тем более ОСМ в одну харю не делается, и от местечковых правил толку в глобальном масштабе - 0.

Опять прошу поднять вопрос пристроек… до сих пор нет единого мнения как их рисовать… :slight_smile:

А почему не получиться то через 3 мультиполигона?

А----Б------В
! ! !
! ! !
Г-----Д-----Е

где
АБГД - здание
БВЕД - пристрой

Будет 3 линии
БАГД
БВЕД
БД

И 3 мультиполигона
БАГД,БВЕД - с адресом
БАГД,БД - с левелами
БВЕД,БД - с левелами

Редактировать это конечно удовольствия мало, но это не нарушает правила что у мультиполигона не должно быть 2-х граничащих полигонов в роли outer.

Дурдом, если честно :slight_smile:

Ага, но формально корректный дурдом :slight_smile:

3 здания на месте одного, да ещё и накладывающиеся, не могут быть корректными.

Ну не ставьте внутренним мультиполигонам building

Вообще-то у полигона есть направление обхода и полигоны АБВГА и АГВБА должны рисоваться по-разному.
Ну, либо манипуляции с ролями inner и outer.

Ну и не будет объектов тогда, у которых этажи.

Понеслась :slight_smile: Вот я и буду рисовать как попало, такие здания :slight_smile:

Щито? На рисунке таких полигонов нет, а направление обхода для зданий значения не имеет.

Направление обхода имеет значение емнимп для береговых линий, земляных валов, и ледников. В описалове на мультиполигон про направление обхода вроде ничего не говориться. inner и outer - в общем то и нужны чтобы не заморачиваться с направлением обхода.

AMDmi3, я честно говоря вообще уже сомневаюсь в существовании схемы которая устроит, даже не большинство, а хотя-бы всех активно обсуждающих эту тему. (Это я про переменную этажность).

Я по рабоче-крестьянски поступил бы - проставил бы адрес обоим. Да некошерно - да копирование информации, да две сущности с одним адресом.

Это я к тому, что картинка с 3 мультиполигонами - просто иллюстрация к тому что составить 3 мультиполигона которые будут соответсвовать требованиям к мультиполигонам в этой ситуации - можно.

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