> 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

Hi,

solche Objekte haben (normalerweise) keine postalische Adresse. Woher kommt die Information '45'?

Wenn der Mülleimer tatsächlich eine Adresse hat, dann statt 'addr:' besser 'object:'.

Lustig wäre schon, wenn man an die Adresse '45' Post senden könnte, die dann gleich wieder verworfen wird.

Gruß
Toni

Servus,

vermutlich ein Versehen:

way/720628774 fehlt nun bicycle=designated.

Gruß
Toni

Hi,

this was a wrong edit.

There are two steps around there, one is leading from level 0 to level 0.5 (from west to east) and the other (longer one) from level 0 to level -1 (from west to east).

According to your edit, both end on the same level (0.5 != -1), the way from north to the south.

Please be careful with such edits without local knowledge.

Toni

Und GraphHopper kann auch access:conditional

osm.org/directions?engine=graphhopper_car&route=48.21905%2C11.68619%3B48.21062%2C11.6955#map=15/48.21074/11.67362

GraphHopper machts richtig.

> Ich habe das routing von openstreetmap.org benutzt.

Dort gibt es OSRM, Valhalla und GraphHopper

> Ich habe es gerade nochmla getestet. routing geht fröhlich durch die Baustelle.

Wie gesagt: das hängt davon ab, wie oft und wann die routing-Software sich Daten aus OSM zieht

*:conditional wirkt dann nicht, wenn das Navi das nicht versteht - Fehler im Navi, das Konzept gibt es schon lange genug. Welches Navi hast du verwendet?

*:conditional wirkt dann noch) nicht, wenn das Navi noch nicht die neuesten Daten von OSM kennt. Hier spielt das Update-Interval eine Rolle (auch beim Löschen der Baustelle).

*:conditional hat den Vorteil, dass schon beim Erfassen der Baustelle in OSM klar ist, wann die Beschränkung endet. Ein Update im Navi braucht's am Ende der Baustellenphase nicht.

> (Nach Vorgabe aus dem Wiki)

Auf welche Stelle im Wiki beziehst du dich? Eventuell sollte dort ein Update des Textes erfolgen.

Z.B. wird OsmAnd am 1.08. Daten aus OSM ziehen (ein paar Tage später zum Download anbieten), danach erst wieder am 1.9. Für OsmAnd-Nutzer (Navi) wird die Straße also mit reinem 'access' bis Anfang September als nicht nutzbar angeboten.

Hi mallok,

wir hatten hier vor ein paar Wochen schon mit "access:conditional=no @(...)" getagged, da die Sperrung nur recht kurz ist.

Jetzt, am 24. Juli ist die Sperrung nur noch 17 Tage, also kürzer als ´die ursprünglichen 6 Wochen.

Ich wir sollten hier wieder auf access:conditional statt access gehen.

Gruß
Toni

soundtrips -> round-trips

Hallo mopfattn,

könntes es sich bei deinem drinking water um den Radlerbrunnen an der selben Stelle handeln, der mit drinking_water=yes gemapped ist.
Oder gibt es dort zwei "Quellen"?

Gruß
Toni

Hallo mallok,

wie lange werden die beiden Spreen jeweils dauern:

Bei der B471, nördlich deiner Änderung dort haben wir statt highway=construction die andere, bessere Methode für kurzzeitige Sperrungen (< 2 Monate) gewählt:

access:conditional = no @ (2025 Jun 30-2025 Aug 10)

das wird von Navis verstanden und ist, bzgl. Update-Intervalle von Navis sicherer.

Bei der B471 wwrde ich da mal anpassen.

Wie steht's in Aschheim mit der Münchner Straße?

Gruß
Toni