This is a shopping and wish list for re-building the OSM geo-database so that ODbL coverage is 100%. In the current version, it is just a collection point for a number of threads that have been going on to bring some of the participants together. Once it is in a more coherent format, we can move it to wiki.openstreetmap.org for wider participation. This document can be read publicly at

It is now time to kick off rebuilding the database to achieve 100% new CTs/ODbl coverage so that the red squares inhttp://matt.dev.openstreetmap.org/treemap.png are either turned green or reduced in size and eventually eliminated. This is LWG’s current consensus strategy on how we will proceed:

Predicate: Remapping is better than just removing non-ODbL data from the current version, that should come last (Simon challenges this). So:

Recruit a core volunteer technical team to help out … anyone can join and/or drop out (many of the tasks may be small but very important). Mike

Focus initially on systems and minor changes that can:

Help all contributors with remapping. Contributors should be able to see an accurate and up-to-date view of status in their own local mapping areas.

Help to a small group of contributors who can re-license some but not all their data. Dermot and Richard will contact four people we have identified.

Second emailing to all folks who not yet accepted or declined the new terms. Focus on providing information or links in key languages. Richard is working on this.

OSM database rebuilding per se. This does not have to be done in one go, but in a series of steps starting with wants has the most beneficial impact for the least amount of work.

First job to do soon: For selected contributors that have both declined the new terms and are clearly not going to change, revert all their changes where they are the last person to make a change.

Mechanical edits?

Better defining what is unclean (clearly must be removed) and de jure clean (clearly OK), de facto clean (a trivial or redundant change to an object needs locking of removing but the net effect on the object means its current publicised version is clean). And, if de facto clean how to mark and show it in a manner satisfactory to the majority … needs community consensus.

… work to define more specific steps that can be done soon.

Unanswered Legal/Ethical/Procedural Questions

These need to be resolved before technical tools are created.

If we remove contributions by a particular contributor, should it completely dissappear from the history as if it never happened (so cannot be reverted back) or just reverted in the current version but still in history?

Split Ways

Technical Wish List

Uncategorised:

Ability to navigate to a particular (declined) user’s contributions ONLY in a defined area (city, country).

JOSM:

JOSM is currently lacking tools for efficient remapping, example: plugin to delete all non-compliant (configurable criteria) contributions in a specific area

Meerkator and other OSM Contributor tools

??

Explicit re-build tools

For a selected contributor, revert all their changes where they are the last person to make a change.

Specific Proposals

17/08/2011

Hi LWG folks,

seeing there is still no decision on the process of rebuilding the database to Odbl-only and that people still discuss about just setting all objects back to the edit before the first non-odbl-compliant edit, I want to propose following process, which I hope should keep almost everything that can be kept without legal problems (not dealing with splits and merges at the moment, that's quite complex I fear). It is more or less based on the bachelor thesis by Jakob Altenstein (http://checkout.yourweb.de/thesis/Jakob_Altenstein_Thesis.pdf, german):

|Mark all changesets by agreeing users (and possibly users stating their data is in PD (I know you refused that, but hey, maybe think about it again :p), known bot accounts, etc.) as "good"

Mark all changesets with bot=yes as "good"

Mark all other changesets as "bad"

Nodes:

-> first changeset bad

-> node not member of a way or relation

-> delete node

-> set current state to empty (no tags, no coordinates)

-> for each changeset, starting with the first and in ascending order

-> changeset bad

-> keep previous tag state

(-> do tag changes considered not protectable)*1

-> changed coordinates

-> set new coordinates to be bad coordinates, keep potential good coordinates

-> changeset good

-> do all tag changes on the current tag state

-> changed coordinates

-> no existing bad coordinates or new coordinates more than 1m*2 away

-> delete bad coordinates if existing

-> set new coordinates to be the good coordinates

-> else

-> set new coordinates to be the bad coordinates

-> no good coordinates

-> delete node

-> set future coordinates to be the good coordinates

-> node odbl-compliant and save

Ways:

-> first changeset bad

-> delete way

-> set current state to be the state of the first changeset

|| -> for each changeset, starting with the second and in ascending order

-> changeset bad

-> keep previous tag state

(-> do tag changes considered not protectable)*1||

-> keep previous node state

||-> changeset good

-> do all tag changes on the current tag state||

-> do all node changes on the current node state

-> remove all deleted nodes

-> no nodes left

-> delete way

-> only one node left

-> keep way but set some kind of fixme attribute

-> way odbl-compliant and save

Nodes:

-> no tags and not member of a way or relation

-> delete node

Relations:

||-> first changeset bad

-> delete relation

-> set current state to be the state of the first changeset

|| -> for each changeset, starting with the second and in ascending order

-> changeset bad

-> keep previous tag state

(-> do tag changes considered not protectable)*1||

-> keep previous member state||

|| ||-> changeset good

-> do all tag changes on the current tag state||

-> do all member changes on the current member state

-> remove all deleted members||

-> no members left

-> delete relation

-> relation odbl-compliant and save

*1 Some tag changes could be considered not protectable, e.g. hghway->highway, deleting created_by tags, etc.