Предлагаю обсудить правки, преобразующие глобально устаревшую схему тегирования в актуальную. Например, на днях сделанную и откаченную замену нодов building=entrance на entrance=yes.
Я вижу два пути внесения глобальных изменений:
1. Постепенно переходить к новой схеме, годами пропагандируя в сообществе новые теги и бурча про deprecated, натыкаясь на старые. За:
Мягкость перехода (не разрушаются в одночасье устоявшиеся операции над данными). Против:
Незаметность перехода. Потребитель данных может годами не знать о новой схеме тегирования и не замечать, что новых данных-то почти и не поступает (тем более, что часть пользователей по различным причинам будет вносить данные в старой схеме). Не надо говорить про списки рассылки с оповещением о новых тегах / вики / тп. Это НЕ работает, так как никто не хочет ничего читать (даже дайджест изменений в осомданных), все хотят мур-мур-мур.
2. Единовременно задействовать новые теги на всей планете. За:
Оперативность ввода в строй новых схем.
Шоковая терапия. Пользователи актуальных проектов немедленно поднимут вой и наоткрывают стопицот багов в трекерах. Против:
Никем не поддерживаемые проекты, основанные на старых тегах, мгновенно умирают, лишаясь данных.
Как видим, первый путь хорош, если мы хотим поддерживать неактуальную тягомотину.
Второй путь - это путь молодости и хардкора. Конечно, никто не мешает и во втором варианте делать рассылки об изменениях для подписчиков.
Выбирайте, что вам милее. :3
Рекомендую сразу отмечать, в копилку какого варианта вы высказываетесь.
Мне кажется второй пункт подойдёт, только не для мира, а для России. Так же хотелось иметь документ где было ДО, и ПОСЛЕ , а то иначе будем по-старому тэггировать .
Выскажусь как тот кто хочет мур-мур-мур. Я не против второго варианта, он кмк предпочтительней. Главное чтобы мгновенно не умирали редакторы, и даже пусть мгновенно перестают deprecated схемы поддерживать.
Я однозначно за второй вариант. Вообще я не понимаю, что такого ужасного в том, что ботом произвели однозначную трансляцию старого в новое.
Моё видение как программиста: в пропозалах должна появиться новая секция, “план миграции со старых схем”. Там подробно расписывать какие шаги по переходу на новую схему можно сделать ботом, какие нет. Для тех, которые можно - делать их ботом, централизованно.
Также завести некий глобальный key-value список deprecated и прочих нежелательных тегов. Обучить josm и прочие редакторы на старте подтягивать обновление этого списка и при присвоении тега предупреждать пользователя о том, что данный тег находится в статусе нежелательного. Можно url приложить с подробностями. Это снимет уйму вопросов “какого х” и позволит большинству мапперов оставаться в курсе событий.
Ну а дальше всё просто, например:
приняли пропозал
устареваемые теги добавили в список нежелательных, приложили урл на пропозал
согласно плану миграции подождали, скажем, месяц, или два, за время которых обновили стили рендереров и т.д. под новые схемы
по истечению срока глобально натравили бота, который подменил теги
теги из списка устареваемых перенесли в список устаревших
Я за второй вариант. И думаю, да надо вести таблицу до, после, плюс заводить пункты указывать дату когда планируется массовая замена. Т.е. за месяц до смены тега объявлять, что он будет меняться, время будет дабы живые проекты подготовились.
Ну, подтягивать каждый раз не надо, JOSM обновляется значительно чаще, чем происходит устаревание тегов.
А вот сама идея годная. Добавил устаревший тег - получи всплывающий бар сверху (как при открытии спутниковой подложки впервые).
За второй вариант.
Чтобы для разрабов это не было неожиданностью можно или на вике публиковать (хотя кто её читает, тем более оперативно).
Или сделать примитивный сайтик-бот, вписал своё мыло и тебе будет приходит уведомление о введении новых тегов заранее (идея Фелиса)
За ранее - например 2 недели, или месяц.
Отдельно в России будет проще протолкнуть, но если не вводить свои правила отдельно от мира, то тоже вариант.
Но все эти замены после голосования, по типу пропозалов. Только я бы обсуждение и голосование перенес в форум, а в иркевике содержание и результаты.
Этот же список могут автоматизированно читать и разработчики-потребители данных. Т.е. есть у меня некий софт, ориентируется на такие-то и такие-то теги. Девелопер пишет простенький скрипт, который периодически скачивает данный список и проверяет наличие используемых тегов в этом списке. Если находит - пинает своего хозяина-девелопера И никаких рассылок и зависимостей от почтовых служб не надо
Существование разных схем, которые друг друга в той или иной степени дублируют - зло.
Если принят более совершенный метод обозначения, автоматический переход на который не приведет к потере какой-либо информации, хранящейся в старой схеме - переходить на новый нужно разом.
При этом, дабы не создавать никому проблем, действительно нужно ограничиваться пределами отдельных стран. Это по той причине, что сменить один тэг на другой по условию - просто, а вот оповестить всех заинтересованных лиц об этом в масштабе больше национального сообщества - сложнее на порядок.
Чтобы “всё было и ничего за это не было”, о процедуре должно сообщаться заранее, в духе: “Для приведения данных к единой схеме обозначений, будет проведена замена того-то на то-то при таком-то условии (тут точное исчерпывающее описание), если у вас есть конкретные возражения, сообщите инициатору таким-то способом. Замена будет осуществлена тогда-то. Дата замены может быть по аргументированному требованию перенесена, но не более чем на n дней. Информация о проведенной замене будет также опубликована в таком-то разделе wiki по постоянному адресу такому-то.” Новость такого рода можно опубликовать в вики, рассылке, в специально выделенной для этого теме национального форума, на любых других ресурсах по желанию.
(Вот минимальный список мест, где нужно сделать такое оповещение, нужно согласовать заранее.)
При соблюдении такого механизма, вероятность появления возмущенных с воплями “а я не знал, у меня проект порушился” не сводится к нулю, но поскольку конкретные меры по их оповещению были предприняты, возражения перестают быть обоснованными. Публичный уведомительный порядок замены позволяет инициаторам не беспокоиться об устройстве голосований и т.п., а несогласным - вовремя выступить с аргументированными возражениями.
Второй вариант с оповещением предпочтительней. Главное сделать это оповещение официальным и собственно везде его указать — в wiki, на switch2osm и прочих ресурсах для пользователей данных.
Думаю здорово было бы организовать RSS и какой-нибудь машиночитаемый список.
1. Считаю поднятую тему очень актуальной.
Действительно, в последнее время очень участились случаи необдуманного применения ботов, а еще в гораздо большей степени - предложений о применении ботов от людей, которые плохо себе представляют алгоритм работы подобных ботов, а еще хуже - возможные негативные последствия.
2. Считаю формулировку основного вопроса неверной по следующим основаниям.
на мой взгляд, “За” и “Против” расставлены весьма субъективно: я бы, например, отнес мягкость перехода в “За”, а шоковую терапию, напротив, в “Против”.
каждый из вариантов, как справедливо отмечено, имеет свои “За” и “Против”, а потому единого способа решения всех подобных вопросов нет и существовать не может, - в каждом конкретном случае “перехода” необходимо индивидуальное решение о способах его осуществления. В частности, может потребоваться как “чистоый 1”, так и “чистый 2”, а может, и какая-нибудь их комбинация.
есть еще, минимум, один вариант:
(3). Автоматическое проставление ботом новых тегов по имеющимся в базе старым без удаления из базы последних.
За:
мягкость,
оперативность,
незаметность,
неподдерживаемые проекты сразу не умирают.
Против:
увеличение объема данных в базе за счет хранения неактуальных полей.
Как вариант:
(3а). Двухшаговый алгоритм:
Автоматическое проставление ботом новых тегов по имеющимся в базе старым без удаления из базы последних.
через несколько месяцев (лет?) и после дополнительного обсуждения - удаление старых в тех местах, где есть новые.
т 3. Считаю необходимым обсудить (а, возможно, и принять решения) не только общую схему осуществления преобразования, но и вообще рекомендуемую схему применения любого бота.
На мой взгляд, применение в стиле “написали - натравили на базу” категорически недопустимо.
Последовательность применения бота должна быть примерно такой:
При написании бота он в обязательном порядке должен содержать модули:
диагностики “неожиданных” данных, т.е. всех данных, которые не подходят под ожидаемый ботом шаблон,
протокола работы, которых, минимум, два: для обнаруженных ошибок и “неожиданных” данных и для фиксации ВСЕХ изменеий производимых(предлагаемых) ботом,
флага отключения обработки, при котором бот в полном объеме формирует протоколы работы, но не вносит изменений в базу.
Написанный бот проходит отладку на небольшом фрагменте карты в режиме отключения обработки. Протоколы тщательно просматриваются человеком (включая тщательный просмотр протокола ВСЕХ изменений).
На основе просмотра уточняются алгоритмы диагностики “неожиданных” данных и ошибок. Количество протоколов увеличивается, минимум до пяти:
очевидные ошибки и случаи, когда НЕ следует вносить изменения,
очевидные случаи, когда СЛЕДУЕТ вностить изменения,
все остальные, при которых алгоритм решит ВНОСИТЬ изменения,
все остальные, при которых алгоритм решит НЕ вносить изменения,
все остальные, при которых алгоритм не сможет принять решение (новая итерация “неожиданных данных”).
Тестирование бота на нескольких других мелких фрагментах. При обнаружении каких-либо признаков неточной работы - возвращаемся на шаг 2 и повторяем. Протокол “неожиданных” данных не пуст - возвращаемся на шаг 2 и повторяем.
Шаг 3 повторяется для нескольких средних по размеру фрагментов местности (с возможным возвратом к шагу 2).
Тестирование бота на нескольких крупных фрагментах. Анализируются протоколы кроме “очевидных” (для которых просмотреть глазами становится уже нереально). Если какой-либо из “остальных” протоколов становится непомерно большим - пересмотр критериев и возвращение на шаг 2 с целью перевести из “остальных” в “очевидные”. При обнаружении ошибок (далее везде: включая - протокол “неожиданных” данных не пуст) - возвращение на шаг 2.
Написание дополнительных утилит для анализа “очевидных” протоколов. Автоматизированный анализ этих протоколов. При обнаружении ошибок - возвращение на шаг 2.
Тестирование алгоритма на всех данных, для которых его предполагается использовать.
При обнаружении ошибок, либо при слишком больших “остальных” протоколах, либо подозрительной диагностике алгоритмов анализа “очевидных” протоколов - возвращение на шаг 2.
Еще раз подумать.
Применение алгоритма на небольшом фрагменте с проведением изменений.
Сообщение о результатах работы на форум. Ожидание реакции других пользователей и ее анализ. По результатам анализа - либо возвращение на шаг 2, либо - переход на шаг 12.
Аналогично 4-8, но с произведением изменений, сообщением о каждом проходе на форум и анализом реакции.
Вот уж за объем БД не переживайте. В любом случае, данных в проекте (при хорошем покрытии планеты) должно быть больше на порядки, чем сейчас. В сотни-тысячи раз, то есть.
И БД всё это прекрасно переварит.
То, что вы предложили - это конечно неплохо, но нежизнеспособно. Почему? Всё очень просто - сейчас даже написание хорошего пропозала штука довольно редкая, ибо для этого надо потратить немало времени для анализа существующих применений, возможных случаев и т.д. Дальше фразы “а давайте маппить вот так” отсеивается 99% мапперов.
Если же в пропозал добавить ещё и подробные многошаговые алгоритмы миграции с проверками и т.д. - то пропозалов не будет вообще. Если не добавлять - то непонятно, кто этими алгоритмами и ботами будет заниматься. Т.е. на практике никто не будет.
Поэтому адекватно использовать массовые миграции схем пока имеет смысл только для довольно простых расширений схем, например таких как миграция building=entrance → entrance=*, тут практически все возможные случаи может предсказать обычный человек и расписать в пропозале действия по миграции.
Выполнять же сложные миграции типа новой схемы public_transport автоматизированно я не представляю возможным. И тут масса аргументов против из прошлого опыта OSM, например взять недавнюю большую миграцию лицензий - технически тоже довольно несложная процедура, однако растянулась на несколько лет, включая формализацию задачи и непосредственно миграцию. И даже в случае миграции схем всё выльется в то же самое - написание бота, отладка на небольших кусках, попытка запуска world-wide, сбои, откаты, отладка, снова запуск, снова сбои, откаты и т.д. Нереально это, по крайней мере пока.
(3а) Способ плох по человеческому фактору, мапперы могут проставить новые объекты старыми тегами после первого прохода бота, а второй удалит это всё. Можно конечно логировать (удалять то что менял), но это усложняет алгоритм, нужно хранить большой лог и есть шанс что после первого прохода бота, незнающий маппер удалит задвоение оставив старое тегирование. В результате второго прохода мы потеряем совсем инфу (конечно по истории можно восстановить, но это уже сложный вариант).
Частный вариант - не везде применимо.
а (3) просто не ясно зачем вообще, по факту это п.1 +автоматизация.
Моё мнение, или п.1 или п.2. А принудительное задвоение тегов ботом - лишнее.
Так это же не одни и те же люди должны делать.
Вот сейчас дофига пропозалов, вот приняли entrance=yes, вот человек взялся пройти ботом.
За миграцию отвечает тот, кто взялся за миграцию. Он проходки ботом делает, он добавляет в рассылки и RSS информацию. Как - вопрос технический, а значит, решаемый.
И вот уже тут можно устанавливать правила. Вроде “не оповестил за месяц - откат без лишних вопросов”.