Hallo,
wie bekomme ich es hin, daß bei der ÖPNV-Karte der Linienplan angezeigt wird? Ich habe schon bei diversen Großstädten nachgeschaut und kopiert, aber es taucht nicht auf.
Gruß
Michael
Ich nehme an, dass du die Haltestellenliste auf https://www.openbusmap.org und diese Linie 75 meinst. Ich sehe diese dort, wenn auch offensichtlich nicht mit der richtigen Reihenfolge. Ein paar Fehler, die mir bei der Buslinie aufgefallen sind:
- Sie ist nicht durchgängig (d.h. es fehlen Ways)
- Sie ist nicht sortiert (zuerst alle Halte (stops und zugehörige platforms), dann die befahrenen Wege)
- Ihr fehlt ein route_master
hth
Ich weiß auch noch nicht so genau was du meinst:
- Interaktiver Fahrplan bei Klick auf die Haltestelle: www.openptmap.org
- Selbst erstellter Plan pro Linie: http://overpass-api.de/public_transport.html
Diese Relation meinte ich: http://www.openstreetmap.org/browse/relation/3067955
Die von dir angesprochene ist schon relativ alt. Möchte ich löschen und nochmals neu erstellen.
route_master?!
Das könnte es sein. Gleich mal nachschauen…
Ich meine sowas wie hier:http://www.openbusmap.org/?zoom=17&lat=48.39694&lon=10.00866&layers=TBTTT. Hier kann man auf eine Haltestelle klicken, es wird die Liniennummer angezeigt, wo ein Linienplan hinterlegt ist.
http: reicht
Am Ortseingang Gerstetten fehlt ein kleines Stück (Linie 75)
Da kann man geteilter Meinung sein. Die gängigen Schemata wie Oxomoa schreiben das nicht vor. Ich bevorzuge die Anordnung der Haltestellen zwischen den Ways, da sieht der Mensch schneller, wo sie hingehören. Wenn man auf Durchgängigkeit überprüfen will, geht das schnell mit einer lokalen Kopie der Relation, die man sortiert.
Hier (Linie 75) ist das allerdings ein Mischmasch aus beidem.
Linie 70 hat noch keine Haltestellen.
Ist hier noch nicht das Thema, da erst eine Richtung noch ohne forward/backward-Rolle an den ways. Erst mit der Gegenrichtung (meist leicht verschiedene Wege) zusammen sollten die beiden in einen route_master. Ist auch nicht das Problem.
Das Problem ist, dass die Haltestellen,die per highway=bus_stop (eigentlich veraltet) o.ä. eingetragen wurden, in ÖPNVKarte zwar per Koordinaten angezeigt werden, aber erst mit Linien verbunden werden, wenn sie in die Routenrelation mit aufgenommen wurden. Bei Linie 75 Gerstetten Seeplatz tut es z.B.
Ein weiteres Problem bei Linie 70: Hin- und Rückrichtung sollten in getrennte Relationen aufgenommen werden. In Bolberg z.B. werden auf Heidenheimer Str. und Albstraße ein kurzes Stück zwei unterschiedliche Wege verwendet.
Im Relationseditor von JOSM geht das Anlegen der Gegenrichtung sehr schnell über Kopieren und Umdrehen der Reihenfolge, danach Entfernen der paar überzähligen Ways der ursprünglichen Richtung. Die Haltestellen müssen übrigens komplett ersetzt/angelegt werden, da sie ja für die Gegenrichtung auf der anderen Straßenseite liegen (sollten).
Ich weiß, daß es veraltet ist, aber ohne highway=bus_stop wird kein Bushaltestellen-Symbol gerendert. Irgendwo hab ich gelesen, daß man es (erst mal) weiterhin verwenden soll - war aber glaube ich eine etwas ältere Nachricht. Denke jedoch, daß ein Bot sowas leicht löschen könnte, sollte es “komplett” obsolet sein.
Meine Route/Relation war auch nur für den Weg Gerstetten–>Bolheim gedacht. Das mit den beiden unterschiedlichen Wegen kommt vermutlich von daher, daß ein Anderer die gleiche Linie von der Gegenrichtung gemappt hat.
Schau ich mir aber nochmals in josm an.
Routen sollten eigentlich grundsätzlich komplett aufgenommen werden. Wenn vorläufig nur ein Teil erstellt wurde, sollte dies vermerkt werden, damit es später nicht zwei Linien 70 gibt. Relationen zusammenzuführen geht relativ einfach, es sollte nur klar sein, dass dieser Schritt noch erfolgen muss.
Oxomoa hat kein Schema gemacht – er hat nur Strukturen vorgeschlagen. Die einzige darauf basierende Ausarbeitung ist das Public Traffic Proposal und dort ist es klar vorgeschrieben.
Nicht vorgeschrieben ist es in der klassischen Route, die stammt auch noch aus einer Zeit, als Relationen noch keine Reihenfolge der Elemente kannten.
Beide Konzepte taugen was. Aber die Vermischung ist Mist. Also entweder oder:
Klassisch:
-sortierung ist nur für den Mapper da. Sie hat keinen Informationsgehalt
-Es gibt keine Rolle “platform”, es wird immer “stop” benutzt.
-alle Halte sind Punkte und haben die Rolle “stop”, “forward_stop”, “backward_stop” oder ähnliches mit Nummern dran. (“forward_stop” für den Hinweg, “backward_stop” für den Rückweg, stop für beides)
-eine Relation pro Linie, es gibt keinen route_master
-alle Ways sind Fahrwege
-jeder Weg kommt nur einmal vor
-wird er in beiden Richtungen (nicht etwa Hin und Rückweg, sondern von links nach rechts und von rechts nach links) durchfahren, dann hat er die Rolle “”
- wird er nur in einer Richtung durchfahren, dann hat er die Rolle “forward” oder “backward”
- man sieht also bei den Wegen ganz direkt an der Rolle, wie die Linie mit Pfeilen gemalt werden soll
Public Traffic Proposal:
-pro Variante eine Relation
-es gibt route_master-Relationen. Man darf sie (leider) weglassen.
-alle Fahrwege kommen nach hinten, haben die Rolle “” und sind in sich sortiert nach Durchfahrreihenfolge
-mehrfach durchfahrene Stücke kommen mehrmals an jeweils der passenden Stelle vor
-alle Haltestellen kommen vorn und sind in sich sortiert nach Durchfahrreihenfolge. Innerhalb einer Haltestelle kommt der stop zuerst und die platform danach.
Wenn man also eine klassische Route hat, dann ist das Malen von Richtungspfeilen in der Karte ganz leicht: die leere Rolle ist für bidirektional genutzte Stücke, forward und backward für unidirektional genutzte Stücke. Bei den PTP-Routen ist das anders, hier ergibt sich alles aus der Reihenfolge der Wegstücke und man muss ggf. mehrere Relationen zusammen betrachten. Deshalb ist es wichtig, die beiden unterscheiden zu können. Daher bekommen bei mir die PTP-Relationen immer einen route_master und haben niemals forward oder backward.
Weide
Nein, ist es nicht. Die neuen Taggingweisen mit public_transport stammen aus dem Public Transport Proposal und dort steht ganz ausdrücklich … huch … ich wollte gerade nachsehen … man kann doch nicht nach einer Abstimmung den Inhalt ändern! Da gibt es massenweise Änderungen. Ab dem Anfang der Abstimmung muss sowas auf alle Ewigkeit read-only sein. Was ist das denn? Das darf doch nicht wahr sein.
Ich bin schockiert.
Weide
OK, ich hab mich nach dem Lesen aller Änderungen wieder abgeregt. Wenn man davon absieht, dass irgendjemand das blöde “light_rail” wieder reingeschmuggelt hat, sind die Änderungen nicht inhaltlich.
The proposed tags can and do coexist with the well known tags.
The usage of the new tags is recommended but not mandatory.
steht immer noch drin.
Leider ist in einem Fall der Gebrauch der alten Tags sogar zwingend erforderlich. Wenn ein Node mit public_transport=platform getaggt wird, dann bedeutet es nämlich, dass dort keine Platform ist. Will man einen B-steig als Punkt darstellen ohne irgendetwas über ihn zu sagen, dann braucht man highway=bus_stop oder ähnliches.
A public_transport=platform is used to tag a Way or Area where the passengers can wait for the vehicles.
If there is no platform in the real world, one can place a Node at the pole.
Weide