Remapping/License Change View on OSM Inspector

From OpenStreetMap Wiki
Jump to navigation Jump to search
Logo.png
This page describes a historic artifact in the history of OpenStreetMap. It does not reflect the current situation, but instead documents the historical concepts, issues, or ideas.
About
The OSMI view License Change was a set of layers available in the OSM Inspector around the license change in 2011/2012.
Reason for being historic
The layers are not available any more and the license change is long ago.
Captured time
2012


The license change view on OSM Inspector shows a (relatively) current snapshot of Contributor Terms acceptance for all currently visible objects in the OSM database. The layer is available world-wide, and you can zoom in to any level of detail.

You can access the license change view by selecting "Redaction Bot" from the "View" dropdown on http://tools.geofabrik.de/osmi or with the following link:

OSMInspector Redaction Bot view

Understanding the Colour Scheme

The ODbL view uses four colours for its map display:

  • red The feature was created by a 'non-ODBL' contributor*. The feature is likely to be removed.
  • orange The feature has been modified by a 'non-ODBL' contributor. The feature is likely to remain but lose some information.
  • yellow The feature has been modified in some minor way by a 'non-ODBL' contributor. The feature will either remain intact or only lose marginal information.
  • green A feature that has been created or modified by a 'non-ODBL' contributor, however the feature has either been tagged with odbl=clean, or the user's contributions have been 'adopted' by another contributor who has accepted the terms by agreement with the original contributor, or the relevant changeset as been 'overridden' and accepted. These feature will be retained. See Quick History Service table for list of overrides.

* A 'Non-ODBL contributor' is someone who has refused the new license or has not responded to the new license.

Similar colours are used in the Potlatch2 and JOSM relicencing views, although Potlatch2 and older versions of the JOSM license change plugin use orange to indicate that an object was created by someone who has not yet decided, as opposed to red for creators who have expliticly rejected the new license. See JOSM/Plugins/LicenseChange and Remapping for more details)

Zoom levels: Raster, Centrepoints, Lines

For speedier browsing, the map view is presented as a (somewhat pixellated) "raster overview" on zoom levels 0 to 9. On these levels, the colour intensity gives a rough indication of just how many problematic objects lie in a certain area, but it doesn't allow for exact readings. Zoom level 10 swaps the raster overview for a real display of all problematic nodes. Ways are not yet shown because most would appear extremely short at this zoom; instead, a small circle is drawn at the centre point of each line. Lines start appearing properly on zoom level 12.

Identifying and Editing Objects

If you are on zoom level 14 or beyond, you can use the "Potlatch" or "JOSM" buttons just above the map to load the currently visible map section into your favourite editor.

You can also click on an object on the map and then the "selection" area to the right of the map should tell you what object it is (e.g. "node_id 1234"). If you have that, there will again be a row of mini buttons above the object:

Osmi-detail-buttons.png

From left to right, they are:

  • zoom OSMI's map view to this object
  • edit this object in Potlatch
  • edit this object in JOSM (must already be running with remote control activated)
  • show OSM's data browser page for this object
  • show a "deep history" page for this object in which you can see who added what

The selection area also gives you one username per object; for red objects, this is the non-agreeing user who created the object, and for orange or yellow objects, this is the non-agreeing user or one of the non-agreeing users who modified it. For green objects, it is the user who placed the odbl=clean tag.

What Data Does This View Have?

Data for this view is usually updated daily (in the early morning hours UTC). What you see here is basically a current planet file, where all objects that have been created or touched by a non-agreeing mapper are highlighted. Note that this view highlights all objects, even e.g. a way with no tags at all, so not everything you see highlighted does necessarily appear on the map.

The tool basically uses the same data as the Quick history service. It looks at the normal history for each object, and at whether the mappers involved have agreed or not. User and changeset overrides as per the link just mentioned are processed. Anonymous accounts having agreed to the ODbL are taken into account but this mechanism depends on processing a list of changeset IDs that is published only infrequently, so it may take weeks. There are a number of limitations:

  • Relations are currently not made visible.
  • All objects are made visible in their current form and not in the form they might have after the license change - e.g. an orange-coloured 50-node road could, worst-case, shrink to two nodes after the license change because a non-agreer has added the other 48.
  • Ways are only highlighted if the way itself has been edited by a non-agreer; you will have to visually inspect the nodes belonging to that way to be sure that this way does not suffer from the license change. A "clean" way supported by 50 nodes that will have to be removed is not worth much.
  • Way splits/joins are not taken into account, so it is possible that close examination finds that a way assumed to be clean is indeed derived from a non-clean one.

A "harmless" (yellow) edit is usually detected if the object has been rolled back to an earlier state. So if an object has gone through versions 1-2-3-4, and 3 was by a non-agreeing mapper and 4 has reverted to 2, then this object is considered "harmlessly" changed. This analysis is, however, only done once a week and therefore if you roll back an object to a clean state it may take a while for it to change from orange to yellow.

Understanding Dynamics

It is important to understand that not all kinds of edits or other activities will have an immediate effect on the map display.

  • If you delete and re-create an hightlighted object, it will be gone from the map within three to four hours. (Used to be daily only before 27th Jan 2012.)
  • If a non-agreeing user changes their mind and agrees to the contributor terms, all their edits should be gone from the map within three to four hours as well.
  • If an object is manually rolled-back to an earlier state that does not involve interim edits by a non-agreeing mapper, then this will be detected by the "harmless edits" code and the object will become yellow, but this might take a full day, so you will have to show a little more patience here.
  • If an anonymous user changes their mind and agrees, this is something that may take a while to register because we have to wait until OSMF next release their list of anonymous agreed changeset IDs.
  • If user or changeset overrides are added to the Quick history service page, these will be added manually and it may take a day or two.

Per-object Overrides with odbl=clean

Main article: Tag:odbl%3Dclean

Use odbl=clean to clear features which contains historic contributions from people who have not agreed to the license change but where their contribution have "washed out" and where the contributor(s) in question cannot reasonably claim any rights to the current feature. Tagging in this way is preferable to deletion and recreation because it keeps the full contributor history available. This tag should only be used with care and must not be used to 'make the map go green' without being able to justify your inclusion of the tab in each case.

This tag should not be used where you know that all contributions relating to a particular user or changeset are in fact clear. See 'Overrides for users and changesets' (below) for details about how to override issues in those cases.

Overrides for users and changesets

Where the relevant contributor has actually accepted the terms using the the Quick History Service to add an override.

Statistics and Availability

Statistics about the number of objects shown are available here: http://tools.geofabrik.de/osmi/munin.html

Data for this layer is available for download as a set of very large shape files here, and can be accessed via the usual OSM Inspector WMS or WFS service. Data can also be downloaded as tiles (only for in-editor usage) using an URL like http://tools.geofabrik.de/osmi/tiles/wtfe/$z/$x/$y.png (with $z, $x, $y replaced by zoom level and coordinates).

Impact in some countries, and possible solutions

Currently, the statistics about the nodes and ways created by users that have still not accepted the new licence demonstrate that Poland and Montenegro will be severely affected on their map. This probably means that the information about the licence change MUST be translated into Polish and into Serbian (Latin script for Montengero) to ease the process of conversion. Otherwise, the maps of these two countries will be severely impacted.

The alternative would be to reschedule the limit date of the licence change for all data nodes and ways in these two countries, as well as relations containing them (with the exception of international relations referencing objets in multiple countries, such as coastal lines, which should be fully converted to the new licence before the first date of when the new licence will apply; because of the presence on the map of objects using different licences, the data requests covering these two countries may contain a link to a page explaining the reason of the presence of two licences, and how to reusers can cope with both of them).

It should be also possible to display data for each licence in layers rendered separately, and activable separately, each one shown with its applicable licence, even if one of them is no longer modifiable, so that it would become obsolete after a few years (this would avoid deleting data: instead the non-converted data would be transfered to a separate database that tile servers will load and render separately).