Servus,

bist du sicher, dass der X800 bis/von Newtonstraße fährt, seit wann?

Leut heutiger Fahrplanauskunft (PDF) und GTFS-Daten (Stand 2022-12-29) geht der nur von/bis Bahnhof.

Siehe auch:

https://ptna.openstreetmap.de/gtfs/DE/trips.php?feed=DE-BY-MVV&release_date=&route_id=20-800-X-s23-2

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

VG
Toni

Thanks.

Servus,

wenn surface=asphalt, dann sollte tracktype=grade1 sein.

VG Toni aus Ottobrunn

Seems that my edit has been reverted ... for the time being hopefully.

From my perspective: be prepared that my edit will be seen as valid deletion and prepare your routing engines to work with relations and follow the discussion in the community.

Thanks, and here we are with the discussion in community

https://community.openstreetmap.org/t/route-shuttle-train-deprecation-of-13-11-year-old-never-activated-proposal/97351

route=shuttle_train versus route=train + shuttle=yes (or whatever) is a minor concern here for me as long as these tags can only be found on route-relations.

I deleted OSM ways here that were tagged with route=shuttle_train with some other tags (but not railway=track) to represent the railway tracks.
The ways had been mapped between / in parallel to the railway=track ways which already existed in OSM.

This is against the mantra "one feature, one object".

I.e. what exists in reality only once, must not be mapped by two more OSM objects, period/basta!

This applies to the Eurotunnel-Shuttle as well.

In addition, there were also two route-relations. the older, propper one, with route=train (having the tracks as members) and the newer one route=shuttle_train (with the suspicious ways as members).

In addition: routes are virtual OSM objects and must not by mapped on odes and ways but using relations. This is well established for all other public transport elements. A train carrying cars and shuttle trains fit well into the schema.

What's the difference between a shuttle train and a train?
Do shuttle_trains have only two stops? No, I guess that's not always true?

BTW: the tracks on the Hindenburgdamm between Sylt and Niebüll are also used by other trains RB*, ICE*, ...
Please refrain from adding route=shuttle_train to those tracks - that would obviously be completely wrong. tracks are tracks and trains are trains, two completely different objects in OSM and reality. Don't mix them.

Back to your question: a route-relation with route=shuttle_train versus route=train + shuttle=yes:

Once routing engines learned to make use of route-relations, the code to differentiate between the two mapping flavours is tiny - so why not take the correct one?

A shuttle train is a train with special service: route=train + some additional tags.
This would also apply for route=ferry carrying cars, bicycles, trains, ... and (!) passengers which came by foot.

BTW: would you introduce an new tagging schema (shuttle_ferry) for ferries crossing rivers (having only two stops)? No!

I'm going to start a discussion in the community and will provide the link here later.

Servus,

das Proposal ist 10 Jahre alt, gilt als "abandoned (inactiv)", wurde nie verabschiedet -> also 'nein': nicht wieder als route=shuttle_train mappen.

Mit hatten sich die Nackenhaare aufgestellt (tun sie auch noch, wenn ich mir way/180387103 anschaue).
Das widerspricht OSM-good-mapping-practice:

- etwas erfinden, um ausschließlich Routing-Engines zu befriedigen

- etwas doppelt mappen (Gleise) um nicht in Konflikt zu geraten mit den bereits gemappten railway=track wegen des route=shuttle_train.

- einen zusätzlichen einzelnen Way (als Gleis) zu mappen, wo die Gleise bereit als zweigleisige Infrastruktur existieren/gemapped sind.

Ein Zug ist ein Zug, wenn er zusätzlich auch Autos befördert bleibt er immer noch ein Zug - vom Wesen her.

service=car_shuttle, hgv=yes, good=yes, motor_car=yes, ... an einer Route-Relation wäre die Lösung gewesen. Diese Route-Relation(en) (eine pro Richtung) wären normale type=route, route=train Relationen mit den notwendigen Zusatzinformationen.

Route-Relationen sind ein probates Mittel im gesamten OSM-ÖPNV-Bereich. Warum hier davon abweichen?

Ich schlage vor, dieses Thema in der Community https://community.openstreetmap.org zu diskutieren (auf english, da es auch den Eutotunnel betrifft).
"chris66" der Author des Proposals ist dort auch aktiv, bei der Erstellung der Beitrags bitte @chris66 im Text erwähnen.

Meine Meinung:

- weg mit dem Blödsinn

- ändern der Routing-Engines Richtung Relationen: type=route, route=train (oder =ferry oder ...), motor_car=yes, bus=yes, hgv=yes, service=car_shuttle ... Dann müssten die noch nicht einmal den Unterschied zw. train und ferry und ... machen.

Gängiges Mantra: "Wir mappen nicht für die Renderer!" Wir mappen aber auch nicht für Routing-Engines.

Viele Grüße
Toni

+1 und hoffentlich kehrt hier diesbezüglich mal Ruhe ein.

Gruß
Toni

Bzgl. iD und Name des Verkehrsverbundes: wie heißt der denn wirklich? iD nimmt das aus dem sogenannte '[name suggestion index](https://github.com/osmlab/name-suggestion-index)'

Yep, iD ist eher hinderlich wenn's ums Editieren von Relationen geht.
Der macht schon mal was kaputt.

Viele Grüße
Toni

Servus Hendrik,

die Kreuzung der Ladestraße / Emsteker Straße lässt sich mMn komplett ohne Fahrspurmapping gestalten, ich sehe da kein Problem.

Mit viel es nur auf, weil dadurch einige Bus-Relationen verhunzt wurden - diese mit iD im Browser zu reparieren mach nun wirklich keine Spass: JSOM ist hier der Freund und Helfer.

lanes=1
lanes:backward=1 und turn:lanes:backward bei Einbahnstraßen? 'backward' oder 'forward' braucht's an Einbahnstraßen nicht.

Bei größeren Mittelinseln lasse ich Fahrspurmapping zu. Bei Verkehrsinseln, die den Fußgängern als Überquerungshilfe (vorm Burgerking?) dienen eher nicht, dafür gibt es am ge,einsamen Node (Straße/Fußweg) 'highway=crossing + crossing:island=yes + ...).

Warum hier Bürgersteige mit access=no versehen sind erschließt sich mir nicht. 'highway=path/footway/cycleway' braucht das nicht, bestimmte Nutzungen (motor_vehicle, ...) schließt das eh aus.

Hallo,

das Mapping am südlichen Ende der Ladestraße ist "Fahrspurmapping", welches in OSM nicht üblich ist. und "zurück gebaut" werden sollte. Die Fahrspuren sind nicht baulich getrennt.

Hier sollte ein einzelner Way gemapped werden mit entsprechenden (z.B.)

lanes=3

lanes:forward=1

lanes:backward=2

turn:lanes:forward=none

turn:lanes:backward=left|right

Siehe auch die Fehler bei den verschiedenen Busrouten, die nun z.T. gegen die Einbahnregelung fahren - aber das ist mit iD nur umständlich zu lösen. Zumal iD gerne mal die Sortierung der Busrouten durcheinander bring

https://ptna.openstreetmap.de/results/DE/NI/DE-NI-VGC-Analysis.html#bus_900

https://ptna.openstreetmap.de/results/DE/NI/DE-NI-VGC-Analysis.html#bus_930

https://ptna.openstreetmap.de/results/DE/NI/DE-NI-VGC-Analysis.html#bus_938

https://ptna.openstreetmap.de/results/DE/NI/DE-NI-VGC-Analysis.html#bus_970

https://ptna.openstreetmap.de/results/DE/NI/DE-NI-VGC-Analysis.html#bus_S90

Viele Grüße
Toni

Hmm, I can't remember, but I guess I haven't been there.

shop=online was just a guess.

Östlich der Straße gibt's den Winterweg und den Sommerweg. Die sind nicht echt parallel, aber evtl. sind die gemeint?

Servus Christian,
Danke für die Info: einleuchtend und sinnvoll.
Viele Grüße Toni Erdmann

@ Kreisel ST 2050 / DAH 3

Servus 915,

wenn das eine railway=abandonnen ist, dann können hier keine Züge fahren: route=train ist also nicht passend.

Wenn das mal eine Kursbuchstrecke war, wäre route=tracks (oder so) passender.

Gruß
Toni

wie schon woanders gelemdet: leider doch

https://ptna.openstreetmap.de/results/DE/RP/DE-RP-VRM-Analysis.html#bus_460

... zerschossen?

Servus, leider doch. Mag aber auch an iD liegen, der kann "split-of-way" mit Realtionen nicht so gut ab.

https://ptna.openstreetmap.de/results/DE/RP/DE-RP-VRM-Analysis.html#bus_460

Gruß
Toni

Hi Migel0,

has the road Am Hart way/15048043 really been downgrades from residential to footway, although some bus routes use this road?

R
Toni

Selber nachschauen hilft: Ja ab 6.3. gibt es für den 263 und 263V einen neuen Fahrplan (bis 30.4., danach einen weiteren - anderen?)