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