edward17, а почему один building? Потому что адрес один? Вот тут пристройки стоят под отдельным адресом, получается и building для них отдельный. И пристройка волшебным образом становится самостоятельным строением только из-за адреса? А тут говорят, что адрес и строение сущности независимые.
Да.
Да.
Я всегда считал, что один адрес - это один building=. Даже если он разделён на “куски”. И наоборот: если два разных адреса выглядят снаружи как один дом, то это всё равно два разных building=. Возможно, есть исключения, при которых эта схема не работает, но я с такими за время картографирования не сталкивался.
UPD: Поэтому использую эту схему.
Возвращаясь к вопросу о том, как замаппить здание, состоящее из “кусков”, так, чтобы у всех POI в нём был его адрес.
Если уж рисовать каждый “кусок” отдельным building=, то можно потом все эти building= собрать в мультиполигон и на мультиполигон поставить теги адреса (addr:housenumber=* и addr:street=*).
Тогда получится, что все POI, находящиеся внутри “кусков”, будут находиться внутри адреса, и им будет присваиваться этот адрес. В теории так. Не знаю, как программы-конвертеры на практике будут обрабатывать POI внутри мультиполигона, у которого нет других тегов, кроме адреса.
Об этом, кстати, уже писали раньше:
Мда, столько всего написали, но никто даже не коснулся сути, то есть основного принципа, в соответствии с которым это делается.
Базовый принцип картографии состоит в том, что карта - это условное изображение местности и свойств местных предметов.
Что из этого следует в данном случае? А вот что.
Изображение любого здания и сооружения в базе OSM - условно. Интуитивно понятно, что это, например, прямо относится к вопросу геометрии - можно нарисовать контур более подробно или менее подробно. Есть здания, которые крайне детально описаны в 3D, есть здания, которые отмечены только габаритным прямоугольником, хотя их реальный контур сложнее по форме.
Это ошибка? Нет, это условность большей степени.
Можно так делать? Так делать не запрещается, но лучше остановиться на большей степени подробности - той, которую позволяет снимок, по которому обводится контур. Это вопрос адекватной подробности. А так - можно и точки с building=yes наставить по условным центрам домов.
Хорошо, а как быть с частями здания?
Для начала - вопрос: а что делает часть здания частью, то есть условно отделяет ее? Частью здания делают ее свойства, отличающиеся от других частей. Например, одна секция здания - ниже на два этажа. Или представляет из себя пристройку из другого материала. Тут в дело вступает схема обозначения трехмерных зданий - каждая часть, имеющая отличающиеся физические свойства может быть обозначена отдельно и эти свойства могут быть для нее указаны в тегах.
Но здание, тем не менее, остается целым. И чтобы это условно отобразить, в схеме есть требование использовать общий контур с building=, покрывающий все building:part=
Теперь - о логических свойствах.
Представим, что всю стилобатную часть здания занимает магазин. По схеме Simple 3D Buildings можно обозначить такое здание двумя путями: разрезав его горизонтально (контур стилобатной части, контур основной части, на последнем - тег, обозначающий, что эта часть начинается со второго этажа), либо разрезав вертикально (высота основной части считается с уровня земли, а основная часть вычтена из контура стилобатной). С точки зрения физ. свойств, оба варианта верны. С точки зрения логических - нет. Потому что когда мы повесим теги магазина на стилобатную часть, при вертикальном делении это будет означать, что магазин будет занимать только ту часть стилобата, которая не лежит под проекцией основной части. Это ошибка? Нет, но это снова неадекватное обозначение, потому что поделить здание правильно стоит тех же усилий, так что нет причин делать это с нарушением логики.
А что с адресами?
Адрес - логическое свойство. Если у нас есть здание, которое состоит из нескольких секций с разными физическими свойствами, но имеет один адрес, логично присваивать адрес тому элементу обозначения, который является для этого здания общим (внешний контур для схему Simple 3D buildings). Если физически здание одно, а адреса разные у разных подъездов, то вполне адекватным обозначением будет повесить адреса на подъезды. Оно будет более условным, чем адрес на здании (или его части, если таковую можно выделить), но это, тем не менее, корректное обозначение.
С одинаковым адресом у двух и более физически разнесенных строений - сложнее. Если они все расположены на какой-то явно определенной территории (например, детского сада), логично назначить адрес территории, потому что адрес все же один, и при поиске будет обнаружено, что принадлежность конкретного здания к данному адресу - предмет неопределенности в пределах указанной территории. Хотя назначить адрес каждому зданию также не будет ошибкой.
Как я уже говорил, в случае, если здание имеет секции с разными свойствами, крайне предпочтительно использовать Simple 3D. Но есть весьма узкий случай, где имеет смысл использовать мультиполигоны. Представьте себе здание со стилобатной частью и несколькими основными частями, возвышающимися над ней. Все здание имеет один адрес. При этом стилобатная часть является подвальной или полуподвальной. Или, того хуже - здание стоит на склоне, и стилобат с одной стороны выступает, как полноценный первый этаж, а с другой является подвалом. В таких случаях стилобат обозначают редко (яркий пример - здание института МИРЭА в Москве). Но все, что выше стилобата - это физически одно здание. И вот тогда имеет смысл собрать его в мультиполигон и навесить все теги здания на отношение. Это пример большой условности и большая редкость, но, тем не менее, такое существует.
А если не принадлежат отдельные здания одной какой то территории, то мультиполигон собрать из них? вот так:
https://www.openstreetmap.org/relation/4595890
да там именно так и есть, сам лично ходил собирал подъезды по тому району.
Конктретно в таких случаях я бы говорил не про “территорию”, а функциональную целостность “один дом” - один building=yes.
Всегда действую по принципу:
у здания (building=) может быть только один уникальный адрес (если он дробный — всё равно он один такой).
Если двойной/тройной/четверной (короче, дробный) адрес оформляется с применением отдельной адресной точки (точек), то одну составную часть адреса обязательно заношу на контур здания, а другую — на адресную точку, располагая её внутри контура здания и поближе к той улице, по которой идёт соответствующая нумерация. Применяю именно такой способ, как наиболее поддерживаемый (и геокодерами, и рендерами).
Но, по-хорошему, красивее, удобнее и логичнее было бы применять, например, схему:
addr:housenumber=6
addr:street=Большая улица
addr2:housenumber=9
addr2:street=улица Ленина
addrN:housenumber=
addrN:street=**
или отношение associatedStreet. Но это отношение не отменяет использование адресных точек с номерами домов (в случае двойной и более адресации), что плохо и не особо отличается от обычных адресных точек.
Физические особенности в рамках каждого building= отражаю по схеме Simple 3D Buildings (создаю и соотв. отношение) или мультиполигональной. Есть случаи даже совмещения обеих схем отрисовки зданий (связано, главным образом, с нюансами «дырявости» проекций зданий и недоработанности в этом плане схемы Simple 3D).
Bushmank, Неплохо бы сию оду как-то в вики отметить
В моем городе появился картограф на редакторе iD и начал клепать такие теги на дома https://www.openstreetmap.org/way/247666487
В iD это отображается как торговая зона, т.е. там был уже адрес и был тег building=yes он этот тег удалил. Будет ли этот адрес отображаться в навигаторах и правильно ли это вообще?
Судя по всему, он типичный новичёк, которому следует указать на его ошибки. Торговая зона/территория к зданию непосредственно отношения никакого не имеет, поэтому это лажа. И не меньшая лажа вбивать названия ТАКИМИ буквами. Плохой пример заразителен, так что советую прекратить эту деятельность и дать человеку напутствие в виде ссылок на osm wiki.
Эта “ода” является всего лишь развитым изложением того, что в вики и так написано. Ничего нового я не сказал. Более того, это описание не является исчерпывающим даже близко.
Гулял тут по городу, нашел 2 интересные пои которые не знаю как правильно обозначить:
- Администрация ГО Коломна - Архивный отдел
- МУП городское бюро приватизации
Первое это скорее всего office=administrative а вот второе…
У нас два тега обозначающий одно и тоже и с одинаковым количеством использований:
shop=pyrotechnics (59)
shop=fireworks (76)
Может определиться, как обозначать и оставить что-то одно (и автоматом перетегировать ненужное). Я ко второму варианту склоняюсь.
Можно поставить office=administrative в обоих случаях. Муниципальные предприятия вполне подходят под определение office=administrative.
Оба можно указать office=company + ownership=municipal.
Такого wiki не знает. Да и company к первой точно не подходит, всё таки явно это подразделение администрации.
Во первых знает http://wiki.openstreetmap.org/wiki/Key%3Aownership,
во-вторых можно было сразу базу посмотреть http://taginfo.openstreetmap.org/keys/ownership#values
Просто до каждого отдельного тега это пока не описывали.
Администрация - через relation site отмечается, а архив - можно через company отметить, можно не отмечать.
Здравствуйте! Подскажите, пожалуйста, как обозначить языковую школу (школу английского языка)?
releation site … читал я что то про него когда то. ТОлько вот отказался от использования. Ну а в данном случае, я не уверен, что администрация правильно отмечена. Точнее даже скажу, она совсем не отмечена! Но на будущее, буду знать что releation site использовать можно.
amenity=training + training=language. Плюс, наверное, language=english.
Можно, но зачем?
Что должно быть участниками этого отношения?
Спасибо большое!