У кого то появятся, а у кого то исчезнут… У кого что и как настроено!
Было бы глупо настроится на “вымирающий” тег времен раннего OSM, когда все POI были в amenity=*, и не настроится на современный и широко распространенный тег…
А мы живём хитрее. Используем все возможные варианты тегов - и отмирающие, но не вымершие, и современные, ещё не прижившиеся! Особенно это актуально когда в России что то массово меняется, а у соседей на постсоветском пространстве остается неизменным.
Лично я уже готов “вчера” к такого рода правкам. Изменения останутся не замеченными.
Кто то памятники ваяет, кто то сносит. Кто то снова ваяет, а кто то снова сносит. Диалектика! ??
В Вашем случае Вы ничего не теряете, напротив, в будущем сможете отказаться от amenity=register_office и сосредоточиться на government=register_office. Вам жизнь упрощают, один тег вместо двух 
Поддерживаю избавление от deprecated-тега.
Ну вот у кого исчезнут, тот пускай и перенастраивает свой софт на нормальные теги
Я планирую также заменить building=entrance на entrance=yes (только ноды без entrance = *; например, building = entrance + entrance = main не будет изменено). Есть возражения или пожелания?
Шо, опять? (c)
https://forum.openstreetmap.org/viewtopic.php?id=14007
https://forum.openstreetmap.org/viewtopic.php?id=14040
https://forum.openstreetmap.org/viewtopic.php?id=19411
Да, это давняя тема. Но building = entrance всё ещё присутствуют.
Вы хотели сказать - двойной вместо одинарного?
Мы все потеряли ровно тогда, когда вместо одной пары тега стало модно применять две (а то и три) пары тегов. Вот с тех пор конвертеры и пухнут. Мало того, что приходится описывать все вариант тегирования, приходится описывать алгоритм выборки из набора однотипных тегов, да ещё и применять сложные схемы тегирования. Один короткий парный тег всегда проще и понятнее двух длинных парных тегов.
Вспомните как усложнили нам жизнь в случае с Метро. Как поменяли действительность в случае с лесами. А загляните что происходит с километровыми столбами…
Кому помешали pk=* и kp=. Зачем нужно было вводить distance= и distance:backward=*? А еще применяют - pk:backward, distance:forward, pk:forward, plk:backward… Визуально видно, теги усложнились. Самое обидное в том, что некоторые из… так и не уходят в прошлое. Их единицы, но приходится держать в конвертере для максимально полного отображения объектов.
Так что заменой одних тегов на другие жизнь не упростится никогда. Тенденция такого подхода - только усложнение!
“когда коту делать нечего, он себе яйца вылизывает”
Заявленная цель вполне достижима и без проведения мероприятия.
Всё одно поддерживать оба варианта. Даже если и вычистите тег, то от рецедивов это не застрахует. То есть цель окажется не достигнута.
Например, osm-carto поддерживает office = *, но не поддерживает amenity = * с сотнями упоминаний, и скорее всего, не будет. Понятно, что кто-то будет вносить под старым тегом, или вообще напишет amenity=ЗАГС (amenity = школа же писали). Цель “100% отображение” не стоит вообще, цель – сделать OSM лучше.
К слову, amenity=emergency_phone был вычищен https://taghistory.raifer.tech/#***/amenity/emergency_phone
Есть принципиальная разница между массовым использованием устаревшего тега и единичными рецидивами. Последние лечатся в рабочем порядке по принципу: “ой, я пометил, а на рендере не видно. почему? ааа, так это ж устаревший тег. ладно, перетегирую по-новому. о, появилось!”
И чем они вам так мешают? Вы почитайте эти темы, там было много обсуждений на тему того что не стоит менять шило на мыло и один тег на другой просто так - качества данным это не прибавит, а проблем может создать.
И какие могут быть проблемы? Неужели кто-то опирается на устаревший тег, игнорируя статистику и wiki, “не замечая” его “вымирания”?
Вы так и не ответили на вопрос. Чем они вам так мешают? Замена ради замены?
В OSM нет “устаревших” тегов, есть альтернативные способы обозначения. Если кто-то изобрёл новый способ обозначения - это не делает все остальные способы “устаревшими” и подлежащими немедленной замене. А кто чем пользуется - это невозможно достоверно узнать, т.к. многие частные применения данных OSM не выставляются на общее обозрение.
Поэтому, пожалуйста, умерьте свой “исправляторский пыл”, и воздержитесь от массовых замен одних тегов на другие. Новую информацию в OSM это не привносит.
Замена ради рендеринга на osm-carto. building = entrance мне не мешает as well.
мне кажется удобнее использовать единый стандарт, тем более если им пользуется большинство, это среди прочего уменьшает размер базы, что сказывается на скорости обработки
если поддерживать хаос в базе и превращать её в помойку из всяких разных альтернативных тегов, обозначающих одно и то же, то ни к чему хорошему это не приведёт
Для этого достаточно просто добавить entrance=*. Удалять то зачем?
В том то и дело, что вы базу не уменьшаете, а увеличиваете дополнительными правками, т.к. базе нужно хранить всю историю. Поэтому никто массово и не удалял всякие created_by, а даже добавили специальную поддержку в JOSM, чтобы он удалял эти теги только если объект редактируется с другими целями.
Т.к. в OSM нет централизованного органа принятия правил обозначений и нет единого рендерера/редактора (как в тех же НЯК или GMM) - наличие нескольких альтернативных схем обозначения - это данность, никакими правками вы этого не избежите. Такова плата за гибкость, увы.
Если новая схема обозначения будет значительно лучше старой - старая сама постепенно отомрёт за ненадобностью. Если же новая особо ничего не привносит - они будут существовать параллельно.
Речь не идет о правках только для того, чтобы удалить что-либо; речь идет о приведению к единообразию.