User:Tirkon/ODbL-License: How to avoid Trash Mapping

Attention: You found this article in the user space of Tirkon. It is no official OSM document. It is under construction and can change at every time. The intention of the article is to inform mappers that they might be doing useless work on the OSM Map data.

OSM will change its licence from CC-by-SA to OdBL on April, 1st 2012. This article makes clear why map-improvements in the future can be threatened by deletion and gives pointers to help avoid this. Further information concerning the licence change can be found in German in this Video.

Improvements on existing objects in the future can be threatened by deletion

The shady side of the license change: Trash Mapping

OSM is in the process of changing its licence from CC-by-SA to OdBL on April, 1st 2012. Im the course of this change we will lose the content of contributors who did not approve to the change of the license and the new contributor terms. This is already known by most of the mappers. What is not not clear to everybody is, that improvements based on such non ODBL compliant objects is also threatened by deletion. This applies to mappings in the past and in the future as well. Every improvement of an existing object in the future could end up in the Trash Can. The most problematic case occurs, when the first editor of an object was a non-approver. Then the object will be deleted with maximum likelihood and with it all edits and improvements in past and in future (performed between now and April 1st, not it's not a joke). If a non-approver has improved the object, subsequent edits can be threatened by deletion. Everything can, nothing must.

Example: OSM ways

The aforesaid criteria apply to ways and their nodes as well and for both of them separate (And for relations as well). Assuming there is a way, where no change can be found in its history. Nevertheless every node of it can change - its coordinates and its tags. That means this way could be located earlier on the other side of the earth without finding any sign of this in its history. The changes are then located in the history of every single node. If the way itself was changed as well, a street in Germany could have theoretically been a house in Canada earlier on. In case these edits are done by a non-approver this street in Germany would revert back to being the house in Canada - even then if subsequent mappers had corrected the location of the street. Such an extreme case will not occur in practice, but it makes clear what is the matter.

It is less disputable that beside the deletions of the non-approvers also the contributions of subsequent editors could possibly be deleted. There are strengthening tendencies but no verbalised algorithms.

For example following scenarios are imaginable for a street by the license clearing-up:

• The entire street is removed, together with all the improvements that were made to it
• The street (way) disappears, but the untainted nodes it was using stay in place
• Some nodes or all of the street are reverted back into something it was before a naysayer touched it
• Some of the street's nodes disappear
• In the case of a union with other ways, only a free floating part remains.
• The name of the street changes back to what it once (erroneously) was
• The street become a cycle path
• Improvements on the tags it received disappear

There will be cases of a worst case scenario, where junctions of a network become completely broken and the streets get the wrong tags and names or end up in wrong places. In particular this danger is given near main roads. As a general rule these have been established in the early times of OSM. Persons drawed with rudimentary editors and guides on a white space only a few nodes per many kilometers at rough estimated points. A severe hint for such an old street is given, if widespread nodes with the author "UNKNOWN" can be found in the roadway.

Once more: If one or more non-approvers were involved these szenarios are possible, if your improvements are done in the future.

Relations

So much the worse will apply to the relations. These have many member-objects. In particular at long routes (like motorways) the possibility is in all likelihood, that they will be massively damaged at the license changeover.

How to prevent this crisis?

What can be done, in order to avoid mapping for the trash can? There is a simple and a hard way. The easy way ensures that future edits (of yourself and others) might end up in the trash. It does not, however guarantee that the map will remain in its current form. This leaves only the hard way then.

The easy solution

• Synthesis: Only create new buildings or objects and don't touch anything which already exists.

As yet, there is not a single tool, which can determine with absolute certainty, whether an object will be able to be declared 'clean'. So, when correcting pre-existing objects there is some danger involved. So the easiest solution is to, until the 1st of April, or a bit later if it gets postponed, not create any new objects in the database. As an example; outside of the major cities, not many buildings are mapped yet, so they could be traced from bing or Luftbilder von Aerowest This will also help if the street between the buildings would disappear or move somewhere else. The empty space between the buildings will be easily recognised as a gap in the road network.

• When creating a new way/street, it's best to not reuse an existing node of the way it connects. Simply create a new node as the start of your street.
• Don't add on to extensive route relations. The probability is high, that they will be incomplete once again after the license change over.
• Do not 100% completeness checks within communes concerning tags or objects like:
  • Are all streets /postboxes / buslines mapped?
  • Is maxspeed / width / surface tagged for all streets?
• These completeness checks have to be done once more after the license changeover in all likelihood.

The hard way

This method's aim is such that the existing map will be modified in such a way that after the license changeover there are only minimal losses to the map data (or none in the best case scenario). It has the further advantage that, when applied to a given area, this area can further be edited by anyone, without the risk of doing all those contribution in vain. It will become clear that this is not an easy method, after reading and understanding its description. Please read it all first and only then start trying it out.

The best kind of repair is the one which is not needed in the first place. So we should try to reach as many past contributors as possible, who became inactive and are not reachable on the address anymore they entered when joining OSM. After this step, one should wait a good while for a response. Example messages can be found here. For users who remain unreachable or who declined, some repair will be forthcoming on the objects they touched, to prevent losses due to the license change over. Bei denjenigen Inhalten, die von der expliziten Ablehnern erstellt wurden empfiehlt die Licence Working Group, die innerhalb der OSM-Foundation für die Lizenzumstellung verantwortlich ist, diese Inhalte zu ersetzen.

Allerdings gibt es bisher kein Instrument, mit dem man sicher feststellen kann, ob man für die Mülltonne mappt. At least finding simple cases can be found with the help of JOSM and its JOSM/Plugins/LicenseChange PlugIn and as well with the Online-Editor Potlatch2 under "Options" and "Show licence status". In both cases jeopardized ways and nodes will be shown by Yellow orange or red frames. If a way is not framed but only its a nodes a movement of the way is nevertheless possible.

• Red - Data loss: original mapper said no.
• Orange - Possible Data loss: a later editor said no.
• Yellow - Data reduction: original mapper or a later editor hasn't decided yet.

The visualization shows only simple menace. If in example a way has been splitted, then one of the two halves will be shown as okay. But in fact it is a copy of the old half. During the license changeover the not jeopardized marked way could be nevertheless deleted. Doubtlessness is not given by the visualisation. Because the rules for the complex are not written yet, a tool cannot exist.

The only technical safe method to protect an OSM-way from changing or deleting during license changeover is to delete and recreate it. One should be aware that only several nodes of a way could be marked. Using the old data is forbidden here - in particular copy and paste. You have to use the common own investigations, Ortskenntnisse, GPX tracks oder aerial images.

Relationen are destroyed if included ways or nodes are remapped. Thus you have to make sure for every remapped object is not included. Otherwise you have to study and note down the detailled structure of the relation(s) and their membership in parent relations. The new ways have to be made member of these relations and old rolls and directions recovered.

It is important that generally the old relation is used and now new one created. Otherwise the parent relations will be destroyed as well. Only in case the relation is created by a non-approver a new relation has to be created and be made member of a existing parent relation what again is not possible with Potlatch. The analog applies to parent relations. Further all links in the OpenStreetMap Wiki have to be changed to the new replacement-relationen. For this you use the wiki-search with the old ID/Number of the old relation and make sure, that you found a relation (and no way or node) and replace the old ID/number by the new one.

Difficult is the remapping of route-relations (not whose members), that are very long - in example motorways. Such a replacement should only be done by only one user - many users only if they are (Wiki-)coordinated. If many uncoordinated users take part there is the danger, that many needless replacements of relations will be done.

Because of his numerous analysing features <i recommend JOSM for this Job.

The described method is alone technical targed-aimed. But it could carry a risk. For instance one destroys material of the old license. Users who want to fork could early begin to safe the current state.

Weblinks

• Vortrag von Frederik Ramm auf der Fossgis Konferenz
• Aufruf der License Working Group zum Neumappen nicht relizensierter Inhalte
• Licensing_Working_Group
• Besprechungen der Licensing_Working_Group
• Online Darstellung der möglichen Relizensierungsverluste als Karte

Bitte diesen Hinweis für Rechtsthemen beachten, der für diesen Artikel gilt, wie bei der Wikipedia beschrieben.