Вандализм

Communities Россия (Russia)
161

Валидаторы - вещь, безусловно, полезная, но их роль тоже не следует преувеличивать.
Практически любой валидатор проверяет какой-то набор свойств по некоторому подмножеству данных ОСМ. И уже на этом этапе проявляется существенный недостаток - на обработку подаются не все данные, а только те, что удалось безошибочно распознать.
Пусть у нас, скажем, есть 10 полностью дублирующихся веев: один из них распознается как дорога, другой - как часть границы лесного массива - а третий - как часть границы города (эти два включены в соотношения границы леса и города соответственно), остальные 7 либо вообще не содержат тегов, либо содержат теги с ошибками либо нестандартные теги.
Еще у нас есть 3 валидатора: дорожного графа, связности и пересечения природных объектов, а также административных территорий.
Все валидаторы сообщают, что у них полный порядок вообще и отсутствие дублирование каких-либо примитивов в частности, что, очевидно, не соответствует действительности, т.к. у нас, грубо говоря, 70% откровенно неверной информации (гнраспознанные веи) и еще 20 - лишней (3 вея вместо одного).

В общем, почаще открывать валидаторы, конечно, необходимо, но совсем не достаточно.

162
  1. Сделать хороший RSS-список правок. OWL таковым является, хорошо бы его уже запустить.
  2. Улучшить отображение правок. Не просто список измененных примитивов, а отдельно: добавленные точки; удаленные точки, у которых не было тэгов; удаленные точки, имевшие тэги; точки, изменившие только координаты, без изменения тэгов; точки с только добавленными тэгами; точки с измененными тэгами, без удаленных тэгов; точки, у которых удалены некоторые или все тэги; та же классификация по линиям и отношениям.
  3. Визуализатор правок. Сейчас на карте показывается только прямоугольная область. Надо, чтобы подсвечивались объекты. Отдельно своим цветом: добавленные (например, зеленым); передвинутые (синий); измененные (рыжий); удаленные (красный).
163

Это же каким умным должен быть алгоритм! Думаю что 1% позитивных срабатываний это будет неплохой результат.

164

А от того что отслеживателя правок не называть валидатором он сможет проверять все без исключения данные?
Он ведь тоже сможет распознать только определенный набор ошибок.

Случай с десятью линиями частично отслеживается

Вот еще ссылка на поломанные мультиполигоны, в том числе и административных границ
http://tools.geofabrik.de/osmi/?view=multipolygon&lon=38.26743&lat=56.56902&zoom=8&overlays=duplicate_ways,intersections,intersection_lines,ring_not_closed,unconnected_end_nodes,touching_inner_rings,role_mismatch
Если бы этих ошибок не было то и отслеживать новые ошибки такого же типа было бы проще.
Просмотрев последние правки кривых объектов можно уже решать исправлять данные или откатывать ченджсет полностью или частично.

У KeepRight’a кстати есть возможность подписаться на RSS новых ошибок в определенной области. Тоже удобная штука чтобы следить за интересуемой областью.
http://keepright.ipax.at/interfacing.php?lang=ru#RSS

165

Такая знатная тема, а я не отметился! Ай-ай.
По делу:
Мне бы не помешала очень простая фича:

Это, вроде несложно реализовать через userjs для браузеров. Но у меня сложности с яваскриптом :frowning:
Кто-нибудь может забацать?

166

А исходники osm.org где-то выложены ?

167

Идея отличная, но нужны абсолютные значения (есть разница, поменялось 10 точек, или 10 тысяч).

Вот здесь, вроде б, всё описано.

168

Попробую поковырять HTML часть. Кто силён в API, чтобы эти данные получить на стороне сервера и запихать их в страницу в этих местах:

<script type="text/javascript">
$("#tr-changeset-13165043").mouseover(function() {
  highlightChangeset("13165043");
});

$("#tr-changeset-13165043").mouseout(function() {
  unHighlightChangeset("13165043");
});
</script>

Предполагаю в функцию highlightChangeset(…) передавать еще объект с нужными значениями. Получиться что-то типа:

$("#tr-changeset-13165043").mouseover(function() {
  var change={'nodes': {'add':9, 'mody':40, 'del': 1},
    'ways': {'add':9, 'mody':40, 'del': 1},
    'relations': {'add':9, 'mody':40, 'del': 1},
  };
  highlightChangeset("13165043", change);
});

Получилось как-то так: cboboda.pisem.su/OpenStreetMap_edits.mht (сохранить и открыть в баузере)

169

Ага. Очень здравое замечание. Можно в каждой шкале процент показывать цветом и цифрами писать общее колличество объектов, чтобы сразу было ясно о каком порядке идёт речь.

Именно то, что нужно. Правда, как получить значения действительно не очень понятно.
Мне приходит в голову только парсинг xml чейнджсета (типа http://www.openstreetmap.org/api/0.6/changeset/13165043/download). Что по понятным причинам не есть гуд.

170

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

171

:slight_smile: не надо ничего парсить, это должен делать osm.org тогда же когда он получает границы правок.

А сам крупный проект когда будет опубликован ?

172

Раньше, чем запустят OWL :slight_smile:

173

Кстати, а возможен сервис оперативного оповещения о данных конкретного пользователя, которые недавно стерты/изменены?
Ну вот я что-то нарисовал, это что-то стерли, перенесли или понавешали тегов, а я могу посмотреть, кто и что изменил.
Тогда и дружин не надо, активных мапперов будет достаточно.

174

Если анализатор берет не “сырые” данные ОСМ, а после конвертора, выборки или иного фильтра - то “да”.
А при анализе “сырых” данных можно выловить “все оставшиеся” ошибки, которые принципиально не ловятся в отфильтрованных данных - случай, когда хранящуюся в ОСМ информацию невозможно распознать. Самый простой случай - ноды или веи без тегов и не входящие в элементы более высокого уровня, второй распространенный вариант - ошибки в написании.

Здесь, правда, есть очень серьезные проблемы - несовместимость с принципом “any tags you like”: все “пользовательские” теги не прошедшие процедуру, а также те, что уже прошли, но еще не включекны в словарь валидатора, будут выдавать ложное сообщение об ошибке. Ну и, само собой, поддерживать этот словарь в актуальном состоянии - тоже не просто ввиду отсутствия собранного в одном месте списка допустимых тегов.

175

Приветствую всех.
Можно попробовать применять статистические методы для отлова вандальных изменений: например вести статистику изменений по некоторым регионам, и в случае сильного отклонения от “мат.ожидания” поднимать тревогу.
К сожалению не знаю как устроена база данных osm изнутри, но можно попробовать применить какую-либо систему контроля версий типа svn и ей подобных для откатов изменений.
Я правильно понимаю что весь движек osm написан на жаве?

176

Такие идеи уже были, но к сожалению, никто не сделал. Сделаете, многие будут вам благодарны! :slight_smile:

177

К сожалению я в вебном программировании не силен… Если есть описание как снять данные с сервера и в каком формате они хранятся - то можно попробовать.
В общем нужна дока по API для OSM, и лучше чтоб он был на плюсах :slight_smile:

178

Я вообще в программировании не селен :slight_smile:
Вот описание API ну и вот.

179

да есть сайты со статистикой по региону. на гис-лабе. а зарубеж. наверно тем более
не изобретайте велосипед. гугл в руки и найдете опенсорс. допилите под себя м в путь

просто никому эт не нуна. ток голословие

п.с. у меня допустим нет возможности по времени и средств (сервак держать)

180

Посмотрим, понюхаем (c) берегись автомобиля :slight_smile:
Завтра на свежую голову покопаюсь в тырнете на предмет анализа данных… Может нароем что-нибудь полезное