Скрипт для наблюдения за своими правками

Часто бывает, что хочется наблюдать за тем, что происходит со своими правками в OSM - а именно, кто изменял уже отредактированные ранее тобой объекты:

  • не навандалил ли;
  • не заменил ли опрометчиво данные, свежесобранные на местности, на устаревшие из каких-нибудь муниципальных схем/реестров
    и т. д.

OSMCha эту задачу не решает: она позволяет следить за всеми изменениями на конкретной территории, но безотносительно к тому, “потрогал” ты когда-либо объекты на ней, или нет. Здесь же задача ортогональная: неважно, в какой точке мира расположен объект, но если я его хоть раз редактировал (а это значит, что либо он мне не безразличен, либо у меня была какая-то информация о нём, которой до этого базе не было), то хочется знать, кто и что делал с ним после меня.

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

https://yadi.sk/d/K43u7o3dfLV8gA

Отдельной документации по нему нет, я постарался описать всё необходимое посредством комментариев в коде на русском языке. Для работы нужен Pyhton с установленными модулями requests и more_itertools (оба можно установить с помощью утилиты pip). Разработка и практическое использование производилось на связке Windows 10 + Python 3.9. Под другими версиями не проверялось, но скорее всего заработает и более старых (ну, конечно, на Python 2.7 не пойдёт :)).

Важный момент - скрипт делает только пакетные запросы к API, и нигде не спускается до уровня “отдельный запрос для каждого объекта”. Поэтому даже когда число исправленных пользователем объектов исчисляется сотнями тысяч, он отрабатывает буквально за несколько минут.

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

опечатка в тему.
Крайний вариант вахтёрства, прям Совой запахло. Вместо того, чтобы внести больше правок, трястись над своими точками, как Кощей над златом.

И как это на практике, что делать в тем ворохом из сотни тысяч точек что ты когда то-то трогал?

Напомнило анекдот про долгоносика в колхозе. Тогда и OSMCha - тоже вахтёрство. Но обычно всё же хочется, чтобы потраченное на рисование время не было обращено в ничто стараниями отдельных уникумов. Вон в НЯКе народ плакался о том, как плохо не иметь возможности мониторить правки яндексовых роботов, потому что фигню творят и не вычистишь потом за ними.

Сова, насколько я помню, вопросы и претензии к чужим правкам писал сотнями и грозился всё откатить. Я за несколько лет пользования скриптом заметил буквально с пяток случаев порчи данных, по которым писал комментарии к чейнжсетам. В одном случае оказалось, что человек вносит правки по Яндекс.Панорамам от 2017 года, а я на месте был летом 2020. В другом наломала дров местная таксокомпания, которая меняла все name чёрт-те как, лишь бы у них в программе удобнее искалось. А иногда при просмотре изменений безо всяких вопросов узнавал о новых принятых тегах (например, line_management), которые начал использовать в дальнейшем сам.

Ну вот у меня сейчас 772 чейнжсета, затрагивающих порядка 112k точек, 10k веев и 2k отношений. С 13 ноября по сегодняшний день был изменён 101 объект из них. Большая часть правок - уточнение геометрии отдельных нодов. То есть отсматривается всё за 10 минут.

Да, интересно, оказалось hdyc имеет такую статистику - у скольких объектов ты последний автор.
Для точек ~20% были после меня изменены, для линий это ~35%. И вроде бы не много, но в абсолютных цифрах это порядка 600 в неделю. И по большей части врятли кого сильно интересует кто там дальше уточняет, нарисованный тобой по IRS лес, реку или поле.
Мне казалось, что тех, кого это интересует, хотят следить всё же за POI. И возможно не только за своими, а скажем за магазинами конкретной сети. Вот хочу мониторить все Магниты в стране, например.

Я как раз POI в основном пропускаю, там мне чаще попадают правки от RocketData. Тот кейс был про ЛЭП - в 2017 году на Яндексе ЛЭП в Покровском-Стрешнево заброшена, а сейчас она уже восстановлена и обновлена. Тема электроэнергетики интересна малому числу маперов, поэтому если там кто-то накосячит, то неизвестно сколько времени в базе пробудут неверные данные. Но в целом, как я заметил, чаще правят геометрию, чем теги. Была идея сделать вывод только в том случае, если был удален объектов с тегом или изменены теги на существующем, но в API тогда придется делать вызов на каждый объект и парсить его историю, и тогда скрипт будет работать сутки.

Можно же обращаться к локальной базе

Тогда надо место (много места), где её локально хранить + будет всегда некий лаг между ней и актуальным состоянием.

Полезный скрипт.
Я вношу правки там где физически бываю и часто вижу как всякие apple и прочие переписчики населения начинают вредить.

Я был тут несколько месяцев назад, а кто-то посмел внести данные за 17-й год. Я хочу следить за этим!

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

Как по мне - инструмент - это всегда хорошо. Есть те, кому он интересен. А есть те, кто колесят по просторам страны и правят все подряд на площадях в тысячи километров - тогда да им такой инструмент, может, и не нужен.

Скрипт MakeWatchList.py не хочет работать и падает с ошибкой

  File "./MakeWatchList.py", line 87, in <module>
    for chunk in grouper(objects[obj_type], CHUNK_SIZE, None):
  File "/usr/lib/python3/dist-packages/more_itertools/recipes.py", line 295, in grouper
    args = [iter(iterable)] * n
TypeError: 'int' object is not iterable

Python 3.7, Debian Linux 10.7

А потом сойдутся в бою два скрипта…

Я под Linux не проверял (и сильно не уверен, что в обозримом будущем на это будет время :frowning: ), но скорее всего дело в том, что какой-то кривой модуль more_itertools встал.

Ссылка на скрипты не работает.

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


Processed 5979 from 5979 relations, total 3877 objects changed
sh: pause: команда не найдена

Без ограничения по территории, как-то сложно 3877 строк проверить. Если это количество строк. Как и не слишком принципиально, что с теми объектами, созданными 10 лет назад в Астрахани…
Не знаю, должна ли быть команда pause в пятом баше, и какое отношение к этому имеет питон, но выдало, что выдало. Сценарий завершился штатно, в процессах не висит.

Можно изменить константу TIME_START с 1 января 2000 на более позднюю. Что будет значить следующее: “те объекты, которые я правил до этого момента (ибо по этой константе отсекаются загружаемые чейнжсеты) - фиг с ними, следим только за теми, что потрогал после”.

Это просто последняя команда в скрипте - питон вызывает функцию pause() операционной системы. Нужно в винде, чтобы окно консоли сразу не закрывалось после отработки, а можно было прочитать результат. Если команды в системе нет - и правда не страшно.

Спасибо за скрипт, с ним интересно.
Вы можете добавить возможность игнорировать определённые объекты?
Условно я добавляю в список “relation/12104967” и скрипт его пропускает.

Одобрям идею.
Для атрибута toll очень актуально.