Ich selber habe Pläne, service=bus_bay zu definieren, welches Zeichen 245 mit einbindet.
Aber selbst wenn bin ich der Meinung, dass beide Fälle eher highway=service anstelle von highway=busway sind, weil es sich bei den Wegen eher um Neben- anstelle von Hauptwegen sich handeln (d.h. abseits der Straßen). Letzteres ist beispielsweise mit Parkplätzen zu vergleichen und auch hier mappt man die Wege mit highway=service anstelle von highway=unclassified (außer Straße führt mitten durch den Parkplatz hindurch).
Ähnliches Beispiele findet man auch für andere Wege, die zwar einem Modus gewidmet sind aber auch mit untypischen highway-Werten markiert werden wie z.B. ein Radweg mit “Anlieger Frei” wird mit highway=service anstelle von highway=cycleway getaggt.
highway=busway impliziert laut doku access=no bus=yes - ist also ausschließlich für Busse. Fußgänger sind also nicht zugelassen. Damit ist es nicht geeignet für Wege mit Fußverkehr, selbst wenn der auf einem Bürgersteig stattfindet. Durch default access=no dürften busways vom Fußgängerrouting meist ignoriert werde (selbst bei explizitem foot=yes).
Ich bin ziemlich sicher, dass implizite Werte durch explizite überschrieben werden, sonst meckert z.B. Osmose nicht bei access=yes auf highway=footway (und OSRM routet Autos tatsächlich auf solche Wege), dass die Fußgängerroute highway=busway nicht berücksichtigen liegt nur, dass diese die Zugriffe nicht definiert haben.
Allerdings muss ich auch sagen, dass Zufahrten zu Busbahnsteigen zumindest für mich als eine Unterkategorie von physisch getrennte Bushaltebuchten sich handeln und für mich deswegen unnötig ist.
Wendeschleifen wiederum kann man als ein weiteres Beispiel hinzufügen.
ja von der Theorie her überschreibt das Explizite die Defautwerte aber die meistern Router ignorieren highway-Typen komplett, die nicht für bestimmte Verkehrsarten vorgesehen sind (So findet z.B. Autorouting in der Regel nicht auf Radwegen, Fußwegen oder Fußgängerzonen etc statt, egal was du dort als Ausnahme per access dann doch erlaubst). Ebenso KÖNNTE es hier mit Fußgänger- und Fahrradrouting passieren.
Ist mir auch noch klar was das sein soll. Eine Bushaltebucht ist normalerweise nicht physisch getrennt. Sobald es physisch getrennt ist, würde ich es nicht mehr als Haltebucht bezeichnen. (eine Bucht ist auf einer Seite (zum Meer/zur Straße) offen.
Kannst Du mal ein Luftbild oder Foto zeigen, was genau Du meinst? Ich habe bei „physisch getrennter Bushaltebucht“ so etwas im Hinterkopf:
Die türkisfarbene Linie ist ausschließlich für Linienverkehr freigegeben und außerdem eine Einbahnstraße entgegen der Fahrrichtung
Haltestelle „Vier Grenzen“ in Hannover.
Nur vom Wording her. Das ist eine Bushaltebucht (bus_bay=left/right/both). Hier hat highway=busway nichts verloren
Was ihr da habt sind für mich separate Haltestellen wo man über die Verwendung von busway nachdenken könnte. Ob das sinnvoll ist oder ob man da nicht doch lieber bei service bleiben solte, versuche ich hier gerade zubesprechen
highway=busway sollte auch nicht für gewöhnliche aufgemalte Busspuren verwendet werden. (kein Fahrspurmapping!) hier kommt Bus lanes - OpenStreetMap Wiki zur Anwendung.
Zugegebenermaßen ist das auch ein Sonderfall, weil die Busspur an der Rheinstraße durchaus einen Bordstein getrennt ist und wegen der Geometrie habe ich dementsprechend auch ein Teil der Quintinstraße separat gezeichnet, auch wenn es es sich sonst um eine dreispurige Straße handelt.
Der Bordstein war für mich nicht erkennbar, mit Bordstein ist die getrennte Erfassung aus meiner Sicht o.k. Man müsste jetzt noch schauen, wie der Fuß-/Radwege/-access sauber auf allen Fahrbahnen erfasst werden kann.
Problematisch hier an highway=busway ist allerdings, dass noch nicht alle Router Fuß/Fahrrad-Access auf busway erwarten. Wenn ich nun eine baulich getrennte rechte Busspur mit “Radverkehr frei” habe und darauf nicht geroutet wird, geht das Radrouting ggf. kaput. Hier wäre international zu klären (post ist in anderem thread abgesetzt), ob busway für solche geteilten Busspuren grundsätzlich zulässig ist. Wenn ja müssten auch hier feature request an die routing-engines raus das zu unterstützen.
@ManuelB701: Gibt es einen Grund, warum du den deutschen Wiki-Artikel nicht zumindest weitestgehend versuchst zunächst am englischen Original zu halten? Aktuell laufen die nämlich auseinander. Bereits der 2. Satz
Busways are not meant to be used by motorists, pedestrians, or cyclists.
steht nicht im deutschen Wiki.
Vielleicht sollte man sich international erstmal auf Default-Rechte für hw=busway einigen.
Da scheiden sich auch die Geister: Die einen (einschließlich mich) sagen ja, die anderen sagen dazu nein. Der UoM Transitway wurde im Thread auch genannt und viele (einschließlich mich) waren auch eher im Bereich ja als nein (das wurde mittlerweile umgeändert aber rein wegen Router, nicht weil highway=busway hier unpassend ist).
Leider hast du meine Frage nicht beantwortet (1. Satz). Basierend worauf hast du z.B. festgelegt, dass hw=busway nur bei VZ 245 genutzt werden darf? Es gibt auch Straßen, die baulich für den Busverkehr gedacht sind, aber mit VZ 250 + “Linienverkehr frei” beschildert sind.
Meiner Meinung nach muss man mit dem Tag hw=busway zurück auf Anfang, d.h. über ein Proposal nochmal genau defnieren, was erreicht werden soll. Aktuell versucht man offenbar, das bestehende Tag umzudeuten - nur hat da jeder andere Vorstellungen.
@ManuelB701 Etwas unglücklich das bisher sich fast niemand aus der deutschen Community für das Thema interessiert hat, daher auch bisher kaum Widerspruch gekommen ist. Das Hinzufügen von neuen oder das Umdefinieren von bestehenden highway-Tags ist meist problematisch, insbesondere wenn es das Routing von Kfz/Radfahrern oder Fußgänger betrifft. Hier kann man schnell viele bestehende Anwendungen kaputt machen, wenn man das nicht umfänglich diskutiert und ungewollte Nebeneffekte dadurch nicht berücksichtigt.
Natürlich gibt es überall Nuancen, die sich in OSM auch schlecht abbilden lassen. Ein gutes Beispiel ist das Taggen von Rad- und Fußwegen: Sind diese highway=footway, highway=cycleway oder highway=path. In Deutschland der Standard ist highway=path (und zugegebenermaßen gibt es auch mehrere Fälle, wo highway=footway bzw. highway=cycleway besser geeignet sind, als highway=path).
In dem spezifischen Fall geht es darum, dass es sich um einen normalen Bussonderfahrstreifen, welcher durch ein Bordstein getrennt ist, handelt, was m.M.n. der Hauptnutzen von highway=busway darstellt d.h. der highway=busway ist ein Nebenweg der highway=primary.
Vielmehr aber steht es analog zu busway=lane, eine m.M.n. veraltete aber dennoch historische Methode, solche Busstreifen in OSM darzustellen und highway=busway (physisch getrennt) steht zu busway=lane wie highway=cycleway (physisch getrennt) zu cycleway=lane steht.
Umgekehrt deuten Zeichen 250 bzw. 267 für mich weniger auf solche Wege, insbesondere, dass sie soweit ich weiß auch nicht für Busstreifen verwendet werden (zumindest habe ich solche Fälle nie gesehen).
Allerdings ist die Frage, ob solche Straßen highway=unclassified, highway=service oder highway=busway sind, vergleichbar mit einen offensichtlichen Fußweg, welcher mit 250 anstelle 239 beschildert ist, als highway=footway oder highway=path zu taggen.
Mapillary (#1) am linken Rand neben der Mittelinsel. Das ist einfach nur die Verlängerung der Busspur, die bei Mapillary (#2) beginnt. Allerdings sind die unterschiedlich beschildert, aber nur #2 dürfte dem Wiki-Eintrag nach mit hw=busway getaggt werden, #1 nicht, obwohl er dieselben Voraussetzungen erfüllt.
Solange international festgelegt ist, dass hw=busway automatisch access=no mit bus=yes ist, kann das Tag nicht für VZ 245 genutzt werden, ohne das foot=yes explizit gesetzt wird. Denn sonst sind die daran liegenden Haltestellen (siehe z.B. #2) nicht erreichbar. Es sei denn, man mappt separate Fußwege.
Auch dann wäre es zumindest noch foot=use_sidepath und nicht foot=no bzw. access=no, da ich ja immer noch die Fahrbahn benutzen darf, wenn der Gehweg blockiert ist oder ich sperrige Sachen transportiere und damit andere Personen auf dem Gehweg behindere.