PS: iD zeigt die Relationselemente und ihre Reihenfolge an, ich habe jedoch keine Hilfestellung bei Sortieren gesehen.

Korrektur: hier ging es um changeset/101411114 - der wurde revertiert

Hi, ich sehe, dass du erst seit relativ kurzer Zeit bei OSM mitmachst. Fühle dich weiter willkommen, auch wenn dir vielleicht mal ein Missgeschick passiert. ("Wer arbeitet macht Fehler, ... nur wer nicht arbeitet macht keine").

Glück gehabt, dass der Weg nicht Teil einer Relation war (z.B. Wanderroute oder so - aber da warnt der iD (Browser-)Editor sicherlich auch).

Besser als Löschen und neu zeichnen ist immer Verschieben - da bleibt die Historie und die Mitgliedschaft in Relationen erhalten - auch wenn's diesmal keine Nebenwirkungen hatte.
Nur mal so. (historie ist immer hilfreich, wie du ja an anderer Stelle gesehen hast)

Viel Spass beim Weitermappen!

Hallo,
du hattest - sicherlich versehentlich - mit dieser Änderung zwei Poller auf die Beusselstraße geststellt ;-)

Zu ganz gut zu sehen auf https://osmhv.openstreetmap.de/changeset.jsp?id=96325984 oder https://overpass-api.de/achavi/?changeset=96325984

Wie sich das auswirkt, weiter unten, fast am Ende. Die OSM-Daten sind ja mehr als "nur" viele Kartendarstellungen.

Also, ich habe die Poller wieder von den Enden etwas nach "innen" gerückt.

Der Weg (Übergang) muss natürlich mit den Straßen verbunden sein (zu denen auch die Fußwege an beiden Rändern gehören), aber die Poller dürfen nicht dort stehen, weil sie dann auch auf der Fahrbahn stehen - und das ist ein Routing-Problem, da wir ja bei OSM Straßen und Wege nicht als Flächen sondern als Linien modellieren (worüber sich jeder Routingsoftware sicherlich freut).

Das entstandene Problem illustriert osm.wiki/DE:Tag:barrier%3Dgate ganz gut.

Aufgefallen ist es mir, weil die Routenanalyse für die Buslinien 106 und 123 merkte, dass der Bus je nach Richtung einen der beiden Poller im Weg hat:
https://web.archive.org/web/20210401115948/https://ptna.openstreetmap.de/results/DE/BE/DE-BE-VBB-Analysis.diff.html
(Auswertung läuft allnächtlich, deshalb wirst du es auf der aktuellen Version der Seite ab morgen früh nicht mehr sehen).

Ich schicke dir noch zwei Screenshots von meinem OSMAND, der noch die alten Daten für's Routing hat.

Ja, doch stimmt:

http://osm.mapki.com/history/way.php?id=76230614

Das war deiner:
https://overpass-api.de/achavi/?changeset=94801179

und das hat @PTR-Berlin daraus gemacht: https://overpass-api.de/achavi/?changeset=96325984

(der fand das wohl nicht "schön")

Sorry, ich hab's heute nacht nicht so genau gesehen, aber jetzt sehe ich, dass der Fußweg in deiner und in meiner Version aus 4 Punkten besteht, in der von PTR-Berlin nicht (siehe mapki-URL oben).

Mein Anlass war: Weil ich mir zum Vergleich zu dem Mist, den einige Mapper in Leipzig mit iD verzapfen (ohne es zu wollen oder zu merken) mal die fast überall fehlerfreien ÖPNV-Routen in Berlin anschauen wollte, stieß ich dann auf
https://ptna.openstreetmap.de/results/DE/BE/DE-BE-VBB-Analysis.diff.html#bus_106
(und genauso 123). Die Gegend kenne ich auch einigermaßen.
PS: schau dir die letzte URL mal morgen (am 2021-04-02) an - die Auswertung läuft jede Nacht.

PS: danke für https://osmhv.openstreetmap.de/changeset.jsp?id= - ist ja manchmal sogar besser als achavi.

es ging um diese beiden:
node/8165919659
node/8165919658

Hallo,
du hast 2 Poller mitten auf die beiden Fahrbahnen Beusselstraße "gestellt".
(leider nur in der Karte, also nicht verkehrsberuhingend - und der Bus 106 und 123 kommt jetzt auch nicht mehr durch ;-)
Das schafft ein Problem analog osm.wiki/DE:Tag:barrier%3Dgate

hab's mal in changeset/102084664 korrigiert.

klar, verstehe. deshalb auch route=railway und keine Stops.

das sollte lieber jemand mit mehr Ortskenntnis machen, ich hab genug mit dem Reparieren in Leipzig zu tun.

Warum hast du die Döllnitzbahn aus dem MDV herausgenommen?Die Züge fahren doch im Rahmen des MDV-Tarifs.
route=railway ist offenbar auch nicht für Linien(dienste) vorgesehen.

Durch deine "Korrektur" sind Reihenfolgen in den Linienrelationen zerstört worden: der Stop "Angerbrücke" steht jetzt bei relation/1242593 ganz am Ende, hinter allen Wegen - er muss aber am Anfang stehen für diese Relation.

Der Wegabschnitt durch die Zschochersche Str. ab Felsenkeller bis Angerbrücke steht in falscher Reihenfolge hinter allen anderen Wegabschnitten. Er muss aber hinter allen Stops (und ggf. Platforms) am Anfang des Weges stehen (für diese Richtungsrelation).

Die Position des Stops Angerbrücke musste ich auch für die Gegenrichtung relation/1227633 an die richtige Stelle bringen: als letzten der Stops vor den Wegen.

ist jetzt repariert: changeset/102065337

Die noch nicht reparierten Auswirkungen von Änderungen kann man recht gut in den entsprechenden Abschnitten von https://ptna.openstreetmap.de/results/DE/SN/DE-SN-MDV-Analysis.html sehen. Aber Vorsicht - Fehler in der Reihenfolge der Stops werden hier meist noch nicht erkannt.

Merci beaucoup pour clarifier note/2588372

Pourrais-tu peut-être repondre à note/2588372 ?

wenn du sehen willst, was mit iD passiert ist, hier am Beispiel Tram16:
Gehe zu relation/1216282/history, rolle nach unten bis zur Version #68 (das ist der Stand nach deiner Änderung)
und unter der Metadatendabelle kannst du die "Mitglieder" (members) der Relation in ihrer tatsächlichen Reihenfolge anzeigen lassen: Da folgt auf "Wilhelm-Liebknecht-Platz" "Roßplatz". Und die Haltestellen des Umleitungsweges sind am Ende angehängt.

Wenn iD soetwas beim Editieren nicht anzeigt, ist er als Editor für ÖPNV Linien-Relationen eben ungeeignet.

gut: du hast mit 2 Änderungssätzen genau ein Thema bearbeitet, das half bei der Schadensbegrenzung.

Aber der Browser-Editor "iD" hat dir (uns allen) dabei die Reihenfolge der Elemente durcheinandergewirbelt.

Ich denke, große (oder viele betroffene) public_transport- Relationen sollte man nur mit JOSM bearbeiten. Kleinere kann iD vielleicht auch, auf jeden Fall Vespucci in der aktuellen Version.

bzw. (das bleibt) https://web.archive.org/web/20210322010438/https://ptna.openstreetmap.de/results/DE/SN/DE-SN-MDV-Analysis.diff.html

so umfangreiche Änderungen, die nach 4 Wochen wieder rückgängig gemacht werden müssen, lohnen sich nicht, ich revertiere deshalb diesen und den Änderungssatz 101454204.

Bei länger andauernden Bauarbeiten ist das evtl. etwas anderes, aber trotzdem auch zu überlegen..

Sorry für die viele Arbeit, aber dabei ging auch einiges kaputt:
https://ptna.openstreetmap.de/results/DE/SN/DE-SN-MDV-Analysis.diff.html#A4.1

(zuerst hatte ich angefangen, das zu reparieren, aber sah dann, dass dies zu viel Arbeit hin & in 4 Wochen zurück machen wird)

ich werde diese Änderung und die beiden Änderungssätze "Bauarbeiten Goethestr" zurücknehmen. (die Vorgänger haben mehr Schaden als Nutzen bei den public_transport Relationene angerichtet, und die Bauarbeiten dauern in der Goethestr. nur 4..5 Wochen, das lohnt keinesfalls.

Bonsoir. Une petite question sur node/5538420882#map=19/45.82946/5.64085
As-tu vu cette station (sur la cotê du lac) en direction de Virieu-le-Grand - sur cet endroit? Moi, j'ai vu (et utilisé) l'arrêt en direction de Virieu à node/3062817812#map=19/45.82935/5.64131 en août 2014.

merci po

PS: kennst du [Vespucci](http://vespucci.io/)?

Hm, einer der typischen Nachteile von StreetComplete: man bekommt keine Übersicht über schon eingetragene Eigenschaften.
Deshalb wurdest du nach der Oberfläche nicht gefragt, sonst hättest du hier sicher auch surface=sett eingetragen wie in osm.org/browse/changeset/97211420

(liegt nicht ganz oben in der Unteren Eichstädtstr. sogar Asphalt? - bin mir nicht sicher)

Der Vorteil von StreetComplete ist natürlich, dass es versucht, alles auf den gleichen "Genauigkeitslevel" zu bringen.