нет, что когда сказали что через месяц будет переход на новые теги, автор конвертора должен уметь держать 2 типа одновременно, или просто наложить патч на свой конвертор в день Ч
Хотя вариант с плавной заменой мне всё больше нравится 
Да, но подобная мягкая миграция будет работать только для относительно простых миграций. Поэтому думаю надо всё же сразу разделить ситуации на “простые” и “сложные”, для простых (аля расшиение тега, уточнения тегов) написать типовой регламент и простого конфигурируемого централизованного бота. А для сложных - писать отдельные регламенты и отдельных ботов и аккуратно их отлаживать и постепенно (пошагово) мигрировать схемы.
PS: Да и вообще, сейчас пришло в голову. Да, “all tags you like”, но почему бы не завести общий машинночитаемый список что-то вроде “common tags” или “well-known tags” и по каждому тегу - url, дата введения, дата истечения, текущий статус, до кучи статистику применений и динамики роста, в том числе по отдельным странам. Да, знаю, сейчас часть этого функционала возложена на wiki, но её сложно назвать машинночитаемой.
Я за первый вариант. Замена building=entrance на entrance=yes - вообще скверный анекдот.
Одномоментный переход со старой схемы на новую, с массовой заменой тегов возможен (приемлим) только после **объявленного переходного периода **(достаточно длинного, например в год), и только **при условии, что все заинтересованные стороны **(подающие признаки жизни пользователи данных тегов) с этим переходом согласились.
Насколько я понимаю, тема посвящена способам преобразования устаревших схем тегирования в актуальные.
К пропозалам она вообще никакого отношения не имеет.
Соответственно, на механику составления и принятия пропозалов повлиять в принципе никак не сможет.
Конечно, хотелось бы, чтобы в формировании и обсуждении пропозалов основную роль играли люди, разбирающиеся в алгоритмах обработки данных, но к данной теме это тоже отношения не имеет.
Не соглашусь, т.к. именно пропозалами принимаются новые схемы, заменяющие старые. И именно в пропозалах указывается, чем новая схема лучше старой. И в моём понимании именно принятие пропозала делает старую схему старой, а следовательно именно с принятием пропозала возникает необходимость осуществлять миграцию схем. И мне кажется вполне логичным, чтобы именно в пропозале был регламентирован порядок этой миграции.
А внимательно прочесть?
А внимательно прочесть?
Это как раз то, о чем я писал в скипнутой Вами части: в каждом частном случае использовать индивидуальный подход, включая комбинации указанных в первом сообщении.
сначала хотел для своего, в нем кстати есть и ссылки на полную инфу, и ключевые слова, и описание. Даже что то сделал, не до конца конечно. Но Зверик прав, что мой каталог не дотягивает до каталога объектов ОСМ, ну если только каталог ПОИ. А вот для формата Зверика хочу сделать сайт-редактор, но чуть позже, сейчас вот стали выяснятся всякие доп.моменты, которые нужно реализовать в нём. Да и монструозен он, нужно продумать сначала юзабилити, чтоб удобно было править.
возможно не внимательно, но и вы не без этого 
тогда у нас останется опять 2 варианта тегирования в базе.
А вообще это уже без толку, я согласился что плавный переход совсем неплох, с условием что будет несколько “волн” замены тегов (второго этапа).
Извиняюсь за оверквотинг, но это лучшее и само грамотное предложение в этой теме.
Безусловно, любой принятый пропозал должен прирасти road-map’ом по дальнейшему внедрению его в жизнь, и только после этого приобрести статус Live вместо Draft.
Не всегда план миграции включает в себя массовую замену тэгов ботом, но хоть какой-то план миграции быть должен.
В нем должны быть определены сроки, мероприятия.
При наличии вот таким образом оформленного принятого пропозала, против второго варианта трудно возражать.
Как точно выполняются планы было видно на примере смены лицензии, а тут всё серьезнее : building=entrance — это вам не СТ какой-то.
Траллинга нам тут и не хватало.
Опять же, все видели, что все можно исправить за кратчайшее время. Проблема, как обычно, в людях.
В этой теме все ровно этим и занимаются. Равно как и в теме про максспид:практикал.
В JOSM-е соответствующий механизм уже есть встроенный - при любом редактировании объекта удаляются теги created_by, odbl и т.п.
Всякие запуски ботов, которые просто меняют один тег на другой, дополнительная нагрузка на общую базу и на все настроенные репликаторы, - и всё это только заради того чтобы не писать пару строк в конвертерах? ИМХО - слишком большая цена.
Это заради поднятия ЧСВ, когда нечем полезным заняться.
А зачем если нагрузку создали (поменяли), ее создают еще раз (вертаютвзад?!).
ААА, ЧСВ 
+1 (дальше тему не читал, извините)
Склоняюсь к тому, что переходный период нужен. Иначе практически нереально избежать случаев вида “в последней сборке карт нет ни одного домика!1”. Просто потому, что выгрузки делаются в одно время, конвертации в другое, и даже оперативное обновление конвертера не позволит штатно собрать ту же карту для навигатора…
Накладываем мораторий на изменения данных, замораживаем выгрузки… PROFIT!11
Но опять же, такое реально лишь централизовано. Если процесс отработать, то вполне возможно избежать длительных простоев.
я за первый вариант. ну её нафиг, эту шоковую терапию.
Я за 2-ой вариант и только за него. В идеальном случае это должно быть частью всего проекта, но и для только российской части тоже подойдет.
Hind, вынеси в первый пост мягкий вариант, третий