Обсуждаем способы задать адресацию

Всю страну нормализировать не нужно: достаточно дублировать на первом попавшемся place=* (city, suburb) теги стран, городов, областей.

Внутри НП: должны быть объекты адресных улиц. Логичнее всего их тегировать через relation street. Уже в этих отношениях легко указывается Википедия, несколько языков и прочее.

Если так нужен этот Номинатим (или что там ещё отношения не поддерживает?), то оставить для него теги Карлсруэ на домах и POI.

Я посмотрел этот и этот примеры. Были какие-то ещё?

Вопрос: новички гарантированно не будут добавлять новые POI в здании в отношение associatedAddress. Как предполагается бороться с этим? Или никак?

Если адрес один, то ставим его на контур здания и все POI внутри легко и безошибочно получают этот адрес по методу геометрической вложенности.

Присвоить несколько адресов точкам POI в здании? Да, украинская схема этого не умеет.

А они когда-то не справлялись?

Nominatim сейчас поддерживает отношения type=associatedStreet, не поддерживает type=street.

Так, погодите-ка.
Глянул ещё раз на отношение в Витебске и увидел, что там только один участник в роли “address”. Это что же, предлагается для всех домиков такое использовать, а не только для зданий со множественной адресацией?

Кстати, надо бы добавить эту линию в это отношение :wink:

Если написать патч к iD и плагин к JOSM - то почему будут?

Конкретно с этим вопросом валидатором бороться очень просто. Нет родительского отношения когда есть addr:housenumber - значит ошибка, исправляем либо вручную либо ботом.

Скачиваете точки с addr:housenumber.
Скачиваете отношения associatedAddress и всех детей с ролью “address”.
Отгружаете отношения associatedAddress и всех детей с ролью “address”.
Всё что осталось - данные затегированные не по associatedAddress.

Одна схема тегирования в данных лучше чем 3-5 одновременно. В данном случае - почему и не associatedAddress.

20 страниц разглагольствований, а оказалось, что всё может сделать бот/постобработка. Так на кой х…р оно тогда надо?

Ни на какой. Выгрузку улиц Москвы давай. У тебя 3 минуты и это вопрос новичка: http://forum.openstreetmap.org/viewtopic.php?pid=525087#p525087

Почти ничего за 6 лет не поменялось: http://forum.openstreetmap.org/viewtopic.php?pid=61670#p61670

  1. интерес чисто номинальный к ней, страна указана на городах и областях
  2. НП в базе затегированы как я сказал (http://forum.openstreetmap.org/viewtopic.php?pid=571870#p571870) + тег страны есть на областях и краях
  3. решает associatedAddress и relation associatedStreet / street
  4. решает indoor тегирование (в этой теме не обсуждалось в должной мере)

Ой планета не успела скачаться за 3 минуты, всё удаляю аккаунт из осм и бросаю это гиблое дело.
Такие халявщики не переведутся никогда, которым вынь да положи. На них как раз надо стричь бабло и чем сложнее схема, тем больше профит :slight_smile:

Отношение позволяет добавлять любое количество адресов (в моём случае просто не нашлось ТЦ с двойным адресом), в украинском примере, ведь, всё нормально (в нём только нет POI )? И ещё момент: если мы отделяем от контура зданий адреса (когда их несколько) на адресные точки, то это логично делать и для одноадресных зданий, чтобы ассоциировать потом с этой адресной точкой все POI. Это, пожалуй, единственное расхождение со «структурой сегодняшнего дня». Можно пойти иным путём и включать контур здания в отношение дважды, но присваивать две роли: address и object (нечто похожее кто-то предлагал здесь).
Линию добавлю, конечно.

Будут, если приложить к этому усилия: информировать, что это более грамотный подход на сегодня; показать примеры; сделать обучающие гифки/видео/скриншоты; поддержать в редакторах, как уже сказано.

Об этом и толкую. А справляться-то — справлялись, но явно не делали интерполяцию мультиадресности с контура здания на POI (для самого здания она не особо нужна, т. к. достаточно нахождения самих адресных точек (позиционирования на них) «внутри здания»).
Хорошо бы задать вопрос людям, которые занимаются различными видами обработки адресных данных OSM, понравится ли им такая схема и облегчит ли она им (их софту) жизнь?
Как, опять же, было замечено — никто никого не принуждает ни к чему и не призывает что-то ломать. Только повысить уровень организации данных. Минимальными усилиями достичь (потенциально) ощутимого эффекта. Конечно же, его никто никогда не почувствует, если такая схема тегирования охватит одну вымирающую деревеньку у чёрта на куличках и о ней (схеме) никто знать ничего не будет. И не будет ничего, если не начинать делать.

Ради смеха запустил простой запрос за 1 секунду и 20 килобайт памяти http://overpass-turbo.eu/s/dNM

[out:json][timeout:1][maxsize:20000];
{{geocodeArea:Херсон}}->.searchArea;
(
  relation["type"="associatedStreet"](area.searchArea);
);
out tags;

Где нормально затегированные объекты в Москве?

Я понять не могу что предлагается сделать то?

Использовать street вместо associatedStreet - шило на мыло, хотя название чуть короче.
Использовать белорусскую адресацию - пожалуйста, но без препроцессора ее никто не понимает.
Использовать адресацию на точках - можно и сейчас, если вам так больше нравится, все только за.
Использовать адресацию на точках + отношение - да пожалуйста.

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

Я точно знаю сколько их. Именно обычно 2-3 куска. И знаю, что дублировать на них достаточно name, остальное может висеть на одном куске - этого достаточно.
То есть wikipеdia, name:mrj или alt_name достаточно держать на одном куске улицы.
При склеивании кусков в единый объект (по совпадению name) дополнительная информация замечательно объединяется.
Так же приклеиваются к улице и домики, только по имени улицы. Многоязычность имен улиц на домиках - это придумка для обхода ограничений одного известного конвертора. addr:street это же просто такая ссылка по name на другой объект.
Ссылку совсем убрать не удасться, можно только заменить, например отношением, но о какой экономии мы тогда говорим?

Посмотрел в ФИАС, там это поле, если не пустое, имеет тип “строение”, “сооружение” или “литер”.
На практике “строение” и “сооружение” зачастую не различают.

Именно это.

Участники не при чём, но цель — чтобы стали причастны.
Согласны не все, а цель — убедить многих, показав, что это работает и работает лучше (тогда другие подходы не будут привлекательны, что сократит неразбериху в них, как минимум).

Часто упоминавшаяся белорусская схема адресации, сколько участников о ней знали? Сколько из них (и потенциальных — в том числе) могли в ней разобраться? Какие общие корни она имела с уже распространёнными схемами? Ответом на все эти вопросы будет «почти никто» или «почти никак». Отсюда — её предсказуемый уход со сцены.
Вот был предложен похожий на мою схему, но более комплексный подход, где всё организовывалось в рамках отношения type=building.
К сожалению, выяснил, попробовав, что iD катастрофически не приспособлен для редактирования отношений, если у них нет, например, тега name (или другого). Тогда просто невозможно выбрать конкретное отношение для работы над ним/с ним (добавлять новых участников — самое основное). Рекомендация использовать временные фейковые имена в процессе редактирования, а перед сохранением данных — удалять их, — будет глуповато выглядеть.
После JOSM, в iD чувствую себя инвалидом (человеком с ограниченными возможностями) :expressionless:
А на официальном сайте — только бледный косвенный намёк на существование JOSM (мол, iD и Potlatch2 — рулят, а остальное — ерунда, не заслуживающая внимания, что само по себе является инверсией действительности в угоду ущербности).

Очевидно, что какие бы сильные аргументы я ни привёл — подобная инициатива не сдвинется с мёртвой точки, если только я сам не «напишу», например, конвертер в польский формат (а это невозможно в силу отсутствия квалификации) или не найдутся сторонники идеи, которые помогут довести её до логического конца (практического применения) тем или иным путём (подключением соотв. людей или непосредственным участием).

LLlypuk82, когда в РБ была эта “белорусская” схема адресации, все кто пытался работать с Беларусью в OSM о ней и знали :slight_smile: - проблема была в том, что с сырыми данными без препроцессинга работать было нельзя. Именно поэтому отказались от ее использования. /Ну еще и потому что память в компе у того кто препроцессингом занимался закончилась :)/

И сколько ждать выполнения этого чуда для Москвы? Сколько памяти займёт для Москвы выбрать все улицы этим способом?

Проверки на совпадения имён - на плечи потребителя данных.
Проверки на 2-3 куска - на плечи потребителя данных.
Проверки каждого куска на наличие тега Википедии - на плечи потребителя данных.
Грабли одноименных улиц (даже в рамках одного Питера) расставим и пользователям не скажем как обходить (“только по имени улицы”).

… почему на хабре о OSM про красноглазых говорят?

Адресная улица это отдельная сущность и должна быть в базе явно для простоты пользователей “адресных улиц”. Не нужно её подменять “именами улиц” разбросанными по кускам highway.

“улица” это те 60-80 домов, школ и заводов в одном отношении. Возможность банально посчитать количество улиц (без написания при этом геокодера!) должна быть в сырых данных.

Автор Разработчик Nominatim-а заявляла в 12-м что “теги addr:street быстрее обрабатываются”. Так вот это не так для всех задач. Особенно когда пользователю всё равно: 50000 адресных точек в Москве или уже 500000; ему нужны другие инструменты для работы с “улицами”.

d1g, обычному пользователю не надо “банально посчитать количество улиц”. Давайте не будем рассматривать OSM как инструмент для профи. Что надо обычным людям? - им надо что бы они могли найти конкретное здание-сущность по конкретному адресу. Как это там будет внутри устроено им абсолютно все равно. И если они не находят этого в картах OSM - а находят в каком нибудь навителе - то все - для них OSM отстой - ведь там же ничего нет из того что они искали. Ну и тут им говорят - а Вы сами заполните адресок в OSM - и он появится для следующего поиска - и что он будет разбираться со всякими отношениями? - нет конечно - он просто забудет об OSM и все. Тот у кого уровень выше среднего или тот кто конкретно занимается обработкой существующих данных OSM и улицы посчитает, и домики и все что там есть, применяя те знания, которые нужны для этого, а чего не знает - научится. И если ему надо работать по серьезному с данными OSM то сконвертирует в нужный формат и все у него будет быстро и искаться и считаться. Я застал и расцвет и смерть белорусской схемы адресации, и прекрасно видел, в какой тупик ставят релейшены неподготовленных пользователей, и если просто внести адрес при помощи тегов как на соседнем здании ни у кого не вызывало проблем, то добавить в какой то релейшен зачем то - это был темный лес…

Возможно не в тему, но все же спрошу. В некоторых маленьких населенных пунктах, а так же в садовых товариществах нет улиц, номеров домов, есть только номера участков, Как их сдедует тегировать?