Notes mit frei definierbaren Tags ?

Communities Deutschland (Germany)
1

Sollten wir nicht frei zu definierende Tags an Notes haben ? Genau wie bei Nodes ?

Hintergrund:

In der Strukturierung von Zusatzinformationen haben wir durchaus positive Erfahrungen (Beispiel Nodes). Nicht die Programmierer geben die Taggingstruktur für OSM vor sondern die Mapper. Haben wir ein flexibleres System bei den Notes, können wir die Informationsstruktur im Laufe der Zeit verbessern.

Anwendungsgebiete:

Relevanzkriterium, Filter
Nodes könnten mit einer noch auszuarbeitenden Relevanz versehen werden. Sie sind OFFEN oder Geschlossen. Jeder Note Bearbeiter wünscht sich mehr Stati.
Hinweise wie (Achtung Extrembeispiel) Hier wird in 10 Jahren eine neue Autobahn gebaut, müssten nicht geschlossen, sondern können auf very postponed gelegt werden. Die sich dadurch ergebenden Filtermöglichkeiten sichern eine höhere Bearbeitungsquote der aktuelleren Notes, einfach durch höhere Bearbeitungsmotivation.

Beispiel: Wenn ich das dritte Mal einen OSB Angeklickt habe, der als Lösung eine Vor Ort Begehung benötigt, dann würde ich den gerne ausblenden, oder irgendwann frustriert mich die OSB Bearbeitung und ich höre komplett auf. Dieses Verhalten war häufiger als Kommentar zu OSM Notes und OSBs zu lesen.

Ausserdem gewinnen wir Möglichkeiten die Qualität der Daten zum Zeitpunkt X zu dokumentieren, und damit eine Lösung für die nicht vorhandenen Inbetriebnahme Stufen wie z.B. Preproduktion für die Daten zu finden.

Aus dem Verfahren, dass wir in einem dauerhaften Live Stream ohne Freigabe arbeiten, werden wir nicht rauskommen. Das was in der Software Entwicklung mit einem expliziten GoLive Test gemacht wird, können wir mit unserem Vorgehen und Mappern nicht leisten. Ich sehe da “Personal” und “Merge” Probleme.

Nutzen Firmen - wie skobbler - nicht unseren permanent gefixten Stream und stellen somit unsere Bug Fixes kurzfristig zur Verfügung, sondern zeihen alle 3 Monate einen Full Dump, dann sind Informationen wie:

am 3.3.2013 waren 100 Schwere , 20 kritische Notes im System und
am 4.3.2013 waren 90 Schwere, 15 kritische Notes im System

hilfreich.

Dafür braucht es aber mehr Informationen an den Notes, als offen und closed.

Hier hat jemand den Landuse geschräddert, könnte das in einem Note erfasst werden.

betrifft: Landuse
Aufgetreten: 1.1.2013
Gefixed: 1.3.2013
Betrifft Gebiet: Gemeinde ID

Möchte jemand jetzt einen Dump Ziehen, für den er insbesondere Landuses benötigt, dann kann er die Fehler in seinem fachlichen (Ich benötige Landuses) und geografischen Gebiet zählen, und versuchen diese zumindest Statistisch klein zuhalten (0 Fehler werden wir nicht hinbekommen).

Sollte versehentlich die A3 gelöscht werden, können wir diesen Fehler nicht verhindern. Wir können sehr schnell reagieren, aber dieser Fehler ist nur auf Talk-DE oder im forum zu finden, die Information am 5.5.2013 war die Karte in einem fatalen Zustand, steht nirgends.
Ein OSMNote der Entdeckung (evlt auch Beginn) und Ende des Fehlers mit Zusatzinformationen dokumentiert, könnte statistische Daten zur Qualität der OSM Daten am Tag X liefern, und damit der steigenden Zahl von Offline Datenanbietern wertvolle Informationen liefern.

Christoph
Edit: trotz 3facher QS immer noch Fehler, den schlimmsten gefixt, :slight_smile:

2

Das darf aber nicht zu kompliziert werden. Mir würde schon reichen, die vielen “ich wünsch mir was”-Bemerkungen als solche kennzeichnen zu können (und dann ausblenden oder anders farblich darstellen => Ampelfarben => orange?). Viele “Fehler” sind nur “hier fehlt etwas” (relativ unbedeutendes) oder “ich weiß gar nicht, ob das falsch ist, kann das mal jemand nochmal anschauen”…

3

Bahnhof? Ja, Bahnhof. :laughing:

4

OK ich sehe ein, das Problem für das ich eine angedeutete Lösungsidee zeigen wollte, habe ich nur minimal angerissen.

Das mit den Kategorien bei den Notes ist, denke ich, ein Wunsch, den jeder beim Note Fixen schon mal hatte. Gehe ich gleich zur Inbetriebnahme.

Wenn wir mit JOSM (oder anderen Editoren) Daten hochladen, sind die direkt LIVE. Es gibt kein System in dem man sich das Ergebnis im Zusammenspiel mit allen Mappen anschauen kann. In der Softwareentwicklung setzt man dafür Test und PrePod Stages ein. Die Lösung ist bei uns nicht möglich. Dann müssten in bestimmten Abschnitten die Sachen “freigegeben” und in die nächste Stufe versetzt werden. Das können wir mit unsere Personaldecke nicht, wir wollen keine 2 Klassen Mapperschaft, und die sich daraus ergebenden Daten Merge Probleme scheinen mir auch nicht wirklich lösbar.

Wir erzeugen also einen Strom sich ständig verändernder Daten.
Was passiert zur Zeit in diesem Strom:

MPs werden zerschossen, Ich bin ab und an über fehlende Strassenstücke gestolpert (da hörte die Strasse einfach auf, und fing nach 50 Meter wieder an).
Alles Fehler, die passieren können. Viele Mapper haben Überwachungen auf “ihren” Teil der Karte, so dass, wenn ein solcher Fehler hochgeladen wird, schnell reagiert werden kann. Hektische Reaktionen im Forum, die mit Nutzersperren durch die Admins beantwortet werden deuten auf noch grössere Probleme hin.

Der Datenstrom hat also eine sich verändernde Qualität, sie geht runter und rauf.

Die Online Kartenanbieter, die täglich neu rendern, haben damit kein Problem. Die Fehler sind so schnell aus der Karte raus, wie wir sie rausbekommen. Dieses Verfahren ist meiner Ansicht nach approved und accepted.

Auf der anderen Seite ist ein Offline Datenanbieter. Dieser zieht sich am Tag X einen Dump, bereitet den z.b. zum Routing auf. Woher soll er wissen ob dieser Dump OK ist, oder nicht. Ein Blick in das entsprechende Landesforum kann die grössten Fehler (uups wo ist die A3 ?) vermeiden.

Fehlerfreiheit werden wir nicht erreichen. Daher war meine Idee eine Möglichkeit zu schaffen alle Fehler mit von und bis und ihrer Relevanz zu taggen. Zieht man sich jetzt einen DUMP so kann man für die relevante Region nachschauen, wie die Qualitätsbewertung in den Notes dieses Dumps zu dem Zeitpunkt war. Dadurch das alle Fehler dokumentiert sind, kann man sich theoretisch für alle Fehler überlegen, ob diese einen Dump 2 Tage später erforderlich machen, oder nicht.

Parallel zu unserem sich ändernden Datenstrom auf der Zeitachse entsteht also eine Qualitätsbewertung, die neben der Zeitachse per Position filterbar ist, und die mit “Relevanzkriterien” zu versehen ist.

Christoph

5

Auf jeden Fall guter Ansatz! Frei definierbar würde ich sie nicht unbedingt machen. Ich sehe den Hauptvorteil im Filtern von Bugs und das funktioniert besser, wenn die Wertigkeiten vorgeschrieben sind. Das Ganze müsste natürlich möglichst einfach gehalten sein. Ich würde naiv jetzt so etwas vorschlagen wie:

  • Hier fehlt etwas in der Karte (Hinweis-Fenster, dass Renderer nicht alles anzeigen usw)
  • Hier ist etwas falsch (Dann Unterpunkt: Name/Position/Form/Sonstiges)
  • Hier ist etwas gesperrt / wird gebaut
  • Sonstiges
    Dazu dann noch ein Flag: “[x] Lässt sich nur mit Vor-Ort-Prüfung (ground survey) erledigen” - das dann jeder User setzen kann (auch zum Filtern)
6

Bei den Notes tendiere ich eher zu KISS. Man sollte es nicht zu kompliziert und umfangreich machen, sonst könnte man es auch gleich ganz eintragen. Außerdem ist es ja auch für nicht mappende Benutzer gedacht.

Alternativ in einer eigenen View ein komplettes Ticket System mit allen üblichen Features (Tagging, Status, Assignment, Component…).

7

Ich habe bereits vor 3 Monaten einen “Issue” auf GitHub eröffnet, in dem es um Filterbare Notes ging. Vielleicht könnt ihr eure Gedanken dort auch noch zusätzlich (auf Englisch) verewigen ?

8

Ah ok, so verstehe ich das nun. Das ist ja bspw. auch ein Problem bei temporär gesperrten Straßenabschnitten. Wenn da für drei Monate eine Baustelle ist, trägt man die dann ein und danach wieder aus? Was ist wenn jemand sich einen Dump zieht, kurz bevor die Baustelle weg ist und dann mit dem Dump ein halbes Jahr lang arbeitet? Dann hat er die Baustelle die seit 5 Monaten schon wieder weg ist, immer noch drin. Und klar, bei Fehlern ist das noch mal schlimmer. Bei Baustellen könnte man zumindest mit end_date=* oder vergleichbarem arbeiten.

Vielleicht könnte man in den Kartenhinweisen wo man Fehler melden kann, eine Möglichkeit schaffen, die es erlaubt, den Hinweis/Fehler zu spezifizieren, ähnlich wie kerosin es weiter oben erwähnte.

9

+1
Allerdings sollten es im Wiki definierte Festwerttags sein.

Als Hauptanwendung sehe ich aber die Kategorisierung der Notes zu Filterzwecken:

  • nach Art des Fehlers: z.B. hier fehlt etwas, hier ist etwas falsch, hier wird sich in Zukunft etwas ändern
  • nach Art der betroffenen Objekte: z.b. Grenzen, Waldwege, Hausnummer
  • nach Status: z.B. wartet auf Antwort zu Rückfrage, wartet auf Besichtigung vor Ort etc.

Ohne eine Möglichkeit zur Kategorisierung bzw. Filterung sind die Notes kaum sinnvoll für Fehlermeldungen durch Nichtmapper und Mapper gemeinsam einsetzbar.
Mapper sollten Fehler, die einfach abzuarbeiten sind, besser gleich direkt in der Datenbank korrigieren. Sinnvoll ist das Erzeugen einer Note für einen Mapper meist nur, wenn der Fehler schwer abzuarbeiten ist. Diese Notes bleiben dann natürlich lange offen und stören diejenigen Mapper, die insbesondere von Nichtmappern gemeldete Dinge einfach eintragen wollen.

10

Prinzipiell korrekt, da es für Mapper ja bisher fixmes und notes gibt. Dummerweise (so meine Erfahrung) macht kaum jemand QA/ Fixme abarbeiten. Daher muss m.E. an den Notes (die QA endlich direkt auf die Seite holen) was passieren.

Prinzipiell korrekt (;)) man könnte da aber auch von der Ticket-systemen scheinbar inhärenten Unverständlichkeit abweichen und allgemeinverständliche Kategorien verwenden.

11

Also ich finde die Idee sehr gut, Notes mit beliebigen Tags versehen zu können. Schließlich setzen wir ja auch bei der normalen OSM-Datenbank auf diesen Ansatz, das Datenmodell durch die Community definieren zu lassen. Einen Schlüssel für einen im Wiki definierten Satz gut ausgedachter Kategorien sollte man sich natürlich ausdenken, aber ich sehe keinen Grund, das im Code festzunageln.

Natürlich ist Teil des Konzepts hinter Notes, das Melden eines Fehlers möglichst leicht für Laien zu machen. Das ließe sich aber leicht mit freiem Tagging vereinbaren, indem man nicht angemeldeten Nutzern nur einen sehr eingeschränkten Spielraum lässt. Man denke etwa an Changesets, die ja auch freies Tagging erlauben, ohne dass deswegen iD gleich die volle Bandbreite an Möglichkeiten bieten braucht. Der erfahrenere Nutzer hätte trotzdem die volle Bandbreite an Möglichkeiten zum Kategorisieren und Filtern von Notes verfügbar.

12

Ich vermute, daß hier nicht Tags als Schlüssel/Wert-Paare wie bei OSM gemeint waren, sondern Tags aus einer einzigen Zeichenkette, wie sie bei Bugtrackern etc. üblich sind und bei OSM auch in der GPX-Sammlung vorkommen. Das scheint mir in diesem Zusammenhang auch sinnvoller als Schlüssel-Wert-Paare. Edit: Tordaniks Posting falsch gelesen. Mit wenigen Stichwörtern wie {road, landuse, poi, addr, access, tagging, geometry, …} (oder in DE auch auf deutsch) sollte man auskommen, größere Komplexität braucht es m.E. nicht.

Nützlich fände ich auch die Unterstützung einer Verlinkung von Objekten in der üblichen Notation n123456789, die einerseits in der Darstellung auf der Website in einen Link übersetzt werden, andererseits im Editor zur direkten Auswahl des Objekts dienen könnte.

Von “Schweregraden” würde ich absehen wollen. Erstens, um das Notes-Feature nicht gleich zu überfrachten, zweitens weil die Einstufung sowieso subjektiv ist. Ich erinnere an das wochenlange Klagelied, “die Karte” sei “völlig unbrauchbar”, als ein paar dutzend Stimmbezirksnamen in die rheinische Landschaft gerendert wurden. Aus Sicht jenes Konsumenten waren das wohl allesamt absolute Showstopper.

13

+1

14

Ich werde das an WE mal als Vorschlag in das Development Forum packen.

15

Referenz in das Development Forum:
http://forum.openstreetmap.org/viewtopic.php?id=23625

16

Done