A changeset is a group of edits to the database by a single user over a short period of time (see also editing).
For example, if you want to add some new houses to the map you can use a single changeset to:
- add a new way (eg, the new residential road)
- delete an area (eg, forest removed for the houses)
- change the tags on an existing element (eg, add a new speed limit on an existing road).
Geographical size of changesets
General recommendation: changesets should be local.
Thousands of volunteers review hundreds of contributions a day (for example using osmcha.org) to maintain the quality of mapping in their area and to provide guidance to new mappers. Some archaic or primitive review tools have limited filtering capabilities: While they allow to filter for changesets that overlap specific areas, the size of each changeset's Bounding Box is defined by the two modified objects that are the farthest apart. When making changes that span a large geographical area, this leads to these changesets being included in many mappers' review filters, which makes it cumbersome for them to focus on changesets that actually touch objects within their local area of interest. As a result, some reviewers flag (otherwise good) changesets as bad because of the size alone.
There is no community-wide consensus on optimal changeset size. Some mappers argue that a changeset should not span more than one continent, while others prefer changesets no larger than a single city.
To avoid conflicts and as a courtesy to reviewers, it is recommended to:
- combine changes in a small geographical area (within a city, district or province)
- keep changes within the same country
- upload/save changes before moving on to map in a different area
NB: The JOSM editor permits to split changes done across a larger area in saves of smaller parts to follow the above guidelines and recommendations.
|Each country may have different OSM wiki rules you may not be aware of. Smaller changesets make it easier to review and revert in case of conflicts.|
- you are adding/modifying 10 objects in 2 distant cities => make 2 changesets, 1 per city.
- you are adding/modifying 5 objects in 5 countries => make 5 changesets, 1 per country.
Tags on changesets
key=value pairs attached (tags). The vast majority of changesets will have these two tags:
- comment=* – describing why a mapper made that group of changes, or what was changed. By some software (e.g. www.osm.org) this tag is not displayed as tag but as changeset summary/headline instead (see the screenshot image here).
While optional, mappers are encouraged to make full use of this tag by setting a meaningful, human-generated description (not an automated message), as it will show up almost everywhere where the changeset is listed, and is likely to be read by fellow mappers to try and understand what has happened. See also Good changeset comments.
- created_by=* – specify the editing software or script which made the changes
Some other commonly used tags include:
- imagery_used=* – indicates which imagery was being displayed in the editor
- source=* – specify the source for the edits that have been made in this changeset
- bot=yes – for automated edits, performed by a program (a.k.a. script or bot)
- locale=* - stores the language used by the editor (JOSM for instance uses created_by=JOSM/1.5 (13367 en) with the last letters indicating the language).
- review_requested=yes - allows a user to request someone to review the changeset. iD and JOSM have an option to insert this tag and OSMCha (and other tools) identifies it and makes it possible to find changesets with this tag. Also see a blog post about it.
After the 2.4.0 update of iD these tags are added to changesets:
- hashtags=* – Semicolon delimited, e.g. “#MissingMaps;#Tanzania”
- host=* - The internet address of the web editor.
- changesets_count=* – The number of edits the user has made, will be “0” for someone making their first edit
- ideditor:walkthrough_started=yes - If the user started the walkthrough.
- ideditor:walkthrough_progress=* - User's progress
The history of changes to tags is not stored on changesets themselves: this can be inferred from the history as a whole.
Custom changeset tags are also possible. JOSM, Potlatch2, and iD editors allow end-users to specify custom changeset tags (and make up new tags if you like, as when tagging data elements).
The History function on www.osm.org shows the changesets of the currently viewed area. The geographical extent of the changeset is shown by an orange rectangle, which surrounds all the changes made. For "bots" that make many small changes across a wide area this can be quite big. (This is why many changesets are shown for an area, even when that changeset seems not to be relevant.) Better tools than the basic orange rectangle are available.
Changesets can be directly accessed using the following URL schema:
https://www.openstreetmap.org/changeset/<Changeset number> Another option is to use the query feature and select a feature which will show the feature details and the last changeset for it.
Time and date of changesets
Each changeset is time-stamped. The web interface at openstreetmap.org gives an approximate date (e.g., 'over a year ago'). Hovering the mouse over the date for a few seconds brings up the exact date and time as a tooltip. You can also view the timestamp in the XML files: in the web interface these are hyperlinked at the very bottom of the panel detailing the changeset.
Changeset Discussions show on the web interface as comments and replies (a discussion!) below the changeset tags. It's a good place to welcome new users and give them tips on their mapping contributions, or to discuss a changeset which seems problematic with the user who added it. Changeset Discussions are public so others in the OpenStreetMap community can contribute and see the reasoning for any further changes agreed. For more details see here: walk-through on the blog.
Some statistics about these discussions are displayed:
- map area/country specific: https://resultmaps.neis-one.org/osm-discussions
- user specific:
- Discussed changesets: https://resultmaps.neis-one.org/osm-discussion-comments?user=USERNAME
- Changeset discussions comments: https://resultmaps.neis-one.org/osm-discussion-comments?user=USERNAME&commented
Someone commented my changeset, what should I do?
Other mappers can ask for clarification on your edits, ask you to provide a source for them, or point out mistakes you made.
You should almost always respond, even if that response might be "I don't know" – or if you fixed the mistakes yourself. Public communication between mappers is crucial to building trust. Edits of people who never respond may be treated as less trustworthy.
To respond you need to be logged in. It's most comfortable to use a desktop PC browser to navigate openstreetmap.org – the interface can be tricky to get around on a smartphone.
Please keep in mind you will not be banned just for making mistakes! We understand that it takes time to learn how OpenStreetMap works. Also, we can help you undo any mess your edits might have caused. However, unresponsive users who continue questionable edits despite being contacted multiple times first get a warning (so called 0-day block), then progressively longer blocks on their account.
If mappers engage in editing zones larger than their country, covering areas that go across countries with different national languages, please use English. For instance an unusual edit that will create a change set bound box from France to India will show up in dozens of countries in between, it would be appropriate to do the closing edit comments in English. Most all who see the edit in their local history view will understand what was added/changed/deleted without having to resort to an online translating service. If the exampled bound box crosses Italy lying in between, not all speak French nor Hindi. The same goes for mappers who usually map only in their home country but in the instance do an edit in another with a different language. Do the comment in the language of the other country or do it in English. Truly no one in Spain is looking for an edit with a comment in German.
Opening and closing changesets
Changesets are 'opened' at the beginning of an editing session, and 'closed' at the end. A closed changeset is fixed and cannot be edited further. A changeset may be closed either explicitly (see the documentation for the editor you are using), or automatically (after a period of inactivity, currently one hour). The same user can have multiple open changesets at any one time. Changesets have a maximum capacity (currently 10,000 elements), maximum open time (currently 24 hours), and an idle timeout (currently 1 hour).
Changesets were introduced with API v0.6 in April 2009. Changesets were "synthesised" for edits before that date. For technical details, see the API 0.6 documentation which contains extensive documentation on them. See also the Get Capabilities documentation.
Some tags were initialy used on elements only for attaching metadata displayed in map editors or in quality assurance tools (such as completion status, things to do, approximations, source, etc.). Since version 0.6 of the API, map editors and import tools are encouraged to attach these metadata tags instead to the changesets they create (changesets are not data elements) instead of tagging every added or modified data element: these old tags on elements are now documented on this wiki as "discardable", meaning that they may be silently deleted from data elements by editors when they update them (they are still usable in changesets only, and still visible in the history of elements, in the version pointed by their initial changeset, but newer updated or created elements will no longer use these tags, attached now to the changeset linked to each version of elements).
There is a big bzipped XML file with all the changesets at planet.osm.org. It can be imported into a postgresql database with either ChangesetMD or osmchanges-postgres.
- JOSM's Wiki explains how to work with changesets.
- Changeset rollback using the reverter plugin for JOSM
- Differencing a survey from armchair mapping (Draft)
- OSM Changeset viewer tools
Here is a proposal to define more common changeset tags that can be used to describe edits: Proposed features/changeset_tags (including the previous)