Keep the history

From OpenStreetMap Wiki
Jump to navigation Jump to search

When things change in the real world, be bold, and edit the map to reflect the current situation. But be aware that OpenStreetMap can store the editing history of an element. It can be worth taking a few extra steps to help preserve this history.

Instead of deleting elements such as buildings or landuse and redrawing them anew, it is generally better to update the geometry of the existing objects, retaining their editing history. Similarly, make sure to preserve the identity of an element even when its tags become different (but don't overdo it, see #Don't mix the history). Example: If a café closes down, don't delete the node. Just remove the cafe related tags and leave other tags (like the address) in place. If a real-world object is physically moved (e.g. Structure relocation) then it is preferable that the history of corresponding OSM element would reflect that.

Editing techniques

When you find a single node for an object, and want to draw the outline of the building or the campus, it is good practice to keep the node (without its tags) prominently in the outline (e.g. as a corner of the building or the campus entrance). This preserves the history of the information in the "old" node, which is easy to find when somebody inspects such an object.

Some editors have a convenient shortcut for merging a point (node) with an area (closed way), preserving the node as one of the area's vertices:

  • In iD, hold down Shift to select both the area and the point, then press C. If the point is older than the area's northwesternmost vertex, the point takes the place of that vertex.
  • In JOSM, install the utilsplugin2 plugin. Select both objects, then go to Edit, Replace Geometry, or press Ctrl+ Shift+G.
  • In Potlatch, select the node, then hold down Shift while selecting the closed way. The node takes the place of the northwesternmost node of the closed way.

You can also carry out the same steps manually. For example, to merge an amenity=school node with a amenity=school or landuse=education area that represents the campus:

  1. Move the school node to a corner of the aerial image.
  2. Draw the campus area with this node as one of the corners.
  3. Copy the tags from the node and delete all its tags.
  4. Paste the tags on the campus area outline.
  5. Remove old source=* tags.
  6. When uploading, add your source to the changeset (not to the school object).

Keep changesets manageable

Try to keep changesets to a manageable size, both in number of changes and geographical scope.

  • If a changeset includes too many different objects, it will be difficult for later mappers to understand what was changed.
  • A changeset that covers too large of an area can be hard to find and difficult to edit. More details are here.
  • Good changeset comments are only possible for simple, smaller changesets.

Good changeset comments

Main article: Good changeset comments

A good changeset comment should concisely and adequately describe an edit. You should do this out of courtesy to your fellow mappers, to avoid misunderstandings, and get mistakes fixed quickly. It makes your edits more valuable. It may even help you when you look back at your edits in the future.

Check the history

Before making significant changes to major features based on aerial imagery or past knowledge, check their history, changeset comments and source tags. A feature may have been mapped based on recent survey in person or more recent aerial imagery. Previous editors may have valuable insights to offer on why things are currently tagged the way they are.

This is especially important for large or complex objects that may be difficult to restore, for example administrative boundaries, buildings with complex footprints, and long route relations.

Previous changeset comments and source tags could be viewed in multiple ways:

Don't mix the history

Don't convert relations, ways, or nodes that would otherwise be deleted into completely different types in an effort to prevent deletion. Deletion is not erasing the history of an object in the database. Generally, only keep the history if at least one tag of the OSM element applies to the current real-world object and they are in the same place.

For example, turning a turn restriction relation into a multipolygon is not helpful (relation example); it is better to delete one relation and create new one.

For example reuse of node number 1 is not resulting in a clear history.

If there is forest and one is improving geometry, then it is better to move existing nodes and keep existing way.

But if forest was cut down and replaced by shopping mall - then reusing nodes is not helpful at all, it is OK to just delete it.

See also