Kann es sein, dass ihr mich falsch verstanden habt? Ich stell oben nicht in Frage, dass es sinnvoll ist, hierarchische Tags zu haben. Da bin ich - wenn ich mich nicht irre - einer Meinung mit euch. Sondern, ich finde, dass route:type=* nicht so unlogisch ist wie train:type=*.
Leuchtet ein, aber dann braucht man für die Spezifizierung von Busdiensten noch ein neues tag.
Leider ist es so, dass man in der postgreSQL-Datenbank für jeden auszuwertenden Spezial-tag eine eigene Spalte anlegen und anschliesend den Planeten neu importieren muß, was die Datenbank aufbläht und auf dem dev-Server vermutlich nicht so einfach möglich ist, oder key und value aus der hstore-Spalte rauspfriemeln muß, was die Verarbeitung ausbremst.
Ich wäre ja auch mit service=commuter einverstanden, aber da wird sich möglicherweise jemand dran stören, weil service=* schon zur Klassifzizierung der Gleise verwendet wird.
Gruß,
ajoessen
Gut. Ich war mir nicht mehr sicher, wer da nun zuständig ist. Bei der ÖPNV-Karte mache ich mir da weniger Hoffnung auf eine zeitnahe Anpassung.
Könntest du dann light-rail ins blaue Farbspektrum verschieben?
Wäre mir bei den Straßenbahnen auch lieber, dann könnte man das rote Farbspektrum für Busdienste aller Art (Schul/Taxi/Schnellbus) reservieren.
Gruß,
ajoessen
Hallo Marqqs
Da in den vorhergehenden Posts Vorschläge zur optischen Unterscheidung von Linientypen gemacht wurden, füge ich meine Frage mal hier an.
Hier >>> http://www.kreis-euskirchen.de/service/oepnv/taxibus.php gibt es den sogenannten TaxiBus. Der fährt nur, wenn er zuvor telefonisch bestellt wird. Da diese telefonische Vorbestellung teilweise schon am Vortag oder sogar mehrere Tage im Voraus erfolgen muß, steht diese TaxiBus-Linie http://www.openstreetmap.org/?relation=944483 nicht wie eine normale Buslinie zur Verfügung. Diese Besonderheit sollte man irgendwie auf der Karte erkennen können. Im Busnetz-Plan http://www.vrsinfo.de/fileadmin/Dateien/downloadcenter/Busnetz2011_KreisEuskirchen.pdf ist die TaxiBusLinie mit einem Telefonhörer gekennzeichnet. In der Relation http://www.openstreetmap.org/browse/relation/944483 habe ich route=TaxiBus gewählt.
Für Anrufsammeltaxi http://www.kreis-euskirchen.de/service/oepnv/anrufsammeltaxi.php würde ich route=AST wählen.
Gibt es das schon?
nächtliche Grüße 
tippeltappel
vorgesehen ist eigentlich
route=bus
on_demand=yes
TaxiBus nennt sich anderswo auch Anruflinientaxi (ALT), einige Linien im Kreis Euskirchen auch TaxibusPlus, weil zum Verbundtarif ein Zuschlag zu zahlen ist. Dafür würde ich aber jetzt nicht drei verschiedene Routentypen erfinden.
Auf der Karte könnte man diese Linien gelb einfärben, halt wie ein Taxi.
Ausserdem gibts noch Bürgerbuslinien, die zwar regelmäßig verkehren, aber nicht in den Verbundtarif integriert sind. Die könnten auch eine eigene Farbe bekommen.
Schul- und Schnellbuslinien könnte man auch noch separieren.
Zu allem Überfluss gibts dann noch Linen, die nur morgens als Schulbus zur nächsten Schule fahren, den Rest des Tages aber nur auf Anforderung. Oder am Wochenende nur auf Anforderung. Oder Schulbus nur auf Anforderung…
Es gibt halt viele Sparmöglichkeiten im ÖPNV 
AST haben die Eigenart, dass sie direkt von der Einstiegshaltestelle zum gewünschten Ziel fahren, sofern nicht weitere Fahrgäste in Reichweite abzuholen sind. Es handelt sich also eigentlich nicht mehr um eine Route, sondern nur noch eine Ansammlung von Haltestellen. Meist sind alle normalen und Schulbushaltestellen einer Gemeinde in das AST einbezogen.
Dann braucht es eigentlich auch keine Relation mehr dafür. Ein tag on_demand=yes an der Haltestelle tuts dann auch, eventuell den operator mit angeben.
Gruß,
ajoessen
Vielen Dank für die ausführliche Info.
Also dann mach ich aus TaxiBus wieder Bus und füge on demand hinzu.
Um Verwechslungen zu vermeiden scheint es mir sinnvoll, vor die Liniennummer der Taxibusse ein TB zu setzen. So lassen sich dann auch andere Linientypen wie ALT und TBP unterscheiden, die unter route=bus + on_demand=yes zusammengefaßt und mit gelber Linie angezeigt werden.
Gruß
tippeltappel
Hallo tippeltappel
Im VRS (Verkehrsverbund Rhein-Sieg) haben Taxibus-Linien von sich aus ein T als Anfang der Linien-Nummer. Leider weis ich nicht wie das bei anderen Verbünden gemacht wird.
In die Liniennummer (ref=*) würde ich nur das setzen, was im Verbund tatsächlich für diese Linie verwendet wird. Im Namen der Route(n) hast du mehr Möglichkeiten zusätzliche Informationen (Fahrtziel, Taxibus, …) unterzubringen.
Edbert (EvanE)
@ Edbert
Die Linien gehören zum VRS.
Aus TB821 läßt sich ja auch T821 machen.
In den Plänen wird ein Telefonhörer verwendet.
Auf die Beschriftung der Busse habe ich noch nicht geachtet.
Als Routen-Name hat der ursprüngliche Ersteller der Relation name=VRS 821 angegeben. (Ich hab die Relation nur ergänzt.)
http://www.openstreetmap.org/browse/relation/944483/history
VRS ist aber auch noch als Network eingetragen.
Als Betreiber war RVK (Regionalverkehr Köln http://www.rvk.de/startseite/fahrplanauskunft/fahrplanauskunft.html)) angegeben.
Jetzt frag ich mich, was ich in das Name-Tag hineinpacken soll.
Start- und Zielhaltestelle ist doch eher etwas für description=*
Wobei ich die Verwendung von route_start=* und route_end=* besser finden würde.
“Taxi-Bus” beschreibt, um welche Art Route es sich handelt.
Daher meine Überlegung route=TaxiBus zu taggen.
In Route soll aber route=bus stehen.
Also auf description=Taxi-Bus ausweichen?
route:type=Taxi-Bus macht wohl nicht so viel Sinn.
Denn route=* beschreibt ja eigentlich den Routentyp, während das Tag type=* für die Klassifizierung der Relation reserviert ist.
name=Taxi-Bus VRS-Linie 821 ist unhandlich lang und nicht üblich auf Linienplänen.
Außerdem ist es möglich, so eine Bezeichnung aus anderen Tags zusammenzusetzen und in das Name-Tag durchzuschleifen, falls man dort eine ausführliche Beschreibung sehen möchte. Der Kartenbastler kann dann selbst entscheiden, wie lang/ausführlich der Name werden soll.
Auf den Linienplänen (Karten) machen aber nur die kurzen REFs Sinn.
Für aus der Datenbank abgeleitete Listen wäre allerdings ein aussagekräftiger Name sinnvoll.
Hmmmmmmmm - grübel …
Gruß
tt
Das geht leider wild durcheinander. Die VRS-Linie 342
http://www.vrsinfo.de/fileadmin/Dateien/minis/b_Linie_342.pdf
fährt z.B. in Schwachlastzeiten nur als Taxibus, Samstags als Kleinbus und zur HVZ als normaler Bus.
Ich würde dann aber trotzdem die normale Liniennummer benutzen.
Anderswo kommt kaltT TB ALT Rufbus oder wasweissich vor die Nummer.
Gruß,
ajoessen
Um die Relationen im Relationseditor auseinanderhalten zu können (vor allem wenn man Linienvarianten oder Hin-und Rückfahrt in eigene Relationen packt), ist es schon sinnvoll, mehr als nur die Liniennummer in den Namen zu packen.
Ich setze da immer “Bus xyz Ziel” rein, so wie es auf Haltestellenschild und Bus drauf steht.
Das Public-Transport-Proposal ist da etwas ausführlicher, aber notwendig ist das nicht.
Auf den Linenplänen soll natürlich nur die Nummer erscheinen. der relationsname ist erst mal für den MApper zur Unterscheidung notwendig.
Übrigens ist es leider nicht (mehr) so, dass Liniennummern verbundweit eindeutig sind:
http://bahnradwandern.bplaced.net/VGM.htm
http://bahnradwandern.bplaced.net/VRL.htm
Gruß,
ajoessen
Hmmmmm - Alles nicht so einfach.
Die normale Liniennummer zu nehmen, verfälscht dann aber die Information auf der Karte.
Bei so einem “Durcheinander” würde ich T/B 342 setzen. Dann ist klar, daß es unterschiedliche Beförderungsmodalitäten gibt.
Den Namen so zu wählen, daß er in den Relationslisten als eindeutig erkannt werden kann, scheint mir das wichtigste Argument für die Formatierung “Verkehrsverbund/Linientyp/Linie/Start-Ziel” zu sein. Sobald ich wieder Zeit für die Tüftelei habe, werde ich das berücksichtigen.
Gruß
tippeltappel
Also Start-Ziel ist jedenfalls nicht eindeutig! Noch nicht mal via reicht um eine Eilfahrt von einer normalen zu unterscheiden. Da wird auch das ganze drumherum davor nicht mehr Eindeutigkeit erzeugen.
Für eine 0815-Linie reicht mMn Liniennummer und Ziel aus.
EDIT: Oder Start-Ziel, wenn man nur eine Relation pro Linie anlegt. Dann aber bitte ohne from und to.
Wenn es komplizierte Linienvarianten gibt, muß man eben im Einzelfall entscheiden. Als nicht-automatisierter Mapper hat man ja sowas wie natürliche Intelligenz mit in die Wiege gelegt bekommen 
Es geht ja erstmal nur darum, dass man als Mapper beim Editieren die Linien auseinanderhalten kann. Wie Routenlistenauswertungen damit umgehen, ist da zweitrangig. Dabei kann man from, via to und Verbund auch separat auswerten.
gruß,
ajoessen
ich weiß nicht ob wir uns missverstehen: http://www.bahn.de/rvd/view/static/kursbuch/360.pdf
Vergleicht man hier die Linienvarianten 127 und 727 wird man feststellen, dass sie den identischen Linienweg haben. Auch die Fahrzeiten sind gleich. Lediglich wird Mo-Fr an einigen Haltestellen nicht gehalten, um die Fahrzeiten auch bei größeren Fahrgastzahlen zu halten. Man hat also gleichen Start, gleiches Ziel, gleiches Via und der Rest ist ja sowieso gleich, weil es die gleiche Linie ist.
Wenn die Wege gleich sind, braucht man ja auch keine getrennten Relationen. Nur für ausgelassene Haltepunkte jedenfalls nicht.
Wenn du jede Fahrt einzeln abbilden willst, wird das ganze nämlich so unübersichtlich, dass dann auch wieder keiner durchblickt. Fügt dann jemand mit Potlatch ein Wegstück ein, ohne die Relationen zu übernehmen, hast du viel Spaß mit so einem Konstrukt.
Bei sowas hier:
http://www.westfalenbus.de/westfalenbus/view/static/kursbuch/464.pdf
macht es dann nur noch Sinn, alles in eine Relation zu kippen.
Gruß,
ajoessen
Wenn du jedoch nicht für jede Linienvariante eine Relation anlegst, dann hat das ganz Schema seine Bedeutung verloren. Weil dann der Nutzer eben nicht sehen kann wohin der Bus von “SEINER” Haltestelle fährt. Insbesondere wenn es darum geht zu ermitteln das man an einer Haltestelle einsteigt und an der nächsten fährt der eine durch, der andere Hält aber.
Wenn du diese Informationen nicht brauchst, dann ist es viel viel einfacher einfach alle Teile die von einer Linie befahren werden in eine Relation zu kippen. Dann brauchen wir nicht für die einfachen Fälle Schema 1 und für die anderen Schema 2 wählen. Auch die zugehörigen Haltestellen sind in der Karte nicht erkennbar. Warum also in die Relation aufnehmen? Dieser Ansatz macht meiner Meinung nach nur wenig Sinn.
Ja, irgendeinen Tod muß man sterben.
Wir tragen die Daten so ein, dass wir als Mapper es möglichst einfach haben, die Relationen zu pflegen.
25 Relationen pro Linie halte ich da für suboptimal, wenn es noch ein Dutzend andere Linien auf dem selben Straßenstück gibt.
Ob und wie die Daten genutzt werden können, ist Sache der Auswerter und Renderer. Ommmmmm…
Gruß,
ajoessen
Wenn die Daten Nicht genutzt werden können, weil sie entweder unvollständig oder total verschieden erfasst werden, dann kann man sich dies sparen. Für den renderer ist es ausreichend wenn alle Wegstücken einer Linie in einer Relation erfasst sind. Der Rest wird von nichts ausgewertet, weil die Verbreitung nicht groß genug ist. Und es wird sich daran auch nichts ändern, jedenfalls wenn man solche Ausnahmen macht.
Das siehst du zu negativ.
In Aachen und Köln werden die OSM-Daten schon von den Verbünden benutzt.
Das Grundprinzip von OSM ist nun mal, dass der Mapper die Daten so einträgt, wie er am besten kann, und der Auswerter das beste draus macht.
Wir geben die Lage der Haltestellen aus Ortskenntnis ein, und soweit bekannt auch den Linienweg. Wenn die Fahrplandaten nun exotische Linienverläufe enthalten, muß der ÖPNV-Router dann eben auf das übrige Straßennetz des OSM-Bestandes ausweichen. Eine Vollständigkeit können wir nicht garantieren, auch nicht in obigen Verbünden. Funktionieren tuts aber trotzdem.
Den Fahrplan komplett in OSM abbilden zu wollen, hat immer mal wieder jemand probiert; ist aber letztendlich immer gescheitert oder verzweifelt.
Gruß,
ajoessen