Freut mich!
Hab grad die Mail abgeschickt.
Das haut leider nicht im Frankfurter Raum hin, wo es diverse SE-linien gibt.
http://openptmap.org/?zoom=9&lat=50.43746&lon=8.81753&layers=0B000TFT
Da es auf der transit-Liste seehr ruhig um das Thema geworden ist: Wie stehen die Chancen, dass die openptmap bei route=commuter mitzieht?
Gruß,
ajoessen
Ja; sauberer ist es natürlich, einen richtigen Tag dafür zu haben.
Auf der tagging-Liste leider auch. Was kann man da tun? Deutschland-Liste?
Wünschenswert wäre das allemal! Sonst werden zig S-Bahn-Linien dort nicht gerendert, solle man auf route=commuter umstellen.
Noch was: Auf der transit-Liste schlug jemand vor, als Zusatz zu route=train gleich einen neuen key zu erfinden: route:type=* und dann commuter oder Fernverkehr oder so. Damit es für größere Komplexität in der Zukunft offen ist. Was meint ihr?
Das hätte den Vorteil, das die Linien beim Umtaggen nicht aus dem Rendering fallen.
route=train
route:type=commuter
könnte dann für S-Bahnen der DB stehen und
route=light_rail
route:type=commuter
für das Karlsruher Modell.
Nebenbei könnte man so auch Schul/Schnell/Taxibusse genauer klassifizieren, ohne eine Handvoll xyz=yes prüfen zu müssen.
Gruß,
ajoessen
Was ich daran nicht sehr logisch finde: route=train ist ja schon eine Näherbestimmung von type=route. Dann wäre route:type dazu doppelt gemoppelt. Folgerichtiger fände ich train:type=commuter/etc.
Durch die beiden tags lässt sich eine Hierarchie besser abbilden. So bleibt es dem Mapper und renderer überlassen, ob sie nur Zug oder detaillierter Nahverkehr/S-Bahn/Fernverkehr spezifizieren wollen.
Mit nur einem tag muß man einen Haufen Werte durchsuchen, wenn man es nicht genau haben will.
Gruß,
ajoessen
Die Chancen stehen gut; ich lese hier mit. 
Seh ich auch so. Das wär dann kompatibel zum Bisherigen. Die, die wollen, werten den neuen “S-Bahn-Tag” mit aus. Die, die nicht wollen, haben dann wenigstens keine leere Karte.
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.