В Вашем случае Вы ничего не теряете, напротив, в будущем сможете отказаться от 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) - наличие нескольких альтернативных схем обозначения - это данность, никакими правками вы этого не избежите. Такова плата за гибкость, увы.
Если новая схема обозначения будет значительно лучше старой - старая сама постепенно отомрёт за ненадобностью. Если же новая особо ничего не привносит - они будут существовать параллельно.
С точки зрения пользователя данных, никакого вымирания быть не может. Пока тег есть в базе, он может встретиться, и его надо обрабатывать. Особенно когда этих тегов не штуки, а тысячи.
Поскольку старая схема уже есть в коде обработки, она работает, и кушать не просит. Если ее выкинуть, пока теги используются, можно лишиться части данных.
Подобные замены не уменьшают количество схем, которые нужно поддерживать, а только увеличивают.
и где логика?
Заменили хрен на редьку, а как обозначать подъезды, так и не придумали, за 10 лет то.
Upd:
entrance=staircase популярный тег, но используется далеко не везде, где надо бы. глянул что творится у немцев и у нас в Калиниграде, entrance=yes/entrance=main.
У администраторов osm-carto другой подход: одна сущность – один тег; однако, для healthcare сделали исключение.
Вы утверждаете, что замена на схему "entrance = " потребует внедрения её поддержки? Т.е. сейчас она не поддерживается? (Если это так, это выглядит странным для меня, учитывая соотношение между схемами: 6218 building=entrance vs 2293355 entrance=).