Это всегда было так, данные для удобства маперов, а не для обработки.
Если существует скрипт, который расставит недостающие теги, значит любой может это сделать у себя локально.
Я за упрощённую схему.
Карта показывает использование этих тегов в целом по территории, без деления по типам объектов. Сокращённая схема про то, что они не должны использоваться на полигонах домов. На полигонах же населённых пунктов они как раз проставляются, что и упомянуто в стартовом посте.
Добавлю: по этой же причине принято, что не надо вносить транслит в name:en и подобные. Наличие заполненных таким образом полей в базе является ошибочным. И аргумент, что вносившему оно нужно именно в таком виде, тут не работает.
Кстати, пример запроса на Overpass, позволяющий вытаскивать адреса верхнего уровня для зданий с полигона НП, был бы очень полезен. Это будет более дружелюбно к начинающим, чем просто сказать “берите с полигона НП, а как именно - разбирайтесь сами”.
Я за использование сокращённой схемы адресации. Но не надо удалять “избыточные адресные данные”, если кто-то использует полную схему - пусть использует.
Бессмысленное обсуждение, потом будет такое же бессмысленное голосование. Всё останется как прежде.
Будет принята сокращённая схема – кто вносил адреса полностью, так и продолжит это делать, потому что удалять лишнее никто не позволит, так данные валидные.
С полной схемой также всё останется по прежнему, никто не заставит заполнять все поля целиком. Вам надо вы и заполняйте.
А значит программам так и придётся поддерживать сокращённые схемы и брать данные из других мест.
Утверждение “берите с полигона place” тоже не понятно к чему. Те, кому нужен полный адрес, ничего с полигона НП не берут и брать не будут, по простой причине – на многих полигонах НП ничего, кроме name нет. До сих пор никто не озадачился внесением этих данных, не говоря уж о каком-нибудь валидаторе, по простой причине – те, кому надо берут все данные с вышестоящих полигонов. addr:city – из name полигона place, addr:region – из name полигона boundary=administrative + admin_level=4 и т.п.
Самое драгоценное - продуктивное время маппера ) Потратим его на внесение данных, которые нельзя получить скриптом из геометрии. Например, на полигоны границ НП.
Запрос для Overpass, дополняющий addr:city, addr:region и addr:country для линий с записанным по сокращённой схеме адресом: ------------------------
Upd. См. запрос в предыдущем сообщении - он лучше.
все дело в том что для сокращенной схемы нужны лишние телодвижения…
А building=no на всех объектах, кроме зданий, это ещё валидный тег или это другое?
Таким образом вы придерживаетесь мнения, что если некто начнет импорт “валидных данных”
addr:city, addr:region, addr:country и addr:galaxy для всех адресуемых объектов,
то это в порядке вещей ?
И как будет учитываться административная иерархия отличная от city,addr,country ,
ее тоже можно добавлять ко всем объектам?
необсужденный и неодобренный (а он не будет одобрен) сообществом импорт будет очень быстро откачен
Обсуждение именно об этом. Чтобы признать дополнительные теги на зданиях невалидными и поступать с ними так же, как с транслитом в name:en, например. При рисовании новых объектов можешь вносить (и даже никто не заругает), потом другие могут удалить в рамках приведения к рекомендуемому виду. Но обратно вернуть удалённое, потому что “мне пофиг на договорённости, мне так нужно” - харам.
Я в шапке, кстати, привёл ссылку на один из чейнжсетов с удалением таких “валидных” данных.
Ну то есть всё равно есть откуда их взять (и берут), а не ожидают же, чтобы непременно всё на конкретном доме было.
Есть такой валидный в прошлом популярный тег is_in:country. Ничего, постепенно выпиливается
https://taghistory.raifer.tech/#***/is_in:country/
Имеются ли причины, по которой верное указание местоположения приводит к ошибкам, ломает что либо?
Имеются ли причины, по которым одна схема несовместима с другой?
Если ответ на оба вопроса негативный - тред не имеет смысла. Подписывать город на каждом здании - бесполезная работа, но с трудом понимаю как это может мешать.
Имеются - если на каждом здании, то можно указать теги addr:place/region/country, не совпадающие с такими на соответствующих полигонах, в которых это здание находится. Это влечёт неоднозначность в данных и непредсказуемую работу с ними.
Опять же, в случае переименования населённого пункта придется массово менять теги на всех домах в нём. Сделать ошибку при этом намного проще, чем если бы поменять надо было в одном месте - на самом населённом пункте.
Я за сокращенный.
- Нужно беречь базу. Избыточная информация чревата появлению проблем. Простота и полнота - разные вещи.
- Если какой-то населенный пункт станет частью другого (крупным городам свойственно поглощать города-спутники), то из-за этого придется делать огромный объем **бессмысленной **работы! Тогда как сокращенная схема позволяет легко поправить границы и здания легко унаследуют нужные теги.
- Современные системы позволяют легко наследовать данные объектов покрывающих их область. Вместо того чтоб тотально забивать гвоздями информацию, следует потратить это же время на освоение современных систем и баз данных.
Чушь какая-то. Мне пришлось лишь С++ установить.
Кстати, еще адреса на каждом ПОИ надо прописать, а то, как мне попалось в украинском чате, у отдельных пользователей проблемы написать оверпас для РФ
У нас уже муниципальные районы в городские округа, а потом далее в муниципальные округа, переделывают по всем регионом. что еще ведет к сносу addr:subdistrict
Ну и самим регионам любят где приписать слово республика, а где убрать.
Но в ограниченном масштабе использование addr:* тегов полезна.
Когда какие-то границы не скачаны в выгрузку или объекты залезают в выгрузку соседних регионов и т.п.
Есть имена на другом языке (татарском и т.п.), почтовые коды попадаются в мелких нп.
Сокращенная форма была придумана для ленивых мапперов, чтобы им не приходилось вносить все addr:*, а карта в навигаторе у них бы была с поиском, благодаря известному конвертору.
Теперь у нас теперь просто есть не ленивые, которые хотя вносить все теги, и у них свои способы конвертации в свои системы.
Но, поскольку, многие другие полную схему не поддерживают, то полнота и целостность полной схему абсолютно не гарантирована. Ошибки замечают не сразу, неполноту никого не волнует, кроме наших не ленивые мапперов, но вот насколько лично они готовы внесенные данные поддерживать? Им же, в конце концов, будет больнее.
Валидаторы есть, но ошибки такого рода мало кого заботят, так как раз конвертор работает, то и ладно.
Я бы сейчас не цеплялся к полной схеме.
За долгую историю, насколько я помню, серьёзных проблем она пока не вызывала.
Проблемы в OSM возникают однозначно, когда пытаются разные варианты обязательно подогнать под что-то одно, а остальное пристрелить.
Ну если вместо исправления ошибок вносить данные по второму разу в другом варианте, то ошибки и не будут никогда исправлены. В итоге вместо того, чтобы сосредоточиться на доведении до ума одной схемы, мы на 15-м году существования проекта имеем две и обе неполные.