OpenStreetMap

Peer review

Posted by gosausee on 23 December 2014 in German (Deutsch).

Ein Lösungsvorschlag zum Thema, neue Mapper machen Fehler oder verwüsten Relationen oder bereits gemapptes.

Wie wäre es, wenn die ersten 10 (15,..) Edits der neuen User durch die Community kontrolliert werden können? Also ein Peer review stattfindet. Für den User gibt es keine Einschränkung und seine Bearbeitungen werden auch online gestellt. Auf einer eigenen Seite, nach Ländern gelistet, werden die User aufgeführt. Die lokale Community sieht wer Neu ist und was der neue User gemappt hat. Sind die Edits kontrolliert worden, wird der User aus der Liste gelöscht.

Location: Bennau, Einsiedeln, Schwyz, 8840, Schweiz

Discussion

Comment from escada on 23 December 2014 at 12:37

I see similar problems with “oldtimers”, especially those that are not active on fora or mailing lists. Also, An oldtimer can be a newbie when she/he starts mapping new types of objects. So it would be good to review all changes, not necessarily those of new users. But that’s what we are already doing all the time without the sandbox, not ?

See also some reactions to http://www.openstreetmap.org/user/escada/diary/28071

Comment from wiedergaenger on 24 December 2014 at 14:11

I like the idea of a more general approach for reviewing changesets, that is not only affecting newbies. First step would be a set of algorithms that can detect suspicious changesets. This could be done external. If this is working out well, so has a low false-negative-rate, in a next step we could think about something like reviews.

Some naive ideas for changeset detection: - errors that are already known in QA-tools like keepright or osminspector - errors that editors already warning - big differences on landuse/water: changes where buildings and roads are under water/massive changes to coasts or borders - a lot of deletions without a replacement with new ways/nodes - big differences on geometry of ways to the previous state to name a few

I think OSM will need something like that in the future. There are a lot of editors that can’t warn about the same stuff and it is never wise to protect a database on clientside. There are a lot of variables that needs to be considered for a good detection, but it is worth thinking and discussing about it.

Comment from flohoff on 27 December 2014 at 17:43

As with the Changeset comment function which i like a lot this must be a lot more improved to actually be able to review changes. We need

  • A better Changeset viewer like this: http://nrenner.github.io/achavi/
  • A better way to track changesets in a certain area I use an RSS feed by http://simon04.dev.openstreetmap.org/whodidit/scripts/rss.php?bbox= This must be integrated with OSM itself and be usable without an RSS feed e.g. people have 1-many watched areas in the user config and can have a look at changes of the e.g. last 30 days in that area.
  • Telling people to COMMENT on their changeset. 80% of the changesets in my area have an empty or non descriptive changeset comment. So its useless to review as i have no clue what the intention of the mapper was.
  • As the nomenclatur of OSM changesets is not the one of a VCS in software development as its not atomic, not self contained there is no way of peer review in the sense of e.g. github. So we need some way to get more people to comment on changes and by thus improving the quality of changes people make.

Its a long way to go but OSM has already come far.

Comment from flohoff on 27 December 2014 at 17:43

As with the Changeset comment function which i like a lot this must be a lot more improved to actually be able to review changes. We need

  • A better Changeset viewer like this: http://nrenner.github.io/achavi/
  • A better way to track changesets in a certain area I use an RSS feed by http://simon04.dev.openstreetmap.org/whodidit/scripts/rss.php?bbox= This must be integrated with OSM itself and be usable without an RSS feed e.g. people have 1-many watched areas in the user config and can have a look at changes of the e.g. last 30 days in that area.
  • Telling people to COMMENT on their changeset. 80% of the changesets in my area have an empty or non descriptive changeset comment. So its useless to review as i have no clue what the intention of the mapper was.
  • As the nomenclatur of OSM changesets is not the one of a VCS in software development as its not atomic, not self contained there is no way of peer review in the sense of e.g. github. So we need some way to get more people to comment on changes and by thus improving the quality of changes people make.

Its a long way to go but OSM has already come far.

Log in to leave a comment