Объект (существующий физически или виртуально), к которому непосредственно относится номер дома. Например, в деревне Новое Девяткино рядом есть три дома номер 1. У одного из них номер относится непосредственно к деревне, у двух других - к улицам этой деревни. Поэтому “окончания адресов” в адресах этих домов “[деревня] Девяткино, дом 1”, “Центральная улица, дом 1”, “Солнечная улица, дом 1”.
Адрес — это цепочка по иерархии. Если какой-то уровень опущен, то это допустимо.
Для построения адреса это не помеха.
“Привязка к объекту адресации” может плавать.
Могу так определить:
Это самый нижний непустой уровень иерархии, например микрорайон (addr:suburb), квартал (addr:quater)
wowik, насколько я вижу (пока я ознакомился с темой довольно бегло), есть две разных точки зрения: “нужно явно указывать объект адресации: это позволяет более легко строить адреса и детектировать ошибки” и “объект адресации не нужно указывать явно: для построения адреса это не необходимо, а детектирование ошибок не является целью заполнения данных OSM”. Мне кажется, компромиссом должна быть констатация того факта, что “явное указание объекта адресации может быть полезным, имеет своё применение, не является ошибкой - соответственно, редакторы могут явно указывать объект адресации, если захотят: это не является ошибкой”. Нужно не чтобы на вопрос участника А участник Б говорил “надо явно указывать объект адресации”, а участник В - “не надо”, а чтобы участники Б и В говорили “если хотите, можете указать, но учтите, что кто-то считает это нужным, а кто-то - нет”.
детектирование фактически ошибок а адресах не является целью заполнения данных OSM. Нужна сторонняя база верных адресов.
детектирование ошибок заполнения адресов возможна в рамках OSM, но не является целью схемы addr:, для валидации лучше использовать другие OSM схемы (validate:).
Я согласен с **Dinamik ** и говорю об этом потому, что считаю это важным. Не по адресации (хотя и тут согласен), а в том, что по обозначениям/схемам должен быть консенсус, допускающий по некоторым вопросам различные схемы/варианты. Если половина участников считает так, а другая половина - эдак, и две этих схемы могут сосуществовать, то следует их обе признать допустимыми.
Слишком часто новички на свои вопросы получают не ответы, а холивары на многие страницы, в которых новичку разобраться трудно - проще плюнуть и пойти на на НЯК. Гораздо более правильно было бы и в вики, и во всяких FAQ и HowTo объективно и правдиво писать что-то вроде “это можно делать 1) так или 2) так, на этот счет среди активных участников существуют разные мнения, плюсы и минусы решения 1) - такие-то, у решения 2) - такие-то.”
Такой консенсус пошел бы на пользу сообществу, упростил бы написание конверторов, рендеров и навигаторов, не отпугивал бы новичков и не вводил бы их в заблуждение и сэкономил бы место на страницах форума.
Я думаю, что абсолютный и безальтернативный консенсус по всем вопросам недостижим, а холивары - вредны. В этих условиях остается признать допустимость вариантов.
По факту всё так и есть.
Наличие addr:place и не является ошибкой, и никак не используется для построения адреса
Поэтому значимые данные в него писать нет смысла, хотя для пущего чсв можно и заполнить.
Говорим за себя, ок? Я как раз планирую использование.
Так может написать к нему строгую документацию? А то у нас нормальный разговор - “все варианты есть костыли, но я компромиссы не обсуждаю”.
И опять не так. Детектирование фактических ошибок не является целью ОСМ. Но детектирование технических - является. Обязательность указания объекта адресации позволяет выполнять детектирование технических ошибок.
Сравним с 3D: допустим мы решим проверить пригодность района на построение трехмерной модели. Нам надо проверить что у каждого дома заполнена высота или этажность и форма крыши. Однако если мы решим, что плоская форма крыши может не заполняться, то никогда мы не узнаем остались ли в районе недописанные домики или нет. Возможно все дома без roof:shape на самом деле имеют плоскую крышу. А возможно для кого-то просто не поставили нужный roof:shape.
Аналогично и с адресами. При отсутствии явно указанного адресного объекта возможно этот дом адресуется по ближашей территории. Возможно по ближайшей улице. Возможно по addr:city. А возможно по дальней улице, но тег просто не забили.
Сегодня очевидно что указанная улица - это адресный объект. (ну в 99% случаев). Если же улица не указана, то менее очевидная, но относительно сложившаяся практика - адресный элемент указан в addr:place.
Этот порядок можно уточнять, можно формализовать, можно заносить в вики.
Но в любом случае разговор о том, что “адресный объект может быть вычислен и не должен заноситься” в форме reductio ad absurdum выглядит как “давайте примем замкнутую линию без тегов как building=yes” (если мы можем принять такое соглашение, то зачем нам лепить теги на дома, а?).
Если же улица не указана, то традиционная сложившаяся практика - адресный элемент указан в самом нижнем по иерархии непустом addr:*
Понятие “адресный элемент” для адресации не важено. Адрес - это совокупность элементов по иерархии.
Для его построения не нужно отмечать крайний в этой иерархии каким-то специальным методом, как “адресный элемент”.
Как ставил на контур здания addr:city так и буду дальше ставить ни чего менять на addr:place не буду. В JOSM в редакторе номеров зданий ни каких addr:place нет.
Если указаны все - то не нужно. А если указано произвольное количество, то нужно чтобы понять указан последний или нет.
Отсутствие явного выделения типа “адресный элемент” связано с тем, что схема тегирования неявно подразумевает наличие улицы у каждого дома. И упоминается как
Отсутствие улицы и указания какой адресный элемент последний приводит к тому, что невозможно определить пропущена улица или адресация по addr:city или адресация по addr:suburb который тоже пропущен.
Ткните где написано что place не утвержден.
2)Что мешает таки утвердить, если оно не утверждено.