Marc, ça marche aussi avec JOSM, mais peut-être tu as essayė de trouver l'erreur quand l'erreur était déjà corrigée ?
Toni

Oops, und dann werden wir (ich) uns wohl noch um den 361er Bus kümmern müssen. Mal schauen, was der MVV hierzu in den März-Fahrplandaten (GTFS) rausspuckt.

changeset/179080656#map=18/47.875469/11.706925&layers=T

https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#bus_361

Ich werde opening_date mal in end_date = 2026-11-01 (im ISO-Format) ändern und start_date = 2026-03-02 hinzufügen.

Servus und Danke für den Eintrag.

Das 'landuse' ist auf der Karte ganz 'nett' anzuschauen, hat aber auf "Navis" keine Auswirkungen.

Da die Baustelle recht langzeitig ist, ist die allgemeine Vorgehensweise, die Straße "B 13" auf highway=construction zu setzen und zusätzlich construction=primary (der derzeitige Wert von highway) zu verwenden. Das wird von Navis verstanden und auf den Karten auch entsprechend angezeigt.

Eine kurzzeitige Sperrung wird mit einem 'conditional' gemapped, das verstehen viele Navis mittlerweile auch.

access:conditional = no @ (2026 Mar 30-2026 Apr 13) auf kurzen Stücken der Straßen um die Kriege-Kreuzung herum.

Bei weiteren Fragen bitte einfach melden

Viele Grüße
Toni aus Ottobrunn

Ähm, das war Bus 451.

Oops: fence%20type=*?uselang=en#Values

Servus,

meinst du mit 'wire_mesh' eventuell 'chain_link'?

fence%20type=*?uselang=en#Values

Gruß,
Toni

Servus,

Google Earth und Google Maps sind für OSm tabu, das sind keine legalen Quellen für uns.

Bitte den Changeset rückgängig machen.

Gruß
Toni

Yep, zumal im Park Fahrräder noch nicht einmal schieben darf.

Hello Ismael David,

the 'check_date' value should be specified in ISO 8601 format: YYYY-MM-DD.

See also https://ptna.openstreetmap.de/results/BO/C/BO-C-Cochabamba-Analysis.html

Best regards,
Toni

Hallo,

hier, in diesem CS, hast du in der relation/2513344

- Bus N22: Alt-Lübars => Tegelort (2513344)

alle Stops, Platforms und Ways gelöscht. Die Relation hat keine 'member', was prinzipiell bei einer Relation nicht vorkommen darf

Kannst Du bitte die 301 'member' der Version 124 dieser Relation relation/2513344/history/124 wieder einfügen, die Relation in den Stand "124 " versetzen. Ein kompletter "revert" dieses CS wäre mit "Kanonen auf Spatzen schießen"

JOSM hat wohl ein "revert CS" Plugin, damit habe ich aber bisher nur komplette CS revertiert.

"CS" = ChangeSet"

Gruß
Toni

Fertig.

> So wie ich es sehe müssten also die 10 relevanten Relationen von way/1126917034 nach relation/20067580 verschoben werden,

Im Prinzip ja. In der OSM-Struktur ist der Way way/1126917034 derzeit Mitglied ('member') der 10 Relationen und müsste aus der Liste er Mitglieder der 10 Relationen herausgenommen werden und (!) an der selben Stelle der Mitgliederliste durch die Relation relation/20067580 ersetzt werden - und hier patzt iD.

Der bessere Editor ist JOSM (josm.openstreetmap.de), gerade für Relationen sehr zu empfehlen. Das ist ein JAVA-basiertes Programm, das auf dem PC läuft. Hat leider eine gewisse Lernkurve, auf Dauer aber das deutlich bessere Werkzeug.

Da ich nun weiß, was geändert wurde, warum und dass es notwendig war, ... kann ich die 10 Änderungen machen - in JOSM

Gruß
Toni

Hallo maxi_,

bei dem Edit sind am Bahnsteig Way way/1126917034 leider alle Informationen verloren gegangen, vergleiche bitte die vorangegangene Version way/1126917034/history/21

Dadurch kommt es zu Problemen mit S-Bahn-Routen-Relationen, z.B. S 1 Leuchtenbergring => Flughafen München https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#train_S1

Sind die Infos komplette verschwunden, oder was ist dort passiert?

Könntest Du bitte die betroffenen S-Bahn-Routen-Relationen S1, S2, S3, S4, S5, S6, S8reparieren oder die Infos am Bahnsteig wieder herstellen oder sagen, wohin die Informationen "gewandert" sind?

N.B. achte beim Reparieren der S-Bahn-Routen-Relationen bitte auf die korrekte Reihenfolge der Relationsmitglieder: "iD", der Editor im Browser ist da manchmal eigenwillig, für solche Relationen eigentlich nicht geeignet.

Viele Grüße
Toni

sorry, typos:

... life-cycle prefixes zu nutzen. Die Route verschwindet ...

Servus,

es wäre günstiger, statt "delete" in 'name' die sogenannten life-cacle prefixes zu nutzen. Die Route verschwindert dadurch von den Karten, taucht aber in PTNA noch im entsprechenden Abschnitt auf - man kann sie also einfach finden.

https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#life-cycle-prefix

Hier bietet sich der Präfix 'suspended' an.

Gruß
Toni

Hi,

Wenn die Bahnsteigkante oder die Bushaltestelle 'member' einer PTv2-Relation ist, ist 'public_transport' = 'platform' oder = 'stop_position' gefordert.

Eigentlich müsste man den gesamten Changeset rückgängig machen.

Gruß
Toni

Servus und willkommen bei OSM

Ein kleiner Tipp:
In OSM werden alle Namen ausgeschrieben, keine Abkürzungen:

addr:street=Kirchenstr

sollte

addr:street=Kirchenstraße

sein

Gruß
Toni

Gracias, Leonardo.

Los datos de OSM no son correctos sin los cambios mencionados en las relaciones route_master.

Puedo modificar la lista CSV en la wiki de OSM si lo deseáis.

Saludos también a los Trufistas y a Christoph,
Toni

Details und Alignments im Umfeld "Bahnhof Asperg (Landkreis Ludwigsburg)" im Rahmen der NVBW-Mappingaktion