Hallo Leute,
ich möchte mich erst mal kurz vorstellen.
Ich heiße Erwin, komme aus Kufstein, liegt bekanntlich in Tirol, Österreich. Ich bin als Deutscher hier seit 1991 glücklich verheiratet, ja, das gibt es noch, habe 2 tolle Töchter und will aus dieser schönen “Stadt” auch nicht mehr weg.
Ich bin durch Zufall auf OSM gekommen. Ich habe mich erst für GPS und Geocaching interessiert. Ausserdem fahre ich gerne mit dem Rennrad durch die Gegend, heute sind es bisher fast 4.000 km und ich mappe bei der Gelegenheit mit dem GPS auch gerne fleißig mit.
Für GPS-Geräte braucht man natürlich auch Karten und hier ist eben der Zusammenhang zu OSM.
Ich habe nun im Bereich Kufstein begonnen, die Straßen und Gebäude zu erfassen und fleißig mit Hausnummern zu taggen. Macht mir riesigen Spass und ich bin auch ein bißchen Stolz, wenn ich anderen meine Heimat etwas näher bringen kann und sie sich durch meine Arbeit bei uns im schönen Tirol leichter zurecht finden
Aber jetzt zu meinem Problem. Ich habe begonnen, die Stadtbuslinie von Kufstein unter der Relation-ID: 1656151 zu erfassen. Nun gibt es jetzt eine Linie Nr. 1 die quer durch Kufstein fährt. Es handelt sich nun um keinen Rundkurs, der Bus befährt einige Teilstücke doppelt bzw. mehrmals, wendet an einer Stelle kommt wieder auf die ursprüngliche Strecke zurück. Es wäre zur richtigen Abbildung der Strecke nötig, Teile doppelt zu erfassen, soll man aber nicht, so viel ich weiß! So weit so gut, alle Teile sauber erfasst, jedoch spuckt mir nun der Routenanalyser 3 nicht zusammenhängende Segmente aus.
Was muss ich nun tun, damit ich eine komplette Route erstellen kann? Ich bin im Moment ratlos, müsste auch noch eine dritte Linie im selben Stil erfassen, warte jetzt jedoch Eure Antworten ab.
Hoffe auf viele nützlich Tipps und Lösungen, bis dann
Erwin6330.
Wenn der Bus auf dem Weg von Endach nach Eichelwang nun mal diese Schlenker zum Bahnhof fährt, würde ich das genau so auch eintragen.
Zwangsläufig kommen die Wegstücke dann doppelt in die Relation, aber das geht nun mal nicht anders.
Für Hin- und Rück würde ich aber getrennte Relationen verwenden, mit name=“Linie 1 Endach” und name=" Linie 1 Kaisertal". So kannst du wenigstens genauer angeben, welche Fahrtrichtung von welchen Haltestellen abfährt. Die gehören nämlich auch in die Relationen.
Der Routenanalyzer ist beim ÖPNV immer mit Vorsicht zu genießen. Je nachdem auf welche Art man die Linien angibt, kann man ihn mehr oder weniger gut brauchen.
Vergiss dabei am Anfang mal alles, was da zu Bushaltestellen steht. Dann sieht die Linie hinterher etwa so aus:
Relation (Hinweg):
type=route
route=bus
ref=1
from=Kufstein Endach
to=Kufstein Eichelwang
name=Bus 1:Kufstein Endach => Kufstein Eichelwang
network=Verkehrsverbund Tirol
platform erste Haltestelle dieser Richtung
... ...
platform letzte Haltestelle dieser Richtung
Enddach
...
Sparchner Straße
Falls irgendwo nicht die Warteposition der Passagiere (neben der Straße) angegeben ist, sondern der Halt des Busses (auf der Straße), dann nimm bei den Haltestellen “stop” statt “platform”.
Bei den Straßen werden hier alle Straßen in ihrer Reihenfolge aufgezählt … wenn sie fünf Mal durchfahren werden, dann kommen sie auch fünf Mal rein.
2.Relation (Rückweg):
type=route
route=bus
ref=1
from=Kufstein Eichelwang
to=Kufstein Endach
name=Bus 1:Kufstein Eichelwang => Kufstein Endach
network=Verkehrsverbund Tirol
platform erste Haltestelle dieser Richtung
... ...
platform letzte Haltestelle dieser Richtung
Sparchner Straße
...
Enddach
Falls da etwa am Wochenende irgendwelche Teile ausgelassen werden, dann kann man einfach noch mehr von diesen Relationen machen.
Relation (Bündeln der Einzelteile):
type=route_master
route_master=bus
ref=1
name=Bus 1
network=Verkehrsverbund Tirol
operator=Busbetriebe Humtata
erste Relation
zweite Relation
Routenanalyser nur mit Vorsicht zu genießen, habe ich verstanden, ist also bei mehrfacher Befahrung von einzelnen Streckenabschnitten bei seiner Auswertung nicht 100 % sicher. Kein Problem, wenn man´s weiß!
Wegstücke die mehrfach befahren werden auch mehrfach in die Relation, auch eine klare Aussage. Fehlermeldungen werden ab sofort nicht mehr beachtet, eine klare und richtige Darstellung der Strecke ist wichtig, was die Analysesoftware dazu meint zweitrangig.
Für Hin- und Rückfahrte jeweils eine eigene Relation anzulegen habe ich auch verstanden, klingt auch plausibel und wird ab sofort angewandt.
Jetzt noch eine Frage an Weide:
So wie Du den Code hier darstellst, bekommst Du bzw. ich ihn mit JOSM nie dargestellt oder ich bin einfach zu blöde. Vermute Du machst das mit einer Art von Editor und erfasst den Text von Hand, bin ich da richtig? Lass mich bitte den Weg wissen, bin ganz gierig auf Input
Vielen Dank erstmal für Eure Hilfe.
Werde die nächste Zeit erst mal mit der weiteren kompletten Erfassung der Straßen und vor allem der Häuser und Hausnummern verbringen, die Busslinien werden dann immer bearbeitet, wenn ich von Häusern die Schnauze voll habe und ein bißchen Abwechslung brauche.
Ja, aber es ist auch nur ein Konzept von vielen. Bei der Zusammenarbeit mit anderen muss man sich mit deren Vorstellungen auseinandersetzen und sie respektieren.
Wenn es um ÖPNV geht. Die Zielgruppe des Programms sind eher Leute mit Wanderrouten etc.
Das gibt es übrigens so ähnlich auch beim JOSM. Der erzählt zur Zeit noch beim Upload, dass er die Rolle “platform” und den Relationstyp “route_master” nicht kennt – aber das wird sich hoffentlich bald ändern.
Nein, ich benutze auch den JOSM. “Code” habe ich nur benutzt, um die Sachen darzustellen. Der JOSM sortiert die Tags z.B. nach Alphabet und ich wollte sie inhaltlich sortieren. Wie das dann wirklich im JOSM aussieht, kannst Du Dir z.B. bei der Relation 934912 oder anderen ÖPNV-Relationen der Gegend ansehen. (In JOSM: Datei → Objekt herunterladen)
Ich habe mal zwei Überschriften in Weides Auflistung eingefügt. Vielleicht wird es damit klarer.
Die Relation hat Taggs, die beschreiben, um was es genau geht (erster Abschnitt).
Eine Relation vom Typ public_transport-Route hat folgende Mitglieder (zweiter Abschnitt):
o Den Fahrweg. Dieser hat keine Rolle und sollte in der richtigen Reihenfolge sein.
o Die Haltestellen mit Rolle platform für die Zugangsstelle und/oder Rolle stop für stop_position
Die Haltestellen sollten in der Reihenfolge ihres Anfahrens sortiert sein. Sind Stop und Plattform angegeben, sollen sie unmittelbar hintereinander stehen.
In JOSM kann der Weg automatisch sorrtiert werden. Für die Haltestellen geht das nicht, dafür ist der Benutzer verantwortlich.
erstmal vielen Dank für Eure Antworten, sie haben mir sehr geholfen. Ich war in den letzten Tagen auch ziemlich fleißig, mit GPS durch die Stadt und alle Haltestellen gemappt.
Hier ist nun mein Ergebnis:
Master-Relation Linie 1 - 1718852
Relation 1 Linie 1 - 1656151
Relation 2 Linie 1 - 1718809
Master-Relation Linie 2 - 1720167
Relation 1 Linie 2 - 1720050
Relation 2 Linie 2 - 1720165
Relation 1 Linie 3 - 1649428
Sollte jemand von Euch Lust haben, dann könnte er ja die Relations mal anschauen. Die Haltestellen sind auch alle dabei und ich hoffe, auch den Rest richtig getaggt zu haben.
Noch eine Frage, ich habe im Wiki gefunden, dass die Haltestellen am Highway als bus_stop getaggt werden sollen. Habe ich auch so gemacht, doch hat jemand zwischenzeitlich einen Teil der Haltestellen mit amenitiy = bus_station betaggt. Eine bus_station besteht in der Regel aus mehreren Bushaltestellen, was in Kufstein eigentlich nie der Fall ist. Bin ich also mit meien Taggs auf dem richtigen Weg?
Für Verbesserungsvorschläge bin ich jederzeit empfänglich, man lernt ja bekanntlich nie aus
Liegt eine falsche Darstellung auf http://öpnvkarte.de/ eigentlich an mir oder wo sind die Ursachen dafür? Auch frage ich mich, wozu ich bei den Relations eine Farbe “color=*” angebe, ich finde keine Seite in der die Farben berücksichtigt werden.
Schönen Tag erstmal aus Kufstein,
es ist heiß heute
amenity=bus_station ist bei Einzelhaltestellen natürlich Quatsch. Wahrscheinlich findet derjenige nur das Bussymbol schöner als das blaue Quadrat. Für den Bahnhof würde ich es gelten lassen.
Das color-tag ist auch Quatsch, sobald mehrere Linien die gleiche Straße benutzen. ich beutzte das deshalb auch nie.
EDIT: Der ref-tag ist das, was als Liniennummer auf der ÖPNV-Karte erscheint. Deshalb würde ich dort ref=1 bevorzugen.
“colour” ist nur für Linien, die allgemein nicht unter ihren Nummern, sondern unter ihrer Farbe bekannt sind. So etwas gibt es in einigen Städten. Wenn jemand eine Karte extra für den ÖPNV in so einer Stadt baut, dann wird er dieses Tag auswerten. Auf allgemeinen ÖPNV-Karten wird es ignoriert, da man die Farben zur Unterscheidung der Verkehrsmittel braucht. Wenn der “normale Kufsteiner” von der “Linie 1” und nicht von z.B. der “roten Linie” spricht, dann solltest Du den Tag streichen.
OK
Wenn ich das richtig sehe, dann ist die Linie 2 der Rückweg der Linie 1. Damit hat also jede der Linien nur eine Variante (nämlich den Hinweg) und die Master-Route hat demzufolge auch nur ein Mitglied:
1656151 und 1718809 sollten nicht getrennt sein sondern eine Route bilden.
1720050 und 1720165 genauso
Die Linie 3 ist ein Rundweg von Haltestelle Feldgasse nach Haltestelle Feldgasse. Dieser Halt sollte also erster und letzter sein. Die Feldgasse (Weg 121141284) sollte als erster und letzter Weg genannt werden und die Lindenallee wird dann also zweimal auftauchen.
“ref” ist die Liniennummer, sollte also einfach “1” sein.
“from” fehlt
“to” fehlt
“description” kann raus, da die Angabe ja in "name"enthalten ist
“name” ist zusammengesetzt aus : =>
wäre also z.B. “Bus 1: Kaisertal => Fachmarktzentrum”
Es bleibt dann noch ein konzeptionelles Problem mit den Master-Routen: Man könnte eigentlich die Master-Routen weglassen, denn es gibt ja nichts zusammenzufassen, da alle nur eine Relation enthalten würden. Nur besteht dann die Gefahr, dass man das Schema (http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport) nicht mehr erkennt und es mit anderen Schemata verwechselt werden kann. Das wäre ein Problem bei den Straßen. Bei anderen Schemata müssen die Straßen, wenn sie nur in einer Richtung benutzt werden, mit der Role “forward” oder “backward” gekennzeichnet werden … keine Angabe bedeutet dort “wird in beiden Richtungen durchfahren”. Da wüsste bei der Linie 3 also niemand mehr, ob die Runde nur in einer Richtung oder sowohl im als auch gegen den Uhrzeigersinn durchfahren wird. Daher würde ich für alle drei Routen eine Master-Route einsetzen und damit eindeutig anzeigen, dass nach Schema http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport getaggt wurde.
Danke für Deine Analyse, finde ich super, dass Ihr mir bei der richtigen Erfassung helft.
Leider habe ich im Moment nicht die Zeit, um sofort alle Vorschläge umzusetzen, werde ich in den nächsten Tagen machen. Was mir nur auf die Schnelle aufgefallen ist, das ist das Problem mit dem Route Manager, bzw. Relation Analyser. Wenn ich die Routen aufteile, dann werden sie als durchgehend erkannt. Schreibe ich nur eine Relation mit den entsprechenden Wegen, dann wird gemeckert. Es wäre Teilabschnitte nicht zusammenhängend, vor allem um den Oberen Stadtplatz herum kann die richtige Fahrroute nicht erstellt werden, geht leider nur wenn sie getrennt sind.
Oder ich mache was falsch, das werde ich mir nach Deinen Erklärungen noch mal genauer ansehen
Wünsche Euch einen schönen heißen Tag, ich darf jetzt noch einen “Freund” beim Ausliefern von Schulbüchern helfen, wird ziemlich schweißtreibend bei der Hitze, was tut man nicht alles für die Freundschaft,
Ja, der Relationseditor im JOSM wird für jedes einzelne dann doppelt vorkommende Straßenstück fragen, ob man man sowas auch wirklich machen will … ja, man will. Und der Analyzer ist hinterher unzufrieden. Wenigstens kann man hinterher im Relationseditor des JOSM rechts eine durchgezogende Linie sehen und das ist ja auch eine Art Bestätigung, das man nicht total falsch liegt
Mach Dir vor allem keinen Stress bei dieser Hitze. Wir machen das ja alle nur, weil und solange es Spass macht!
Weide
