Было бы глупо настроится на “вымирающий” тег времен раннего OSM, когда все POI были в amenity=*, и не настроится на современный и широко распространенный тег…
А мы живём хитрее. Используем все возможные варианты тегов - и отмирающие, но не вымершие, и современные, ещё не прижившиеся! Особенно это актуально когда в России что то массово меняется, а у соседей на постсоветском пространстве остается неизменным.
Лично я уже готов “вчера” к такого рода правкам. Изменения останутся не замеченными.
Кто то памятники ваяет, кто то сносит. Кто то снова ваяет, а кто то снова сносит. Диалектика! ??
В Вашем случае Вы ничего не теряете, напротив, в будущем сможете отказаться от amenity=register_office и сосредоточиться на government=register_office. Вам жизнь упрощают, один тег вместо двух
Я планирую также заменить building=entrance на entrance=yes (только ноды без entrance = *; например, building = entrance + entrance = main не будет изменено). Есть возражения или пожелания?
Вы хотели сказать - двойной вместо одинарного?
Мы все потеряли ровно тогда, когда вместо одной пары тега стало модно применять две (а то и три) пары тегов. Вот с тех пор конвертеры и пухнут. Мало того, что приходится описывать все вариант тегирования, приходится описывать алгоритм выборки из набора однотипных тегов, да ещё и применять сложные схемы тегирования. Один короткий парный тег всегда проще и понятнее двух длинных парных тегов.
Вспомните как усложнили нам жизнь в случае с Метро. Как поменяли действительность в случае с лесами. А загляните что происходит с километровыми столбами…
Кому помешали 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
Есть принципиальная разница между массовым использованием устаревшего тега и единичными рецидивами. Последние лечатся в рабочем порядке по принципу: “ой, я пометил, а на рендере не видно. почему? ааа, так это ж устаревший тег. ладно, перетегирую по-новому. о, появилось!”
И чем они вам так мешают? Вы почитайте эти темы, там было много обсуждений на тему того что не стоит менять шило на мыло и один тег на другой просто так - качества данным это не прибавит, а проблем может создать.
Вы так и не ответили на вопрос. Чем они вам так мешают? Замена ради замены?
В OSM нет “устаревших” тегов, есть альтернативные способы обозначения. Если кто-то изобрёл новый способ обозначения - это не делает все остальные способы “устаревшими” и подлежащими немедленной замене. А кто чем пользуется - это невозможно достоверно узнать, т.к. многие частные применения данных OSM не выставляются на общее обозрение.
Поэтому, пожалуйста, умерьте свой “исправляторский пыл”, и воздержитесь от массовых замен одних тегов на другие. Новую информацию в OSM это не привносит.
мне кажется удобнее использовать единый стандарт, тем более если им пользуется большинство, это среди прочего уменьшает размер базы, что сказывается на скорости обработки
если поддерживать хаос в базе и превращать её в помойку из всяких разных альтернативных тегов, обозначающих одно и то же, то ни к чему хорошему это не приведёт
Для этого достаточно просто добавить entrance=*. Удалять то зачем?
В том то и дело, что вы базу не уменьшаете, а увеличиваете дополнительными правками, т.к. базе нужно хранить всю историю. Поэтому никто массово и не удалял всякие created_by, а даже добавили специальную поддержку в JOSM, чтобы он удалял эти теги только если объект редактируется с другими целями.
Т.к. в OSM нет централизованного органа принятия правил обозначений и нет единого рендерера/редактора (как в тех же НЯК или GMM) - наличие нескольких альтернативных схем обозначения - это данность, никакими правками вы этого не избежите. Такова плата за гибкость, увы.
Если новая схема обозначения будет значительно лучше старой - старая сама постепенно отомрёт за ненадобностью. Если же новая особо ничего не привносит - они будут существовать параллельно.