Ну как минимум группировка всех “адресов” (адресных точек) на один тип объектов OSM (отношения).
Чтобы был один объект которому указывать теги википедии, нескольких имён на многих языках и прочего.
Ещё просто не решаемый вопрос это выбор всех “улиц” в городе. relation street помогает в этом случае.
при том что несколько адресов одному объекту из OSM задать нельзя нормально (только AddrN). Либо ничем не связанные адресные точки.
Применяемых решений слишком много и они не решают все задачи. Простые теги addr:housenumber addr:street не поддерживают многоязычности если их применять на самих объектах адресации.
Преимущества relation street и associatedAddress в том что они выделяют “адресный набор” в отдельные сущности от адресуемого объекта (дома, POI).
associatedAddress вообще выделяет адрес (адресная точка), адресный набор (отношение associatedAddress) и адресуемые объекты (участники associatedAddress).
Причём и в участники и в relation street учитывается many-to-many отношения в первую очередь, а не в последнюю. Поэтому с такой схемой дубликатов-тегов-адресов в базе будет меньше.
Я был свидетелем смерти “белорусской” схемы адресации в пользу существующего “бардака”. Как я понимаю, предлагается нечто схожее на самом нижнем уровне - домиках и POI.
Нынешняя “проблема” множественных адресов не в плохих или хороших схемах, а в отсутствии поддержки у софта. Заинтересованные лица давно мапят addrN:* .
Если до сих пор не удалось пропихнуть их поддержку повсеместно, то почему другую схему вдруг примут с распростёртыми объятиями?
Избыточность данных не есть безусловное зло. Речь человека избыточна наполовину и это позволяет понимать частично расслышаное. В базе, где какая-то часть информации может быть в любой момент вольно или не вольно искажена, некоторая избыточность оказывается весьма кстати.
Когда “белорусская” схема адресации была полностью внедрена в Беларуси - выяснилось сразу что без препроцессирования данные никому не нужны, а заниматься приведением данных в удобоваримый вид никому не упиралось. Поэтому и померла схема - хотя избыточность хранения данных она конечно победила - но кому это оказалось надо? - оказывается никому… Вернулись к тому что имеем - и все ищется, всеми поддерживается, в любых редакторах без всяких плагинов и все понятно. Насаждать схему которую можно потом разгрести только при соответствующей квалификации смысла нет, какими бы простыми релейшены не были - все равно с ними работать не сильно интересно… Что касается поддержки мультиязычности - то вот пусть кому это надо и используют необходимую обработку имеющихся данных и на основе этой обработки и создают карты на нужных языках, в принципе так это сейчас и работает. Так что если есть желание все таки делать очердной армагедон в данных - выберите какой нибудь город, желательно небольшой и особо никому не нужный - и тренируйтесь, пытайтесь убедить разработчиков софта что Ваша схема найлучшайшая и самая достойная - а там смотришь и весь мир подтянется
Т.е. все “недостатки” той схемы были в том, что для неё никто не написал препроцессор для отдельных программ?
Сейчас нужна не одна! А целый десяток схем которые учитывают все “местные особенности” тегирования. Карлсруэ не используется в/на Украине. Кто вам насаждает relation street? Их уже сейчас используют.
Отношения в iD сейчас корректировать и создавать можно без головной боли.
Не сильно интересно - что это значит?
Нет, сырые данные должны быть настолько удобными чтобы ими можно было решать бОльший круг задач. http://www.openstreetmap.org/relation/4655900 - сколько есть названий, столько и указывают.
Даже если и в 2-3 раза. “улицы” дублируются по 50-100-200 раз. Вы это специально забываете?
Новички их вводят вручную потому что видят вокруг что “все теги адресации указаны” и указывают все дублирующиеся теги на каждом новом доме и магазине: Россия-Иваново-…
Есть другие объекты на которые нужно уделять внимание, а не заниматься расстановкой тегов которые всё равно определяются границей НП.
Всю страну нормализировать не нужно: достаточно дублировать на первом попавшемся place=* (city, suburb) теги стран, городов, областей.
Внутри НП: должны быть объекты адресных улиц. Логичнее всего их тегировать через relation street. Уже в этих отношениях легко указывается Википедия, несколько языков и прочее.
Если так нужен этот Номинатим (или что там ещё отношения не поддерживает?), то оставить для него теги Карлсруэ на домах и POI.
Так, погодите-ка.
Глянул ещё раз на отношение в Витебске и увидел, что там только один участник в роли “address”. Это что же, предлагается для всех домиков такое использовать, а не только для зданий со множественной адресацией?
Кстати, надо бы добавить эту линию в это отношение
Если написать патч к iD и плагин к JOSM - то почему будут?
Конкретно с этим вопросом валидатором бороться очень просто. Нет родительского отношения когда есть addr:housenumber - значит ошибка, исправляем либо вручную либо ботом.
Скачиваете точки с addr:housenumber.
Скачиваете отношения associatedAddress и всех детей с ролью “address”.
Отгружаете отношения associatedAddress и всех детей с ролью “address”.
Всё что осталось - данные затегированные не по associatedAddress.
Одна схема тегирования в данных лучше чем 3-5 одновременно. В данном случае - почему и не associatedAddress.
Ой планета не успела скачаться за 3 минуты, всё удаляю аккаунт из осм и бросаю это гиблое дело.
Такие халявщики не переведутся никогда, которым вынь да положи. На них как раз надо стричь бабло и чем сложнее схема, тем больше профит
Отношение позволяет добавлять любое количество адресов (в моём случае просто не нашлось ТЦ с двойным адресом), в украинском примере, ведь, всё нормально (в нём только нет POI )? И ещё момент: если мы отделяем от контура зданий адреса (когда их несколько) на адресные точки, то это логично делать и для одноадресных зданий, чтобы ассоциировать потом с этой адресной точкой все POI. Это, пожалуй, единственное расхождение со «структурой сегодняшнего дня». Можно пойти иным путём и включать контур здания в отношение дважды, но присваивать две роли: address и object (нечто похожее кто-то предлагал здесь).
Линию добавлю, конечно.
Будут, если приложить к этому усилия: информировать, что это более грамотный подход на сегодня; показать примеры; сделать обучающие гифки/видео/скриншоты; поддержать в редакторах, как уже сказано.
Об этом и толкую. А справляться-то — справлялись, но явно не делали интерполяцию мультиадресности с контура здания на POI (для самого здания она не особо нужна, т. к. достаточно нахождения самих адресных точек (позиционирования на них) «внутри здания»).
Хорошо бы задать вопрос людям, которые занимаются различными видами обработки адресных данных OSM, понравится ли им такая схема и облегчит ли она им (их софту) жизнь?
Как, опять же, было замечено — никто никого не принуждает ни к чему и не призывает что-то ломать. Только повысить уровень организации данных. Минимальными усилиями достичь (потенциально) ощутимого эффекта. Конечно же, его никто никогда не почувствует, если такая схема тегирования охватит одну вымирающую деревеньку у чёрта на куличках и о ней (схеме) никто знать ничего не будет. И не будет ничего, если не начинать делать.
Использовать street вместо associatedStreet - шило на мыло, хотя название чуть короче.
Использовать белорусскую адресацию - пожалуйста, но без препроцессора ее никто не понимает.
Использовать адресацию на точках - можно и сейчас, если вам так больше нравится, все только за.
Использовать адресацию на точках + отношение - да пожалуйста.
Не использовать другие способы - ну не хотите использовать, не используйте, но остальные участники тут причем?
Не проставлять адрес на пои если она внутри домика, - лично вы вольны делать как считаете правильным, но не све с этим согласны.
Я точно знаю сколько их. Именно обычно 2-3 куска. И знаю, что дублировать на них достаточно name, остальное может висеть на одном куске - этого достаточно.
То есть wikipеdia, name:mrj или alt_name достаточно держать на одном куске улицы.
При склеивании кусков в единый объект (по совпадению name) дополнительная информация замечательно объединяется.
Так же приклеиваются к улице и домики, только по имени улицы. Многоязычность имен улиц на домиках - это придумка для обхода ограничений одного известного конвертора. addr:street это же просто такая ссылка по name на другой объект.
Ссылку совсем убрать не удасться, можно только заменить, например отношением, но о какой экономии мы тогда говорим?
Посмотрел в ФИАС, там это поле, если не пустое, имеет тип “строение”, “сооружение” или “литер”.
На практике “строение” и “сооружение” зачастую не различают.
Участники не при чём, но цель — чтобы стали причастны.
Согласны не все, а цель — убедить многих, показав, что это работает и работает лучше (тогда другие подходы не будут привлекательны, что сократит неразбериху в них, как минимум).
Часто упоминавшаяся белорусская схема адресации, сколько участников о ней знали? Сколько из них (и потенциальных — в том числе) могли в ней разобраться? Какие общие корни она имела с уже распространёнными схемами? Ответом на все эти вопросы будет «почти никто» или «почти никак». Отсюда — её предсказуемый уход со сцены.
Вот был предложен похожий на мою схему, но более комплексный подход, где всё организовывалось в рамках отношения type=building.
К сожалению, выяснил, попробовав, что iD катастрофически не приспособлен для редактирования отношений, если у них нет, например, тега name (или другого). Тогда просто невозможно выбрать конкретное отношение для работы над ним/с ним (добавлять новых участников — самое основное). Рекомендация использовать временные фейковые имена в процессе редактирования, а перед сохранением данных — удалять их, — будет глуповато выглядеть.
После JOSM, в iD чувствую себя инвалидом (человеком с ограниченными возможностями)
А на официальном сайте — только бледный косвенный намёк на существование JOSM (мол, iD и Potlatch2 — рулят, а остальное — ерунда, не заслуживающая внимания, что само по себе является инверсией действительности в угоду ущербности).
Очевидно, что какие бы сильные аргументы я ни привёл — подобная инициатива не сдвинется с мёртвой точки, если только я сам не «напишу», например, конвертер в польский формат (а это невозможно в силу отсутствия квалификации) или не найдутся сторонники идеи, которые помогут довести её до логического конца (практического применения) тем или иным путём (подключением соотв. людей или непосредственным участием).
