То, что вы предложили - это конечно неплохо, но нежизнеспособно. Почему? Всё очень просто - сейчас даже написание хорошего пропозала штука довольно редкая, ибо для этого надо потратить немало времени для анализа существующих применений, возможных случаев и т.д. Дальше фразы “а давайте маппить вот так” отсеивается 99% мапперов.
Если же в пропозал добавить ещё и подробные многошаговые алгоритмы миграции с проверками и т.д. - то пропозалов не будет вообще. Если не добавлять - то непонятно, кто этими алгоритмами и ботами будет заниматься. Т.е. на практике никто не будет.
Поэтому адекватно использовать массовые миграции схем пока имеет смысл только для довольно простых расширений схем, например таких как миграция building=entrance → entrance=*, тут практически все возможные случаи может предсказать обычный человек и расписать в пропозале действия по миграции.
Выполнять же сложные миграции типа новой схемы public_transport автоматизированно я не представляю возможным. И тут масса аргументов против из прошлого опыта OSM, например взять недавнюю большую миграцию лицензий - технически тоже довольно несложная процедура, однако растянулась на несколько лет, включая формализацию задачи и непосредственно миграцию. И даже в случае миграции схем всё выльется в то же самое - написание бота, отладка на небольших кусках, попытка запуска world-wide, сбои, откаты, отладка, снова запуск, снова сбои, откаты и т.д. Нереально это, по крайней мере пока.
(3а) Способ плох по человеческому фактору, мапперы могут проставить новые объекты старыми тегами после первого прохода бота, а второй удалит это всё. Можно конечно логировать (удалять то что менял), но это усложняет алгоритм, нужно хранить большой лог и есть шанс что после первого прохода бота, незнающий маппер удалит задвоение оставив старое тегирование. В результате второго прохода мы потеряем совсем инфу (конечно по истории можно восстановить, но это уже сложный вариант).
Частный вариант - не везде применимо.
а (3) просто не ясно зачем вообще, по факту это п.1 +автоматизация.
Моё мнение, или п.1 или п.2. А принудительное задвоение тегов ботом - лишнее.
Так это же не одни и те же люди должны делать.
Вот сейчас дофига пропозалов, вот приняли entrance=yes, вот человек взялся пройти ботом.
За миграцию отвечает тот, кто взялся за миграцию. Он проходки ботом делает, он добавляет в рассылки и RSS информацию. Как - вопрос технический, а значит, решаемый.
И вот уже тут можно устанавливать правила. Вроде “не оповестил за месяц - откат без лишних вопросов”.
Если для относительно простых миграций это будут разные люди делать - то для большей части пропозалов миграций не будет вообще. Т.е. либо эту “отдельную” обязанность возьмёт на себя DWG (в чём я лично сомневаюсь на все 100%), либо на это сразу забьют.
Давайте пойдем от того, кому вообще выгодна миграция.
Выгодна она, прежде всего, авторам конвертеров и проектов по поиску/визуализации и т.п. - именно им удобнее, если нужно предусматривать меньше вариантов хранения одной и той же информации, если не нужно поддерживать старые схемы. Ради этого вопрос и затевается, на сколько я понимаю, а не ради абстрактного обновления и наведения порядка.
Так что нет, не забьют.
Возможность заменить что-то в базе - это просто более логичный вариант того, что и так делается в той или иной форме при втягивании данных в какой-либо конвертер. На это, как мы видим, не забивают. Разного рода валидаторы, ноги которых растут из конвертеров - из той же оперы.
Я не отрицаю, что для некоторых douchebag-ов это может быть проще. Однако при наличии внятного механизма миграции это может стать менее актуальным даже для них. Если они не законченные douchebag-и, конечно.
Я за второй вариант, с например переходным периодом и оповещением.
Например мы везде где есть building entrance добавляем тег entrance yes - если это трактуется однозначно и например оповестив всех и вся, через месяц-два-три автоматически стираем нафег все building entrance. Этот вариант поможет более мягко подкачивать изменения софту и не губить работу всяческих программ, которые сами по себе ну не могут обновляться раз в неделю. Авторы тоже могут быть в отпуске/в декрете и т.п.
вообще-то depricated это в первую очередь указание не для мапящих, а для кодящих. Чтобы знали, что есть метод лучше и включали поддержку нового.
А старые данные должны отмереть не в силу указа, а в силу невостребованности пользователями, ибо ведь есть метод лучше и его всемерная поддержка софта взамен ограниченной для сарого тега.
В смысле влияния на человеческий фактор, переходный период бесполезен. Предположим, что есть Вася с проектом показа POI. Он обрабатывает тэг key1. Для него переходный период означает только то, что key1 будет существовать несколько дольше. Если он пропустил каким-то образом оповещение о смене key1 на key2, сделанное за месяц до добавления key2, то само добавление также не будет для него “последним китайским предупреждением”, потому что key2 он просто в своем сервисе игнорирует, т.к. не знает о нем. И момент исчезновения key1 для него будет в той же степени неожиданным. Вопросы декретов и отпусков решаются до какой-то степени определением существенного срока оповещения. Но полностью предотвратить ситуации, связанные с человеческим фактором подобного рода, невозможно.
Единственное, что дает переходный период - время на контроль качества перехода проектов со старой схемы на новую (скажем, сравнение результата конвертирования с учетом старой и новой схем).
Хорошо, допустим для простых миграций можно пойти ещё дальше. Предположим, та же ситуация с entrance, т.е. машинно-однозначное расширение схемы без потенциальных потерь данных.
Делаем в несколько этапов:
дописываем тег в список устаревающих с указанием даты выпиливания из БД (п.3)
каждые 2 недели все building=entrance меняем на entrance=yes при условии отсутствия тега entrance=*
по истечении описанного в регламете времени перехода выполняем последний раз операцию п.2 и вместе с этим выпиливаем building=entrance, а также переносим building=entrance из списка устаревающих в список устаревших/нежелательных, до кучи можно в списке сохранять id ченджсета, которым были выпилены исходные теги, дабы была возможность по full-history однозначно поднять версию до выпиливания.
В редакторах при наличии тега в списке устаревающих показывать ненавязчивую подсказку (жёлтым) с указанием урла-пропозала. При наличии тега в списке устаревших - вместо ненавязчивой подсказки показывать вполне себе навязчивый попап с всё тем же урлом и матами
Нет, переходный период нужен именно из-за человеческого фактора, т.к. нельзя заставить всех мапперов в одночасье прочитать, понять и начать использовать некий пропозал. Этот процесс будет естестенным образом размазан по времени, и если редактор в некий момент начнёт жёстко ругаться на какой-либо тег - многие мапперы либо проигнорят ругань, либо перестанут юзать этот тег вообще. Поэтому необходимо это сделать мягко, вначале ненавязчиво, потом жёстко.
Это я делаю выводы в первую очередь по себе, т.к. в подобной ситуации я открою урл, но совсем не обязательно буду его сразу же читать. Скорее всего замаплю по-старому если будет некогда/неохота читать, а когда дойдут руки прочитаю. Возможно даже перемаплю по новой схеме, а возможно и нет.
Не всегда есть время/возможность/желание. Да и вообще есть миллион всяких “но”. Тут все так любят брать в пример некоего абстрактного идеального сферического маппера в вакууме, что я вообще не понимаю, как при столь идеальных мапперах ломаются выверенные отношения (и не только в потлатче).
И уж тем более я не могу взять в толк как в одночасье внесутся изменения в рендереры, в шаблоны josm и потлатча и т.д. Имхо переходный период нужен.