Массовые правки при смене схем тегирования

1. Считаю поднятую тему очень актуальной.
Действительно, в последнее время очень участились случаи необдуманного применения ботов, а еще в гораздо большей степени - предложений о применении ботов от людей, которые плохо себе представляют алгоритм работы подобных ботов, а еще хуже - возможные негативные последствия.

2. Считаю формулировку основного вопроса неверной по следующим основаниям.

  • на мой взгляд, “За” и “Против” расставлены весьма субъективно: я бы, например, отнес мягкость перехода в “За”, а шоковую терапию, напротив, в “Против”.
  • каждый из вариантов, как справедливо отмечено, имеет свои “За” и “Против”, а потому единого способа решения всех подобных вопросов нет и существовать не может, - в каждом конкретном случае “перехода” необходимо индивидуальное решение о способах его осуществления. В частности, может потребоваться как “чистоый 1”, так и “чистый 2”, а может, и какая-нибудь их комбинация.
  • есть еще, минимум, один вариант:
    (3). Автоматическое проставление ботом новых тегов по имеющимся в базе старым без удаления из базы последних.
    За:
  • мягкость,
  • оперативность,
  • незаметность,
  • неподдерживаемые проекты сразу не умирают.
    Против:
  • увеличение объема данных в базе за счет хранения неактуальных полей.

Как вариант:
(3а). Двухшаговый алгоритм:

  • Автоматическое проставление ботом новых тегов по имеющимся в базе старым без удаления из базы последних.
  • через несколько месяцев (лет?) и после дополнительного обсуждения - удаление старых в тех местах, где есть новые.
    т
    3. Считаю необходимым обсудить (а, возможно, и принять решения) не только общую схему осуществления преобразования, но и вообще рекомендуемую схему применения любого бота.
    На мой взгляд, применение в стиле “написали - натравили на базу” категорически недопустимо.
    Последовательность применения бота должна быть примерно такой:
  1. При написании бота он в обязательном порядке должен содержать модули:
  • диагностики “неожиданных” данных, т.е. всех данных, которые не подходят под ожидаемый ботом шаблон,
  • протокола работы, которых, минимум, два: для обнаруженных ошибок и “неожиданных” данных и для фиксации ВСЕХ изменеий производимых(предлагаемых) ботом,
  • флага отключения обработки, при котором бот в полном объеме формирует протоколы работы, но не вносит изменений в базу.
  1. Написанный бот проходит отладку на небольшом фрагменте карты в режиме отключения обработки. Протоколы тщательно просматриваются человеком (включая тщательный просмотр протокола ВСЕХ изменений).
  2. На основе просмотра уточняются алгоритмы диагностики “неожиданных” данных и ошибок. Количество протоколов увеличивается, минимум до пяти:
  • очевидные ошибки и случаи, когда НЕ следует вносить изменения,
  • очевидные случаи, когда СЛЕДУЕТ вностить изменения,
  • все остальные, при которых алгоритм решит ВНОСИТЬ изменения,
  • все остальные, при которых алгоритм решит НЕ вносить изменения,
  • все остальные, при которых алгоритм не сможет принять решение (новая итерация “неожиданных данных”).
  1. Тестирование бота на нескольких других мелких фрагментах. При обнаружении каких-либо признаков неточной работы - возвращаемся на шаг 2 и повторяем. Протокол “неожиданных” данных не пуст - возвращаемся на шаг 2 и повторяем.
  2. Шаг 3 повторяется для нескольких средних по размеру фрагментов местности (с возможным возвратом к шагу 2).
  3. Тестирование бота на нескольких крупных фрагментах. Анализируются протоколы кроме “очевидных” (для которых просмотреть глазами становится уже нереально). Если какой-либо из “остальных” протоколов становится непомерно большим - пересмотр критериев и возвращение на шаг 2 с целью перевести из “остальных” в “очевидные”. При обнаружении ошибок (далее везде: включая - протокол “неожиданных” данных не пуст) - возвращение на шаг 2.
  4. Написание дополнительных утилит для анализа “очевидных” протоколов. Автоматизированный анализ этих протоколов. При обнаружении ошибок - возвращение на шаг 2.
  5. Тестирование алгоритма на всех данных, для которых его предполагается использовать.
  6. При обнаружении ошибок, либо при слишком больших “остальных” протоколах, либо подозрительной диагностике алгоритмов анализа “очевидных” протоколов - возвращение на шаг 2.
  7. Еще раз подумать.
  8. Применение алгоритма на небольшом фрагменте с проведением изменений.
  9. Сообщение о результатах работы на форум. Ожидание реакции других пользователей и ее анализ. По результатам анализа - либо возвращение на шаг 2, либо - переход на шаг 12.
  10. Аналогично 4-8, но с произведением изменений, сообщением о каждом проходе на форум и анализом реакции.

Вот уж за объем БД не переживайте. В любом случае, данных в проекте (при хорошем покрытии планеты) должно быть больше на порядки, чем сейчас. В сотни-тысячи раз, то есть.
И БД всё это прекрасно переварит.

То, что вы предложили - это конечно неплохо, но нежизнеспособно. Почему? Всё очень просто - сейчас даже написание хорошего пропозала штука довольно редкая, ибо для этого надо потратить немало времени для анализа существующих применений, возможных случаев и т.д. Дальше фразы “а давайте маппить вот так” отсеивается 99% мапперов.
Если же в пропозал добавить ещё и подробные многошаговые алгоритмы миграции с проверками и т.д. - то пропозалов не будет вообще. Если не добавлять - то непонятно, кто этими алгоритмами и ботами будет заниматься. Т.е. на практике никто не будет.

Поэтому адекватно использовать массовые миграции схем пока имеет смысл только для довольно простых расширений схем, например таких как миграция building=entrance → entrance=*, тут практически все возможные случаи может предсказать обычный человек и расписать в пропозале действия по миграции.

Выполнять же сложные миграции типа новой схемы public_transport автоматизированно я не представляю возможным. И тут масса аргументов против из прошлого опыта OSM, например взять недавнюю большую миграцию лицензий - технически тоже довольно несложная процедура, однако растянулась на несколько лет, включая формализацию задачи и непосредственно миграцию. И даже в случае миграции схем всё выльется в то же самое - написание бота, отладка на небольших кусках, попытка запуска world-wide, сбои, откаты, отладка, снова запуск, снова сбои, откаты и т.д. Нереально это, по крайней мере пока.

(3а) Способ плох по человеческому фактору, мапперы могут проставить новые объекты старыми тегами после первого прохода бота, а второй удалит это всё. Можно конечно логировать (удалять то что менял), но это усложняет алгоритм, нужно хранить большой лог и есть шанс что после первого прохода бота, незнающий маппер удалит задвоение оставив старое тегирование. В результате второго прохода мы потеряем совсем инфу (конечно по истории можно восстановить, но это уже сложный вариант).
Частный вариант - не везде применимо.
а (3) просто не ясно зачем вообще, по факту это п.1 +автоматизация.
Моё мнение, или п.1 или п.2. А принудительное задвоение тегов ботом - лишнее.

Так это же не одни и те же люди должны делать.
Вот сейчас дофига пропозалов, вот приняли entrance=yes, вот человек взялся пройти ботом.
За миграцию отвечает тот, кто взялся за миграцию. Он проходки ботом делает, он добавляет в рассылки и RSS информацию. Как - вопрос технический, а значит, решаемый.
И вот уже тут можно устанавливать правила. Вроде “не оповестил за месяц - откат без лишних вопросов”.

Мысли по ходу прочтения:

  • нужен централизованный один-единственный бот
  • формализованный шаблон этого бота должен позволять делать все те сложные вещи, расписанные выше
  • боту нужна площадка (на глагне?) на которой и будет происходить отладка каждого изменения схем тегирования
  • возможно такие глобальные изменения должны становиться в очередь, назначаться крайние люди/сроки
    как-то так

Если для относительно простых миграций это будут разные люди делать - то для большей части пропозалов миграций не будет вообще. Т.е. либо эту “отдельную” обязанность возьмёт на себя DWG (в чём я лично сомневаюсь на все 100%), либо на это сразу забьют.

Ну вот только что одну наблюдали.

Давайте пойдем от того, кому вообще выгодна миграция.
Выгодна она, прежде всего, авторам конвертеров и проектов по поиску/визуализации и т.п. - именно им удобнее, если нужно предусматривать меньше вариантов хранения одной и той же информации, если не нужно поддерживать старые схемы. Ради этого вопрос и затевается, на сколько я понимаю, а не ради абстрактного обновления и наведения порядка.
Так что нет, не забьют.

Возможность заменить что-то в базе - это просто более логичный вариант того, что и так делается в той или иной форме при втягивании данных в какой-либо конвертер. На это, как мы видим, не забивают. Разного рода валидаторы, ноги которых растут из конвертеров - из той же оперы.

Не забываем, что второй вариант уменьшения вариантов хранения - всячески гнобить новые схемы. :3
Что гораздо легче…

Я не отрицаю, что для некоторых douchebag-ов это может быть проще. Однако при наличии внятного механизма миграции это может стать менее актуальным даже для них. Если они не законченные douchebag-и, конечно.

Я за второй вариант, с например переходным периодом и оповещением.
Например мы везде где есть building entrance добавляем тег entrance yes - если это трактуется однозначно и например оповестив всех и вся, через месяц-два-три автоматически стираем нафег все building entrance. Этот вариант поможет более мягко подкачивать изменения софту и не губить работу всяческих программ, которые сами по себе ну не могут обновляться раз в неделю. Авторы тоже могут быть в отпуске/в декрете и т.п. :slight_smile:

Скорее уж через год-два :slight_smile:

вообще-то depricated это в первую очередь указание не для мапящих, а для кодящих. Чтобы знали, что есть метод лучше и включали поддержку нового.
А старые данные должны отмереть не в силу указа, а в силу невостребованности пользователями, ибо ведь есть метод лучше и его всемерная поддержка софта взамен ограниченной для сарого тега.

Про переходный период.

В смысле влияния на человеческий фактор, переходный период бесполезен. Предположим, что есть Вася с проектом показа POI. Он обрабатывает тэг key1. Для него переходный период означает только то, что key1 будет существовать несколько дольше. Если он пропустил каким-то образом оповещение о смене key1 на key2, сделанное за месяц до добавления key2, то само добавление также не будет для него “последним китайским предупреждением”, потому что key2 он просто в своем сервисе игнорирует, т.к. не знает о нем. И момент исчезновения key1 для него будет в той же степени неожиданным. Вопросы декретов и отпусков решаются до какой-то степени определением существенного срока оповещения. Но полностью предотвратить ситуации, связанные с человеческим фактором подобного рода, невозможно.

Единственное, что дает переходный период - время на контроль качества перехода проектов со старой схемы на новую (скажем, сравнение результата конвертирования с учетом старой и новой схем).

Хорошо, допустим для простых миграций можно пойти ещё дальше. Предположим, та же ситуация с entrance, т.е. машинно-однозначное расширение схемы без потенциальных потерь данных.
Делаем в несколько этапов:

  1. дописываем тег в список устаревающих с указанием даты выпиливания из БД (п.3)
  2. каждые 2 недели все building=entrance меняем на entrance=yes при условии отсутствия тега entrance=*
  3. по истечении описанного в регламете времени перехода выполняем последний раз операцию п.2 и вместе с этим выпиливаем building=entrance, а также переносим building=entrance из списка устаревающих в список устаревших/нежелательных, до кучи можно в списке сохранять id ченджсета, которым были выпилены исходные теги, дабы была возможность по full-history однозначно поднять версию до выпиливания.

В редакторах при наличии тега в списке устаревающих показывать ненавязчивую подсказку (жёлтым) с указанием урла-пропозала. При наличии тега в списке устаревших - вместо ненавязчивой подсказки показывать вполне себе навязчивый попап с всё тем же урлом и матами :slight_smile:

Нет, переходный период нужен именно из-за человеческого фактора, т.к. нельзя заставить всех мапперов в одночасье прочитать, понять и начать использовать некий пропозал. Этот процесс будет естестенным образом размазан по времени, и если редактор в некий момент начнёт жёстко ругаться на какой-либо тег - многие мапперы либо проигнорят ругань, либо перестанут юзать этот тег вообще. Поэтому необходимо это сделать мягко, вначале ненавязчиво, потом жёстко.

Это вы сами придумали или вам кто рассказал?

Если мапер игнорит текущие предупреждения при выгрузке, то конечно он забъёт болт и на это. А так вменяемые должны разобраться в чём же дело.

GaM, http://forum.openstreetmap.org/viewtopic.php?pid=297494#p297494

тоже верно. ну а контроль качества можно проводить на n примерах преобразованные руками/ботом.

Все это здорово, а как же “any tag you like”?