Idee: Änderungserinnerungen

E-Malte · 2011-04-19T14:45:29.000Z

Hallo zusammen,

bei OSM vermisse ich soetwas(, und bei Wikipedia scheint mir das auch ganz angebracht):

Änderungserinnerungen

Was soll das sein?
Änderungserinnerungen kann man benutzen, wenn man ein bestimmtes Feature zu/nach einem bestimmten Zeitpunkt ändern sollte.

Wofür braucht man soetwas?
Zum Beispiel bei Baustellen: eine Straße ist gesperrt von Tag X bis Tag Y. Größere Bauvorhaben sind meist ausführlich geplant. Zuerst soll ein Straßenabschnitt gesperrt werden, danach ein nächster, usw. Diese Daten stehen meist auf den Informationsseiten der Kommune und in Berichten der Tageszeitungen. Diese Daten könnte man mit den OSM-Objekten verknüpfen, sodass bei jedem neuen Bauabschnitt eine Änderungsmitteilung für alle betreffenden Straßenabschnitte ausgegeben wird.
Oder zum Beispiel bei Neueröffnungen, Ladenschließungen, Umbenennungen: Oftmals sieht man, dass ein Laden an Datum X öffnet, schließt, oder irgendeine andere “Eigenschaft” desselben geändert werden soll. Die Daten vorzeitig einzutragen kann je nach Dauer zur Umsetzung ungünstig sein, da damit die Daten noch nicht korrekt sind. Andersherum kann es passieren, dass eine Änderung verpasst wird, weil keiner mehr daran denkt. Dadurch wären die Daten dann nicht mehr korrekt.

Wie soll das ganze funktionieren?
Das ist der Punkt, an dem ihr gefragt seid!
Zwei grundsätzliche Prinzipien der Datenspeicherung sind hier denkbar:

Aufnahme der relevanten Daten in die Datenbank. Hierfür wäre ein simples Tagging-Schema denkbar.
2)Eigene Datenbank, ähnlich zu OpenStreetBugs.
Wenn dann diese Daten vorhanden sind, würden die Daten gefiltert. Wenn das Datum der geplanten Mitteilung mit dem heutigen übereinstimmt, würde diese Mitteilung ausgegeben. Diese Mitteilung kann auch auf verschiedenen Wegen erfolgen:
OSM-Nachricht an die Person, die die Mitteilung eingetragen hat (oder irgendjemand anders).
Übersichtskarte mit farblicher anzeige, welche Änderung erledigt werden soll.
… (Hier fällt euch sicher noch mehr ein.)
Kombinationen sind hier selbstverständlich möglich.

Warum nicht direkt vollautomatisch?
Gute Frage, das wäre eventuell ein nächster Schritt.

Was haltet ihr von der Idee? Denkt ihr, man sollte das weiterverfolgen? Habt ihr vielleicht eine komplett andere Umsetzungsidee dazu?

Viele Grüße,
Malte

_i · 2011-04-19T14:47:46.000Z

Da es um die Veränderung von Zuständen geht, hier mal noch ein paar Denkanstöße
http://wiki.openstreetmap.org/wiki/Comparison_of_editors

Ich muss mir deins erst mal in Ruhe durchdenken

aighes · 2011-04-19T15:15:08.000Z

Bei vollautomatisch steht man vor dem Problem: IDs sind flüchtig. Der Service müsste also regelmäßig die diffs auswerten und IDs anpassen. Nächstes Problem: Baustelle dauert länger, als angenommen. Dann greift der Automatismus zu früh. Evtl. stimmen auch andere Eigenschaften nicht mehr, was man vorher nicht absehen konnte. Wenn nun aber die “Info Baustelle weg” eingetragen ist, suggeriert das den anderen Mappern, dass die Straße so nun passt. Weiterhin schüren Automatismen immer misstrauen, weil sie eben auch unsinn machen können.

Was spricht dagegen, sich selbst ein Knoten ins Taschentuch zu machen. Eine Kalenderanwendung mit Erinnerungsfunktion hat doch mit Sicherheit jeder auf dem Rechner…

EvanE · 2011-04-19T15:27:29.000Z

E-Malte:

bei OSM vermisse ich … Änderungserinnerungen
…
Änderungserinnerungen kann man benutzen, wenn man ein bestimmtes Feature zu/nach einem bestimmten Zeitpunkt ändern sollte.

Wofür braucht man soetwas?
Zum Beispiel bei Baustellen: … Oder zum Beispiel bei Neueröffnungen, Ladenschließungen, Umbenennungen: …

Wie soll das ganze funktionieren?
…

Was haltet ihr von der Idee? Denkt ihr, man sollte das weiterverfolgen? Habt ihr vielleicht eine komplett andere Umsetzungsidee dazu?

Hallo Malte

Die Idee finde ich auf jeden Fall interessant. Die Realisierung wird aber vermutlich nicht trivial. Auf der anderen Seite haben wir eine Menge Muster, die man als Startpunkt verwenden könnte.

Vielleicht trägst du die Idee mal bei http://wiki.openstreetmap.org/wiki/API_v0.7 als Vorschlag ein. Das ist eine Ideensammlung für die nächste API-Version. Wenn ein Erinnerungsdienst direkt in der API implementiert würde, wäre das optimal. Ob die Chancen dafür gut stehen, ist zur Zeit nicht einzuschätzen.

Edbert (EvanE)

flaimo · 2011-04-19T15:45:49.000Z

diesen gedanken hatte ich vor einiger zeit auch. mit dem proposal, welches ich gerade schreibe, gehe ich sogar noch einen schritt weiter: http://wiki.openstreetmap.org/wiki/Proposed_features/automated_tasks

ich suche noch wen, der bots schreiben kann und daran interessiert wäre für einen kleine bbox einen prototypen zu bauen.

GeoCounter · 2011-04-19T16:44:43.000Z

Hallo flaimo,

flaimo:

diesen gedanken hatte ich vor einiger zeit auch. mit dem proposal, welches ich gerade schreibe, gehe ich sogar noch einen schritt weiter: http://wiki.openstreetmap.org/wiki/Proposed_features/automated_tasks

Bei der Syntax sehe ich ein ähnliches Problem wie bei bedingten Access Beschränkungen: Zusätzlich zu Schlüssel und Wert gibt es noch eine Bedingung. Da die API aber nur Schlüssel und Wert erlaubt, muss die Bedingung in einem der beiden Felder untergebracht werden.

Tordanik schlägt in seinem Proposal zu der Access Problematik vor, die Bedingung im Schlüssel unterzubringen und somit dem Wert “sauber” zu halten.

Bezogen auf dein Proposal sehe ich folgende Vorteile einer Bedingung im Schlüssel:

bei ata_change könnte das “;” entfallen, da der neue Wert exakt dem angegebendem Wert entspricht

bei mehreren Veränderungen wäre das “ata_change_2” nicht notwendig, da die Schlüssel sich ohnehin durch die Bedingung unterscheiden

Nachteilig wäre natürlich, dass das Konzept einer begrenzten Menge möglicher Schlüssel aufgeweicht wird, was evtl. die Auswertung erschwert.

Beide Ansätze (Bedingung in Schlüssel oder Wert) haben also Vor- und Nachteile, allerdings halte ich es für sinnvoll, eine einheitliche Lösung für dieses grundsätzliche Problem zu verwenden.

Gruß
GeoCounter

flaimo · 2011-04-19T17:00:30.000Z

GeoCounter:

Beide Ansätze (Bedingung in Schlüssel oder Wert) haben also Vor- und Nachteile, allerdings halte ich es für sinnvoll, eine einheitliche Lösung für dieses grundsätzliche Problem zu verwenden.

diese problematik zieht sich jetzt aber schon einige jahre hin. ich würde das deshalb nicht als showstopper für das proposal sehen. sollte sich die allgemeine verwendung dann andersrum entwickeln, kann man den syntax ja immer noch updaten, da es sich hierbei ja um flüchtige tags mit ablaufdatum handelt. da sie nichts mit kartendarstellung oder routing direkt zu tun haben könnten sie mithilfe eines weiteren bots oder einmaligen datenbankscript in einem rutsch umgeschrieben werden.

das escapen sehe ich auch nicht so als problem an, da ich sowieso davon ausgehe, dass die editoren dann dafür ein vernünftiges GUI mit passenden controls zur verfügen stellen würden, die das escapen übernehmen.

E-Malte · 2011-04-19T20:13:31.000Z

GeoCounter:

Bei der Syntax sehe ich ein ähnliches Problem wie bei bedingten Access Beschränkungen: Zusätzlich zu Schlüssel und Wert gibt es noch eine Bedingung. Da die API aber nur Schlüssel und Wert erlaubt, muss die Bedingung in einem der beiden Felder untergebracht werden.

Je nachdem, was man machen möchte, halte ich das für nicht so dramatisch, wie es immer dargestellt wird. In einem Renderer eine solche Auswertung zu implementieren ist sicher schwierig, aber wenn man die Daten einfach nur auswertet, sehe ich da keine Probleme, wenn man ein Tag hat, das immer gleich benannt ist:

es werden alle Objekte mit dem Tag xyz inklusive aller anderen Tags an diesem Element ausgelesen
in einer foreach-Schleife oder vergleichbarem werden alle Tags durchgegangen

i) wenn der Tag mit den Buchstaben xyz-do beginnt, wird er analysiert
ii) wenn hinter xyz-do ein : ist, schiebt man all diese Elemente in eine “Gruppe” (Array o.ä.), wenn dahinter ein _ steht, dann schreibe das in die Gruppe (alles was hinter dem _ steht)
– alternativ: auswerten von dem String hinter dem : bzw _

für jede dieser Gruppen kann man nun individuell weiterverfahren

Vom Programmieraufwand mag das vielleicht geringfügig mehr sein, als wenn man es nicht hat, aber es funktioniert in vielen Programmiersprachen intuitiv…

Oder habe ich das Problem falsch verstanden?

Viele Grüße,
Malte

E-Malte · 2011-04-19T20:20:59.000Z

EvanE:

Vielleicht trägst du die Idee mal bei http://wiki.openstreetmap.org/wiki/API_v0.7 als Vorschlag ein. Das ist eine Ideensammlung für die nächste API-Version. Wenn ein Erinnerungsdienst direkt in der API implementiert würde, wäre das optimal. Ob die Chancen dafür gut stehen, ist zur Zeit nicht einzuschätzen.

Hallo Edbert,

das sieht momentan eher aus wie ein Schlachtfeld.

Ich weiß nicht, ob diese Funktion in der API nicht fehl am Platz ist. Die API ist nur für das Management der Daten verantwortlich, aber was darin steckt interessiert sie wenig.
Außerdem müsste man dann laufend(?) die DB nach den Änderungsdaten durchsuchen, aber damit sollte die API m.E. nichts zu tun haben.

Viele Grüße,
Malte

EvanE · 2011-04-19T21:05:58.000Z

E-Malte:

EvanE:

Vielleicht trägst du die Idee mal bei http://wiki.openstreetmap.org/wiki/API_v0.7 als Vorschlag ein. …

das sieht momentan eher aus wie ein Schlachtfeld.
Ich weiß nicht, ob diese Funktion in der API nicht fehl am Platz ist. …

Hallo Malte

Das ist erst einmal eine reine Ideensammlung (Brainstorming). 80 oder mehr Prozent der Vorschläge gehören nicht in die API oder können auf anderen Wegen behandelt werden. Also keine Scheu, deine Idee dort einfach einzutragen.

Irgendwann werden die Vorschläge ausgewertet. Dann kann man immer noch sehen, ob das in die API V0.7 passt oder ob es andere Methoden gibt.

Edbert (EvanE)