Ченджсет

В программном обеспечении для контроля версий набор изменений (также известный как фиксация и ревизия представляет собой набор изменений, упакованных вместе, наряду с метаинформацией об изменениях. Набор изменений описывает точные различия между двумя последовательными версиями в репозитории изменений системы контроля версий. Системы контроля версий обычно рассматривают наборы изменений как атомарную единицу, неделимый набор. Это одна из моделей синхронизации.

На стройке произведенную работу Changeset подписывают на стенке иногда с обратной стороны декорпанели, например Здесь был Вася 09-05-1945.

Терминология

В системе контроля версий Git набор изменений называется фиксацией, не путать с операцией фиксации, которая используется для фиксации набора изменений (или, в случае Git, технически моментального снимка) в репозитории.

Другие системы контроля версий также используют другие названия для обозначения наборов изменений, например, Darcs называет их "исправлениями", в то время как Pijul называет их "изменениями".

Метаданные

Системы контроля версий присоединяют метаданные к наборам изменений. Типичные метаданные включают описание, предоставленное программистом ("сообщение о фиксации" на жаргоне Git), имя автора, дату фиксации и т.д.

Уникальные идентификаторы являются важной частью метаданных, которые системы контроля версий прикрепляют к наборам изменений. Централизованные системы контроля версий, такие как Subversion и CVS, просто используют увеличивающиеся числа в качестве идентификаторов. Распределенные системы контроля версий, такие как Git, генерируют уникальный идентификатор путем применения криптографической хэш-функции к набору изменений.

Лучшие практики

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

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

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

OSM

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

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

Во избежание конфликтов и из уважения к рецензентам рекомендуется:

Объедините изменения в небольшой географической области в пределах a (города, района или провинции)

• Сохраняйте изменения в пределах одной и той же страны
• Загрузите / сохраните изменения, прежде чем переходить к карте в другой области.

Примеры

Если вы добавляете / изменяете 10 объектов в 2 удаленных городах => вносите 2 набора изменений, по 1 на город.

• Если вы добавляете / изменяете 5 объектов в 5 странах => вносите 5 наборов изменений, по 1 на страну.

Теги к наборам изменений

К наборам изменений прикреплены key=value пары (теги). Подавляющее большинство наборов изменений будут содержать эти два тега:

комментарий=* - описание того, почему картограф внес эту группу изменений или что было изменено. Некоторым программным обеспечением (например, www.osm.org) этот тег отображается не как тег, а как сводка / заголовок набора изменений (см. скриншот здесь).

Хотя это необязательно, картостроителям рекомендуется в полной мере использовать этот тег, задав осмысленное, созданное человеком описание (не автоматическое сообщение), поскольку оно будет отображаться почти везде, где указан набор изменений, и, вероятно, будет прочитано другими картостроителями, чтобы попытаться понять, что произошло. Смотрите также Хорошие комментарии к набору изменений.

• created_by=* - укажите программное обеспечение для редактирования или скрипт, который внес изменения

Некоторые другие часто используемые теги включают:

imagery_used=* - указывает, какие изображения отображались в редакторе источник=* - укажите источник изменений, которые были внесены в этот набор изменений

• бот=да – для автоматических правок, выполняемых программой (также известной как скрипт или бот)
• locale=* - хранит язык, используемый редактором (JOSM, например, использует created_by=JOSM/1.5 (13367 ru) с указанием языка последними буквами).
• review_requested=да - позволяет пользователю запросить кого-либо просмотреть набор изменений. У iD и JOSM есть возможность вставить этот тег, а OSMCha (и другие инструменты) идентифицирует его и позволяет находить наборы изменений с этим тегом. Также смотрите сообщение в блоге об этом.

После обновления iD версии 2.4.0 эти теги добавляются в наборы изменений:

хэштеги=* - разделяются точкой с запятой, например “#Отсутствующие карты; #Танзания”

• host=* - интернет-адрес веб-редактора.
• changeset_count= * - Количество правок, внесенных пользователем, будет равно “0” для того, кто вносит свою первую правку

идентификатор редактора: пошаговое руководство_started=да - если пользователь начал пошаговое руководство.

идентификатор редактора: walkthrough_progress= * - прогресс пользователя

История изменений тегов не хранится в самих наборах изменений: это можно сделать из истории в целом.

Также возможны пользовательские теги набора изменений. Редакторы JOSM, Potlatch2 и iD позволяют конечным пользователям указывать пользовательские теги набора изменений (и создавать новые теги, если хотите, как при помечении элементов данных).

Обсуждения набора изменений

Обсуждения набора изменений отображаются в веб-интерфейсе в виде комментариев и ответов (обсуждение!) под тегами набора изменений. Это хорошее место, чтобы приветствовать новых пользователей и дать им советы по их вкладу в картографирование или обсудить набор изменений, который кажется проблематичным, с пользователем, который его добавил. Обсуждения набора изменений являются публичными, поэтому другие участники сообщества OpenStreetMap могут внести свой вклад и ознакомиться с обоснованиями любых согласованных дальнейших изменений. Более подробную информацию смотрите здесь: пошаговый обзор в блоге.

Отображаются некоторые статистические данные об этих обсуждениях:

Для конкретной области карты / страны: https://resultmaps.neis-one.org/osm-discussions

Зависит от пользователя:

Обсуждаемые наборы изменений: https://resultmaps.neis-one.org/osm-discussion-comments?user=USERNAME

Комментарии к обсуждению набора изменений: https://resultmaps.neis-one.org/osm-discussion-comments?user=USERNAME&commented

Кто-то прокомментировал мой набор изменений, что мне делать?

Другие разработчики могут запросить разъяснения по вашим правкам, попросить вас указать источник для них или указать на допущенные вами ошибки.

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

Чтобы ответить, вам необходимо войти в систему. Удобнее всего использовать браузер для настольных ПК для навигации openstreetmap.org – интерфейс может быть сложным для использования на смартфоне.

Пожалуйста, имейте в виду, что вы не будете забанены только за допущенные ошибки! Мы понимаем, что для изучения того, как работает OpenStreetMap, требуется время. :Кроме того, мы можем помочь вам отменить любой беспорядок, который могли вызвать ваши правки. Однако пользователи, не отвечающие на запросы, которые продолжают вносить сомнительные правки, несмотря на неоднократные обращения, сначала получают предупреждение (так называемая блокировка на 0 дней), а затем более длительные блокировки своей учетной записи.

Открывающие и закрывающие наборы изменений

Наборы изменений "открываются" в начале сеанса редактирования и "закрываются" в конце. Закрытый набор изменений является фиксированным и не может быть отредактирован далее. Набор изменений может быть закрыт либо явно (см. Документацию к используемому вами редактору), либо автоматически (после периода бездействия, в настоящее время одного часа). У одного и того же пользователя может быть несколько открытых наборов изменений одновременно. Наборы изменений имеют максимальную емкость (в настоящее время 10 000 элементов), максимальное время работы (в настоящее время 24 часа) и время ожидания (в настоящее время 1 час).

Технические

Технические подробности см. в документации по API 0.6, которая содержит обширную документацию по ним. Вызов API Get Capabilities возвращает текущие ограничения для наборов изменений.

Наборы изменений были представлены с API версии 0.6 в апреле 2009 года. Наборы изменений были "синтезированы" для правок, внесенных до этой даты (код переноса)

Некоторые теги изначально использовались в элементах только для прикрепления метаданных, отображаемых в редакторах карт или в инструментах обеспечения качества (таких как статус завершения, что нужно сделать, приближения, источник и т.д.). Начиная с версии 0.6 API, редакторам карт и инструментам импорта рекомендуется прикреплять эти теги метаданных к наборы изменений, которые они создают (наборы изменений не являются элементами данных) вместо того, чтобы помечать каждый добавленный или измененный элемент данных: эти старые теги элементов теперь задокументированы в этой вики как "удаляемые", что означает, что они могут быть автоматически удалены из элементов данных редакторами при их обновлении (они по-прежнему используются только в наборах изменений и по-прежнему видны в истории элементов в версии, указанной в их первоначальном наборе изменений, но более новые обновленные или созданные элементы больше не будут использовать эти теги, которые теперь прикреплены к набору изменений, связанному с каждой версией элементов).

Дамп набора изменений

По адресу planet.osm.org есть большой архивированный XML-файл со всеми наборами изменений.

Загрузите последнюю версию дампа через BitTorrent с помощью этой команды aria2c --seed-time 0 https://planet.openstreetmap.org/planet/changesets-latest.osm.bz2.torrent

Существует несколько инструментов для анализа файлов набора изменений:

Его можно импортировать в базу данных postgresql с помощью ChangesetMD

.. или с помощью osmchanges-postgres.

Файл дампа набора изменений можно преобразовать в CSV с помощью osmchangesets2csv

Примечание

Уникальность: author + id + filename • Id =. Удобство анализа (include)

Смотрите также

Исправление (вычислительное)

• Моментальный снимок (компьютерное хранилище)
  • Вики JOSM объясняет, как работать с наборами изменений
• Откат набора изменений с помощью плагина reverter для JOSM
• Отличие опроса от кабинетного картографирования (черновик)
• Инструменты просмотра набора изменений OSM

Пруф

personeltest.ru/avtokolona-2858-otladki-i-dostavki-v.