Откаты правок

Так-то восстановить границу на какую-то дату технически не проблема, надо только выбрать эту дату и дождаться когда осядет пыль после DWG.

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

https://osmcha.org

Скрипт самописный на питоне - по UID через OSM API выкачивается список чейнжсетов, затем для каждого пакетно выгружается список объектов. Получается список объектов, которые я хотя бы раз правил. Затем смотрится последняя правка (она выдаётся в том же запросе, т. е. отдельный запрос к API на каждый объект не делается) - если она не моя и сделана позднее заданной даты-времени (после которой меня интересуют правки), то ссылка на этот объект пишется в итоговой html report. Я думал его выложить это в общественное пользование, но надо написать какую-никакую документацию, а пока на это времени нет :frowning:

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

Пост пропитан болью…
К сожалению эта проблема встречается повсеместно, особенно где много пользователей ОСМ. Чаще всего люди портят чужие ошибки неосознанно по неопытности.

Я у себя взял за практику следить за местностью где я часто бываю и вношу те или иные правки через osmcha. Там есть удобный инструмент, который позволяет выделить область, задать фильтр и вывести это в rss рассылку. И каждая новая правка падает мне в почтовик. Мне остается только открыть её, убедиться что все хорошо\плохо и предпринять те или иные меры. Так же это позволяет вовремя заметить деятельно переписчиков и прочих apple.

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

Да не то чтобы… Уже всё починили. Главный вывод, который я сделал - перед тем, как торопиться исправлять вручную (без полного отката, типа проявляя уважение и пытаясь сохранить часть новых внесённых данных), надо внимательно изучить другие правки пользователя в регионе, чтобы потом было меньше конфликтов при откате DWG. А внесённые данные впоследствии можно восстановить из дампа поиском объектов по имени пользователя и анализируя по-отдельности.

И, конечно, вы правы - следить надо регулярно.

Какое-то нашествие скрытых ботов. Правки в виде одной точки без изменения положения. В профиле количество правок не больше десятка или старый профиль с активностью 2-4 года назад.
Стоит присмотреться:
https://www.openstreetmap.org/user/EBA_IL
https://www.openstreetmap.org/user/Imee01
https://www.openstreetmap.org/user/Kayhan%20Sonkaya
https://www.openstreetmap.org/user/Kosistka
https://www.openstreetmap.org/user/Tamanskaya
https://www.openstreetmap.org/user/Wengzkie
https://www.openstreetmap.org/user/LukaCroo
https://www.openstreetmap.org/user/Leith
https://www.openstreetmap.org/user/Deanthony%20Small
https://www.openstreetmap.org/user/Gallileo

Про нашествие лжепоправщиков с тегом #adt вообще молчу. Банить всех.

Правки были отправлены через iD без фактических изменений (кроме номеров версий). Но iD же не отправляет неизмененные элементы (координаты и теги не изменились), если я не ошибаюсь?

Почитал про API. Предположительно тег created_by передаётся просто в виде строки, при этом проверки на сервере не происходит (по крайней мере я ничего не нашёл).
Возможно кто-то тренируется заливать данные, пишет скрипт для автоматической загрузки данных.
Аккаунты скорей всего левые.

Все теги (включая на пакетах правок) записываются в XML, создаваемый редактором/скриптом. Возможно, правили в iD методом “добавить тег, удалить тег”, точки считались измененными, и iD генерировал пакет правок. А может быть, специально iD – специфичные теги задавались через “хакерский” скрипт.

Slavik987654321 наспамил 7-6 месяцев назад.
Он добавил кучу кондитерских (shop:confectionery) ПРИЧЕМ УКАЗАЛ ФАМИЛИИ! Местами его “кондитерские” рядом с магазинами. А местами - рядом с жилым домом :frowning: (то-есть это может быть нарушение закона о персональных данных, хотя если эта информация взята из открытых источников, может и не нарушение законодательства). В любом случае нет там никаких кондитерских. Прошу откатить все правки Slavik987654321

Наконец-то дошли руки - всё лежит по ссылке в подписи под моими постами :slight_smile: Совсем без документации было выкладывать неудобно, поэтому набросал заметки в комментариях в коде скриптов. Если будут вопросы и замечания - с удовольствием отвечу!

AnakinNN, можно сделать отдельную тему, и там предметно обсуждать :slight_smile:

Готово :slight_smile:

Спасибо за помощь с правками Slavik987654321.
Заметил, что не удален пакет правок https://www.openstreetmap.org/changeset/85542795 Прошу перепроверить. Может ещё какие не удалены.

Товарищи, а может ли кто-нибудь корректно откатить пакет 97327923? Там речь идет об удалении отношений “boundary=historic” у района, недавно преобразованного в муниципальный округ. Я преобразовал границы поселений из administrative в historic, но потом пришел товарищ по увлечению и решил, что надо вообще их снести. По-моему, делать это рано.
(Сейчас идет переходный период и все еще существует администрация упраздненного района. Кроме того, в некоторых нормативных актах (например, здесь, стр. 55) описано распределение бабла по “поселениям” с горизонтом аж до 2022 года. То есть, формально упраздненные “поселения” будут еще использоваться довольно долго и выпиливать их вотпрямщас – преждевременно).

Да ладно, признаемся себе честно, эти устаревшие границы вряд ли кто будет искать в ОСМ. И уж тем более маловероятно, что кто-то, кто будет заниматься этим хлопотным делом, вносить границы, прежде не разберётся в вопросе актуальности. Я не раз натыкался на вот такие оставленные границы которые весят по 5 лет. И вот приходится погружаться, что это, зачем когда, действительно ли счас актуальные и т.д. что бы их уже удалить.

То есть теперь в OSM каждый может прийти и делать всё, что ему захочется?

Ну как бы с самого начала так было, чай не НЯК :slight_smile:

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