OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2012-12-12 04:33:13

Hind
Member
From: Moscow
Registered: 2009-05-25
Posts: 3,948

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

Предлагаю обсудить правки, преобразующие глобально устаревшую схему тегирования в актуальную. Например, на днях сделанную и откаченную замену нодов building=entrance на entrance=yes.

Я вижу два пути внесения глобальных изменений:

1. Постепенно переходить к новой схеме, годами пропагандируя в сообществе новые теги и бурча про deprecated, натыкаясь на старые.
За:
Мягкость перехода (не разрушаются в одночасье устоявшиеся операции над данными).
Против:
Незаметность перехода. Потребитель данных может годами не знать о новой схеме тегирования и не замечать, что новых данных-то почти и не поступает (тем более, что часть пользователей по различным причинам будет вносить данные в старой схеме). Не надо говорить про списки рассылки с оповещением о новых тегах / вики / тп. Это НЕ работает, так как никто не хочет ничего читать (даже дайджест изменений в осомданных), все хотят мур-мур-мур.

2. Единовременно задействовать новые теги на всей планете.
За:
Оперативность ввода в строй новых схем.
Шоковая терапия. Пользователи актуальных проектов немедленно поднимут вой и наоткрывают стопицот багов в трекерах.
Против:
Никем не поддерживаемые проекты, основанные на старых тегах, мгновенно умирают, лишаясь данных.

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

Рекомендую сразу отмечать, в копилку какого варианта вы высказываетесь.

Offline

#2 2012-12-12 05:00:16

lenux
Member
Registered: 2011-12-06
Posts: 617

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

Мне кажется второй пункт подойдёт, только не для мира, а для России. Так же хотелось иметь документ где было ДО, и ПОСЛЕ ,  а то иначе будем по-старому  тэггировать roll.

Offline

#3 2012-12-12 05:50:18

az09
Member
From: Магнитогорск
Registered: 2011-02-03
Posts: 219
Website

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

Выскажусь как тот кто хочет мур-мур-мур. Я не против второго варианта, он кмк предпочтительней. Главное чтобы мгновенно не умирали редакторы, и даже пусть мгновенно перестают deprecated схемы поддерживать.

Offline

#4 2012-12-12 06:38:40

LinFor
Member
From: Moscow
Registered: 2011-10-17
Posts: 155

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

Я однозначно за второй вариант. Вообще я не понимаю, что такого ужасного в том, что ботом произвели однозначную трансляцию старого в новое.
Моё видение как программиста: в пропозалах должна появиться новая секция, "план миграции со старых схем". Там подробно расписывать какие шаги по переходу на новую схему можно сделать ботом, какие нет. Для тех, которые можно - делать их ботом, централизованно.
Также завести некий глобальный key-value список deprecated и прочих нежелательных тегов. Обучить josm и прочие редакторы на старте подтягивать обновление этого списка и при присвоении тега предупреждать пользователя о том, что данный тег находится в статусе нежелательного. Можно url приложить с подробностями. Это снимет уйму вопросов "какого х" и позволит большинству мапперов оставаться в курсе событий.

Ну а дальше всё просто, например:
1. приняли пропозал
2. устареваемые теги добавили в список нежелательных, приложили урл на пропозал
3. согласно плану миграции подождали, скажем, месяц, или два, за время которых обновили стили рендереров и т.д. под новые схемы
4. по истечению срока глобально натравили бота, который подменил теги
5. теги из списка устареваемых перенесли в список устаревших

Offline

#5 2012-12-12 06:41:25

Arhemed
Member
From: Калининград
Registered: 2011-09-21
Posts: 86

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

Я за второй вариант. И думаю, да надо вести таблицу до, после, плюс заводить пункты указывать дату когда планируется массовая замена. Т.е. за месяц до смены тега объявлять, что он будет меняться, время будет дабы живые проекты подготовились.

Offline

#6 2012-12-12 06:47:27

Hind
Member
From: Moscow
Registered: 2009-05-25
Posts: 3,948

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

LinFor wrote:

на старте подтягивать обновление этого списка и при присвоении тега предупреждать пользователя о том, что данный тег находится в статусе нежелательного

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

Offline

#7 2012-12-12 06:51:02

ErshKUS
Member
From: Калиниград
Registered: 2010-12-27
Posts: 795

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

За второй вариант.
Чтобы для разрабов это не было неожиданностью можно или на вике публиковать (хотя кто её читает, тем более оперативно).
Или сделать примитивный сайтик-бот, вписал своё мыло и тебе будет приходит уведомление о введении новых тегов заранее (идея Фелиса)
За ранее - например 2 недели, или месяц.

Отдельно в России будет проще протолкнуть, но если не вводить свои правила отдельно от мира, то тоже вариант.

Но все эти замены после голосования, по типу пропозалов. Только я бы обсуждение и голосование перенес в форум, а в ирке вике содержание и результаты.

Last edited by ErshKUS (2012-12-12 07:00:43)


Ты никогда не спутаешь пути: ты стоишь...
И, может, так и нужно, но как тогда узнать, что там выше крыш?   (Lumen, Лабиринт)

Offline

#8 2012-12-12 06:56:12

freeExec
Moderator
From: Ульяновск,Модератор всех слоёв
Registered: 2012-07-31
Posts: 7,565

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

LinFor - здравую мысль высказал.
П.С. Что есть - дайджест изменений в осомданных ?

Offline

#9 2012-12-12 06:57:34

Hind
Member
From: Moscow
Registered: 2009-05-25
Posts: 3,948

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

freeExec wrote:

П.С. Что есть - дайджест изменений в осомданных ?

Это гипотетическая рассылка. :3

Offline

#10 2012-12-12 07:06:07

LinFor
Member
From: Moscow
Registered: 2011-10-17
Posts: 155

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

Hind wrote:

А вот сама идея годная. Добавил устаревший тег - получи всплывающий бар сверху (как при открытии спутниковой подложки впервые).

Этот же список могут автоматизированно читать и разработчики-потребители данных. Т.е. есть у меня некий софт, ориентируется на такие-то и такие-то теги. Девелопер пишет простенький скрипт, который периодически скачивает данный список и проверяет наличие используемых тегов в этом списке. Если находит - пинает своего хозяина-девелопера smile И никаких рассылок и зависимостей от почтовых служб не надо smile

Offline

#11 2012-12-12 07:15:57

Hind
Member
From: Moscow
Registered: 2009-05-25
Posts: 3,948

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

Можно просто помечать теги как deprecated и описывать рекомендуемую замену в Машиночитаемом стандарте™.

Проблема, как всегда у нас, кто будет за это отвечать, и что ему будет за саботаж. :3

Offline

#12 2012-12-12 07:16:31

ullus
Member
From: Москва
Registered: 2011-04-17
Posts: 373

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

Поддерживаю второй вариант при наличии "дайджеста изменений" или любого другого варианта оповещения.

Offline

#13 2012-12-12 07:17:24

LinFor
Member
From: Moscow
Registered: 2011-10-17
Posts: 155

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

Hind wrote:

Проблема, как всегда у нас, кто будет за это отвечать, и что ему будет за саботаж. :3

Ну как минимум то, что было коту с твоей аватарки - неспроста же у него такое выражение морды smile

Offline

#14 2012-12-12 07:48:48

BushmanK
Member
Registered: 2011-05-03
Posts: 5,106

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

Существование разных схем, которые друг друга в той или иной степени дублируют - зло.

Если принят более совершенный метод обозначения, автоматический переход на который не приведет к потере какой-либо информации, хранящейся в старой схеме - переходить на новый нужно разом.

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

Чтобы "всё было и ничего за это не было", о процедуре должно сообщаться заранее, в духе: "Для приведения данных к единой схеме обозначений, будет проведена замена того-то на то-то при таком-то условии (тут точное исчерпывающее описание), если у вас есть конкретные возражения, сообщите инициатору таким-то способом. Замена будет осуществлена тогда-то. Дата замены может быть по аргументированному требованию перенесена, но не более чем на n дней. Информация о проведенной замене будет также опубликована в таком-то разделе wiki по постоянному адресу такому-то." Новость такого рода можно опубликовать в вики, рассылке, в специально выделенной для этого теме национального форума, на любых других ресурсах по желанию.
(Вот минимальный список мест, где нужно сделать такое оповещение, нужно согласовать заранее.)

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


"Не умею" не значит "невозможно", "не видел" не значит "не бывает". "Нет проблемы", вероятнее всего, значит, что "нет мозгов".

Offline

#15 2012-12-12 08:14:15

Kato Kontenta
Member
From: Нижний Новгород
Registered: 2012-04-27
Posts: 75

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

Второй вариант с оповещением предпочтительней. Главное сделать это оповещение официальным и собственно везде его указать — в wiki, на switch2osm и прочих ресурсах для пользователей данных.
Думаю здорово было бы организовать RSS и какой-нибудь машиночитаемый список.

Offline

#16 2012-12-12 08:22:06

andriano
Member
Registered: 2009-06-15
Posts: 1,667

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

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

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

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

Offline

#17 2012-12-12 08:34:27

Hind
Member
From: Moscow
Registered: 2009-05-25
Posts: 3,948

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

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

Offline

#18 2012-12-12 08:44:40

LinFor
Member
From: Moscow
Registered: 2011-10-17
Posts: 155

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

andriano wrote:

(3). Автоматическое проставление ботом новых тегов по имеющимся в базе старым без удаления из базы последних.

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

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

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

Offline

#19 2012-12-12 08:48:49

ErshKUS
Member
From: Калиниград
Registered: 2010-12-27
Posts: 795

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

andriano wrote:

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

Как вариант:
(3а). Двухшаговый алгоритм:
- Автоматическое проставление ботом новых тегов по имеющимся в базе старым без удаления из базы последних.
- через несколько месяцев (лет?) и после дополнительного обсуждения - удаление старых в тех местах, где есть новые.
т

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

Last edited by ErshKUS (2012-12-12 08:49:58)


Ты никогда не спутаешь пути: ты стоишь...
И, может, так и нужно, но как тогда узнать, что там выше крыш?   (Lumen, Лабиринт)

Offline

#20 2012-12-12 08:50:25

Hind
Member
From: Moscow
Registered: 2009-05-25
Posts: 3,948

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

LinFor wrote:

Если же в пропозал добавить ещё и подробные многошаговые алгоритмы миграции с проверками и т.д. - то пропозалов не будет вообще.

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

Offline

#21 2012-12-12 09:16:17

az09
Member
From: Магнитогорск
Registered: 2011-02-03
Posts: 219
Website

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

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

Offline

#22 2012-12-12 09:55:20

LinFor
Member
From: Moscow
Registered: 2011-10-17
Posts: 155

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

Hind wrote:
LinFor wrote:

Если же в пропозал добавить ещё и подробные многошаговые алгоритмы миграции с проверками и т.д. - то пропозалов не будет вообще.

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

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

Offline

#23 2012-12-12 10:13:14

Hind
Member
From: Moscow
Registered: 2009-05-25
Posts: 3,948

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

LinFor wrote:

миграций не будет вообще

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

Offline

#24 2012-12-12 10:18:27

BushmanK
Member
Registered: 2011-05-03
Posts: 5,106

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

LinFor wrote:

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

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

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

Last edited by BushmanK (2012-12-12 10:21:29)


"Не умею" не значит "невозможно", "не видел" не значит "не бывает". "Нет проблемы", вероятнее всего, значит, что "нет мозгов".

Offline

#25 2012-12-12 10:30:19

Hind
Member
From: Moscow
Registered: 2009-05-25
Posts: 3,948

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

BushmanK wrote:

именно им удобнее, если нужно предусматривать меньше вариантов хранения одной и той же информации

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

Offline

Board footer

Powered by FluxBB