Da geht es immer nur darum eine einzige Zeile reinzuschreiben. Die einzigen Anworten dich ich bisher gesehen habe waren das man bus/tram nicht auseinander halten kann bzw. das platform problem.
Da muss ich habe sagen nachdem ich in letzte Zeit ein duzend Haltestellen verbessert habe kann man das bei highway=bus_stop auch nicht. Das wird benutzt wie es den Leuten lieb ist.
Grundsätzlich finde ich es da auch mal angebracht nach 3 Jahren nach einer Lösung zu suchen bzw. mal zu sagen was sie wollen.
Ist grundsätzlich mal die Frage ob nicht ein “verkehrsmittel neutrales” symbol sinnvoller wäre:
Die Unterscheidung bus=yes/no oder tram=yes/no scheitert daran, dass im Standard-osm2pgsql-Stil diese Tags nicht mitgelesen werden (ich glaube, nicht mal public_transport ist da vorgesehen). Diesen Stil könnte man ändern, aber sowas macht man eher zögerlich, schliesslich schleppt man dann für alle Zeit diese Spalten mit und auf das Neu-Importieren nach einer Änderung am Stil hat man auch nicht ständig Lust.
Damit ist gemeint, dass man erst eine Relation lesen muss, bevor man weiss, was man als Icon rendern soll?
Auch das wäre ein Problem des Importprogrammes. Das kümmert sich schon um ein paar Relationen (Muoltipoygone z.B, oder Routen), um Transport hat sich da wohl noch keiner gekümmert.
Ich will nicht sagen, dass es unmöglich wäre, das alles zu erledigen, aber ein bisschen Verständnis für die Stilisten sollte man aufbringen: Es ist weder einfach, noch ist es ein Problem, das sich auf den Renderstil beschränkt. Da müsste man an mehreren Ecken viele Zeilen reinschreiben…
Naja eben einmal public_transport=platform und dann stop_postion
Glaub wirklich jemand, dass sich das nicht durchsetzt? Das das jetztige Schema nicht final ist, klar. Aber ich glaube nicht das diese ganzen tags weiterhin alle auf amenity, highway, railway etc. verteilt sein werden.
Das problem ist, dass der tag in der stop position steht, aber die meisten das Icon wohl auf die Platform haben wollen.
Ich bin da ja offen für Ideen, aber das einzige was ich mal als antwort gesehen habe ist das es schlecht ausgelegt ist, aber das hilft ja keinem beim verbessern und irgendwas bei der Datenbank, wohl was du meinst, aber war halt unverständlich.
Ich meine von mir aus kann man auch gerne noch ein (public_transport:)platform= taggen.
Ich habe zumindest arge bedenken. Es sind nur wirklich wenige Regionen, wo so ein detailliertes (um nicht kompliziert zu sagen) Schema notwendig ist. In den meisten Regionen der Welt gibt es Haltestellen, an denen Busse halten, die mit etwas Glück einen Fahrplan haben und mit noch mehr Glück diesen sogar halbwegs einhalten.
Solange das Schema keinen simplen Ersatz für die Basics hat (Bushatestelle, Busbahnhof, Bahnhof, usw.) und der komplexe Kram nur Ergänzung ist, wird sich das Schema nur da durchsetzen, wo ÖPNV sehr wichtig ist und die Mapper “Langeweile” haben.
EDIT:
Bspw. mal ins blaue geschrieben:
public_transport=stop
bus=yes
tram=yes
Damit kann der Mast beschrieben werden. Das ist simpel, für jeden verständlich und eigenständig. Dh. wenn mich die Komplexität des ÖPNV nicht wirklich interessiert, bin ich damit dann schon durch. Den Rest kann man dann, wie jetzt auch schon, hinzufügen, wie auch immer man es möchte und dann eine Relation für die Haltestelle, mit den Membern “Mast”, “Wartebereich”, “Stopposition”,…
Naja ich dachte es ging erstmal nur um public_transport=* in der datenbank
Ansonsten ich habe kein Problem damit wenn man sich auf eine public_transport= basic version einigt, die man dann ausbauen kann. Weil dann werden die Leute zumindest mal auf der public transport seite schauen.
Das war eine Vermutung von mir in #38, die aber falsch war. Ich hab nachgesehn, seit Ende 2012 ist public_transport im default-Import-Style. “bus=" und "tram=” fehlt allerdings tatsächlich. Mal sehn, was bei deiner Anregung zum Stil rauskommt…
Aus “es besteht in der Community keine Einigung ob der tag an den Straßenrand oder die Straße kommt” wurde jetzt “er gehört immer auf den Straßenrand wo die Leute warten”.
Also viele scheinen das ja ähnlich zu sehen und ich habe damit auch kein Problem, aber gleichzeitig sagt man somit auch, dass mindestens 100000, vermutlich sogar deutlich mehr tags flasch sind. Ich wollte den Eintrag auch schon lange ändern, aber sowas wollte ich jetzt nicht einfach mal “entscheiden”.
Es wäre klasse wenn es da endlich etwas Einheitliches geben würde. Und wenn jetzt Konsistenz zwischen Wiki und Mapnik-Karte hergestellt würde, dann würde sich das Taggen auch ändern. Ich weiß aber nicht wie die/ob die Öpnv-Router (Mentz) die Stop position auf der Straße nutzen/brauchen. Und mir leuchtet auch ein, dass für dünn besiedelte ländliche Gebiete und Entwicklungsländer ein einfacher Node durchaus reicht. Weiß jemand, wie das International gesehen wird (Tagging-Liste)?
tut mir leid, dass ich diesen Post nochmal aufwärmen muss.
Aber wird das Public Transport Schema in Deutschland anders angewendet als im englisch sprachigen Raum? Oder ist die deutsche Übersetzung falsch? Zumindest unterschieden sich die Wiki Seiten zum Teil deutlich. Besonders ist mir das bei der Platzierung von highway=bus_stop aufgefallen.
Im englischem Wiki steht sinngemäß, dass hw=bus_stop zusammen mit pt=platform verwendet werden **kann **und neben der Straße plaziert wird; im deutschen Wiki steht dass es zusammen mit pt=stop_position verwendet werden muss. Dafür fehlt auf der deutschen Seite der Tag bus=yes.
Außerdem steht weiter unten “Vorgeschlagene Änderungen”, dass hw=bus_stop durch pt=platform ersetzt werden soll oder mit einen Node der Straße vermolzen werden soll.
Das englischen Wiki liest sich ganz anders.
Andi hatte hier eine ähnliche Frage, jedoch ist mir nicht ganz klar wie die nun beantwortet wurde. Irgentwie sehe ich die entschiedene Stelle nicht.
Vielen Dank schon mal für eure Mühen.
Hubert
Da sollte die deutsche Seite an die englische angepasst werden. highway=bus_stop wurde mit dem neuen Schema nicht verändert, also gibt es keine alte und neue Verwendung davon. Und was soll es einem Kartennutzer bringern, wenn er zwei Punkte mitten auf der Strasse sieht und nicht weiss zu welchem der beiden er muss, wenn er in eine bekannte Richtung will?
Anders gesagt: Ich kenne es nur so, wie auf der englischen Seite beschrieben. Ausser von Mappern, die zwanghaft das neue Schema nutzen wollen, egal wie viele Fehler sie dabei machen…
Bus Stop gehört anscheinend schon immer neben die Straße wie ich herausgefunden habe, jedoch wurde das nicht immer so klar herausgerstellt.
z.B. fand sich dieser Absatz auf der Seite, bevor ihn entfernt habe:
Ansonsten hat ID hat z.B. auch ein spezielles Icon, wenn ich bus_stop auf die Straße setze.
Ich habe es am Anfang bei mir im Dorf auch auf die Staße gesetzt, weil ich dachte bus_stop steht für “Bus”;“Stop”, mir war erst gar nicht klar, dass “Bus Stop” = Haltestelle. Zudem ist es ein highway= tag, scheint also logisch den auf einen highway zu packen.
Ich mache den highway=bus_stop auch immer auf die Straße, und zwar weil das bei den meisten Haltestellen schon der Fall war (dass sie auf der Straße sind) und weil irgendwann mal im Proposal stand, das beides möglich ist, man solle immer das so machen, wie in der Umgebung alles andere schon ist/war…
Wenn ich das jetzt richtig verstehe ist es tatsächlich so, dass die Übersetzung nicht ganz in Ordnung ist und hw=bus_stop eigentlich neben die Straße gehört. Falls gewünscht werde ich die Wikiseite am Wochenende anpassen. Meine Vorstellung dazu:
was im Widerspruch zur Englischen Seite steht korregieren,
was nur nur auf der deutschen Seite steht beibehalten
Strucktur etwas anpassen, so dass man die deutsche und englische Seite weitestgehen paralell lesen kann
Bezüglich hw=bus_stop auf oder neben den Weg stelle ich mir so etwas wie folgt vor. Unter der Tabelle **Haltepunkt ** als Verwendung : *wahlweise* und als Komentar : *falls keine Platform vorhanden*.
Und Allgemien als Text an passender Stelle, so oder ähnlich:
hw=bus_stop wird gewöhnlich als Node an die Position gestetzt, wo die wartende Passagiere stehen. Falls keine Platform als Fläche gemappt ist, wird am selben Node auch pt=platform eingetragen, ansonsten befindet sich der hw=bus_stop Node auf der Fläche der Platform. In Einzelfällen wird hw=bus_stop auch auf dem Weg an der Stelle gemappt wo der Bus hält. In diesem Fall ist am selben Node pt=stop_position anstatt pt=platform getaggt.*
Dort, wo die Bushaltestellen für beide Richtungen auf annähernd gleicher Höhe liegen, platziere ich bus_stop auf der Straße. Dort, wo sie mehr als 20 Meter voneinander entfernt sind, neige ich dazu, für jede Richtungen eine separaten bus_stop neben der Fahrbahn anzulegen. Dann erkennt man beim Blick auf eine Karte eher, zu welcher Haltestelle man gehen muss, wenn man in Richtung XY fahren will.
Ich befürworte hier eine Übersetzung, die dem englischen Text entspricht – also ein Tagging von highway=bus_stop neben der Straße empfiehlt.
Zumindest die Einleitung sollte man auch sehr knapp halten und dort nicht zusätzlich versuchen, public_transport=platform zu erklären. Dazu kann man gerne einen eigenen Abschnitt über das Zusammenspiel mit dem detaillierteren ÖPNV-Tagging schreiben.
Es gibt die Firma Mentz Datenverarbeitung, welche einen Vorschlag für das Tagging des gesamten ÖPNV gemacht hat: Modellierungsvorschlag.
Hier wird vollständig auf den Tag “highway=bus_stop” verzichtet.
Der Münchener Verkehrsverbund MVV, ebenfalls von Mentz betreut, benutzt highway=bus_stop auf der stop_position, also auf der Straße. Dieses Schema haben wir für den Verkehrsverbund Rhein-Ruhr VRR übernommen.
Mir ist es egal, ob man highway=bus_stop auf der Straße oder als node für den Mast setzt. Wichtig ist, dass es die Nutzer der Daten dies entsprechend übernehmen. Nutzer sind nicht nur die Renderer der OSM-Karte sondern mittlerweile auch viele weitere, teilweise schon kommerziell genutzte Karten. Hier muss sichergestellt werden, dass nicht die Befindlichkeiten von Mappern bedient werden, sondern die Anliegen der Nutzer.
Wenn es nicht gerendert wird, hilft die Eindeutigkeit aber auch nicht weiter. M.E. muss man dann möglichst so mappen, wie gerendert wird, so kann man dann auch Eindeutigkeit herstellen, allerdings von hinten aufgezäumt.
Das Argument riecht schon ein bisschen nach Tagging für den Renderer.
Aber zum eigentlichen Problem: Die Varianten des neuen ÖPNV-Schemas sind geschaffen worden, um komplizierte Gegebenheiten (vor allem Großstädte) abbilden zu können. Auf dem flachen Land braucht man das Meiste davon nicht, es führt nur dazu, dass Ungeübte abgeschreckt werden.
Dort könnte man zum großen Teil mit dem alten Schema leben, wenn es sauber durchgeführt würde.
Was spricht dagegen, um des lieben Friedens willen neben platform auch bus_stop redundant zu taggen. Letzteres könnte man rauswerfen, wenn denn je die letzten Renderer das neue Schema zur Kenntnis nehmen.
Taggen der Haltestelle auf der Straße, wenn die Haltestellen fast genau gegenüber liegen, wäre eigentlich akzeptabel. Mir ist es aber trotzdem lieber, wenn beide neben der Straße liegen. Dann bin ich sicher, dass das wirklich für beide Richtungen gilt.
