Etwas ist kaputt, wie tagge ich das?
Das Wiki sagt:
status=* ist (zu) vage lt. Wiki
condition=* ist eher für gut-schlecht, aber nicht 0 oder 1 (?)
operational_status=* ist angeblich veraltet, aber die in der Wiki-Box vorgeschlagenen Alternativen (disused usw.) ersetzen das meiner Meinung nach nicht. Disused ist doch etwas längerfristig aufgegebenes/stillgelegtes, oder nicht?
Würde ich gar nicht taggen, und wenns dauerhaft kaputt ist : disused.
5 Likes
Grds. richtig.
Für “kaputte” Dinge verwende ich allerdings trotzdem das “disused:”-Schema. Allerdings nur, wenn etwas (absehbar) längerfristig kaputt ist. “Kaputte” Dinge werden ja in der Regel repariert, aber nun auch nicht immer, vor allem aber nicht immer zeitnah. Einschätzen zu können, wie zeitnah etwas repariert wird, ist natürlich die andere Frage.
Das hängt für mich wiederum indirekt damit zusammen, was genau kaputt ist. Manchmal kann man anhand dessen ungefähr abschätzen, wie lange eine Reparatur dauern wird…
Oder wenn ich öfter an einem Objekt vorbeikomme und sehe, dass das nach Monaten immer noch nicht repariert ist. Dann kommen disused: und ein check_date dran.
condition, status und operational_status beschreiben durchaus, dass ein Objekt (zur Zeit) nicht mehr funktionstüchtig ist, ändern aber die Eigenschaften des Objektes nicht. Das heißt, es wird in allen Karten, Datenauswertern usw. erst einmal weiterhin ganz normal angezeigt und ausgewertet (Außer halt, eine Anwendung wertet condition, status und operational_status wirklich aus, was aber selten sein dürfte). Ich könnte mir höchstens eine Verwendung dieser Tags vorstellen, wenn eine baldige Reparatur vermutet wird, und man das Objekt daher nicht als solches “canceln” möchte, trotzdem aber anzeigen möchte, dass es am xx.xx.xxxx kaputt war. Ist aber ein schwieriges Unterfangen.
1 Like
Die Frage hab ich mir vor einigen Monaten auch schon mal gestellt (nach der großen Flut in Stolberg) … Hab keine Antwort bekommen!
Hat sich inzwischen halbwegs erledigt.
Ansonsten?
Genau! Oder noch besser …
Ich verwende das disused:* Prefix dafür. note oder description wäre noch sinnvoll.
Das wäre dann abandoned:*. demolished:* und destroyed:* gibt es auch noch.
4 Likes
Den Ansatz hab ich noch nie verstanden und für mich ist eine Datenbank mit kaputten Objekten, eine kaputter Datenbank.
Neulich hab ich lauter Sitzbänke aufgeräumt. Eine Sitzbank ist doch dadurch definiert, dass man darauf sitzen kann. Wenn nur noch Seitenfundamente rumstehen sind da halt irgendwel he Betongteile, aber beim besten willen keine Sitzbank. Und Eisenpfähle im Boden sind auch kein Papierkörbe, bloss weil irgendwann mal einer daran befestigt gewesen sein könnte.
Den Müll sollten wir doch einfach entsorgen.
Das einzige wo ich dieses “ich mache die Karte kaputt indem ich behaupte das da etwas ist und sage in einem Untertag das es das eigentlich garnicht ist” irgendwie gerechtfertigt finde ist das Problem inaktueller Luftbilder. Da kann man schlecht zwischen “fehlt noch” und “nicht mehr da” Unterschieden…
1 Like
Nun ja, das disused:-Schema umgeht das wenigstens ein bisschen,
denn ich meinte schon, disused:amenity=bench statt amenity=bench zu taggen. Natürlich kann man, ggf. nach einer gewissen Zeit, je nach dem, wie es einem beliebt, den Node später immer noch komplett löschen.
Das einzige wo ich dieses “ich mache die Karte kaputt indem ich behaupte das da etwas ist und sage in einem Untertag das es das eigentlich garnicht ist” irgendwie gerechtfertigt finde ist das Problem inaktueller Luftbilder.
wir beschreiben die Realität, und wenn irgendwo Reste einer Sitzbank sind, oder andere Bruchstücke, kann man die natürlich so mappen (und das Entfernen solcher Teile wäre Vandalismus, zumindest wenn sie so gemappt sind wie der allgemeine Konsens ist). Es gibt die Verwechslungen mit dem Präfix nicht, zusätzliche tags (Trolltags) wären ein Problem aber abgewandelte Keys nicht.
Allerdings ist „disused“ für beschädigte Features nicht passend, dafür gibt es abandoned und andere, disused ist ein Ding das nicht genutzt wird obwohl das möglich wäre (also nicht signifikant beschädigt)
1 Like
1 Like
Nu und am Dienstag kommt die Müllabfuhr und holt den ganzen Plunder runter 
Ich hab meine Meinung geäussert, was allerdings nicht bedeutet, dass ich deswegen das Mapping anderer verändere. Aber: Wir beschreiben nicht eine temporäre Realität sondern eine dauerhafte. Wo Du die Grenze ziehst, ist nicht eindeutig festgelegt. Im öffentlichen Raum sind viele Objekte wenn Sie dissued oder destroyed sind ein temporärer Zustand und es gibt einen klar definierten Auftrag an die Eigentümer dafür zu sorgen, dass es sowas nicht gibt. Auch wenn sich das über Monate und manchmal Jahre hinziehen kann.
Daher denke ich dass jeder der soetwas einträgt sich im klaren sein sollte, dass er damit vielen Menschen die einfach nur beitragen wollen Steine in den Weg legt. Und man sollte die Einschätzung haben, dass man den Eintrag auch selber pflegen kann.
Natürlich stimmt es, dass Experten das genau eintragen können und mit den Prefix (die allerdings kaum ein Newbiew Editor standartmässig vorschlägt) umgeht man tatsächlich das Hauptproblem ein Tagging mit einem Untertagging wieder sinnzuenstellen. Leider findet man häufig das Haupttag plus ein kreatives Untertag (z.B. destroyed=yes) oder die wesentliche Information im name (“zerstörte Sitzbank”), note oder fixme versteckt…
Hallo. Auf die Frage kam ich übrigens wegen Fahrrad-Reparatursäulen (amenity= bicycle_repair_station). Ich halte dieses Objekt grundsätzlich für ein gutes Beispiel, dass es sehr wohl sinnvoll sein kann, etwas dysfunktionales so anzuzeigen, da diese Säulen immer mal von Vandalismus oder unsachgemäßer Benutzung usw. betroffen und damit kaputt sein können. Die Instandsetzung wird dann vermutlich erst einige Wochen später geschehen (mal so als Szenario).
Ein grundsätzliches Problem ist natürlich die viel zu geringe Mapperanzahl, um einen solchen Status auch dauerhaft aktuell zu halten. Wenn man ehrlich ist, könnte man sich momentan kaum darauf verlassen, dass der Funktionalitätsstatus dann auch wirklich aktuell ist. Aber das sollte wiederum kein Grund sein, diesen Status nicht anzugeben. An vielen anderen Stellen tun wir ja - überspitzt ausgedrückt - auch so, als sei OSM aktuell.
Konkret wird bei Reparatursäulen im Wiki das Tag lastcheck:status=working/needs repair vorgeschlagen. Nun ist aber mindestens “lastcheck” veraltet. Was ich schade fände, wäre, das jetzt trotzdem beizubehalten, weil es schon manchesmal so genutzt wurde. Dann haben wir aber einen Flickenteppich zum Tagging über verschiedene Objekte hinweg (ist ja an vielen anderen Stellen bereits der Fall).
Daher wollte ich wissen, ob es momentan ein übliches Schema gibt. Den bisherigen Antworten nach zu urteilen ist das tatsächlich nicht der Fall. Die Präfixe disused, abandoned, ja auch destroyed beschreiben im Kern andere Sachverhalte und setzen de facto auch das Objekt an sich “außer Kraft”, wobei das vielleicht eher ein Rendering-Thema ist.
Somit habe ich leider kein gutes Argument, an dem Tagging für die Reparatursäulen etwas zu ändern (außer vielleicht lastcheck als Präfix wegzunehmen und stattdessen nur “status” zu nehmen und es mit check_date:status zu ergänzen).
Für mich ist gerade das was Du schreibst ein gutes Beispiel von “Finger weg” und "drann denken dass wir einen dauerhaften Zustand mappen’.
Gerade per Rad komme ich oft in Gegenden, wo der Handyempfang eher instabil ist und bin auch an topografischen Informationen interessiert. Daher ist dass für mich ein typischer Anwendungsfall für Orux und lokus - und Spezialkarten.
Diese Karten wie openandromaps, freizeitkarte-osm und andere noch spezialisierte Karten bleiben sehr lange in Verwendung und sind alles andere als tagesaktuell. Monatliche updates sind schon super Service, einmal in Vierteljahr üblich - was aber nicht heist, dass die Anwender mit der aktuellen Version rumfahren.
Deine Idee und Dein Bedürfniss nach “tagesaktuell” steht gerade bei sowas im Widerspruch zu langfristig. Und irgendwie sehr ich nicht richtig ein, wieso ich mir Mobildatenkosten, hohen Batterieverbrauch und OSMand quasi “aufzwingen” lassen sollte.
Selbst Autofahrer, Camper usw haben oft Geräte mit statischen Karten.
Womit ich allerdings nicht sagen will, dass ich Dein Bedürfniss unberechtigt finde. Nur das ein Widerspruch zwischen geografischen Informationen und “Störungsmeldungen” besteht. Für mich wäre es eine schöne Entwicklungsaufgabe für Openstreetmap hier sinnvolle Dienste zu entwickeln, die diesen Widerspruch auflösen.
|
|
- | - |
Aber: Wir beschreiben nicht eine temporäre Realität sondern eine dauerhafte.
nichts ist dauerhaft, weder Berge noch Flüsse oder Bäume, von Straßen und Gebäuden ganz zu schweigen. Wir sind uns aber mittlerweile wohl einig, dass wir auch Dinge mappen, bei denen absehbar ist, dass sie bald wieder verändert werden, z.B. Baustellen. Die Realität ist ständig in Bewegung und wir versuchen, am Ball zu bleiben.
Wo Du die Grenze ziehst, ist nicht eindeutig festgelegt.
das ist aber das Entscheidende: wo zieht man die Grenze. Wir sind uns afaik weitgehend einig, dass das der einzelne Mapper entscheidet, und auch, dass es eine gewisse Verpflichtung bedeutet, wenn man kurzlebige oder veränderliche Dinge einträgt (d.h. es wird ein bisschen erwartet, dass man die dann auch selbst wieder updated, bzw. ist es AFAIK ok, kurzfristige Dinge einzutragen wenn man sich selbst darum kümmert, dass sie aktuell gehalten werden, während es eher skeptisch gesehen wird, sehr Kurzlebiges einzutragen und dessen Wartung “den anderen” aufzubürden).
Im öffentlichen Raum sind viele Objekte wenn Sie dissued oder destroyed sind ein temporärer Zustand und es gibt einen klar definierten Auftrag an die Eigentümer dafür zu sorgen, dass es sowas nicht gibt.
anderes Thema, es geht uns darum, die Realität zu beschreiben, wenn es diese Dinge gibt, dann kann man sie kartieren (sollte es ggf. sogar, weil so die Realität umfassender beschrieben ist), unabhängig davon, ob sie eigentlich schon weggeräumt sein sollten oder nicht. Jede Stahlbetonbrücke ist ein “temporärer Zustand” weil jetzt schon klar ist, dass sie in ein paar Jahren oder Jahrzehnten abgerissen werden müssen.
Daher denke ich dass jeder der soetwas einträgt sich im klaren sein sollte, dass er damit vielen Menschen die einfach nur beitragen wollen Steine in den Weg legt.
diesen Schluss kann ich aus der vorhergehenden Argumentation nicht nachvollziehen und es steht für mich hier zusammenhangslos und unbegründet.
Für mich ist gerade das was Du schreibst ein gutes Beispiel von “Finger weg” und "drann denken dass wir einen dauerhaften Zustand mappen’.
d.h. dein Vorschlag ist, kaputte Dinge als funktionierend einzutragen wenn deine Erwartungslage ist, dass sie vermutlich bald repariert werden könnten? Wie dauerhaft ein Zustand ist bzw. war sieht man erst im Rückblick. Der Flughafen in Berlin hätte schon 2011 eingeweiht werden sollen, hätten wir den 10 Jahre lang trotz Schließung als funktionierend mappen sollen, weil wir jederzeit davon ausgegangen sind, dass er bald eröffnet wird?
Gerade per Rad komme ich oft in Gegenden, wo der Handyempfang eher instabil ist und bin auch an topografischen Informationen interessiert. Daher ist dass für mich ein typischer Anwendungsfall für Orux und lokus - und Spezialkarten.
Diese Karten wie openandromaps, freizeitkarte-osm und andere noch spezialisierte Karten bleiben sehr lange in Verwendung und sind alles andere als tagesaktuell. Monatliche updates sind schon super Service, einmal in Vierteljahr üblich - was aber nicht heist, dass die Anwender mit der aktuellen Version rumfahren.
Wer mit alten Karten navigiert muss damit rechnen, dass sie mittlerweile nicht mehr aktuell sind, bzw. ist das bereits implizit. Ja, das steht im Widerspruch zu tagesaktuellen Änderungen, wie sie mittlerweile üblich sind bei vielen Anwendungen, so dass diese “statischen” Apps auf Dauer entweder aussterben werden oder sich anpassen müssen. Oder Themen behandeln, wo es nicht so wichtig ist, tagesaktuell zu sein.
Deine Idee und Dein Bedürfniss nach “tagesaktuell” steht gerade bei sowas im Widerspruch zu langfristig. Und irgendwie sehr ich nicht richtig ein, wieso ich mir Mobildatenkosten, hohen Batterieverbrauch und OSMand quasi “aufzwingen” lassen sollte.
Selbst Autofahrer, Camper usw haben oft Geräte mit statischen Karten.
Das ist ein bisschen offtopic, aber es juckt mich, die Sache mit den Mobildatenkosten ist ein deutsches Problem, hohe Kosten und schlechte Netzabdeckung kombiniert, aus der Ferne sieht es so aus, als wäre das ein Thema um sich bei der Telekom zu beschweren, oder der Bundesnetzagentur (nicht als Einzelperson, als Bevölkerung). Ich sage mal so als Beispiel einen beliebigen italienischen Tarif: 150GB 5G traffic im Monat und unbegrenzt Gespräche in alle (italienischen) Netze, jederzeit kündigbar, 10 EUR brutto. Es gibt hier auch Funklöcher, aber so miserablen Empfang wie in Deutschland habe ich selten erlebt, wo man selbst in Großstädten teilweise kein oder kaum Netz hat (erfahren in Stuttgart). Wenn die Infrastruktur erstmal gebaut ist und betrieben wird, kostet es praktisch nicht mehr, wenn man sie auch nutzt, wieso Traffic so teuer ist in Deutschland ist eine Frage des Geschäftsgebarens (und der Politik, irgendwer muss die Erlöse des Finanzministers aus den Frequenzversteigerungen ja bezahlen, außerdem war die Deutsche Telekom AG zuletzt nach Reduktion noch zu 58% in Staatsbesitz), nicht der Notwendigkeit.
Der Vergleich hinkt, da er ja zuvor nie eröffnet war.
Aber wenn er wegen einer Bombendrohung für einige Stunden komplett gesperrt würde, würdest Du ihn daher nicht umtaggen, da davon auszugehen ist, dass er zeitnah wieder freigegeben würde. Richtig?
richtig, wegen ein paar Stunden würde ich ihn nicht umtaggen. Der Vergleich mit der Bomdendrohung hinkt auch, weil etwas “kaputtes” (das man entsprechend taggen will) in aller Regel nicht nur ein paar Stunden sondern tage-, wochen- und sogar jahrelang kaputt sein wird/kann. Wenn ich die Erwartung hätte, dass etwas in ein paar Stunden wieder repariert sein wird bzw. in Funktion, dann würde ich das nicht mappen (Rolltreppen und Aufzüge in Bahnhöfen sind z.B. so was, wo es zwar für bewegungseingeschränkte Menschen ggf. ein großes Problem ist wenn sie kaputt sind, wo OSM aber wegen der Kurzfristigkeit keine gute Plattform ist, um über Störungen zu informieren).
In dem Beitrag auf den ich geantwortet hatte, ging es aber darum, Dinge “langfristig” zu mappen, auch wenn sie kurz- und vielleicht mittelfristig dann falsch wiedergegeben sind (Zitat: “Finger weg” und "drann denken dass wir einen dauerhaften Zustand mappen’).
Natürlich, da der Vergleich mit dem Flughafen von Anfang an hinkte. 
Da es oben u.a. um eine Fahrrad-Selfservice-Station ging. Wie lange sind diese Dinge im Durchschnitt defekt?
Haben die Menschen die so etwas umtaggen Erfahrung und belastbare Quellen wie lange so etwas durchschnittlich defekt ist, oder wird da einfach nach Gefühl gehandelt?
Was, wenn es erst wenige Minuten zuvor kaputt gegangen ist und der Betreiber ne Stunde später die Reparatur durchführen wird? Weiß man das?
Ich habe in München beim Bahnschutz gearbeitet. Auf der Strecke zwischen Dachau und Altomünster hatten wir über Monate extreme Probleme mit Vandalismus. Da waren die Fahrscheinautomaten quasi durchgehend außer Betrieb.
Genau genommen wurden die jedoch mehrfach die Woche, teilweise täglich repariert. Ich habe es selbst erlebt, dass wir den Techniker getroffen haben, wie dieser gerade das Display austauschte und als wir keine zwei Stunden später wieder an diesem Haltepunkt waren, war das Display erneut zerstört worden.
Da könnte man nun meinen, dass die Automaten nie oder nur sehr selten repariert würden, was aber einfach nicht wahr ist. Und mit dieser Erfahrung / Meinung würde man dann entsprechend andere Automaten umtaggen, weil ja defekt und es dauert (in der eigenen Meinung) ja ewig, bis mal etwas passiert.
Wenn etwas offensichtlich schon sehr lange defekt und inzwischen entsprechend verwittert ist, könnte ich es nachvollziehen. Aber nur weil gerade jetzt etwas defekt ist etwas umtaggen und dann über Tage / Wochen und länger nicht mehr nachkontrollieren… Nun ja…
wenn so etwas ständig kaputt gemacht wird sobald es repariert wurde ist der Effekt für die Nutzer der gleiche als wenn es selten repariert wird, d.h. es sollte entsprechend als kaputt getaggt werden.
Nur kann man dies an anderen Stellen nicht wissen. Der Logik nach würde man also jeden Automaten umtaggen, auch wenn er vermutlich kurz danach repariert wird.
Daher meine Frage woher man die Information hat, wie lange etwas, das man umtaggt, durchschnittlich defekt sein wird. Einfach geraten? Ich denke, also tagge ich…
Ich ernnere mich da übrigens an eine Fahrtreppe vom Sperrengeschoss Richtung Starnberger Flügelbahnhof, im Münchener Hauptbahnhof.
Die funktionierte grundsätzlich, war aber die meiste Zeit ausgeschaltet, da sie nur noch fuhr, es keine Fahrtreppe runter gab und danach weitere Stufen folgten.
Ein in der mobilität eingeschränkter Mensch hätte also diese Fahrtreppe hoch fahren können, um erst danach festzustellen, dass er ohne Hilfe nicht weiterkommen wird.
Dennoch gab es immer mal wieder Kolleg*innen, die die Treppe aus Unwissenheit in Betrieb genommen haben…
Wie gesagt… Dinge also defekt zu taggen, wenn man die Hintergründe nicht kennt ist mehr als schwierig, wenn nicht offensichtlich ist, dass die Reparatur voraussichtlich nicht (all zu bald) erfolgen wird.
Wenn etwas offensichtlich verwittert oder über längere Zeit immer wieder beschädigt / zerstört wurde, kann man davon ausgehen, dass hier keine zeitnahe Reparatur stattfinden wird. Wenn gerade etwas einfach nur defekt / außer Betrieb ist, kann man dies aber ohne Hintergrundwissen unmöglich sagen und rät bestenfalls.
Und an der Stelle wird es dann problematisch, wenn man nicht alle paar Tage nachsieht. Und selbst dann ist es problematisch, weil diese (evtl. schnell wieder falsche Information) über lange Zeit in diversen Datenbanken bestehen bleibt.