Описание действия заменить на код: [+] — добавлена, [-] — удалена, [.*] — изменена.
ЗЫ редактор не даёт написать звёздочку в квадратных скобках 
И визуально разделить:
- добавление/удаление линии
- добавление/удаление точек в линии
- изменение тегов
В идеале, конечно, хорошо бы ещё отслеживать сплиты/джойны и что связность не изменилась.
//Описание действия заменить на код: [+] — добавлена, [-] — удалена, [.*] — изменена.
Изменение тоже бывает разное. Бывает удаление вершин, а бывает добавление тегов.
//И визуально разделить:
//…
Не очень понял, как именно? Фильтр?
//В идеале, конечно, хорошо бы ещё отслеживать сплиты/джойны и что связность не изменилась.
Cплиты-джойны отслеживать можно, это будет. А вот связность - это немного из другой оперы. Тест рутинга делается после двойного передела исходного осм-файла. А здесь просто отслеживаются версии осм объектов типа “вей”.
Я сейчас наверно скажу какую-то глупость, но можно это как-то представить в графическом виде?
Например, окно браузера делим на две части: вот так было, а так стало. С выделением изменённой части.
*n, *t, *nt — как вариант.
Ещё хотелось бы ссылку на ченджсет.
Добавить мультимедии 
Чтобы анимацией плавно перетекало из как было в как стало, и ещё звук перетекания
И на историю?
Смешно, да
На самом деле ссылка на сам объект может уже устареть, и ченджсет там придётся отыскивать опять же в истории. А ссылка на историю не намного лучше, потому что показывает вообще все версии и все ченджсеты.
В истории по ббоксу очень удобны ссылки на юзера и на ченджсет, я ими пользуюсь в равной мере. Поскольку тут ещё и сам объект важен, то и на него должна быть ссылка. Итого нужны ссылки на объект, на ченджсет и на юзера (причём лучше на ченджсеты юзера, а не на него самого, чтобы сразу увидеть что и где он сейчас продолжает портить).
Это не глупо совсем. Такое можно попробовать сделать, только не в графическом виде, а в текстовом, как в истории вея.
Особенно если мне кто-то скажет как из осм API извлечь конкретную версию вея…
Супер! Меня спалило в Питере)))
Ещё бы такое же для РЕК! А то писец Неву нашу родимую рушат регулярно, а чинят долго потом. Я например не представляю как и где найти ошибки, а те кто знают им некогда :((
Вы у меня теперь все под колпаком!
А что именно понимается под реками?
Ну вот riverbank, а точнее его отношение на реке Неве регулярно кто-то рушит 
И из-за этого всякие программы типа маперитива или же osmand’a рисуют Неву как линию river тонюсенькую И найти ошибку по длине Невы, не заметив её в момент допущения кем-то очень не просто.
Zkir, а возможно дополнить анализатор проверкой изменений связности?
Принцип такой: для каждой точки скачанных дорог запоминается, какому набору дорог она принадлежит. Изменения выводятся.
есть подозрение, что в список попадают changeset-ы которые не изменяющие граф, а изменяющие только его ребра (например изменение точек не являющихся перекрестками). IMHO такие изминения не очень интересны - их или не нужно показывать либо стоит выделить в отдельную категорию. В первую очередь полезо видеть изменения меняющие топологию графа.
Ссылку на ченджсет можно повесить на дату-время, чтобы сэкономить колонку.
citrin,
разумеется, данный инструмент просто тупо отслеживает изменения ВЕРСИЙ веев, которые этот самый граф образуют. Собственно он и появился из за неспособности обнаруживать ошибки топологии определенного типа.
Если бы я мог составить и показать список “изменений топологии” (в духе “улица Пупкина переделана из одновейки в двухвейку, попутно порушены запреты поворотов”), я бы конечно именно так и сделал…
Реально и притом негативно повлиять на топологию могут удаления, и они а) подсвечиваются красным б) показываются в отдельном списке “ожидающие одобрения”.
dimuzz,
//…для каждой точки скачанных дорог запоминается, какому набору дорог она принадлежит…
Такое делается в валидаторе связности (см. соотв. тему :)). Здесь же требуется нечто иное. Например, если кто-то удалит кусок М1, “наборы дорог” (связные подграфы) останутся теми же самыми (потому что степень связности высокая). Чтобы образовался новый набор, нужно изрядно постараться.
Не-не-не, я не про статику, а про изменения принадлежности точек дорогам между выгрузками.
Т.е. если кто-то удалит кусок вея, примкнет или разомкнет дорогу, изменится множество дорог, которым принадлежит конкретная точка.
Возможно, сверки “с точки зрения дорог” и “с точки зрения точек” и эквивалентны, но теория множеств мной давно и надежно забыта… 
Это тоже самое, или я не могу ухватить мысль.
Как бы там ни было, основные изменения за последние несколько дней следующие:
- Правки теперь подствечиваются в соответствии с классом опасности;
- добавлена ссылка на чейнджсет.
- Самое главное - как в лучших домах Парижа и Конотопа, теперь можно посмотреть сам дифф (разницу между правками), правда разумеется в текстовом виде.
Все конечно только для новых правок (или в отчете для Ивановской области). Остальные области переобновятся через пару дней, если за это время не возникнет каких-то новых хотелок, которые потребуют изменить структуру базы.
Повторно предлагаю ссылку на пакет правок перенести на дату-время в первой колонке и сэкономить тем самым целую колонку.
Ну и действия как-то закодировать и сократить.