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

Если отношение, то какое? Мультполигон или что-то специальное?

просто отношение, без типа.

Не совсем по теме но ИМХО имеет смысл добавлять адрес к POI. С тегов зданий, наоборот убирать всякие amenty, shop и т.д. Должно быть просто здание, а всякие обвесы оформлять в виде POI.
Теги адреса у POI позволят однозначно его идентифицировать и использовать в проектах подобных этому: http://www.maps51.ru Правда, в этом проекте разрабртчик использует собственную базу POI, поскольку считает, что так ему будет проще поддерживать её в актуальном состоянии, плюс не хочет засорять ОСМ избыточной информацией. При этом он готов экспортировать данные в ОСМ (например, обновить время работы кафешки или изменившийся номер телефона, или вообще удалить точку,если заведение закрылолсь), вот тут почтовый адрес в POI просто необходим.

Ну и потеряем кучу полезной информации. Территорию больниц/детсадов как отмечать собираетесь?

Не получится там однозначности.

Это кто-то поддерживает?

Дык он есть, только не на каждой точке, а один раз на доме. Приколько будет поддерживать mall с тысячей магазинов, задавая для каждого адрес. А особенно учитывая что у нас творится с адресами (по разным улицам, официальные и on-ground, с разными комбинациями дробей и т.д.).

Не согласен. Если заведение занимает все здание - то оно и есть здание и тэги должны быть на здании.

Абсолютно.
Кроме того, повторюсь, у POI есть адрес - адрес вмещающего это пои здания.

А я ничего плохого в адресации точек 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 здания на месте одного, да ещё и накладывающиеся, не могут быть корректными.