Новый "cleanup" сервис, и вопрос...

nyuriks · 2017-10-15T06:46:50.000Z

Всем привет, есть новый сервис, специально для “clean-ups” - то-есть если есть какая-либо распространённая ошибка, и её можно легко полу-автоматизированно исправить, новый сервис это упростит. Учтите что просто вслепую всё менять нельзя - все существующие правила продолжают действовать. Просто вместо того чтобы создавать MapRoulette challenge, или изменять код в Оsmose, или загружать кучу данных в JOSM, менять их с в текстовом файле, и загружать обратно, теперь есть новый способ.

Идея проста: вы пишите SPARQL query для поиска нужных OSM объектов, и для каждого query генерирует нужные изменения. Запустив эту query, вы видите карту с результатами. Кликнув на каждую точку, вы можете проверить правильность изменения, и принять её, сохранив прямо в OSM. Так как эту query можно сохранить в вики, другие могут помочь вам с проверкой всех найденных объектов.

Главный вопрос – что делать с “rejects”: если изменение предложено неправильно, нужно как-то его пометить. Иначе кто-то другой может не заметить и сохранить его. Сейчас сервис не имеет такую базу данных (работаю над этим), но есть обходной путь. Можно хранить rejects прямо в самом OSM, точно так-же как мы храним “fixme” и другие подобные тэги. Вопрос - согласно ли сообщество на такой новый тэг, например “nobot”. Если мы стандартизируем его, то разные queries и другие сервисы смогут помечать все подозрительные объекты, а далее люди смогут в ручную их исправлять если надо. Этот тэг будет содержать список всех query IDs где кто-либо пометил как “reject”.

техническая инфа
пример предложенный Владимир К: amenity=sanatorium → leisure=resort+resort=sanatorium
несколько других примеров

freeExec · 2017-10-15T07:06:08.000Z

Плюс MapRoulette challenge, то что правки не автоматизированы и нет соблазна все 200 точек не глядя загнать в ОСМ. Так что я за принцип только валидации. Соответственно и ложные срабатывания надо хранить в валидаторе, а не основной базе.

nyuriks · 2017-10-15T10:34:37.000Z

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

Более того, cleanup tool специально требует чтобы вы видели по крайней мере zoom 16 чтобы сделать изменение - тем самым человеку сложно просто кликать автоматом - нужно просмотреть вручную каждый конкретный объект.

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

freeExec · 2017-10-15T10:47:40.000Z

Да, я именно про то, что наличие интеллектуальных действий уменьшает вероятность принятия неправильного решения.
Вот то же пример с санаториями, что по вашему там должен проверить человек, что в исходном был amenity=sanatorium, а в новый добавились теги leisure=resort+resort=sanatorium? Я думаю алгоритм отрабатывает чётка в 100% случаях.
А по уму как должно быть, показать что тег некорректный и человек сам должен подобрать к нему замену. Пойти порыться в интернете и понять чем занимается данное учреждение. А не слепо верить надписи на вывеске “санаторий”.
В текущей ситуации можно было просто объявить импорт со всем соответствующим и автоматом всё переименовать, разницы вот никакой не вижу.

nyuriks · 2017-10-15T11:04:10.000Z

freeExec, про санатории возможно вы правы - данный пример был придуман не мной, а предложен на Телеграмм-канале. Просьба рассматривать его исключительно как пример возможности, а не призыв к исправлению. Идея же в том, чтобы сообщество вместе собрали и отслеживали ряд полезных мини-изменений, вместо того чтобы либо А) программист написал бот и только один человек его реально смотрел/запускал, либо Б) бездумно бы кликали “FIX” в JOSM, при этом комбинируя массу различных изменений вместе, что делает последующие проверки сложнее.

Посмотрите пожалуйста на другие quick fixes - простейшие очевидные исправления - вот моя основная цель. Использовать наиценнейший ресурс - человеческий мозг - для неоправданной рутины это невозможность его использования там где он реально нужен.