Relationen in JOSM

Um die Höchstgeschwindigkeiten von Straßen zu korrigieren, musste ich häufiger “Linien spalten” um jedem Teil andere Geschwindigkeiten zuzuweisen.

Nur alleine das Aufspalten dieser (Straßen-)Linien führt fast jedes Mal dazu, dass ich beim Hochladen Warnungen bekomme.

*Problem bei Rollenprüfung - Die Rolle eines Relationsmitglieds stimmt nicht mit dem Ausdruck ‘highway=bus_stop || railway=station || railway=halt || railway=tram_stop’ in der Vorlage Public transport route (Legacy) überein (1) *

Ich kenne den Begriff Relationen und denke auch zu wissen, was in OSM damit gemeint ist. Und ich vermute, dass die Warnung nicht durch mich verursacht wurde, sondern wahrscheinlich eine “Altlast” ist. Dennoch mag ich es nicht Warnung zu ignorieren. Andererseits habe ich auch keine Lust Relationen mit 500 bis 600 Positionen manuell zu durchsuchen, in der Hoffnung dort einen Fehler zu finden.

Wie sollte man sinnvoll in solchen Fällen vorgehen?

.

In der Warnung wird doch das Member referenziert, oder?

Das wäre zum Beispiel in einem Fall “Ostheim Bahnhof” mit Koords.

Wenn ich dahinzoome gibt es dort zwei Objekte mit diesem Namen. Nur einer ist Teil einer Relation. Diese Relation hat ca. 200 Einträge. :frowning:

Dieser Knoten Ostheim Bahnhof https://www.openstreetmap.org/node/5068780365 gehört zur Routen-Relation der Buslinie FB-56 und zeigt bei meinem JOSM-Validator keinen Fehler in der Routenrelation an.

Aber der Hessische Radfernweg R6, der die Bahnhofsallee in Ostheim als Mitglied enthält, besitzt als erstes Element einen Knoten, worüber sich mein Validator beschwert (er mag keine Knoten in Fahrrad-Routen).

Mir ist aufgefallen, dass das Objekt das Einzige war, welches ein anderes Logo hatte, als die anderen Haltestellen. Und nachdem ich mir die Eigenschaften angesehen hatte, viel mir auf, dass Ostheim Bahnhof als einziger nicht als highway=bus_stop getaggt war. Nachdem ich ich das nachgetragen hatte, war der Fehler verschwunden.
Aber ich habe immer ein ungutes Gefühl, wenn ich an Daten Anderer rumändere, ohne richtig zu wissen, ob das, was ich da mache auch richtig ist. :confused:
Aber ich glaube, daran muss man sich bei OSM gewöhnen. :roll_eyes:

Ich traue mich an diese Relationen auch nicht dran. Manche Warnungen von JOSM (oder auch anderen QA Tools) sind schlicht falsch. Ich verbessere nur, wenn ich mir ziemlich sicher bin. Ich denke nicht, dass sich igendein Mapper mit allen Dingen in der OSM DB auskennen kann. Also konzentriere ich mich auf die Objekte, die ich gut verstehe und ignoriere andere Warnungen, die ich nicht selbst produziert habe.

Naja, Warnungen sind nur Warnungen, sie heißen nur “das hier kommt mir komisch vor, schau dir das noch mal kurz an”. JOSM warnt auch bei ähnlichen Namen wie Burgstraße / Bergstraße. Kann ein Fehler sein, muss aber nicht. Das würde ich nicht “Warnung ist falsch” nennen.

Und was, wenn ich mir eine Warnung “anschaue” und nicht weiß, was diese Warnung mir sagen will? Einfach ignorieren?
Es ist jetzt weit hergeholt, aber was es bedeutet, Warnung nicht zu verstehen und einfach zu ignorieren, sieht man an der Hochwasserkatastrophe in NRW.
Etwas, was ignoriert werden kann, sollte Hinweis heißen. “Der Name wurde in Großbuchstaben geschrieben” kann ich wohl ignorieren. Aber eine Warnung, dass eine Relation oder Route oder was auch immer entspricht nicht (mehr) den Anforderungen würde ich schon ernst nehmen wollen. Vor allem, weil ich nicht weiß, wozu diese Objekte verwendet werden. Und was ein Ignorieren für Auswirkungen hat.

:frowning: :frowning: Wie macht man es richtig ??? :frowning: :frowning:

.

Hier zu fragen ist schon richtig. Ich mache dir doch keinen Vorwurf. Mein “Warnungen sind nur Warnungen” war keine Antwort an dich, sondern bezog sich auf die Formulierung von GerdP, dass manche Warnungen “schlicht falsch” sind.

Also, da muss schon mehr kommen, bevor ich es als Vorwurf sehe. :smiley:

Ich bin vielleicht etwas sensiebel mit technischen Warnungen. Ich hatte am Anfrang meines Berufsleben einmal die Warnung eines Compilers irnoriert. Das Ergebnis war, dass ich einen großen, damals neuen, süddeutschen Verkehrsflughafen fast lahmgelegt hätte, weil die Klimaanlage im Tower bei 30° Außentemperatur plötzlich von kühlen auf heizen umgeschaltet hatte. Glücklicherweise hat dann ein Kollege vor Ort, kurz bevor die Lotsen den Turm verlassen wollten, die Anlage auf Handbetrieb umgeschaltet und den Lotsen bei 45° dann Erleichterung verschafft.

Daher sind Warnung für mich immer wichtig. Man muss nur klar zwischen Warnungen und Hinweisen unterscheiden. Und das, glaube ich, wurde hier nicht konsequent zu Ende gedacht. :confused:

.

Hm… Also ich sehe das bisschen differenzierter: Wenn dein Code so eine Auswirkung hätte, wäre es eigentlich schon fast ein Fehler (Error).

  • Ein grober Fehler stellt schwerwiegende Folgen dar und sollte so sein, dass es immer behoben wird (z.B. sich überschneidende Linien)
  • Eine Warnung stellt dar, hier könnte etwas sein; muss aber nicht - z.B. folgt ja aus einem “Vorsicht Wildwechsel”-Schild, was eine Warnung darstellt, nicht sofort, dass dort (immer) Wildwechsel stattfindet.

Aber was man aus deiner Geschichte lernen kann: Man sollte sich Warnmeldungen, wenn sie kommen immer mal angucken.

JOSM hat drei “Fehler”-Klassen, im englichen “error”, “warning” oder “other” bzw. “informational” genannt. Da wird sehr wohl unterschieden. Letztere bekommt man nur zu sehen, wenn man “Unwichtige Warnungen anzeigen” aktiviert.

Jetzt gibt es aber mindestens drei Probleme:

  1. Was der eine als Fehler ansieht ist für den anderen irrelevant. Die JOSM Programmierer (mich eingeschlossen) verlassen sich da auch oft auf die Person, die ein Ticket aufmacht und schreibt, das X mit Y nicht zusammen geht oder A auch ein B erfordert. Manchmal ist also tatsächlich die Einstufung problematisch. Die Ticket-Ersteller sehen ein Problem typischerweise eher als Fehler.
  2. Bei alles Tests ist es immer möglich, das der JOSM Java Code oder die entsprechende MapCSS Regel fehlerhaft oder unvollständig ist oder einfach aus Performance-Gründen nicht alle Daten erfassen kann, die für ein richtiges Ergebnis nötig sind.
  3. Menschen machen Fehler. Als Programmierer verlässt man sich gerne aufs Wiki, aber das ist selten so klar wie man sich das wünschen würde und nach einiger Zeit ist vielleicht ein unklarer Punkt im Wiki so geändert worden, dass der JOSM Test nicht mehr passt.

Wie so oft in OSM gibt es da keine klaren Grenzen.

Ich stimme Dir in allen 3 Punkten zu. :slight_smile:

Ich verwende den JOSM-Validator nur beim Hochladen. Dann werden auch nur die Objekte geprüft, die ich bearbeitet habe. Sollten hier Hinweise angezeigt werden, überprüfe ich diese auch.
Uraltfehler in Relationen, die ich nicht angefaßt habe, interessieren mich nicht.

Prinzipiell ist es so, dass, wenn man einen Weg splittet, man die “Fehler” der Relationen erbt.

(weil man, ohne dass man das eigentlich vorhatte, der Relation ein Mitglied hinzufügt)

Hier gibt es dann sehr viele Optionen, die alle für sich selbst entscheiden müssen:

  • Wenn es sich um triviale Fehler (Tipfehler im Tagging etc.) handelt, dann sollte man die imho reparieren
  • komplexere Sachen, wie Busrouten - wenn man Plan davon und Langeweile hat kann man die reparieren, oder man lässt es. Oder man schaut in der Historie nach, wo der Fehler herkommt und schreibt den Verursacher an, ob er sich das nochmal anschauen kann - oder man lässt es.
  • irgendwas anderes

P.s. wenn irgendwas von TMC in der Relation steht, dann ist das von Haus aus kaputt und nicht reparierbar :wink:

Richtig gut erklärt. :slight_smile:

Ich hab mal versucht, als in meiner Heimatstadt der Busbahnhof verlegt wurde, die Busrouten umzulegen. Die waren damals aber schon so kaputt, dass man sie komplett hätte löschen müssen und neu aufsetzen hätte müssen. Selbst bei nur 10 Linien eine Sisyphusarbeit. Die Taggingschemata im ÖPNV sind ja immer noch umstritten. Allein deshalb lass ich die Finger davon.

TMC war IMHO in OSM von Anfang an ein tot geborenes Kind. Weil sich das vom Otto-Normalmapper nicht pflegen lässt. Wird TMC überhaupt noch benutzt?

Meines Wissens ja. Alle ÖRR-Radios und ein paar private senden über RDS-TMC immernoch aus.

Mal gucken, wann dem UKW-Radio der gar ausgemacht wird. DAB+ kommt auf jeden Fall mit einem neuen Stauservice auf TPEG-Basis. Das heißt komplett ohne Kodierung und im Klartext. Wie die aber genau aussehen - keine Ahnung :smiley:

Diese Frage wurde hier vor ca. 10 Jahren schon einmal gestellt.
Da kam heraus, dass stellenweise Verkehrsnachrichtenredaktionen (BR?) das genutzt hatten. Daraufhin hat man diese Relationen drin gelassen.
Ob RDS nutzende Sender OSM heute noch verwenden - keine Ahnung.
Ich hätte da meine Zweifel, da diese Relationen mW so gut wie nicht gewartet werden.
Neuere Autos haben jedenfalls nur noch DAB+ Radios.

Was ich oft mache, wenn ich einen Bereich heruntergeladen habe, in dem ich etwas bearbeiten will: erstmal die Prüfung laufen lassen, damit ich sehe, welche Altlasten da Fehler und Warnungen hervorrufen. Dann kann ich überlegen, was ich davon beheben kann und will. In jedem Falle weiß ich aber, was vor meiner Bearbeitung schon war und kann besser erkennen, welche Fehler ich eingebaut habe.
Was Relationen, die über Wege laufen, die ich teilen will, angeht: da ist es gut, die jeweiligen Relationen ganz herunterzuladen, damit beim Teilen nichts schief geht (auf die z.B. Bus–Relation rechts klicken → unvollständige Elemente herunterladen). JOSM warnt seit einiger Zeit auch, wenn man so einen Weg teilen will.