DE talk:Proposed features/Public transport schema

Andere Vorschläge

Wie steht das hier zu andere Vorschlägen wie Proposed features/Railway, nach dem wohl schon im Stuttgarter Raum viel gemacht wurde? Bei dem Proposal tut sich aber nicht mehr sehr viel... --Mueck 21:35, 8 May 2009 (UTC)

Stimmt, da tut sich nicht mehr viel, aber dennoch habe ich mir diesen Vorschlag genau angesehen und ihn zwar als ganz gut, aber in mancher Hinsicht nicht so genau durchdacht angesehen. Denn viele Tags wie priority=* oder type=*, die dort vorgeschlagen werden, sind zu wenig Aussagekräftig und mir gefällt es nicht, Informationen über die drüberfahrenden Verkehrsmittel an Schienenwege dranzuhängen, wie der Vorschlag es zum Beispiel mit metro=yes oder tram=yes vorsieht. --Oxomoa 10:34, 9 May 2009 (UTC)

priority = primary/secondary orientiert sich an die deutsche Einteilung Haupt-/Nebenbahn, das sollte man einbauen

type ist in der tat nicht so tauglich... s.u.

Für welche Zugarten eine Strecke zugelassen oder konzipiert ist, kann man durchaus an die Strecke hängen. Sooo schnell ändern sich auch aktuelle Nutzungen nicht... maximal 2x im Jahr, eher weniger, wenn das zu oft ist, dürften auch Tempolimits nicht rein ;-)

--Mueck 00:03, 14 May 2009 (UTC)

S-Bahnen

Schon öfters heiß diskutiert... War mal eine Zeit lang ein Übersetzungsfehler in DE:Map_Features light_rail = S-Bahn Ich bin nach wie vor der Meinung, dass weitgehend eigenständig genutzte S-Bahn-Netze (Hamburg + Berlin eh mit eigenem Stromsystem, aber auch bspw. Stuttgart und Teile des Frankfurter Netzes) irgendwie separat getaggt gehören zur Unterscheidung zu Mischverkehrsstrecken (S-Bahn RheinNeckar etc.), auch wenn auf der S-Bahn-Strecke sehr vereinzelt andere Züge fahren (Auf der Rodgau-S1 mal ein Dampfzug, auf der Dietzenbacher S2 sporadische Bananengüterzüge, wenn's die noch gibt...) --Mueck 21:35, 8 May 2009 (UTC)

Da würde ich eher zur Eignung der Strecke als Kriterium tendieren: Wenn Eisenbahnen auf ihr verkehren können, dann sollte immer railway=rail verwendet werden – das erspart uns außerdem eine eigene Kategorie für S-Bahnen, wie etwa railway=commuter. --Oxomoa 10:34, 9 May 2009 (UTC)

Nun ja... Da auf reinen S-Bahn-Strecken oft etwas andere Planungsparameter verwendet werden, kann es durchaus zu besonderen Eignungen kommen. Eisenbahnfans geben oft unterschiedliche Antworten, ob ein ICE oder jeder Güterzug über eine S-Bahn-Strecke fahren könnte, ohne an Hochbahnstiege anzuecken... Aus dem path-tag habe ich mal "designated" aufgegriffen... --Mueck 00:05, 14 May 2009 (UTC)

Verbünde

Als ich heute die S5 nach Westen erweitern wollte, deren Relation bisher in Pforzheim endete, geriet ich ins Stutzen, weil in der Relation auch der KVV angegeben war als network oder so, die S5 aber diesen weit hinter sich lässt (wie auch die S4 etc.). Ist hier zum Glück nicht mit drin in der Def. der Linienrelation, aber in der Verbundrelation wird auch von Linien geredet... Knifflig... --Mueck 21:35, 8 May 2009 (UTC)

Ja! Das ist wahrlich knifflig, denn oft liegt wirklich nur ein Teil von Linien in einem Verbund, der andere Teil dann in einem anderen. Ich habe mir aber gedacht, dass man mit den Halten, die in einem Verbund liegen, dessen Liniennetz quasi "ausstanzen" kann, die Linien also zum Beispiel bei der Visualisierung des Verbundes an den Halten enden lässt, die den Verbund begrenzen. --Oxomoa 10:34, 9 May 2009 (UTC)

Immer noch unlogisches drin im System

Habe mir beides (Oxomoa hier und "Stuttgart" nach der umgesetzten Region) eben mal genauer angeschaut und irgendwie ist immer noch Kuddelmuddel drin...

Oxomoa:

Im EBO-Bereich wird alles über einen Kamm geschert (nur railway=rail), im BOStrab wird differenziert (railway=tram/subway/funicular/light_rail), wobei light_rail nicht eindeutig BOStrab/EBO zuordbar ist und "ländlicher Raum: ohne Eisenbahnverkehr" ist auch verwirrend...

Antriebsart mal im Haupttag (railway=funicular), mal in Zusatztag (traction=cable)

Klassifizierung (usage=main/branch) vermuddelt mit Zugnutzung (usage=tourism/industrial/military)

"Stuttgart":

Etwas klarer, nur railway=rail erstmal für alles, allerdings noch mit Vermischung mit Antriebsart (rack, funicular)

type unvollständig

Klassifizierung mit priority klar

Zugarten halbwegs klar mit Fragezeichen

Vielleicht sollte man versuchen besser zu strukturieren ... mal was vorschlagen: (mir fehlende englische Wörter nicht rausgesucht, sondern deutsche verwendet)

Fahrweg:

Grundaufbau:

railway = rail / monorail ( / Transrapid? / rollercoaster? / ...)

highway = bus_guideway / conveyor / steps(+escalator=yes)

Antriebsart:

traction = Adhäsion (Antrieb durch Rad direkt auf Schiene) / rack (Zahnrad) / cable (Unterflurkabel San Francisco) / Standseilbahn (funicular auch hier als value?) Default: Adhäsion

Spurweite:

gauge = ... (Dreischienengleise etc. beachten!)

scale = ... Für Modellbetriebe zum Anschauen oder tw. auch mitfahren, s.u. für Bsp.

Stromzuführung:

electrified = yes/no / contact_line / rail ( / plus paar Spezialitäten vorwiegend aus Frankreich wie Bodenplatten, Induktion, ...) ( / Akku? zur Überbrückung kurzer Strecken wie in Frankreich tw. ) ( / trolley ? zweipolig ? ...)

Stromart:

... = alternating / direct / 3phase

Volt:

voltage = ...

Zustand:

planned/construction/.../disused/abandoned/...

Klassifizierung:

class = main (primary?) / branch (secondary?) / yard (Betriebshof?) / service (Betriebstrecke?) / ... / siding / ...

Gleiszahl:

detail = track / line ? (wie bei "Stuttgart")

tracks = ...

Rechtsstatus bzw. Planungsparameter für Länder, wo nicht so unterschieden wird:

mode ?? = heavy (Vollbahn, EBO, großzügige Kurven, ... ) / light (Trams und Metros, BOStrab, enge Kurven, ...)

siehe auch unten:

light_rail = never für mode = heavy auf Schnellfahrstrecken möglich

heavy_rail = never für mode = heavy (Albtalbahn im EBO-Bereich Albtalbf - Ettlingen-Stadt) möglich

heavy_rail = sporadic für mode = light (Gerwigstraße) möglich

Kurven = weit (Vollbahn) / eng (Trams) / ... m

way = independant (völlig unabhängig: monorail, tw. Vollbahn, subway) / on_highway (Mischverkehr tram, vereinzelt auch Vollbahn) / ??? (eigener Gleiskörper mit Kreuzungen: Vollbahn, Stadtbahn)

Sowie:

ref = ... (verschiedene Numerierungssysteme beachten! intern, Kursbuch, ...)

name =

maxspeed =

Gewichtsbegrenzungen, Achslasten, ...

Lichtraumprofil

oneway = ... (Straßenbahnwendeschleifen etc.)

operator = ... (AVG, VBK, DB Netz, ... )

owner = ... (bei AVG-Pachtstrecken bspw.)

einiges in Streckenrelationen auslagerbar???

Betrieb:

praktizierte Zugarten:

commuting (S-Bahnen) = yes (im Mischverkehr wie RheinNeckar) / designated (für reinen Verkehr optimiert wie S, tw. F) / sporadic (gelegentlich) / service (Betriebsfahrten) / no / never (technisch/rechtlich nicht möglich, Bsp. s.o.)

heavy_rail (Vollbahnzüge aller Art) = yes / ...

fast_train (HGV) = yes / designated / ...

light_rail (Stadtbahnen) = yes / ...

tram (Straßenbahnen) = yes / ...

subway (reine U-Bahnen) = yes / ...

praktizierte Transportarten:

passengers = yes / designated (für alle Tramsysteme, S-Bahnstrecken etc.) / ...

goods = yes / designated (für reine Industriebahnen) / sporadic / ...

besondere Betriebsarten:

tourism = yes / no (In Alb- und Murgtal fahren Dampfzüge auch auf Nichtmuseumsbahnstrecken) (von A nach B)

show = yes / no (in KA Schlossgartenbahn und diese: nur 1 Bahnhof, letztere: scale = ... )

Draisinenbetrieb = yes / no

Linienrelation:

ref = ...

operator = ... (AVG, VBK, S-Bahn RheinNeckar, DB Regio, ... gemeinsame Linien beachten! (S5: AVG+DB) beachten: S2 operator-Strecke tw. AVG, operator-Linie VBK )

Zugart = passenger? (normaler Personenzug wie Regionalbahn, D-Zug, Regionalexpress, ...) / Fernverkehr? / Nahverkehr? / goods / fast_train (IC, ICE) / commuting / light_rail / tram / subway / ...

Betriebsstoff = Strom / Öl/ Kohle / ... / Einsystem/Zweisystem (2x Strom oder Diesel/Strom (Nordhausen) ) / ...

bevorzugte Baureihe = ET423; ET420

Betriebszeiten?

...

---> angefahrene Haltestellen ( role = end / sporadic / ... )

---> befahrene railways

Verbundrelation:

operator = ... (KVV)

---> angefahrene Haltestelle ( role = originär dem KVV zugehörig / Übergangstarif / ... )

---> Linienabschnitte ( ... )

railway=tram wäre dann eine (veraltete) Abk. für:

railway=rail

mode=light

electrified=contact_line

passengers=designated

tram=designated

etc. --Mueck 00:03, 14 May 2009 (UTC)

Rolltreppen und Fahrsteige

Unter Escalator sind bereits Fahrsteige als Highway=speedwalk vorgeschlagen. Escalator=yes reicht nicht, da es in Bahnhöfen und U-Bahn-Schächten oft Rolltreppen rauf und runter an verschiedenen Eingängen gibt, da braucht das Routing die Richtung. --Lulu-Ann 08:04, 19 May 2009 (UTC)

Stimmt, und zwar gleich doppelt - man muss wissen, ob die Rolltreppe aufwärts oder abwärts geht (oder zeit- oder bedarfsgesteuert ist), ferner aber auch, welches der beiden Enden des Ways "oben" und welches "unten" ist! --Frederik Ramm 12:42, 19 May 2009 (UTC)

Zudem fände ich highway=escalator sinnvoller, da eine Rolltreppe (zumindest wenn sie in Betrieb ist) nur in einer Richtung benutzt werden kann. Wird also highway=steps benutzt und escalator=yes nicht beachtet, dann sieht es wie eine normale Treppe aus. Bei einem eigenen highway-Tag ist aber automatisch klar, dass man nach weiteren Tags für die Richtungen schauen sollte, es ist also weniger irreführend. --Driver2 23:12, 8 June 2009 (UTC)

Falls eine Rolltreppe noch nicht bekannt ist, finde ich, daß eine Treppe eine bessere Annäherung an die Wahrheit ist als eine fehlende Verbindung. --Lulu-Ann 16:26, 10 June 2009 (UTC)

Zugangsstellen

Zugangsstellen werden hier einfach neu definiert, obwohl es ein funktionierendes System gibt. Hier fehlt mir die sonst benutzte Gegenüberstellung zum bisherigen System. Siehe auch stop_area.

--Lulu-Ann 08:06, 19 May 2009 (UTC)

Wie wird ein Zugang zur U-Bahn vorgeschlagen, der ein Fahrstuhl ist? --Lulu-Ann 08:08, 19 May 2009 (UTC)

Barrierefreiheit

Bitte nicht nur an die Rollstuhlfahrer denken, sondern auch die Tags für Blinde und Sehgeschädigte aufnehmen, z.B. tactile paving, siehe Category:Visual Impairment.

--Lulu-Ann 08:12, 19 May 2009 (UTC)

Toilet yes/no reicht nicht, die Position muß genau bestimmt werden und die Eintragung als amenity erfolgen (Soll mal einer sagen, das wäre kein Ziel, das man gezielt aufsucht). Nur dann sind erweiterte Tags für Barrierefreiheit anbringbar. --Lulu-Ann 08:14, 19 May 2009 (UTC)

Toilet yes/no, wie auch die anderen Dinge, sollen ein detailliertes Tagging nicht ersetzen, sie sollen aber ermöglichen, dass man diese Informationen festhält, auch wenn man keine Zeit oder Gelegenheit hat, den exakten Ort der Toilette (des Mülleimers, des Fahrkartenautomaten, ...) zu vermessen, z.B. weil man nur im Zug vorbeifährt oder aus Erinnerung weiss, dass dort eine Toilette ist. In diesem Fall ist - auch für den Blinden! - die Information "dort ist eine Toilette, aber wir wissen nicht, wo genau" besser als eine nicht gemappte Toilette... man sollte aber evtl. genauer dazuschreiben, dass alle diese Objekte auch exakt gemappt werden koennen. --Frederik Ramm 12:37, 19 May 2009 (UTC)

Gesamthalt Gruppe

Auch hier fehlt mir wieder die Gegenüberstellung zum alten Modell mit Relation type=site, site=stop_area. --Lulu-Ann 08:22, 19 May 2009 (UTC)

Das mit dem "site" ist m.E. nicht passend. Das kann man für ein abgeschlossenes und evtl. sogar zugangsbeschränktes Gebiet nehmen. Nach meiner Interpretation ist "site" exklusiv - ein Quadratmeter Boden kann entweder zur einen oder anderen site gehoeren, aber nicht zu mehreren. Site ist sowas wie ein Uni-Campus oder eine Grossbaustelle oder ein Gebaeudekomplex oder Firmengelaende. Im Gegensatz dazu ist die "stop area" als Zusammenfassung z.B. gegenüberliegender Bushalte durchaus nicht exklusiv zu anderen "sites" (eine stop area koennte sich räumlich auf dem Gebiet einer "site"-Relation befinden, z.B. auf einem Uni-Campus). My €.02... --Frederik Ramm 12:18, 19 May 2009 (UTC)

Rendering / Stop-Schild

In "Beispiele für das Modell" wird das Stop-Schild benutzt, um einen Halt darzustellen. Das finde ich falsch und irritierend, es hat mit einer Haltestelle nichts zu tun. Mir fehlt ein Beispiel, wie das Modell aussieht, wenn die Haltestellen zu einem Halt nicht gegenüber sondern weit auseinander liegen. Außerdem ist das Rendering mit Busbuchten oft falsch, gerade bei Neubauten wird zur Verkehrsberuhigung sogar das Gegenteil, eine Verengung der Fahrbahn an der Haltestelle gebaut (Wolfsburg/Käsdorf). --Lulu-Ann 08:21, 19 May 2009 (UTC)

Es wäre toll, wenn sich jemand der einen entsprechenden SVN-Account hat um ein Basis-Rendering der Zugangspunkte in den "Publikumsrenderer" Mapnik und Osmarender kümmern könnte.

Mir würde vorschweben:

Zoomstufe 17/18

bei punktförmiger platform (public_transport: platform, bus: yes) => Bus-Icon wie bisher oder ggf. auch, Haltestellensymobl bei traffic_sign: DE:224

bei linienförmiger platform: dezente Linie

für die Halteposition (public_transport: stop_position) => Punkt mit Rand auf Fahrbahn

aus der Gesamthalt-Relation (public_transport = stop_area , name = XXX) => Name der Gesamthalt-Relation aus dem Bereich an/über die Haltestelle schreiben.

In Zoomstufe 16 könnte ich mir vorstellen nur stop_position und name anzuzeigen.

Auf Vorschläge für andere Haltestellenarten halte ich mich erst mal raus. Davon habe ich noch nicht genügend umgesetzt um da eine Meinung zu zu haben. Das Linienrendering wird vermutlich eh eine Anwendung von Spezialrenderern bleiben. Und das macht Melchior ja ganz gut.

--Langerweher 04:20, 25 July 2009 (UTC)

Fahrstühle

Auch hier gibt es bereits ein Proposal elevator. Das Wheelchair=yes dürfte ja wohl klar sein und muß nicht getaggt werden. Wichtiger einzutragen sind Hilfen für Blinde wie Braillebeschriftung oder erhabene Druckbuchstaben auf den Tasten und Leitstreifen am Boden zum Fahrstuhl hin, sowie Sprachansagen der Etage. Siehe auch OSM for the blind --Lulu-Ann 16:27, 10 June 2009 (UTC)

Linien from / to

Was soll denn da als Text eingetragen werden ? Hannover / Wunstorf oder Hannover/ZOB / Wunstorf/ZOB? Oder gar ZOB/ZOB ? --Lulu-Ann 08:30, 19 May 2009 (UTC)

Faustregel: "Was am Fahrzeug vorne dran steht". --Frederik Ramm 11:25, 19 May 2009 (UTC)

Ich finde die Aufnahme einzelner Linienvarianten ziemlich mutig. In einem städtischen Verkehr ist das sicherlich sinnvoll, aber im regionalen Busverkehr? Ich verweise mal auf diese regionale Linientabelle: (RVF 7200.2). Sie hat nicht gerade wenige Varianten und eine Hauptlinie ist so nicht aus der Tabelle ersichtlich. Und das ist nicht das einzige Beispiel aus dem Regioverkehrsverbund Freiburg. Man kommt da, wenn man sich die Kursbuchtabellen zu Gemüte führt, bei manchen Linien recht schnell auf über 50 Linienvarianten - und da sind Teleskoplinien bereits außen vor. Und zum Fahrplanwechsel gibt's dann alljährlich wieder neue Linienvarianten und vorhandene werden dafür aufgegeben. Die unterschiedlichen Linienverläufe aus den Kursbüchern zu erschließen, wenn Haltestellen am Ende auch noch in umgekehrter Reihung dargestellt werden ist eine sicherlich abendfüllende Tätigkeit, und es stellt sich die Frage, für was und vor allem für wen. Wo ist der Mehrwert, die Kursbuchlinien manuell so detailliert in OSM eintragen zu wollen, dass man sogar einzelne Linienvarianten dabei herausziehen kann? --Q un go 23:43, 29 June 2009 (UTC)

Kombiniertes Fußgänger + Öffentliche Verkehrstmitte-Routing für Blinde und Sehgeschädigte Lulu-Ann

Linienfarbe

"Linienfarbe als benannte Farbe oder Webfarbe im Hexadezimalformat" für die beiden Varianten brauchen wir verschiedene Keys. Ein Blinder kann wohl kaum jemanden fragen, wo die FF14A3-Farbene Linie abfährt... --Lulu-Ann 08:33, 19 May 2009 (UTC)

Würde ein Blinder nicht eher fragen, wo die Linie "S2" abfährt? Ich bin gegen verschiedene Tags für Hex- und Sprachfarbe; dort, wo die Farbe das identifizierende Merkaml ist (wenn also mal gar keine "S2" gibt, sondern nur die "Linie Blau"), gehört das "Blau" doch eher in "ref", oder? --Frederik Ramm 11:24, 19 May 2009 (UTC)

Entweder wollen wir das zum Rendern benutzen, dann nehmen wir Hexwert und *englischen* Farbnamen aus der HTML-Liste ins gleiche Feld, oder wir wollen es als Namen, dann gehört es in Ref, da stimme ich zu. Auf jeden Fall sehe ich keinen Grund eine nicht-englische Farbbezeichnung mit einem Hexwert ins gleiche Feld zu schreiben, dann ändern uns die Blinden das wieder raus und lachen sich über uns Guckis schlapp. --Lulu-Ann 16:32, 19 May 2009 (UTC)

type=?

Bis jetzt war es so, dass alle Relationen ein type= gesetzt haben. Wie soll das hier gehandhabt werden? type=public_transport für Gesamthalt- und Gesamthaltgruppen-Relationen, type=line bei Linien, type=???? bei Linienvarianten? Oder überall type=public_transport und dann über public_transport=(stop_area|stop_area_group|line|???) weiter differenzieren? --UncleOwen 20:56, 23 May 2009 (UTC)

Das Tag type=* wird eigentlich nicht benötigt, da es keinen Zugewinn an Informationen bringt: Beispielsweise lassen sich alle Informationen, die in den beiden Attributen type=public_transport und public_transport=stop_area stecken, auch einfach mit dem Tag public_transport=stop_area allein ausdrücken. --Oxomoa 06:37, 25 May 2009 (UTC)

Ok. Aber ist das Grund genug, eine funktionierende Konvention über den Haufen zu werfen? JOSM benutzt das type-tag z.B., um die Relationen in der Übersicht danach zu sortieren. Gerade in sehr stark gemappten Städten (und davon reden wir hier ja) würd ich sonst kaum eine Relation wiederfinden. Auch [1] meckert Relationen ohne type=* an. Ja, das könnte der keepright-Maintainer ändern. Sollte er aber IMHO nicht müssen. --UncleOwen 19:56, 26 May 2009 (UTC)

Also aufs type= steh ichs mir nicht unbedingt. Was ich aber nicht versteh, warum "line=tram/bus" verwendet wird und nicht wie bisher "route=tram/bus". -- Skunk 13:42, 26 June 2009 (UTC)

Ich bin für maximale Kompatibilität mit bisherigem Guten. Daher bitte Type lassen, und route=bus sollte auch bleiben. --Lulu-Ann 23:20, 26 June 2009 (UTC)

Nochmalige Nachfrage: Werden die Relationen für Linie und Linienvariante mit einem type=* versehen? Und ja welchem? Gibt es in den Relationen für Linienvariante auch ein kenzeichnenden Tag außer from=*, to=* & alternate=yes oder alternate=no? --Josef73 06:33, 31 July 2010 (UTC)

Die Unterscheidung Linie / Linienvariante ist unnötig. Eine Linienvariante im Datenmodell erkennt man einfach daran, dass sie eine Elternrelation mit line=* besitzt, besser noch ausschließlich type=line statt line=*, da das konkrete Verkehrsmittel nicht immer für den Betrieb der Linie bindend ist (man denke an SEV), das konkrete Verkehrsmittel (line=*) sollte damit in der Variante zur Linie erfasst werden. Prinzipiell sollte eine Linienvariante genauso getaggt werden dürfen, wie eine Linie, also zusätzlich (nicht ausschließlich) mit from=* und to=* tags versehen. --Cmuelle8 01:26, 11 October 2010 (BST)

IMHO sollte die Aggregation der Varianten einer Linie optional sein - jede Variante sollte für sich alleine stehen können und immer ein Mindestmaß an Informationen enthalten (ref=*, name=*, line=*, color=*, etc.), um auch ohne den Relationsbaum zu traversieren, nutzbar zu sein (das gilt für Humans+Software). Momentan werden alle wichtigen und interessanten tags im Proposal in der aggregierenden Relation erfasst - das vermeidet zwar Redundanz, ist aber sehr unpraktisch. Weiterhin wird es damit notwendig, immer eine aggregierende Relation zu erstellen, auch wenn z.B. erst eine Variation einer Linie erfasst wurde. Besser ist es, die tags, die Oxomoa für die Linie angibt, größtenteils schon in den einzelnen Relationen der Variationen zu einer Linie zu verwenden (auch falls es dort Dopplungen gibt) und in der aggregierenden Relation ein minimales Set an tags zu verwenden (z.B. nur name=*, ref=*, type=line, operator=* und network=*). Auf diese Weise ist es dann z.B. auch möglich, Schienenersatzverkehr einer Tramlinie vernünftig zu erfassen. --Cmuelle8 01:42, 11 October 2010 (BST)

Für mich ist klar, ich werde nicht mit alten Standarts brechen. Dazu gehören 1. dass eine Relation immer ein type-Tag haben muss (also wird eine Haltestelle mit type=public_transport getaggt) und 2. dass eine Buslinie mit type=route getaggt wird. Das hinzufügen des type=public_transport bei Haltestellen tut dem ÖPNV-Schema nicht weh. Ein Ändern von type=route in type=line bringt nur bestehende Software durcheinander. --Teddych 19:54, 16 October 2010 (BST)

Nachtverkehr nur am Wochenende

Wie würdet ihr das taggen? by_night=Fr,Sa? --UncleOwen 20:59, 23 May 2009 (UTC)

• by_night ist nur schwammig definiert! Wann ist eigentlich Nacht und was genau passiert da?
• by_night ist Teil des Fahrplans und sollte deshalb besser gar nicht getagged werden!

Welche Anwendung könnte diesen Tag sinnvoll auswerten?

Besser wäre es einfach opening_hours=* zu verwenden! --Phobie 12:56, 1 June 2009 (UTC)

Nein, das ist eben nicht besser, weil opening_hours=* an sich schon nicht so toll ist und für Fahrpläne und dessen meist hoch redundante Informationen ungeeignet ist. Da sollte man besser so etwas wie "service_times=Mo-Fr (2-6:10,30,50;7-16:15,30,45);!Su", "first=Mo-Fr 6:10" "last=Mo-Fr 16:30", "max_maininterval=20" stop_times=0,2,5,6,8+10,20,25 (für Mo-Fr 2-6:xx Uhr immer x:10,30,50 Uhr und 7-16 Uhr immer x:15 Uhr, x:30 Uhr und x:45 Uhr, wobei um 16:30 Uhr die letzte Fahrt stattfindet und Sonntag die Linie gar nicht verkehrt, die Ankunftszeiten an den Haltestellen sind z.B. für die Fahrt um 6:10 ab der Starthaltestelle, dann 6:12, 6:15. 6:16, 6:18 Ankunft mit 10 Minuten Aufenthalt, 6:30 und 6:35 Uhr). Das nur mal als erstes Beispiel für ein mögliches Schema, wobei man noch eine gute Notation für die ganzen Betriebsausnahmen braucht, welche besser (allgemeingültiger, also und für mehr Fälle) sein sollte als die jetzigen opening_hours=*. --Fabi2 19:35, 18 April 2010 (UTC)

Reihenfolge von Linienvariantenelementen

"Für Hin- und Rückweg einer Linie wird jeweils eine eigene Relation verwendet: Dabei werden alle Haltepositionen, Zugangsstellen und Verkehrswege als Mitglieder aufgenommen. Deren Reihenfolge in der geordneten Mitgliederliste gibt dabei genau die reale Verbindung zwischen Quell- und Zielort wieder."

Das heisst für mich, ich trage die Elemente in folgender Reihenfolge ein:

HP1
Zugangsstellen zu HP1
Linienweg von HP1 zu HP2
HP2
Zugangsstellen zu HP2
Linienweg von HP2 zu HP3
...

Das widerspricht aber dem, dass man die Wege nicht auftrennen soll.

Oder wäre auch folgende Reihenfolge möglich?

HP1
HP2
...
Zugangsstellen zu HP1
Zugangsstellen zu HP2
...
Linienweg

--UncleOwen 21:07, 23 May 2009 (UTC)

Ja. -- Oxomoa 06:38, 25 May 2009 (UTC)

ich finde das auch noch etwas unklar auf der seite erklärt. heißt das im endeffekt, dass nur die richtige reihenfolge der stop positions verpflichtend und notwendig für das routing ist und die reihenfolge der restlichen elemente optional? würde ich eigentlich schon annehmen, da sich die korrekte platform für den zustieg ja aus routenrelation, stopposition-relation und haltestellenrelation ergibt. ein sehr reales problem ist nämlich wenn zB neue mapper in potlatch einen weg aufsplitten der in einer sauber angelegten relation ist. potlatch pflanzt den neuen way dann nämlich einfach an das ende der relation. -- Flaimo 09:55, 03 September 2010 (UTC)

Gibt es denn ein Programm, welches bereits über den öV routet? Auf der ÖPNV-Karte werden die Streckenabschnitte ja nur für die graphische Darstellung benötigt, daher ist dort die Reihenfolge der Strecken-Elemente egal. (Natürlich ist es zur eigenen Kontrolle im JOSM trotzdem einfacher, wenn die Strecke auch geordnet wird.) --t-i 22:13, 3 September 2010 (BST)

Carsharing-Stationen

Ich hoffe, das ist nicht zu off-topic:

Wäre es möglich, auf der Karte auch Carsharing-Stationen zu rendern? (amenity=car_sharing) Auf der Diskussionsseite gibt es auch einen Icon-Vorschlag, allerdings nicht als SVG.

http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcar_sharing http://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dcar_sharing#Voting_2

Z.B. in Heidelberg hat schon jemand einzelne Stationen eingetragen. Wenn die Stationen gerendert werden, könnte man bei den örtlichen Carsharing-Unternehmen mal nachfragen, sie die Koordinaten für OSM zur Verfügung stellen. (Es gibt auf z.B. der Carsharing-Seite von Stadtmobil schon eine Google Maps Integration, aber dort sind nat. die ÖPNV-Linien nicht drin, nur StraBa-Haltestellen.)

Auf diesem Ausschnitt gibt es eine unsichtbare Station (unterhalb der Mitte): http://www.öpnvkarte.de/?lat=49.425279&lon=8.68387&zoom=18

MichaK 07:24, 29 May 2009 (UTC)

Hier ist eine sichtbare Carsharing Station http://www.openstreetmap.org/?lat=53.566358&lon=9.98688&zoom=18&layers=B000FTF

Divjo

construction=yes und planned=yes führen zu Fehlern

Über construction=yes wurde bei Straßen schon viel diskutiert. Es besteht immer die Gefahr, dass Renderer, Router oder andere Analyseprogramme das Attribut nicht berücksichtigen.

planned=yes ist noch viel schlimmer. Es wird bislang fast nicht verwendet (laut OSMDOC nur viermal) und alle bestehenden Programme erzeugen damit falsche Daten. Der Fehler, eine nur geplante Strecke als existent anzunehmen und in Karten einzuzeichnen, ist viel größer als eine geplante Strecke zu ignorieren.

Ob disused auch in diese Gruppe gehört, kann man unterschiedlich beurteilen. Lokal betrachtet sind die Gleise sichtbar und ihr verrosteter Zustand ist nur eine Eigenschaft. Funktional betrachtet ist ein ehemaliges Gleis nicht mehr Teil des Schienennetzes und sollte in Übersichtskarten und Datenanalysen nicht berücksichtigt werden.

Das alte Scheme railway=construction, construction=rail und analog railway=planned bzw. railway=disused ist zwar etwas umständlicher einzugeben, aber dafür können die auswertenden Programme einfacher und schneller arbeiten und produzieren keine fehlerhaften Daten. --User:Seawolff 22:03, 31. Mai 2009

Es gibt noch mehr Werte bei railways (und highways), wie ich feststellte, als ich das rendering von railways nach derzeitiger Notation erneuerte:

• disused
• neben abandoned auch dismantled
• construction
• neben planned auch proposed

Werden derzeit alle in beiden Kombinationen (railway=x & x=* und railway=* x=yes) in z13-z17 unterstützt, aber ohne beim Rendern verschiedene Typen (tram ... rail) anders zu rendern. --Mueck 22:55, 31 May 2009 (UTC)

Zonen im Verkehrsverbund

Wie kann man Zonen im Verkehrsverbund darstellen?

Zum rendern ist wohl eine Polygon-Relation, wie bei anderen Grenzen, am besten. Für andere Zwecke wäre es sinnvoll jede stop_position zu Taggen. Als Key würde ich so etwas wie zone:public_transport=*, zone:tram=* und zone:bus=* nehmen. --Phobie 16:42, 4 June 2009 (UTC)

Status-Seite

Ist angedacht, ein Status-Seite ähnlich dem für Städte anzulegen oder soll nur das "State Transport"-Symbol aus der allgemeinen Auflistung verwendet werden? Ist vielleicht zu viel, aber für die Bearbeitung schon praktisch, wenn man weiß, wie weit die Linien, Haltestellen und Gleise der verschiedenen Verkehrmittel vollständig sind --DINENISO 13:28, 4 June 2009 (UTC)

Auf Kiel haben wir dafür eine separate Tabelle zusätzlich zu Template:State_Place mit dem Schlüssel tr. --Phobie 16:19, 4 June 2009 (UTC)

Eine solche Tabelle haben alle größeren Städte. Für mich stellt sich die Frage, ob dieses Thema so wichtig ist, dass es auch eine zentral verwaltete Status-Seite bekommen sollte oder durch seine begrenzten Auswirkungen wie andere Aspekte eine normale Liste geführt wird - ich tendiere inzwischen zu letzterem, aber ich würde gerne von denen, die damit schon länger arbeiten, wissen, ob das ausreichend ist, oder ob sie sich eine mit Farben und Symbolen unterstützte Seite wünschen. --DINENISO 05:36, 5 June 2009 (UTC)

Ruf-Busse

Einige Bushaltestellen im GVH Hannover werden nur nach telefonischer Anmeldung bedient. Wie soll solch eine Haltestelle eingetragen werden? --Lulu-Ann 12:09, 5 June 2009 (UTC)

Mit on_demand=*. Siehe User:Oxomoa/ÖPNV-Schema#Bus-_und_Oberleitungsbuslinien! --Phobie 17:34, 5 June 2009 (UTC)

Internationale Bahnhofsnummern-Datenbank zur Vollständigkeitsüberprüfung?

Der Wikipedia-Artikel zur Internationalen Bahnhofsnummer (IBNR) enthält einen Link auf eine IBNR-Datenbank, der allerdings keine Lizenz beigefügt ist. Hat hier jemand schonmal nachgefragt, unter welcher Lizenz diese steht? Ansonsten würde ich das mal machen.

Es ist vorstellbar, diese Datenbank dazu zu nutzen, um noch nicht erfasste ÖPNV-Halte aufzuspüren. --Dwi Secundus 09:31, 7 June 2009 (UTC)

Stop- und Access-Areas trennen

würde besonders beim Bahnverkehr die Tatsachen entwirrend. --Cbm 09:56, 15 June 2009 (UTC)

Ich halte es für sinnvoll den Relationsmitgliedern einfach eine "rule" aufzudrücken! Z.B. "stop" und "access". Das entwirrt auch und lässt uns nicht in Relationshaufen ersticken. --Phobie 13:27, 17 June 2009 (UTC)

man könnte als role Dinge wie "halt", "stop_position", "stop_area", "access-area" nutzen.--Cbm 01:33, 27 June 2009 (UTC)

Vorteil daran wäre, man fürde den Relations die Chance geben sugsessiv wachsen zu können.

Im ersten Schritt sammelt man z.B: alle halts der Strecke in der Relaton. Im nächsten Schritt kann man dann durch "stop_area" das genaue Gleis definieren wo der Zug hält. Parallel natürlich auch die entsprechende Plattform im Bahnhof mit "access_area" erfassen. UNd erst wenn mans ganz genau haben will/kann kommen die einzelnen stop_positions der Gleises. Schließlich ist ein Gleis in einem Bahnhof in beide Richtung befahr- und nutzbar. Es gibt da kein "Rechtsaussteig-gebot" wie es bei Bussen ja quasi besteht. --Cbm 13:15, 27 June 2009 (UTC)

Ja, das Verfahren hat sich als sehr nützlich herausgestellt. Die Keys und Values des ÖPNV-Schema sind zudem unnötig lang und man könnte sie wie folgt abkürzen:

• public_transport => pt
• stop_position => stop
• stop_area => area
• stop_area_group => group

Die möglichen Werte von rule=* sind dann identisch zu pt=*.

Allen Rollen darf optional eine Nummer angehängt werden um die Wartung zu vereinfachen. Z.B. rule=stop:01

Für die Route selbst sind die Rollen forward/backward/route zulässig

Anstatt jeden Wegabschnitt der Route mit rule=forward/backward zu markieren, könnte man auch einfach rule=route setzen und die Relation mit direction=forward/backward taggen.

Beispiele: 166149 166149 165027 165027

--Phobie 03:02, 3 July 2009 (UTC)

Oneway an Straßenbahngleisen?

Wird die Richtung an Straßenbahngleisen und Bahngleisen getaggt? --Lulu-Ann 11:35, 30 June 2009 (UTC)

Das Bahnnetz kennt so etwas wie "Einbahnstraße" nicht. Da sind immer alle Gleise für beide Richtung (wenigstens theoretisch) nutzbar. Ich vermute, bei Straßenbahnen ist das ähnlich. --Cbm 23:46, 30 June 2009 (UTC)

Doch, Straßenbahnen die auf der Straße verlaufen dürfen dem restlichen Verkehr sicher nicht entgegen fahren! Nur weil es keine Einbahnstraßenschilder gibt, heißt dies ja nicht, dass es keine Regeln gibt. Aber auch bei normalen Eisenbahnen gibt durchaus jede Menge Gleise, die zu 99% nur in eine Richtung befahren werden. Auch dort macht es Sinn mit oneway zu taggen. oneway=yes + oneway:special=no ;-) --Phobie 02:07, 1 July 2009 (UTC)

natürlich können dir STraßenbahnen in "Auto"-Einbahnstraßen entgegenkommen. Und nein, im Eisenbahnnetz gibts kein "oneway". Das an die Railways zu taggen wäre also mit ziemlicher Sicherheit falsch. --Cbm 11:43, 1 July 2009 (UTC)

Ohne Worte: [2] [3] [4] [5] [6] [7] [8] Ausnahme: [9] --Phobie 02:08, 2 July 2009 (UTC)

bis auf Bild5 sind das doch alles keine Einbahnstraßen, oder erkenne ich nicht, was du mit den Bildern zeigen wolltest? --Cbm 07:47, 2 July 2009 (UTC)

Es geht hier um Einbahngleise und nicht um Einbahnstraßen. Wenn auf einer zweispurigen Straße auf beiden Spuren Gleise verlegt sind, darf die Bahn natürlich nicht links fahren, auch wenn sie das theoretisch könnte und es auch keine Beschilderung für diese Tatsache gibt. --Phobie 11:05, 2 July 2009 (UTC)

Das sind alles doppelte Schienenstränge, die jeweils stets nur in eine Richtung benutzt werden. Einbahn-Gleise eben. --Lulu-Ann 10:07, 2 July 2009 (UTC)

Ja, genau! Da gibt es eigentlich gar nichts zu diskutieren. --Phobie 11:05, 2 July 2009 (UTC)

Eben doch, weil oneway=no eine relevante Ausnahme ist! Vielleicht sollte man statt einem einfachen Pfeil auf oneway-Straßenbahnen lieber einen Doppelpfeil auf oneway=no rendern. --Lulu-Ann 12:30, 3 July 2009 (UTC)

Bei Straßenbahnen wird man sich wahrscheinlich auch die Mühe machen sich dem Rechtsfahrgebot der PKWs anzupassen, um den Autofahrer nicht noch mehr zu verunsichern. Im "echten" Eisenbahnnetz gibts wie gesagt kein oneway=yes. Da können alle Gleise in jede Richtung verwendet werden. (Gut zu erkennen übrigens an Bahnhöfen, wo immer an _beiden_ Seiten Ampeln sind) --Cbm 11:54, 3 July 2009 (UTC)

Sowohl bei Straßenbahnen als auch bei der "richtigen" Eisenbahn gibt es Gleise, die nur in einer Richtung befahren werden. Zum einen gibt es Rückfallweichen, die bei Ausweichmöglichkeiten auf eingleisigen Strecken dafür sorgen, dass die Züge automatisch auf das jeweils rechte (bzw. je nach örtlicher Situation: linke) Gleis gelenkt werden. Und bei der "richtigen" Eisenbahn sind bei weitem nicht alle Strecken für Gleiswechselbetrieb ausgerüstet. Meist erkennt man diese Strecken daran, dass am nächsten Bahnhof nur eines der Gleise ein Einfahrsignal hat. Dort können zwar auch beide Gleise in beiden Richtungen genutzt werden, wobei für die Fahrt auf dem "falschen" Gleis einige zusätzliche Regeln zu beachten sind. Aber das gibt es ja auch im Straßenverkehr, so darf z.B. die Müllabfuhr (in Deutschland) auch verkehrtrum durch Einbahnstraßen fahren, vgl. § 35 Abs. StVO.

Daher halte ich es für sinnvoll, bei Gleisen, die aufgrund technischer Gegebenheiten im Regelfall nur in einer Richtung befahren werden, den oneway-Tag zu verwenden - zumindest bei der "richtigen" Eisenbahn.

Bei Straßenbahnen dürfte es meiner Meinung nach nur einen sinnvollen Anwendungsfall für oneway geben: Die Fahrtrichtung, in der Wendeschleifen - insbesondere am Ende von eingleisigen Strecken - durchfahren werden. --Streckensucher 10:39, 12 July 2009 (UTC)

du stimmst also zu, dass pauschal im Bahnhof alle Gleise oneway=yes zu taggen , nur weil an der Plattform "Richtung X" und auf der anderen Seite "Richtung Y" steht, ein falscher Ansatz ist? --Cbm 05:25, 22 July 2009 (UTC)

Nach Durchlesen dieser Diskussion würde ich sagen, man sollte als oneway taggen, was nur Signale in eine Richtung hat. --Lulu-Ann 12:03, 22 July 2009 (UTC)

Ja, darauf kommt es wohl an. Womit wir bei Straßenbahnen wohl eher ein oneway finden. Die Eisenbahnschienen sind ja meistens eh nur als Linien und nicht als einzelne Gleise eingezeichnet.--Skyper 11:38, 1 December 2009 (UTC)

Wenn sie das noch sind, dann ist das ein Fehlerzustand. --Lulu-Ann 12:20, 1 December 2009 (UTC)

In FR sind leider bis jetzt nur die Bahnhöfe spurtreu, Tram nur an den Stellen, an denen nur 1 Gleis existiert. In Stuttgart wird gerade daran gearbeitet (train), aber bei U-Bahn und Tram siehts auch hier noch schlecht aus--Skyper 15:54, 3 December 2009 (UTC)

@Streckensucher: In Frankfurt sind jetzt alle Straßenbahn- und U-Bahn-Gleisanlagen gleisgenau aufgetragen, hier würde es also definitiv Sinn machen, oneway-Tags zu vergeben, denn mindestens alle Straßenbahngleise dürfen (in zweigleisigen Streckenabschnitten und außerhalb von Wendeanlagen) nur in eine Richtung befahren werden. Baeuchle 12:31, 4 June 2010 (UTC)

Haltepositionen für längere und kürzere Straßenbahnen

In Hannover zum Beispiel gibt es stets zwei Halt-Markierungen für die Spitze der Stadtbahnen: Eine für kurze Züge ( ein Wagen ) und eine für lange Züge ( zwei Wagen ), beschriftet mit H1 und H2. Dies führt zu verschobenen Einsteigepositionen für die Türen, relevant für Blinde und die Anbringung von Leitstreifen und Aufmehrksamkeitsfeldern. Wie wird das eingetragen? --Lulu-Ann 11:35, 30 June 2009 (UTC)

Mehrere Haltepunkte sind eher die Regel als die Ausnahme. Beide Haltepunkte sollten deshlab erfasst werden, denn beide sind gültige Stop-Positions. (In Bahnhöfen gibt es sogar oft mehrere Haltepunkte an beiden Enden eines Gleises. Je nachdem aus welcher Richtung und für welchen Zug. spätestens aber bei der Ampelanlage sollte die Stop_Area aber zu Ende sein (d.h. die stop_area zwischen den Ampeln liegen). --Cbm 23:53, 30 June 2009 (UTC)

Bushaltebuchten und Engstellen an Bushaltestellen

Bis eine spurgenaue Erfassung der Straßen möglich ist wäre es denkbar die Haltepositionen der Bushaltestellen an denen der Bus in einer Haltebucht hält mit cutout=yes oder stop_position=cutout (Haltebucht) zu kennzeichnen.

Wenn die Bushaltestelle Baulich als Engstelle ausgeführt ist lässt sich das durch constriction=yes oder stop_position=constriction (Engstelle) erfassen.

Für den einfach Fall, der Bus hält auf der Fahrbahn, ist theoretisch kein zusätliches Tag nötig. --christianb 22:28, 10 July 2009

Ich habe nochmals recherchiert und weitere mögliche Tags aufgetan. Im AE Sprachgebrauch scheint wohl "turnout" der Begriff für eine Bushaltebucht zu sein. Bei den Engstellen gibt es wohl den Begriff "bus bulb". --christianb 19:16, 23 July

Das Problem habe ich auch, hatte schon überlegt ob man evtl. an die Straße dafür einen kleinen highway=service für die Haltebucht taggen sollte. Im Moment tagge ich die Haltepunkte noch auf der Wegline der Straße, obwohl ich bei vielen Haltestellen die genauen Haltebuchteinfahrten habe, --Fabi2 19:50, 18 April 2010 (UTC)

unterschiedliche Streckenführung in Abhängigkeit der Zeit

Wie soll denn die Tatsache modelliert werden, daß je nach Wochentag bzw. Zeit, die Linienführung unterschiedlich ist? OK, man erstellt dann eine Linienvariantenrelation, aber wie soll man dann die unterschiedlichen Zeiten angeben?

Praktisches Beispiel: http://www.sw-greifswald.de/verkehr/linienplan_05_2008.pdf

Da fährt z.B. die Linie 4 in Richtung ZOB je nach Tageszeit anders. Meistens fährt sie über Goethestraße (also links herum um die Innenstadt), und dann gibt es am Tag ein paar Ausnahmezeiten, da fährt die Line dann rechts um die Innenstadt heraum, also über Marienkirche.

Wenn es nur zwei verschiedene Routen sind, dann würde ich beide komplett eintragen. Kiel Linie 2 Kiel Linie 2

Bei mehr Alternativen hänge ich den Rollen der Relationsmitglieder :alternate:<Nummer> an. Das kann man gut bei der sehr komplexen Kieler Linie 100 Kieler Linie 100 sehen! Die würde nach dem ÖPNV-Schema übrigens mal locker 13 Relationen benötigen! Versuch mal die Haltestellenfahrpläne 100 vorwärts und 100 rückwärts zu lesen ;-) --Phobie 14:42, 26 July 2009 (UTC)

Ja, danke inzwischen habe ich auch mehr Erfahrung mit dem neuen Schema als noch vor einem Jahr. Die Idee mit alternate:x als role ist gut, aber ich glaube ich werde da wirklich für jede Linienvariante eine Relation erstellen, da man nur so dann noch vernüftig den Fahrplan mit integrieren (ja, ich war nicht der erste mit dieser Idee... (siehe hier und hier)) kann. Wobei diese Notation nur rudimentär und schlecht lesbar ist und man besser die Unterschiede der Betriebszeiten und die Ausnahmetage etc. eben über die Linienvarianten modellieren kann. Außerdem fehlen da so wichtige Sachen wie die extra Anführung der Anfangs- und Endbetriebszeit und das mehrheitlich gefahrenen Intervalls (dann kann man auch ungefähre Fahrzeiten für Routen berechnen, wenn der Fahrplan tatsächlich kürzlich veraltet ist (z.B. weil sich die Zeiten minimal verschoden haben) bzw. muß beim Routing nicht erst die ganze Fahrzeitentabelle aufbauen um zu sehen, ob die Haltestelle überhaupt zeitlich in Frage kommt. --Fabi2 18:57, 18 April 2010 (UTC)

Unterschied einer Halteposition und einer Zugangsstelle

Es tut mir leid, doch leider ist mir der Unterschied einer Halteposition und einer Zugangsstelle nicht ganz klar geworden. An einer Halteposition steigen doch auch Fahrgäste zu!? Dort wo ich momentan die mir bekannten Bushaltestellen eintragen möchte, gibt es verschiedene Arten von Bushaltestellen.

Gibt es eventuell ein Gebiet auf der OS-Karte auf dem die Bushaltestellen schon nach diesem neuen Schema getaggt wurden, damit ich mir das mal mir JOSM anschauen könnte um einen Überblick zu gewinnen?--Mojo Dodo 14:21, 11 September 2009 (UTC)

Eine Halteposition ist der Ort des Bahnsteigs der U-Bahn. Eine Zugangsstelle ist der Ort der Treppe, die zur U-Bahn herunter führt. Lulu-Ann

Unterirdische Verbindung von U-Bahn-Stationen

Es gibt in einigen Städten U-Bahn-Stationen, die unterirdisch miteinander verbunden sind und somit einen Umstieg ermöglichen, obwohl zwei Linien nicht die gleiche Station anfahren. Ein Beispiel hierfür sind die Haltestellen "Auber" und "Opera" in der Pariser Metro (die noch mit drei weiteren Stationen verbunden sind). Dies enstpricht, soweit ich das Schema verstanden habe, nicht dem "Gesamthalt Gruppe", da die Stationen eigenständig sind. Speziell für Routenplanung wäre es natürlich sinnvoll, eine solche Verknüpfung abbilden zu können. Gibt es hierfür schon ein Schema? --Tippfeler 16:46, 4 October 2009 (UTC)

Das gibt es auch oberirdisch, z.B. in Hannover die Bushaltestelle Sprengel-Museum hat einen kurzen Fußweg zum Fährenanleger. --Lulu-Ann 18:46, 5 October 2009 (UTC)

Oder wenn ein Bahnhof (Zürich Hauptbahnhof) mehrere Tramhaltestellen runderherum hat, von denen man umsteigen kann: Bahnhofstrasse/HB, Bahnhofplatz/HB, Bahnhofquai/HB, Sihlquai/HB. Da müsste noch eine Lösung her, wie z.B. eine Relation für Umsteigemöglichkeiten. --RalpH himself 12:51, 29 December 2009 (UTC)

Das wäre doch eigentlich die Aufgabe der Routingsoftware festzustellen, das die Haltestellen nur wenige Meter auseinander liegen und dann entsprechend den vorhandenen Fußweg zwischen x und y zu empfehlen. --Fabi2 20:04, 18 April 2010 (UTC)

Eintragen von Nahverkehrszügen

Ich arbeite eigentlich im ganzen ÖPNV-Bereich nach diesem Schema, stehe jetzt jedoch vor dem Problem, dass ich eine Regionalbahn bei uns eintragen will. Und da stellt sich mir die Frage, ob wir wirklich jede einzelne Regionalbahn eintragen soll, nur weil sie eine Stunde später fährt und damit eine andere Nummer von der Bahn bekommen hat.

Der Fall ist der folgende: Ich habe die RB 22936, die von Herrenberg über Tübingen nach Plochingen fährt. Dabei fährt sie zuerst auf der Kursbuchstrecke der Ammertalbahn (764) und dann auf der Necker-Alb-Bahn (760). Da die Strecken ja an sich nichts über die einzelnen Züge aussagen, die darauf verkehren, ist es durchaus sinnvoll die einzelnen Zugrouten einzutragen.

Das Problem ist jedoch, dass sie nicht immer die gleiche Nummer haben, wie es bei Buslinien normalerweise der Fall ist, sondern jede Fahrt eine eigene Nummer hat. So hat die Bahn, die eine Stunde früher fährt die Nummer 22934 und die eine Stunde danach die Nummer 22938. Natürlich steckt da ein Schema dahinter (ein gewisser Zahlenbereich und dann der Uhrzeit nach durchnummeriert. Die Lücken stammen daher, dass es auch noch eine Gegenrichtung gibt), aber trotzdem erscheint es mir nicht wirklich sinnvoll dann einen Nummernbereich anzugeben (zumal die Bahnen teilweise an anderen Gleisen ankommen/abfahren). Auf der anderen Seite erscheint es mir nur wenig sinnvoll jede einzelne Fahrt in eine Relation zu verpacken und einzutragen. dann wäre man erstens Ewigkeiten beschäftigt, und zweitens läuft man Gefahr, dass sich dass bei einer Fahrplanumstellung alles ändert. Es ist jedoch aus meiner Sicht die einzige Möglichkeit präzise zu taggen. Sofern man auf so Kleinigkeiten wie unterschiedliche Abfahrtsgleise achten will. Ich wäre jedoch dafür. Selbst wenn es nicht jeder nutzt, so sollte wenigstens die Möglichkeit vorhabenden sein.

Habe ich da jetzt irgendein Schema übersehen, dass uns die ganze Arbeit erleichtern würde oder ist es wirklich so unpraktisch? Und wenn es wirklich so unpraktisch ist, hat dann jemand eine Idee, wie man das Problem umgehen kann?
--T3QU1LA 12:56, 30 November 2009 (UTC)

Zugnummer ist nicht gleich Liniennummer! Die Bezeichnung für die Linie findest du in der Regel in den Linienplänen des zuständigen Verkehrsverbundes(hier also Verkehrs- und Tarifverbund Stuttgart (VVS)). Die von dir gesuchte Verbindung wäre wohl: R73 (Plochingen - Tübingen - Herrenberg) --pebe 15:07, 6 January 2010 (UTC)

Gut, dass bringt uns schonmal ein Schritt weiter, aber diese Linie fährt nun durch 2 Tarifverbünde (VVS und naldo) und hat bei beiden unterschiedliche Nummern. Und bei Fernverkehrszügen besteht das gleiche Problem und da gibt es gar keine Verkehrsverbünde. --T3QU1LA 09:20, 12 January 2010 (UTC)

Die Linienführung der einzelnen Linienvarianten bzw. der Linie hat nichts mit den Betreibern oder den Tarifzonen der Verkehrsverbunde zu tun. Wenn die Linie zwei Betreiber hat, kannst du doch immer noch den operator=* und evtl. die Traifzone in die Haltestellenrelation (public_transport=stop_area) angeben oder eben die Angaben weglassen. --Fabi2 18:28, 18 April 2010 (UTC)

Im Fernverkehr gibt es von der Bahn entsprechende Liniennummern [10] --rayquaza 14:33, 27 March 2011 (BST)

Überwachungskameras in Bussen und Zügen

Ich schlage vor

surveillance=transportation

zu benutzen, um Überwachungskameras in Bussen und Zügen einzutragen, als Tag der Relation.

--Lulu-Ann

Gibts schon, nennt sich man_made=surveillance. Einfach der Route-/Line-Relation (in Fahrzeugen) und den Stationen hinzufügen, wo nötig. --RalpH himself 12:42, 29 December 2009 (UTC)

Ähm, surveillance=* wird immer zusammen mit man_made=surveillance benutzt. Ich schlage hier "transportation" als zusätzlichen Wert neben "public", "indoor", "traffic" vor. Lulu-Ann

Routing zu Abschnittsbezeichnungen an großen Bahnhöfen

Hi,

(für Deutschland)

an großen Bahnhöfen gibt es einen Wagenstands-Anzeiger, der die Halteposition von Personen-Waggons den Abschnitts-Bezeichnungen am Bahnsteig zuordnet. Die Abschnitts-Bezeichnungen sind meist unter dem Dach angebrachte große weiße "Würfel" mit Großbuchstaben von A bis F.

Für Blindenrouting sind dies Abschnitte von Wert.

Wenn diese Abschnitte genauso wie Hausnummern behandelt werden, muß keine zusätzliche Routing-Funktion programmiert werden.

Ich bitte also, Gleis-Abschnitte mit addr:housenumber=A/B/C/D/E/F zu taggen. (Alphanumerische oder alphabetische Hausnummern gibt es ja eh schon auf der Welt)

Wenn zwei Züge in einem Gleich halten können, dann wird das oft als Bahnsteig 1a und 1b angegeben (in Kleinbuchstaben!). Dies schlage ich vor als zwei Plattformen zu taggen.

(Foto wird nachgeliefert)

Was gibt es da in anderen Ländern? Kommentare?

Lulu-Ann

Dann müsste man zur Adresse aber auch den Bahnsteig hinzufügen, sonst wird doch die Adresse uneindeutig, oder? Nicht sicher Baeuchle 12:36, 4 June 2010 (UTC)

Zugangsstellen in Relationen

Ich verstehe nicht ganz, weshalb Zugangstellen in jede Relation integriert werden sollen. Hingegen wird für jede Platform/Stop-Kombination keine eigene Relation erstellt. Ich würde vorschlagen, jeden stop mit den Zugängen zu verknüpfen, die er hat und dann diese Relation in Linien, etc. zu integrieren. Außerdem würde ich generell zwei stop tags nutzen, sobald zwei Haltestellenschilder da stehen, denn so lassen sich spätere Verschiebungen wie sie später eventuell auftreten besser nachvollziehen und umsetzen, ohne ganze Relationen ändern zu müssen. Das selbe gilt auch für den ersten Teil dieses Vorschlags, die Relation bleibt erhalten und deren Mitglieder können flexibel geändert werden. (Z.B. ein weiterer Eingang für eine unterirdische Haltestelle, oder ähnliches, das muss man dann nur der Haltestellenrelation hinzufügen und nicht jeder Linie). So hat man weniger zu editieren und kann schneller Fehler beheben. Gibt es etwas, was dagegen spricht?TobiBS 20:58, 11 February 2010 (UTC)

Kreuzung zwischen Straßenbahn und Bahngleisen

Wie taggt man das?

http://www.openstreetmap.org/?mlat=52.295453&mlon=10.517728&zoom=18&layers=B000FTF

--Lulu-Ann 19:09, 22 March 2010 (UTC)

railway=crossing? Baeuchle 12:42, 4 June 2010 (UTC)

Endhaltestelle

Wie tagge ich korrekt eine Endhaltestelle, bei der die Haltestellen zum Aus- und Einsteigen an verschiedenen Positionen sind? Konkretes Beispiel ist die Haltestelle "Schwabing Nord" der Tram 23 in München. Die Tram kommt von Süden, hält zum Aussteigen, fährt dann die Schleife, so dass sie wieder Richtung Süden steht und bleibt dort für ein paar Minuten zum Einsteigen stehen. --SveLil 08:04, 25 March 2010 (UTC)

Beispiel aus Frankfurt, Linie 14 (6094 6094 948043 948043), südliche Endhaltestelle (Neu-Isenburg Stadtgrenze): Einfach 2 verschiedene Stop-Positionen, eine für die Hin-, die andere für die Rückrelation. Baeuchle 12:39, 4 June 2010 (UTC)

Varianten

Kann man bei den Variant-Relationen nicht etwas abspecken und zusätzliche Schleifen als Relation mit der Rolle variant weiterhin der Haupt-Linie hinzufügen ? Gleiches gilt für einige Haltestellen und -buchten, welche nicht immer angefahren werden. Ansonsten sehe ich es als fast ünmöglich an manche Überland Buslinien mit dieser Methode dazustellen, ganz zu schweigen von den Änderungen bei Fahrplanwechsel.--Skyper 10:31, 20 April 2010 (UTC)

Nein, soweit ich daß jetzt überlegt habe, geht das nicht, zumindest wenn man mehr Metainfos außer dem Linienverlauf, wie etwa den Fahrplan, etc. dann noch korrekt zuordnen können will. Ich dachte ja auch erst, man kann ja eine common-Relation machen, wo der Linenverlauf drin ist, den alle Linienvarianten gemeinsam haben, aber das geht nicht, weil im Endeffekt muß man dann für die Metainfos z.B. wenn es nur eine Teleskoplinie (Hauüptlinie + deren Verlängerung) ist, und die Hauptlinie ist in der common-Relation, dann doch wieder eine neue Relation (mit wenigstens einer Haltestelle) für die Metainfos der Hauptline erstellen, da man aus der common-Relation nicht ableiten kann, ob der Fahrplan zur Hauptlinie oder Verlängerung gehört. Fazit, es bringt also nicht viel und macht die ganze Sache eher noch unübersichtlicher. Ich kann mir nicht vorstellen, das Überlandbusse so komplex sein sollen, wenn ich mir die hier im Raum Greifswals ansehe sind die eher einfach im Vergleich zum Stadtverkehr wo man solche Linenführungen hat. Das ist nicht die einzige, die Linie 5 hat zum Glück ja nur 5 Varianten, in Anbetracht von 8 Linien im Stadtverkehr ist es aber in absehbarer Zeit dann hoffentlich doch mal geschafft, denn im Moment sammele ich noch überwiegend fleißig Haltestellen, wobei ich die Mehrheit der Greifswalder Haltestellen inzwischen auch schon umgestellt habe. --Fabi2 23:09, 21 April 2010 (UTC)

Nachdem ich gerade mal oben den Kursbuchauszug angesehen habe, muß ich auch sagen, daß das ja echt übel ist, da braucht man dann dringend einen grafischen Linieneditor, der einem die Erstellerei der ganzen Variantenrelationen abnimmt nachdem man die Haltestellen für jede Variante herausgesucht hat. Für JOSM gibt es da ja inzwischen ein Plugin, aber da muß ich erst mal näher ansehen. --Fabi2 00:19, 22 April 2010 (UTC)

Das JOSM-Plugin benuztzt leider das alte Schema, bringt also nichts. --Fabi2 00:28, 22 April 2010 (UTC)

Umstellung alter Routenrelationen

hat da schon jemand Erfahrung, wie man die auf das neuen Linien/Linienvariantenschema umstellt, wenn man z.B. sich eine Stdtbuslinie und Überlandlinie zum teil die Haltestellen teilen und die Überlandlinie schon als alte Relation existiert, man aber die Stadtbuslinie komplett auf das neue Schema umgestellen will und die Überlandline und deren highway=bus_stops nicht surveyen kann? Was macht man da? Die alte Überland-Relation mit den neuen Platformen drin, ist nicht so gut und Die aus der Relation rauswerden ist ja auch nicht so gut, weil dann löscht man ja den schon erfaßten Linienverlauf der Überlandlinie. Hab mal experimentell ein paar Dualhaltestellen (highway=bus_stop + name=* + public_transport=platform + bus=yes) erstellt, da fällt zumindest dann der Renderer der ÖPNV-Karte auf die alten Tags zurück und faßt die Richtungshaltestellen nicht als Relation zusammen. Das ist Momentan nur für die Haltestelle, ich müchte nicht wissen, was da für Murks herauskommt, wenn ich die Haltestelle so in eine neue Linienvariantenrelation und Linie packe... --Fabi2 23:40, 21 April 2010 (UTC)

Wann stop_area_group verwenden?

Ich finde die erläuterung, wann eine relation "stop_area" reicht und wann ich eine relation "stop_area_group" drüber setzen soll noch nicht ausreichend erklärt. nehmen wir mal zum beispiel den hauptbahnhof in linz, oberösterreich. dort bleibt die ÖBB mit ihren zügen stehen, hat aber auch ein bus-terminal wo die schienenersatzbusse halten. im gleichen terminal (auf anderen service paths) bleiben dann auch noch busse von drei anderen anbietern stehen und unterirdisch gibt es dann noch eine straßenbahnhaltestelle. vor dem bahnhof existiert weiters noch ein taxistand. die haltenstellen an den unterschiedlichen geografischen punkten heißen für alle "Hauptbahnhof". verwende ich jetzt hier ein stop_area_group, weil die unterschiedlichen stop_areas eigentlich unterschiedliche operators haben, oder nur dann wenn die haltestellen "unterbezeichnungen" haben (zB "Linz Haubtbahnhof" wenn man mit dem zug ankommt vs nur "Hauptbahnhof" bei den busterminals). --Flaimo 15:49, 15 August 2010 (UTC)

Ich habe es so verstanden: "stop_area" wird für alle Haltestellen und sonstige Einrichtungen verwendet, die den selben Namen tragen. In deinem Fall also für alle erwähten Haltestellen, da sie ja alle zum Hauptbahnhof gehören. "stop_area_group" würde ich verwenden, wenn zwei unterschiedliche Haltestellen so Nahe beieinander sind, dass sie dennoch zum Umsteigen verwendet werden können. Ich kenne mich in Linz nicht so gut aus, vielleicht gibt es diesen Fall dort gar nicht, aber ein Beispiel aus Wien: Die U-Bahn-Station "Karlsplatz" würde ich mit den gleichnamigen Bus- und Straßenbahnhaltestellen als "stop_area" zusammenfassen. Dann gibt es aber auch noch die Haltstelle "Kärntner Ring, Oper", ebenfalls eine "stop_area". Allerdings sind die beiden ziemlich Nahe beisammen, daher würde ich die beiden "stop_area"-Relationen in eine "stop_area_group"-Relation zusammenfassen. Weiteres Beispiel aus Graz: Krenngasse/Schillerplatz, sieht auf einem Übersichtsplan so aus: Link, die Positionen A, B und C heißen Krenngasse, Position D Schillerplatz. Somit sind A-C eine "stop_area", D-I eine andere "stop_area", gemeinsam sind sie dann eine "stop_area_group". Wobei ich nicht weiß, welchen Namen (wenn überhaupt) ich der geben soll. -- A uller 09:59, 16 August 2010 (BST)

Teleskoplinien mit selber Haltestellenrelation aber anderer stop_position

erstes problem: ich habe hier in linz eine busline 45 die zu stoßzeiten um vier haltestellen verlängert unter dem namen 45a geführt wird. es würde sich eigentlich die integration über das role-element anbieten. das problem ist allerdings, dass wenn die linie verlängert wird, der bus zwar bei der (normalerweise letzten) haltestelle im haubptbahnhof linz stehen bleibt, allerdings nicht in das busterminal des bahnhofs reinfährt, sondern außen bei einer anderen stop_position stehen bleibt. die haltestellenrelation ist aber die gleiche. bedeutet eine unterschiedliche stop_position automatisch, dass ich dafür eine eigene linie anlegen muss? "additional" als rolle bedeutet ja nur dass zusätzlich stop_positions dazukommen, nicht aber, dass andere dadurch ersetzt werden.

zweites problem: manche linien werden zu gewissen zeiten nicht verlängert geführt, sondern umgekehrt zu später stunde verkürzt geführt. insofern bildet hier die längere route den normalzustand. wie soll soetwas abgebildet werden? -- Flaimo 09:55, 03 September 2010 (UTC)