Hallo,
mein englisch ist leider nicht so gut.
Verstehe ich das richtig: Das Durcheinanderwirbeln der Reihenfolge einer Relation beim Auftrennen wurde bei der neuen Version 2.20.3 behoben?
Der zweite Punkt bei operations
https://github.com/openstreetmap/iD/blob/release/CHANGELOG.md#whats-new
Gruß
Danfost
Hm, du hast zu v 2.20.3 verlinkt.
Der zweite Punkt bei operations sagt was über Verbesserung bei der Objekthistorie, aber wenn ich weiter suche, finde ich unter bugfixes “Fix wrong order of route relation members after a split operation (#8519)”. Das Ticket mit der Nummer 8519 handelt von falsch sortierten Relationen nach Aufteilen eines Weges mit iD.
Wäre schön, wenn das damit wirklich behoben ist. Da hat iD viele Relationen beschädigt, meist ohne daß die Mapper davon eine Ahnung hatten.
Hallo
habs im Beitrag korrigiert
Gruß
Danfost
Kannst Du bitte noch den Titel anpassen. Sollte durch bearbeiten des ersten Beitrag möglich sein.
Danke.
Laut unseren Nachbar ist noch nicht alles im Reinen: https://forum.openstreetmap.org/viewtopic.php?pid=854758#p854758
Hallo,
den Titel hatte ich schon angepasst.
Die 2.20.4 kam dann gleich einen Tag hinterher.
so gings mit auch, deshalb halte ich mich von Relationen fern, gerade bei Busrelationen.
Nachdem mir @ALu68 gezeigt hatt wie man in ID auch die Reihenfolge in Relationen überprüfen kann habe ich mal mit der neuen 2.20.4 Version eine Kreuzung zu Kreisverkehr (mit Busrelationen) umgemodelt. Hier schien alles zu stimmen.
Habs dann doch nicht hochgeladen, nicht dass dann doch noch in der Entfernung was durcheinander kommt.
Laut dem “Nachbarn” gibt ja immer noch Probleme, dann war das auch gut so.
Gruß
Danfost
Sorry, da habe ich mich verguckt. Entschuldigung.
Ein Kreisverkehr ist jetzt aber auch oberste Schublade und selbst mit JOSM nur mit pt_assistant Erweiterung als Funktion erhältlich. Ob da dann alle Routen-Relationen und auch TMC richtig abgehandelt werden habe ich noch nicht intensiv geprüft. Da ist meine Empfehlung, im Zweifel Mut zur Lücke zu haben und den Kreisverkehr ohne Mitgliedschaften in Relationen einzutragen, wenn es separate Ein- und Ausfahrten gibt. Ansonsten sollte es kein Problem geben, so lange der Kreisverkehr nicht in mehrere Objekte zerlegt wird.
Was andere Fehlleistungen, wie das komplette Umwürfeln bei Schleifen angeht, habe ich auch kein Plan, ob das schon korrigiert wurde.
Das größte Problem in Bezug auf Bus-Relationen war das Umwürfeln auf freier Strecke, aber da ist PTNA die letzten Tage recht still geworden.
Ja, in Bezug auf PTv2 ist es recht leise geworden. Bei anderen Routen, besonders mit backward und forward Rollen bin ich mir da noch nicht so sicher. Bei den Problemen mit Schleifen ist das Reparieren allerdings noch um einiges aufwendiger und ich komme eigentlich selten ohne Zurücksetzten aus.
Aus berichtigten Lücken vermute ich:
Der Fehler scheint dadurch umschifft zu werden, dass die Routen neu durchgerechnet werden.
Dabei wird die andere Schwäche von iD, die fehlerbehafteten Schleifen-Berechnung, auffällig.
Ich stufe die Änderungen als Verschlimmbesserung ein.
Ja, leider, jetzt gehen dadurch mehr Relationen kaputt, z.B. https://openstreetmap.org/changeset/117584564. Dies war noch recht einfach zu reparieren, aber spätestens bei so was (https://openstreetmap.org/changeset/117535317) werden wohl etliche im Regen stehen gelassen und geübte Personen dürfen dann damit ihre Freizeit verschwenden. Schade.
Auch würfelt iD Gebäude zu Multipolygone nur mit überlappenden outer. Richtig ist building:part=* mit Umrißlinie building=*. Leider wird durch Anfänger so einiges ungewollt zerstört bzw. Fehler erzeugt. Langsam verliert man die Lust wenn SC oder iD nur teilweise etwas einträgt und bestehende Daten nicht beachtet. SC trägt ein Gebäude über einen Zaun ein. Nur Nachräumen - die Neuen müssten erst mal Qualitätssicherung in Ihrem Gebiet beheben. Leider mehrmals “umsonst” hingewiesen.
https://wiki.openstreetmap.org/wiki/File:Multipolygon_Fehler_durch_iD.jpg
