Einheitliche Regeln für die Erstellung von Haltestellen

Ich sehe railway als Schlüssel für Wege des Schienenverkehrs und Einrichtungen, die der Steuerung des Schienenverkehrs und des Schienenverkehrsnetzes dienen – darunter fallen m.E. aber nicht solche, die dem Zugang zum Schienenverkehr dienen. Aus dieser Betrachtungsweise heraus würde ich annehmen, dass ich durch Beschränkung auf railway=* nur Wege erhalte, auf denen sich Schienenfahrzeuge fortbewegen können, sowie Signale etc. Bei highway erwarte ich analog das Straßen- und Wegenetz samt Ampeln usw. Dass eine Zuordnung von Bahnsteigen zu railway sinnlos wäre, würd ich auch nicht grad behaupten wollen, insofern ist dieser Aspekt der Diskussion wohl ein wenig fruchtlos.

Wenn ich das Proposal nicht falsch interpretiere, läge ein korrekt getaggter Bahnhof als Relation vor (die Relation ist jedenfalls in “Grundelemente” und nicht in “Weitere Details/Optionales”, zum Fehlen einer Relation heißt es: “wenn die Haltestelle nur aus dem Haltepunkt besteht, kann auf die Relation verzichtet und die Attribute an diesen Punkt gesetzt werden” – wird ein Bahnsteig dazugesetzt, wäre das nicht mehr erfüllt). Diese Relation enthielte sämtliche Bahnsteige etc., so dass die Relation (bzw. deren Mitglieder) bei korrekt eingetragenen Daten als gutes Kriterium für eine Einordnung als Bahnsteig gelten könnte. Das ist aufwendig, und ich gebe zu, dass das ein Argument für eine Trennung von Bahnsteigen und sonstigen Plattformen ist, fände von daher eine Stellungnahme des Proposalautors ganz gut. Momentan besteht, wenn du dem Wiki “glauben” würdest, hingegen keinerlei Möglichkeit, Bahnsteige von Bussteigen zu unterscheiden. Die Relationen sind ja nur Teil des Proposals und railway=platform ist idiotischerweise beschrieben als “a railway or bus platform” – http://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform.

Hast du was gegen die Loveparade? :wink: Meine lokalen Vorbilder sind aber nie wirklich voll, ich würde nicht mal ausschließen, dass Passanten hier sogar die Hauptnutzergruppe stellen. Ansonsten sind da natürlich immer die tendenziell konservativen Standardeinstellungen und Optionen zu trennen. Manche Dinge könnte ein stark konfigurierbarer Router mich durchaus selber entscheiden lassen, etwa “bitte auch Bahnsteige einbeziehen” oder “Treppen bis x Stufen sind ok, da krieg ich mein Rad hoch”.

Das ist ein Problem der Kommunikationskanäle. Der Vorschlag wurde ja auf der ML diskutiert, bevor er überhaupt ins Wiki kam, und er stand dann auch zuerst mal auf der Benutzerseite von itschytoo. Im Forum scheint der Ersteller ja kaum vorbeizuschauen, wenn ich das aus seiner Beitragszahl schließen darf.

Und da haben wir das Problem. Normal ist der Bahnhof eine Betriebsstelle in deren Grenzen alles zur Bahn gehört. Und Railway ist übersetzt Eisenbahn oder einfach Bahn und ist daher ein Sammelbegriff der sich nicht nur auf Schienenwege und Betriebseinrichtungen beschränkt, sondern die Bahn ansich umfasst.

Das würde ich da auch erwarten. Wobei Highway auch etwas ungünst ist. Übersetzt schütteln es da einen auch bei manchen Kombinationen Schnellstraße=Fußweg ist z.B. so einer. Aber am wenigsten erwarte ich da Fluggates, Fährhäfen oder eben Bahnsteige.

Da kommen wir auch glaube ich nie auf einen Nenner. Bahnsteig ist für mich schon immer untrennbar mit der Eisenbahn verbunden und auch so definiert. Die Sichtweise Fußweg ist mir hier zum ersten mal untergekommen. Es ist daher nicht ausgeschlossen, das in Zukunft hinzustoßende Bahner ähnliche Bauchschmerzen bekommen und den mit Highway versehenen Bahnsteig wieder zurück in die Railway proposen. Auch wenn ich vielleicht den Eindruck erwecke in dem Punkt pingelig zu sein. Auf der Nietenzähler- und Pufferküsserskala bin ich da noch harmlos. Andere hätten hier den Krieg erklärt und gleich noch eine eindeutige Kennzeichnung mit Normhöhe über SO und andere Angaben gefordert.

Die Betonung liegt auf “bei korrekt eingetragenen Daten”. Die Praxis kennen wir ja. Im Moment kann da nichts falsch laufen mit railway=halt/station/platform. Bis auf eventuell vertauschte halt/station (Bahnhof muss mindestens ne Weiche haben lässt grüßen… :roll_eyes:) war das eindeutig. Man musste sich schon derbe verklicken. In Zukunft hätte ich dann Worstcase einen Node mit halt (Bahnhof wurde ja abgeschaft, statt Weichen ist es nun die Anzahl der halt Nodes), einen Schnellstraßen Bahnsteig, keine Relation und kein Service. Ich zitiere da mal die Mailingliste. Das Wiki ist keine Bibel, es gibt kein richtig oder falsch.

Wo ließt du das? Ich sehe nur railway=platform und highway=platform mit “For platforms used in bus stations or by non rail services” In den JOSM Styles ist das auch seit einiger Zeit sauber in Bahn- und Bussteig getrennt.

Ich habe nichts gegen die Parade. Mir fielen da nur die Folgen eines lausigen Routings ein und kenne auch die Erfahrungsberichte betroffener Triebfahrzeugführer. Als Option kann man natürlich auch sowas anbieten. Solange das wirklich einen Nutzen wie erhebliche Abkürzungen bringt, nichts verbotenes passiert (Abkürzen über Betriebsgelände, Personalübergänge etc.) oder eben Behinderungen verursacht. Nicht jeder Schleichweg den man kennt, eignet sich auch als offizielle Abkürzung. Wir haben hier auch einige inoffizielle Trampelwege. Die würde ich aber so nie in der Karte verzeichnen. Bei anderen bekommt man einen inneren Konflikt, einerseits will man genau sein und kann den Weg nicht vorenthalten, andererseits will man dort keinen Fremdverkehr. Wege durch den Friedhof oder die Gartenanlagen zum Beispiel. Ich hoffe mal das durch steigende OSM Nutzung kein Wanderweg vor meinem Garten ensteht.

Ich habe das verfolgt, lese die Liste ja passiv mit. Habe das in der Form aber nicht wirklich ernst genommen. Dann war es lange ruhig und taucht jetzt hier auf. Er wird schon nochmal reinschauen

'tschuldigung, dass ich mich an dieser Stelle mal kurz einmischen muss.

Ein weitverbreiteter Irtum in DE ist es, ein “Highway” wäre eine Schnellstraße (oder zumindest eine “Überland-Straße”). Dies ist ausschließlich im amerikanischen Sprachgebrauch der Fall - und auch dort nur ‘Slang’. Jeder legal zu benutzende Weg ist ein “Highway”, ich zitiere mal die offiziellen Definitionen eines highways im UK:

Da OSM ja eine britische Erfindung ist, hat man natürlich den (korrekten) britischen und nicht den (ungenauen, weil Slang) amerikanischen Sprachgebrauch übernommen. Undjeder Übersetzer, der highway stur mit Schnellstrasse übersetzt (es sei denn, es geht aus dem Kontext hervor, dass dier gemeinte highway wirklich eine solche ist…) hat meiner Meinung nach seinen Beruf verfehlt.

Auf der verlinkten Beschreibungsseite für railway=platform im grünen Kästchen rechts als “Description”. Auch bei Tagwatch entsprechend. Auf Map Features kommt highway=platform nicht vor. Im unteren Teil der Beispiele auf erstgenannter Seite steht dann allerdings plötzlich was von highway=platform. Anscheinend war es also doch so gemeint, wie es sinnvoll ist, und ist nur irreführend dokumentiert.

Eine Frage: im Namen auch mit (H) für Bushaltestellen, (S) für die S-Bahn, (DB) … taggen? Halte ich für sinnvoll, da im Navi oftmals nur Müllerstraße angezeigt wird man aber nicht ersehen kann ob nun die eigentliche Straße, die Bushaltestelle, der Bahnhof oder die S-Bahn gemeint ist - oder ist dies ein Problem bei der Kartenerstellung und sollte von mir übergangen werden? Im Navi ist es nur verwirrend, wenn man nicht weiß was was ist :wink:

Im Name macht das wenig Sinn. Stattdessen sollten das vernünftige Icons übernehmen.

Dann sollte der Programmierer eine Vorverarbeitung der einzulesenden/konvertierten Karten vornehmen, wenn dieses Feature gewünscht ist. In den Namen sollten meiner Ansicht nach keine Kürzel oder sonstige Erkennungshilfen. Begründung: * fehlen Informationen im Namen, so kann man sie recht leicht davor oder dahinter schreiben (natürlich nur, wenn man sich darauf verlassen kann, dass das der Mapper noch nicht selber gemacht hat, sonst hat man sie dann doppelt) – erfordert eine simple Vorverarbeitungsstufe, die zumindest von der Funktionalität trivial zu programmieren ist * sind dagegen eventuell zu viele Informationen im Namen, so ist das Filterverfahren deutlich aufwendiger als es der Ergänzungscode gewesen wäre. Und es kann ja durchaus sein, dass ein anderes Navi die Unterscheidung nicht über Namenszusätze, sondern passende Icons trifft. Oder dass in einer Software ohnehin nur bestimmte Objekttypen vorkommen bzw. die Auswahl des Objekttyps vor dem Anzeigen von Namen erfolgt. Oder dass man die Kürzel an die gewählte Sprache anpassen will, um die Verständlichkeit zu verbessern. In solchen und vielen anderen Fällen führt der “angereicherte” Name zu Komplikationen, überflüssigen Dopplungen … Außerdem ist auch zu bedenken, dass Zusätze im Namen nur dann überhaupt sinnvoll funktionieren könnten, wenn sich alle ans gleiche Schema hielten. Das ist meiner Erfahrung nach sehr unwahrscheinlich, und das zu erwartende Chaos aus Namen ohne Zusätzen, voll ausgeschriebenen Objekttypen, Kürzeln am Anfang oder am Ende des Namens, unterschiedlichen Kürzeln etc. kann allerlei Ärger machen. Das fängt schon bei einer simplen alphabetischen Sortierung an.

Die Liste ist echt ein lustiger Haufen. Jetzt streitet man sich schon über die Frage wo denn der Haltestellen Node hinkommt. Auf oder neben die Straße. Eine Frage die sich eigentlich garnicht stellt, außer man hat Langeweile.

Es gibt ja nur 3 Möglichkeiten. Haltestelle direkt an der Straße, Bucht oder Haltestelle auf der Servicestraße (ZOB, Schleife etc.)

Kann man alles direkt auf den Weg legen. Irgendwo daneben macht wenig Sinn. Möglichkeit 1 und 2 kommt zu 90% vor. Und wenn die Straße nicht unbedingt 80 Meter breit ist, sieht man den Abstand zwischen Straße und Node auf keiner Karte. Die 2,5 oder 3 m Abstand sieht man bei der breit gerenderten Land, oder Bundesstraße erst ab Zoomstufe 321. Darunter braucht man Pikometerpapier. Bei Fall 3 kann auf den Servie Weg gehen. Da zieht auch kein Routing zum genauen Standort des Schildes. Zum einen sind die Eingetragenen Daten ungenau, dazu kommt die Abweichung des Gerätes mit dem man geroutet wird. 10 m Abweichung sind Minimum Standard, 3 m zur Straßenmitte fallen also nicht ins Gewicht.

Die Nodes werde ich also weiterhin auf die Strippe legen.

Also bei uns in Berlin haben die S- und U-Bahn-Stationen keine Kürzel im Namen. Die Bushaltestellen heißen aber z.B. “S Sonnenallee” wenn sie direkt an der S-Bahn-Station halten…

@Mirko: Ich hab noch nie eine Haltestelle auf der Straße gesehen … bei uns halten die Busse an einer Haltestelle, und nicht auf einer Haltestelle. :wink:

Wir stellen aber keine Katatsterkarten mit 1:2500 mit Straßen usw. als Flächen her, wo auch alles super zu erkennen ist. Unsere Haltestellen sind hier in der Region zu 99% in die Straße gequetscht. Das macht einen Abstand für den die nötige Zoomstufe erst noch erfunden werden müsste. Selbst abgesetzte Servicewege für den Bus verschwinden fast unter der Straße. Der Unterschied neben oder auf ist also ein rein gedanklicher auf einem oft rein gedanklichem Fußeweg. Auf der Karte gibts den faktisch nicht. Wir erstellen Busrouten mit Stops, nicht mehr. Der Punkt muss nur da sein, wo man in den Bus fällt. Es bringt also rein garnichts den Node irgendwohin zu setzen, wo man meint das tatsächliche Schild gemessen zu haben. Wenn du hier nicht zufällig mit nem professionellem Leica etc. eine Langzeitmessung gemacht hast, ist der Standort nur in der Einbildung genau.

Ein Zug hält mit der Zugspitze auch in Höhe der Haltetafel. Das ist die mit H am Ende des Bahnsteiges. Trotzdem gehört der Node aufs Gleis in der Mitte des Bahnsteiges oder des EG, oder setzt man den Node nun auch auf die H Tafel? Noch besser, gleich aufs EG. Bei manch von der DB kastriertem Bahnhof läge dann der Node bis zu 500m von den Bahnsteigen entfernt. :laughing:

Edit: Ich vergaß noch die unterschiedlichen Haltepunkte für Viertel, Halb, Vollzüge und Achsen, sowieso die Bahnsteigabschnitte. Legen wir als für jeden Zug einen genauen Punkt an. Gleiches dann bei Straßenbahnen mit Einfach, Doppel oder Dreifachtraktion oder Beiwagen. Klein, Normal, Schlenkerbusse. :smiley:

Wenn ich einfach mal meinen Wohnort betrachte, und mir vorstelle die Bushaltestellen wären dort auf dem Weg, dann wüsste ich überhauptnichtmehr wo welcher Bus hält. Da liegen die Haltestellen schonmal ewig weit auseinander. Und die Bushaltestellen sind durchaus weit genug von der Straßenmitte entfernt, um das eindeutig zu erkennen. Da brauch man nichtmal die größte Zoomstufe.
Zu den Bahnen … wolltest du da nicht sowieso jede Kleinigkeit mappen, du hattest da doch ein mehrseitiges Taggingschema ausgearbeitet…

Na dann setzt du halt deine Nodes daneben, wenn ihr Autobahnen mit vielen Busbahnhöfen habt. Davon hats hier exakt zwei. Der Rest ist entweder direkt an der Straße, an einer schmalen Bucht oder in einer eigenen Schleife immer mit jeweils nur einem Bus. Das bewegt sich innerhalb von 3 bis 5 m. In dem Fall bringts einfach nichts den Node zwei Millimeter daneben zu legen, der Abstand ist hier zu minimal. Node generell neben die Straße wäre hier totaler Käse.

Hier mal ein kleines Beispiel mit Haltebucht und für hiesige Verhältnisse viel Platz. Das ist eine Dopppelseitige Haltestelle. Südlich ist die kleine Wartehalle, nördlich gegenüber ein Wohnhaus.

In Osmarender verschwimmt das fast zu einem:
http://www.openstreetmap.org/?lat=51.30533&lon=11.40366&zoom=17&layers=0B00FTF

In Mapnik sind da immerhin noch 5 mm:
http://www.openstreetmap.org/?lat=51.305331&lon=11.403664&zoom=18&layers=B000FTF

In der ÖPNV nicht anders:
http://www.öpnvkarte.de/?lat=51.305474&lon=11.40349&zoom=18

Bei denen direkt an der Straße und ohne Bucht ginge es noch enger zu. Knalle ich da nun links und rechts eine Haltestelle hin, bringt das null komma nix.

Bei dir siehts tatsächlich ziemlich eng aus. Und solange die Bushaltestellen direkt gegenüberliegen ist das ja auch noch ok. Bei uns sind die weit voneinander entfernt. Hier mal ein Beispiel bei mir in der Nähe: http://www.openstreetmap.org/?lat=52.46865&lon=13.46265&zoom=17&layers=0B00FTF

Bei dir kann man fast das gesamte (r)Ostkreuz und den Schnelltriebwagen in Lichtenberg quer dazwischen packen. :smiley:

In dem Fall macht das daneben wirklich Sinn. Nur kann man die Großstadt eben nicht auf die Fläche anwenden. Solche Rennpisten gibt es hier weit und breit nicht und versetzte Haltestellen liegen maximal 10 m auseinander und sind mit wenigen Schritten über die Straße direklt zu erreichen. Hier würde daneben nur in einem von 100 Fällen wirklich Sinn ergeben, ansonsten nicht. Versetzte Haltestellen sollten wirklich versetzt sein. Sprich es ist ein Hinderniss wie eine Kreuzung, Fußgängertunnel oder Brücke, nicht einzusehen etc. oder minimal 20 - 30m dazwischen, ansonsten kommt der Node in die Mitte. Denn welchen Vorteil hat es bitte, zwei versetzte einzutragen, wenn ich beim stolpern quasi vor der anderen liege und ich diese selbst bei dickstem Nebel garnicht übersehen könnte? In dem Fall ist weniger wirklich mehr.

Von daher bin ich auch strikt gegen Regeln ala Node nur daneben. Hier muss man sehen was Sinn macht und nicht stur nach Vorschrift losrennen. Ansonsten sehe ich schon das unausweichliche kommen. Die “Verbesserer” legen meine angelegten Haltepunkte hübsch neben die Straße und ich kann das ganze dann beim einzeichnen der Details wieder ändern, da die Nodes dann 100% mitten in einem Gebäude oder gar Hinterhof liegen.

Weniger ist mehr, Stichwort mehrseitiges Taggingschema. Das ist wieder ganz etwas anderes. Das sollten Informationen für eine Spezialkarte und nicht für die normale Karte oder ÖPVN werden, so wie z.B. die Reit- und Wanderkarte eigene Spezialtags hat und OSM war dafür wie geschaffen. In dem Fall eine Rail Map für die Pufferküsser, ein riesiger Gleisplan sozusagen. Nur weiß ich nicht obs was wird. Zum einen wegen der völlig undurchsichtigen Lizenz, zum anderen wegen der möglichen Inkompatiblität mit so Geschichten wie dem hier genannten stop_area Proposal. Da die Unterscheidung zwischen Bf und Hp, Bahnsteig und Bussteig quasi wegfallen würde, müsste man das über eine eigene DB lösen und im Alleingang pflegen.

Also ich gehöre zu denen, die jeweils neben die Straßen ihre Haltestellen setzen. Ich mache das nicht für die Renderer sondern für die Router. Der OSM-Horizont ist nämlich nicht auf Mapnik und Osmarender begrenzt. Da gibt es auch Router, die irgendwann einmal mit Fahrplandaten gefüttert den Passagier auf die richtige Straßenseite lotsen sollen. Navis sollten doch in der Lage sein, etwas tiefer als zB Mapnik zoomen zu können, um sowas anzuzeigen.
Wenn die Haltestellen zu dicht stehen, daß sie bei Renderern im Rauschen untergehen, dann ist das doch wohl ein Problem des Renderers. Zwei Punkte mit gleichem Namen zusammenzufassen oder einen auszublenden, ist doch nicht die Welt und klappt doch sonst einwandfrei.

Nun in den Schleifen gibts ohnehin nur eine Richtung und eine Seite. Wenn ich dahin gelotst werde, stelle ich mich dann bestimmt nicht auf die Grünfläche und warte dort auf den Bus. Da gibt es nur eine logische unübersehbare Seite. Die Haltestellen folgen einer Linie und werden durchnummeriert. Im obigen Beispiel fahren die Busse seit Einführung des ÖPNV nördlich nach Artern und südlich entgegen gesetzt. Damit ist zusammen mit dem Rechtsverkehr die Seite eindeutig. Die Schilder stehen in dem Fall keine 10m gegenüber an einer schwach befahrenen Straße mit 6m Breite. Nichts was ein halbwegs vernünftiges Programm nicht ohne tausend Nodes herauskriegen sollte. Da haben wir ganz andere Probleme. Bei bestimmten Bussen muss man eine Stunde vorher anrufen, ansonsten ist auch die richtige Seite egal, es wird mangels entsprechender Info kein Bus kommen.

Wir sollen die Leute ans Ziel bringen, nicht das Denken abnehmen. Ich hatte ja schon das Beispiel mit den Bahnsteigen gebracht. Da kann ich dem Anwender auch nur den Weg auf den Bahnsteig zeigen. Im Fernverkehr hätte man damit einen Bahnsteig mit 400m Länge. Für den richtigen Einstiegspunkt ist noch immer der Blick auf den Wagenstandsanzeiger und möglichweise zusätzliche Aushänge nötig. Vollautomatisch bis zur Waggontür wird nie möglich sein.

Bei so Beispielen wie in Berlin ist das ja ok. Aber auf den schnöden Dorfhaltestellen ist das ganze total überflüssig.

Ganz lustig wird es dann noch mit Bussteigen. Die braucht es auf dem Dorf ebenso nicht. Die normale Dorfhaltestelle ist ein Schild an der Straße oder Hauswand. Dazu ab und an eine mehr oder minder brauchbare Wartehalle und kein irgendwie erkennbarer Bussteig. Der Bus hält da am Fußweg direkt an der Straße und staut erstmal den Verkehr. Wenn dort ein auswärtiger parkt, steht der Bus auch gerne mal 50m hinter oder vor dem Schild.

Jetzt erzähle mir bitte keiner, dass sich ernsthaft einer mitten auf die Straße stellt und genau an diesem Punkt nach einem Bus sucht. Vielleicht bin ich abnorm oder denke einfach nur zuviel, aber wenn ich eine Bushaltestelle suche dann brauche ich nur die in etwa Lage in einer Straße, dort gucke ich nach einem Haltstellenschild und wenn ich das gefunden habe, gucke ich auf den Aushang. Bin ich auf der falschen Seite, laufe ich eben die 6m rüber. Ich brauche kein Gaffa Tape Kreuz direkt vor der Einstigstür und ein Routing was mich genau zum Kreuz führt.

Es stimmt, dass für Router der Unterschied zwischen 0,01 mm neben der Straße und auf der Straße entscheidend ist. Wesentlich wichtiger als der zwischen 0,01 mm neben der Straße und 10 m neben der Straße.

Nur meine Folgerung ist eine andere: Gerade deshalb setze ich die Bushaltestellen auf die Straße, so dass der Punkt Teil des Wegenetzes ist. Entsprechend dem “unified stoparea”-Proposal ergänze ich das wo sinnvoll allerdings um Nodes (oder bei Bushöfen o.ä. Ways/Areas) mit highway=platform, die dann mangels separat gezeichneter Fußwege neben der Straße landen.

Mir fällt ehrlich kein Grund ein, warum man ein Node auf den Way setzen sollte… Falls ein Node auf dem Weg vom Renderer auf der Straße gewünscht ist, dann kann er das ohne Probleme berechnen. Andersrum ist das nicht möglich…
Auch ein Router hat kein Problem damit, sowas zu berechnen.

Wir wollen auch nicht den Leuten das denken abnehmen. Es geht vielmehr darum die Wirklichkeit möglichst genau abzubilden, da wir nicht die geringste Ahnung haben, wofür diese Daten verwendet werden könnten… Von der Wirklichkeit abgeleitete Vereinfachungen auf die Wirklichkeit zurückrechnen kann keine Software der Welt, da dann einfach entsprechende Informationen fehlen…

Du bildest doch die Wirklichkeit soweit wie möglich ab. Eine ÖPNV Linie mit Haltepunkten. Nicht mehr und nicht weniger. Mehr braucht es doch auch nicht.

Echte Wirklichkeit ist hier doch garnicht gegeben. Die ganze Straße ist eine eizige Abstraktion. Eine Linie an der alles hängt. Bei zwei gegenüberliegenden Haltestellen hängen an der einen Linie zwei Fahrspuren, zwei noch garnicht tagbare Buchten und zwei Fußwege. Jetzt setzt man einzig die Haltepunkte irgendwo daneben, weicht plötzlich von der Linie ab und pappt den Node dahin wo Heinz Stadtplaner irgendwann mal das Schild hingestellt hat?

Und wieso kann eine Software nicht von der Mitte nach außen abstrahieren, umgekehrt aber schon? Damit führst du doch wiederum die ganze bisherige Taggingweise ad absurdum. Die Router haben doch heute auch keine physische Straßenseite und orientieren sich einzig anhand der Angaben auf Wegen oder den darauf befindlichen Punkten, sowie der Wegrichtung. Ein footway=left/right/booth funktioniert, bei einer Haltestelle aber nicht? Was ist der nachvollziehbare Grund?

Wenn wir von der Abstraktion weg wollen dann richtig. Entweder bleibt die Straße ein Ábstrakt und wir taggen weiterhin alles direkt auf den Weg oder es wird vernünftig gelöst. Ansonsten ist das keinerlei Fortschritt. Wir haben dann zwar einen imaginären Bussteig und ein “Schild” am halbwegs rechten Fleck, der Rest klebt aber weiterhin nur an einer Linie. Der Fußweg hätte rein nach Adam Riese nichtmal eine Beziehung zum Bussteig, denn der hängt im Regelfall als footway=booth am Abstrakt. Die Beziehung muss sich die Software selber herstellen indem sie den Fußweg irgendwie auf der höhe des Bussteiges mit selbigen in Einklang bringt, eine Physische Verbindung mit festen Punkten hat es ja nicht. Das passt so alles hinten und vorne nicht zusammen.

In vielen Großstädten ist eher der umgekehrte Weg zu beobachten. Dort strebt man an, jede einzelne Haltestelle einzuzeichnen. Dies macht auch Sinn. Denn wenn eine Haltestelle nicht an der Linienroute liegt, ist das schon sehr verwirrend. Die Doppel- bzw Mehrfachbeschriftung ist kein Problem des Mappens, sondern das der Renderer, die das nicht erkennen. Inzwischen gibt es aber schon erste Lösungen (z.B. die konfigurierbare Karte: http://www.openstreetbrowser.org), in denen das vermieden wird. Sie ziehen automatisch eine Art Polygon über gleichlautende Haltestellen und beschriften diesen nur einmal. Diese Lösung sollte und dürfte über kurz oder lang Einzug in alle Renderer finden. Dein Problem wird sich dann in Luft auflösen. :slight_smile: Dennoch findet auch der Ortsunkundige auf Anhieb seinen Einsteigepunkt. :slight_smile: Auch im Zusammenhang mit zukünftigen ÖPNV-Routenplanern/Fahrplanern mit Handicap-Option kann jeder der Haltepunkte unterschiedliche Eigenschaften aufweisen. Vermutlich gibt es noch mehr Argumente, die ich auf Anhieb nicht sehe. Auch hier beweist sich die von vielen gepriesene OSM Leitregel, detailliert zu mappen.

Gruß
Tirkon