Статья на Штосме про 3-е измерение и комментарии к ней наводят на мысль, что сообщество идёт к запрету больших импортов. А если не к запрету, то к жёсткому ограничению.
Я считаю это в корне неправильным, т.к. новых участников в проект привлекает в существенной степени фактическое наполнение - наличие хоть как-то прорисованных объектов в области интереса. Поставить POI на готовые здания или улицы проще, чем на бескрайнее белое поле.
Проблема больших импортов обозначена как “иначе как всё удалить и импортировать заново, данные в OSM не обновить” и “править руками импортированное настолько муторно, что этим никто не занимается”.
Недавний же успех полуавтоматического распознавания номеров домов для Эстонии навёл меня на мысль, что аналогичный процесс можно использовать для фильтрации больших импортов, их обновления или пост-корректировки и вообще.
Предложение
Сервис, который будет показывать пользователю 1 объект на некотрой подложке и предлагать выбрать что с ним делать - импортировать или не импортировать; удалить или оставить; заменить на более новый или оставить как есть или добавить новый объект.
Если 2 пользователя (два из двух, два из трёх и т.п.) выберут одно действие - бот это действие и производит. Может быть даже сразу же.
Примеры
Объект X был импортирован из TIGER 2005 и с тех пор не редактировался, в TIGER 2012 есть похожий объект. Что делаем?
Заменяем
Оставляем старый
Оставляем старый + загружаем новый
Предлагается импортировать объект Z из CORINE 2014
Импортируем
Не импортируем
Импортируем, но я хочу поправить тэги вручную
(следующему участнику уже показываются тэги, заданые этим)
Объект U импортирован из TIGER 2012, проверьте, пожалуйста, его тэги
Задать тэги
Открыть в JOSM
Тэги и так заданы правильно
Дорога W из TIGER 2005/2012 находится близко к дороге T, нарисованной участником P, но не подключена. Можете ли отредактировать в JOSM по снимкам bing, чтобы правильно связать дороги?
Открыть в JOSM
Здесь не нужна связка дорог
Ну и так далее.
Во всех случаях можно пропустить, можно попросить показывать объекты только из заданой области (для тех кто хочет проконтролировать импорт в своей области интереса).
Во всех случаях должна быть отметка (на объекте или правке), что объект создан/скорректирован таким-то процессом полуавтоматического импорта (и может быть даже, кем именно из участников был сделан выбор указанного действия).
Преимущества
Поучаствовать просто, затраты времени могут исчисляться минутами
Участникам не нужно искать проблемные области
Если правки делать (почти) сразу, то быстрее можно выявить проблемы (а не после нескольких 50000-объектных правок) и остановить процесс
Гигантский импорт может быть профильтрован практически вручную на очевидные косяки
А далее можно развить идею до общей корректировки OSM в таком режиме
показывать случайный объект с тэгом fixme и предлагать его поредактировать.
случайную область где нет объектов, но есть bing с хорошим разрешением.
Здравая идея атомизации процесса.
Зло - не импорт, а импорт без верификации и валидации данных.
Для каждого конкретного набор параметров валидации может и должен быть свой, т.к. данные разные.
Возникает вопрос: а каков должен быть механизм учета голосов при валидации? Мне видится подходящим вариант накопления голосов до кворума, если они однозначны, и сверх кворума, пока не будет достигнуто требуемое большинство (скажем, соотношение 1 к 5). Это позволило бы не обращать внимания на проблему неквалифицированного голосования. (Заниматься охотой на ведьм и исключать из рассмотрения голоса пользователей, которые находятся в, гхм, оппозиции - определенно не задача такого сервиса.)
Важно не обойти некоторые мотивации в погоне за модной “геймификацией”.
Кому-то наплевать на рейтинг, но он может хотеть исправить все в “своем районе”. И т.п.
Поэтому я и добавил “можно попросить показывать объекты только из заданой области (для тех кто хочет проконтролировать импорт в своей области интереса)”.
Идея полуавтоматизировать валидацию мне нравиться, но есть технические сложности:
Далеко не всегда понятно что импортируется новая версия.
К примеру проимпортировали Тайгер 2005, дальше вей отредактировали (к примеру разделили попалам)
Мы толком не знаем редактировался ли объект с момента последнего импорта.
Тайгеровский айдишник окажется на 2х половинках вея, в Тайгере 2012 будет по целому вею на замену каждой половинке.
В Литве полуручной импорт сработал столь удачно потому, что загружать josm практически не требовалось.
С импортами типа тайгера - сложнее: к примеру уже есть вей в осм (пусть не импортированный), но в тайгере он проходит чуть в стороне и имеет другие атрибуты. Если загружать жосм и копировать атрибуты с тайгера на осм-вей весь смысл пропадает, проще заимпортировать кусок криво, с дубликатами и на большой территориии перенести теги, чем каждый раз вызывать josm для отдельных кусков.
(Но это лучше чем просто тупо импортнуть тайгер, обрезав его к примеру)
Ну или требуется соединить импорт с уже существующими данными: к примеру пусть импортируем лес. Часть уже нарисована точно по бингу, часть сгенерили по ландсату. Тут и дропать ландсатовский кусок не хочется т.к. у него покрытие больше, но уже нарисованный кусок он перекрывает, причем с худшей точностью - это опять импортировать с наложением,открывать в джосм и мерджить.
Но в любомслучае crowd валидируемый импорт лучше чем просто импорт.
Не в качестве спора, а как я это вижу:
Пользователю покажут новый вей (из 2012), старый (одну из половинок) и подложку, где видно, что есть продолжение и новый вступит с ним в конфликт.
Адекватный пользователь должен нажать “Оставляем старый”
(ну а вообще, можно попробовать проверять “тайгеровский айдишник более чем на 1 вее” и были ли правки после создания объекта с тайгеровским айдишником)
Хм. Ну скажем, в первый пример добавляем кнопку - “Тут желательно выполнить слияние вручную”.
Если это вариант “побеждает”, то новый объект пока не импортируется, но данные передаются на второй этап, там близкие объекты группируются и выдаются участникам на ручное слияние.
Да я тож об этом подумал :), но увы, для хорошей капчи надо получать побольше бит информации (не 2-3) от пользователя, иначе боты просто будут угадывать правильный вариант. Тут же задача обойтись 3-4 кнопками, не больше (с)
Ну а капча со вводом тэгов будет слишком убойной
IMHO, система применима только для независимых объектов либо вообще только тегов.
Покрытие растительности или сеть дорог так не импортируешь, слишком многое может произойти между валидацией одного объекта и смежного. Да и стыковка с имеющимися данными в этих случаях очень нетривиальная задача. Эти случаи - только вручную. Хотя создание объекта в JOSM через Remote Contol автоматизировать несложно.
Это хорошо если так. А я вот например разделяю здания методом уменьшения текущего, и дорисовываю рядом новый вей… Естественно, непонятные мне айдишники я переносить не буду.
Ошибка автора в том, что надо придумывать инструмент под задачу, а не задачи под инструмент
Покажите конкретную задачу (что имеется, что хотим импортировать, с какими проблемами столкнулись), а мы уже подумаем, как максимально облегчить ручную работу (если она вообще требуется).
В моём случае “рекапча” была обоснована тем, что автоматическое распознавание символов не заработало должным образом из-за сложных входных данных (номера были повёрнуты как попало, а в процессе поворота ещё и получили искажения).
Независимых объектов в осм вообще нет. И ценность осм в том, что все объекты прошли проверку человеком на взаимную согласованность.
Например, если на берегу озера стоит дом, вокруг дома забор, в заборе ворота и к ним подходит дорога, эти объекты абы как располагаться не могут. Если же просто натырить объектов с разных источников, то тут же вылезут дороги поперек домов, заборы по водоемам, и.т.д.
Возможно.
Но если инструмент получается универсальным, то им можно решать больше одной задачи - не надо будет каждый раз тратить время на создение инструмента.
Ну я не могу ткнуть в явный косяк TIGER 2005, с разбегу нашёл вот улочку, которая на bing-е короче, за Main Street не продолжается.
Насколько я вижу по tms-ке, в TIGER 2012 улица такая же, можно не импортировать.
Но чтобы в этом убедиться, удобного инструмента нету. Может быть будут делать выпиливание 2005 и импорт 2012.
Так для того и предлагается в ручном режиме фильтровать импортируемые объекты. Если участнику показывают дом, которой в случае импорта упадёт на дорогу, то он должен жать кнопку “Не импортируем” или “Я хочу поправить объект вручную”
В случае “Я хочу поправить объект вручную” как он должен подготовить место для будущего дома. Двигать дорогу ? Но наверняка она находится на нужном месте, а это кривой дом. Как он будет двигать несуществующий дом. Или предлагается импорт по одному дому
В случае ручной правки - да, импорт 1 объекта от аккаунта участника.
По совокупности участник должен загрузить в JOSM (ну или в другой редактор): bing, объекты из OSM в области импорта и импортирумый объект (которого ещё нет в OSM). Что-то автоматически, что-то в ручную, как сделаем. Дальше крайне желательно проверить смещение bing-а по трекам и т.п. ну а потому уже приступать к корректировке положения, формы и тэгов объекта.
