OSMB: Hinweis auf Check vor Ort?

margin-auto · 2012-02-06T18:26:56.000Z

Hallo,

mir ist folgender Verbesserungsvorschlag für Openstreetbugs eingefallen und ich wollte ihn gerne zur Diskussion stellen, ob er evt. sinnvoll ist:
Hinzufügen einer zusätzlichen Option je Bug mit Auswahl zwischen “muss vor Ort überprüft werden” und “muss nur gefixt werden bzw. kann remote geprüft werden”.
Wenn die Bugs mit diesem Wert versehen sind, lassen sie sich einfacher filtern für Mapping Parties ohne Aktion im Gelände (wie bspw. die kommende Night of the living Maps). Hierfür kann man sich dann einfach einen Auszug aller remote erledigbarer Bugs in einem bestimmten Gebiet ziehen. Andersrum kann man sich natürlich auch eine Liste aller notwendigen Checks vor Ort ziehen und für die nächste Tour im Gelände verwenden.

Wäre sowas sinnvoll, oder stehen dem irgendwelche Gründe entgegen, die ich übersehen habe?

Gruß

_i · 2012-02-06T19:20:21.000Z

Den find ich gut. Das Filtern müsste eh mal verbessert werden

mtb · 2012-02-06T19:59:17.000Z

In diesem Zusammenhang möchte ich einen Vorschlag wiederholen, den ich im Rahmen einer Lizenzwechseldiskussion gepostet habe, aber dort etwas untergegangen war.

Meine Überlegung: etliche gemappte Wald- und Feldwege sehe ich nach dem Mappen so schnell nicht wieder (manche nie) - und teilweise wohl auch kein anderer Mapper (ich mappe ganz gerne unscheinbare Wege / Trampelpfade irgendwo im Wald oder auf Feldern/Wiesen). Aber manchmal sind Wege nach einiger Zeit nicht mehr vorhanden (z.B. zugewachsen) oder es wird track zu path (oder umgekehrt) oder die Beschaffenheit ändert sich etc. So habe ich kürzlich einen ehemals von mir als tracktype=grade2 gemappten Weg komplett gelöscht, da nichts mehr davon übrig war (der Weg war völlig zugewachsen, der Boden nur noch Matsch).

Idee: wer als Mapper einen (vermutet) selten besuchten Weg / Pfad so vorfindet, wie er in der Datenbank vorhanden ist, setzt ein Tag ‘reality_checked’ oder ‘confirmed’ oder ‘validated’ oder ‘verified’ oder ‘data_ok’ oder ähnliche Bezeichnung. Als Wert würde ich nicht einfach yes oder ok nehmen sondern eine Jahres- / Monatsangabe im Format JJJJMM (ein konkretes Datum halte ich nicht für notwendig). Beispiel wäre also: data_ok=201112 für eine Bestätigung sowohl der Lage als auch der Tags im Dez. 2011.

Natürlich kann sich so etwas auch auf einzelne Tags eines Objektes beziehen, also z.B. mit data_ok:oneway=201112 bestätigt man, dass die Einbahnstraßen-Richtung im Dez. 2011 (genauer: zum Zeitpunkt der ‘Bestätigung’) der Realität entspricht (wenn man sich z.B. beim maxspeed-Wert oder anderen Eigenschaften unsicher ist) .

Wer die Idee aufgreifen möchte, möge dies bitte tun (Mailinglisten, Vorschläge via Wiki etc. sind mir zu umständlich) und das Thema vorantreiben.

Viele Grüße,
mtb

erwin6330 · 2012-02-07T05:39:31.000Z

mtb:

…

Idee: wer als Mapper einen (vermutet) selten besuchten Weg / Pfad so vorfindet, wie er in der Datenbank vorhanden ist, setzt ein Tag ‘reality_checked’ oder ‘confirmed’ oder ‘validated’ oder ‘verified’ oder ‘data_ok’ oder ähnliche Bezeichnung. Als Wert würde ich nicht einfach yes oder ok nehmen sondern eine Jahres- / Monatsangabe im Format JJJJMM (ein konkretes Datum halte ich nicht für notwendig). Beispiel wäre also: data_ok=201112 für eine Bestätigung sowohl der Lage als auch der Tags im Dez. 2011.

…

+1, fände ich super

BBO · 2012-02-07T08:35:22.000Z

mtb:

Idee: wer als Mapper einen (vermutet) selten besuchten Weg / Pfad so vorfindet, wie er in der Datenbank vorhanden ist, setzt ein Tag ‘reality_checked’ oder ‘confirmed’ oder ‘validated’ oder ‘verified’ oder ‘data_ok’ oder ähnliche Bezeichnung. Als Wert würde ich nicht einfach yes oder ok nehmen sondern eine Jahres- / Monatsangabe im Format JJJJMM (ein konkretes Datum halte ich nicht für notwendig). Beispiel wäre also: data_ok=201112 für eine Bestätigung sowohl der Lage als auch der Tags im Dez. 2011.

Natürlich kann sich so etwas auch auf einzelne Tags eines Objektes beziehen, also z.B. mit data_ok:oneway=201112 bestätigt man, dass die Einbahnstraßen-Richtung im Dez. 2011 (genauer: zum Zeitpunkt der ‘Bestätigung’) der Realität entspricht (wenn man sich z.B. beim maxspeed-Wert oder anderen Eigenschaften unsicher ist) .

Das wird bei vielen Objekten zu einem unnötigen/unübersichtlichen Rattenschwanz an Tags führen und die Datenbank unnötig belasten. Wenn jemand so etwas vor hat, dann bitte komplett in einer eigenen Datenbank. Ein zusätzliches Tool zum anzeigen der schon länger nicht kontrollierten Objekte wäre so und so nötig.

Ich könnte mir da ganz gut ein angepasstes keepright vorstellen: Blitze auf die länger nicht kontrollierten Objekte, beim Klick auf den Blitz öffnet sich ein Popup in dem die Tags aufgelistet werden und mit einem Häkchen hinter jedem Tag (und zusätzlich dem Verlauf) als kotrolliert markiert werden können.

Gruß
BBO

mtb · 2012-02-07T20:38:17.000Z

BBO:

… Ein zusätzliches Tool zum anzeigen der schon länger nicht kontrollierten Objekte wäre so und so nötig.
Ich könnte mir da ganz gut ein angepasstes keepright vorstellen: Blitze auf die länger nicht kontrollierten Objekte…

Wie soll denn aber festgestellt werden, welche Objekte seit längerem nicht mehr kontrolliert wurden?

margin-auto · 2012-02-12T10:28:16.000Z

Gerade entdeckt, dass es dazu bereits einen (wenn auch etwas versteckten) Kommentar im Bugtracker zu OSMB gibt: https://github.com/emka/openstreetbugs/issues/19#issuecomment-648718