Servus Steffen,

willkomme bei OSM.

Ich würde hier statt access=no eher access=customers nehmen. Zu den Öffnungszeiten hat man freien Zugang, oder? Bin selber mal dort gewesen und habe Version 1 und 2 des Weges "Bauzentrum" angelegt.

VG
Toni

> Hm, seems like I realized why there was a dedicated route=shuttle_train way.

Yeah, another reason - but still not valid reason.

I've discussed this topic with the maintainer of osm2po and I've come to the conclusion that valid transfer points from highway=* to railway=rail should be - and are - defined explicitly:

- for motor_vehicles, ...: osm.wiki/OpenRailwayMap/Tagging#Car_shuttle also tagged as public_transport=stop_position

- for bicycles and others : public_transport=stop_position on the rail, public_transport=platform next to it for the bicycles

So to have a positive (and not a never exhaustive negative) list of transfer points

Hallo jemareu,

danke für deinen vielen Beiträge bzgl. ÖPNV.

Kennst du schon PTNA und die Auswertungen für saarVV?

https://ptna.openstreetmap.de

https://ptna.openstreetmap.de/results/DE/SL/DE-SL-saarVV-Analysis.html

VG
Toni

Trigger "Baustelle", "Oneway" auf
osm.org/history#map=10/48.0593/11.7911

Die ist aber schon länger Einbahnstraße. Ich kann mich erinnern, die Museumslinie 100, den 58, 68? vor längerem angepasst zu haben.

Gruß
Toni

Usually, PTNA is configured to filter specific 'network's values. This is not the case here, so 'ARR' is not excluded.
In addition, there is no CSV list which contains all routes that exist in reality.
See the others (e.g. Amtrak), rightmost column of the US page [2] above.

I forgot to point you to the "diff":

https://ptna.openstreetmap.de/results/US/AK/US-AK-Anchorage-PTD-Analysis.diff.html#12445740

the four relations with 'ref' = 'GD' and closing the gaps

"PTv2 route: has gaps, consists of 3 segments. Gaps appear at ways: 'Whittier Branch' 8998220 ( iD , JOSM ) , 'Whittier Branch' 178863770 ( iD , JOSM )"

You can see this 'diff' in red at least until 3 AM 2023-03-29 AKDT - then the next analysis run might overwrite that.

Hi Clay,

I've seen your edit here because the fix has popped up on PTNA [1], a tool for public transport network analysis.

Together with some fellow mappers from US 'stevea', 'Mundilfari' and others I set up some analysis tasks for the US [2].

It is quite easy to add more areas.

> "Always happy to help; send me a message!"

Regards
Toni

[1] https://ptna.openstreetmap.de/

[2] https://ptna.openstreetmap.de/results/US/index.php

Danke und: deine Erinnerung täuscht dich nicht.

Eine ältere GTFS-Quelle

https://ptna.openstreetmap.de/gtfs/DE/trips.php?feed=DE-BY-MVV&release_date=2022-05-04&route_id=20-800-X-s22-3

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.