Korrektes Mappen von Bushaltestellen und -linien

Schina02 wrote:

1. Wenn ich eine Bushaltestelle auf einer Straße mappen will, dann setze ich direkt auf den highway-Way auf Höhe der Bushaltestelle einen Node mit highway=bus_stop. So weit so gut. Dann gibt es aber auch noch den public_transport:stop_position. Warum brauche ich das extra noch? Im Idealfall ist das doch schon durch highway=bus_stop geklärt oder? Kann mir das jemand erklären?

highway=bus_stop ist das alte Schema und wird nur zur kompatibilität gesetzt. Früher hat man mit highway=bus_stop das gemapped, was heute public_transport=platform ist. Also: public_transport=stop_position bekommt kein highway=bus_stop, aber public_transport=platform darf eins bekommen.

Schina02 wrote:

2. Und wenn ich das einsetze, falls mir die Erklärung einleuchtet, was ist mit Stopposition gemeint? Da wo der Bus mit seiner Front zum Stehen kommt? Oder mit dem Eingangsbereich? Oder mit seinem Mittelpunkt?

Mit der Front

Schina02 wrote:

3. Wie mache ich das mit den Relationen für die einzelnen Haltestellen: eine Straße, eine Bushaltestelle für jede Richtung die mehr oder weniger gegenüber liegen, die mache ich in eine Relation (oder doch nicht?). Aber wie weit auseinander dürfen die sein um noch in eine Relation gehören zu dürfen? Und gehört in die Relation auch highway=bus_stop mit rein?

Also wenn Du einfach nur 2 Haltestellen hast, in jede Richtung eine, würde ich das als Overkill ansehen. Ansonsten: wenn du eine Relation des Typs stop_area hast, kommen sowohl public_transport=stop_position, wie auch public_transport=platform hinein. Zusätzlich alles, was dazugehört, also auch amenity=shelter wenn das Bushäuschen separat gemapped ist, etc.

Schina02 wrote:

4. In die Routen-Relation für die einzelnen Buslinien, was kommt da alles rein? Die Straßen, klar, aber auch highway=bus_stop? Und noch mehr wie die Relation der ganzen Haltestelle oder die Plattform oder was?

Die Best Practise ist:
Zuerst alle public_transport=stop_position und public_transport=platform, dann alle Straßenabschnitte. ich würde immer die stop_position und platform die zusammegehört untereinandersetzen, aber es gibt keine Regel, dass es so sein muss. Du kannst Dir ja einfach mal eine bereits gemappte Buslinie anschauen. Die highway=bus_stop sind ja normal eh dasselbe wie public_transport=platform, von daher ignorier sie einfach. Die Rolle wird immer entsprechend korrekt vom Relations-Editor getagged.

Vorschlag:

Vielleicht könnte auf der WIKI-Seite eine Route als Beispielroute (zum ansehen) verlinkt werden. (Besonders auch mit forward/backward - tritt öfters auf)

Ah okay, danke Nadijta, das erklärt einiges. Es gibt einige Seiten die dazu was schreiben, aber dann fehlt der Hinweis, das jenes eigentlich veraltet ist, dann das dieses veraltet ist. Dann schreibt es eine Seite eher so, eine andere wieder eher so. Teilweise sehr verwirrend.
Zusätzlich mit geri-ocs Seite habe ich glaube die Idee raus.

Apropos verwirrend: hier ( http://wiki.openstreetmap.org/wiki/Prop … t#Examples ) sind die Beispiele so angegeben, dass highway=bus_stop auf public_transport=stop_position sitzt und nicht auf public_transport=platform. Was ist denn vorzuziehen?

Und gehe ich richtig in der Annahme, dass die Reihenfolge in der Relation keine Auswirkungen hat, lediglich der Übersichtlichkeit dient?

Schina02 wrote:

Zusätzlich mit geri-ocs Seite habe ich glaube die Idee raus.

Selbst die genannte Wikiseite selbst sagt allerdings:

Zu beachten ist, dass es sich hier um die Dokumentation der vom ÖPNV-Renderer unterstützten Tags und nicht unbedingt um die sauberste Art zu mappen handelt.

Daher würde ich davon abraten, diese Seite allzu ernst zu nehmen. Insbesondere die dort propagierten forward/backward-Rollen sind im aktuellen Schema überhaupt nicht mehr vorgesehen, weil sie sich zwanglos aus der Reihenfolge der Wege und der Regel "eine Relation pro Fahrtrichtung" ergeben. Hier wäre die ÖPNV-Karte gefragt, dies endlich zu unterstützen.

Und gehe ich richtig in der Annahme, dass die Reihenfolge in der Relation keine Auswirkungen hat, lediglich der Übersichtlichkeit dient?

Nein. Die Wege und Haltestellen werden jeweils in der Reihenfolge sortiert, wie sie angefahren werden.

Hi,
obwohl ich den ÖPNV eigentlich aufgegeben habe, muss ich jetzt doch kommentieren:

Nadjita wrote:

highway=bus_stop ist das alte Schema und wird nur zur kompatibilität gesetzt.

Nein. Bei Platforms mit Wartebereich als Node kann public_transport=platform nicht benutzt werden. Dort geht nur highway=bus_stop.

Nadjita wrote:

Früher hat man mit highway=bus_stop das gemapped, was heute public_transport=platform ist.

Nein. highway=bus_stop wurde sowohl für die heute mit public_transport=platform als auch für die heute mit public_transport=stop_position Nodes benutzt.

Nadjita wrote:

Mit der Front

Nein. public_transport=stop_position ist immer auf dem in der Relation angegebenen Fahrweg. Aber auf Höhe der Front würde ich es auch machen.

geri-oc wrote:

(Besonders auch mit forward/backward - tritt öfters auf)

Nein. forward und backward treten niemals auf, wenn es sich um eine Public-Transport-Relation handelt.

Schina02 wrote:

Und gehe ich richtig in der Annahme, dass die Reihenfolge in der Relation keine Auswirkungen hat, lediglich der Übersichtlichkeit dient?

Nein. Zuerst kommen alle Haltestellen und ihre Reihenfolge gibt an, in welcher Reihenfolge sie angefahren werden. Dann kommen alle Wege und ihre Reihenfolge gibt an, in welcher Reihenfolge sie vom Bus benutzt werden und damit wird auch indirekt angegeben, ob sie von links nach rechts oder von rechts nach links durchfahren werden.

Das unverfälschte Original des Public Transport Proposals findet man unter
http://wiki.openstreetmap.org/w/index.p … did=625726

MfG
Weide

Vielen Dank, jetzt bin ich vollständig verwirrt. :-)

Es fehlt glaube ich eine relativ leicht verständliche, einfach und übersichtlich gehaltene, deutschsprachige, aktuelle Übersichtsseite (die gerne auch unterschiedliche Meinungen wiedergibt). Kann das sein? :-)

Schina02 wrote:

Vielen Dank, jetzt bin ich vollständig verwirrt. :-)

Jederzeit gerne wieder.

Eventuell hilft das hier bei der weiteren Verwirrung weiter: http://forum.openstreetmap.org/viewtopi … 81#p193181
Da findet sich zumindest eine in sich geschlossene, konsistente Aufbereitung des Themas. Inwieweit die Dokumente noch aktuell sind, vermag ich allerdings nicht zu sagen.

Weide wrote:

Hi,
obwohl ich den ÖPNV eigentlich aufgegeben habe, muss ich jetzt doch kommentieren:

Nadjita wrote:

highway=bus_stop ist das alte Schema und wird nur zur kompatibilität gesetzt.

Nein. Bei Platforms mit Wartebereich als Node kann public_transport=platform nicht benutzt werden. Dort geht nur highway=bus_stop.

Genau dafür ist doch platform da. Im Proposal heißt es:

The platform is tagged as Way or Area where the passengers can wait for the vehicles. If there is no platform in the real world, one can place a Node at the pole with public_transport=platform.

Ich kombiniere mal scharf, dass wenn man public_transport=platform setzt und das Haltestellenschild damit meint, drumherum gewartet werden darf. Wobei der Wartebereich eh nicht so klar ist. Wenn es regnet, sind vermutlich alle Passagiere im Shelter statt neben dem Schild ;o)

Weide wrote:

Nein. highway=bus_stop wurde sowohl für die heute mit public_transport=platform als auch für die heute mit public_transport=stop_position Nodes benutzt.

Das Stimmt natürlich, aber außer im Wiki habe ich das nocht nicht erlebt. In der freien Wildbahn kam's mir noch nicht über den Weg ;o)

Weide wrote:

Nein. public_transport=stop_position ist immer auf dem in der Relation angegebenen Fahrweg. Aber auf Höhe der Front würde ich es auch machen.

Genau das hab ich doch gesagt…

Nadjita wrote:

Genau dafür ist doch platform da. Im Proposal heißt es:

The platform is tagged as Way or Area where the passengers can wait for the vehicles. If there is no platform in the real world, one can place a Node at the pole with public_transport=platform.

Ich kombiniere mal scharf, dass wenn man public_transport=platform setzt und das Haltestellenschild damit meint, drumherum gewartet werden darf. Wobei der Wartebereich eh nicht so klar ist. Wenn es regnet, sind vermutlich alle Passagiere im Shelter statt neben dem Schild ;o)

Da steht aber nicht, dass damit das Haltestellenschild gemeint ist. Da steht sinngemäß: Ein Haltestelle wird als Linie oder Fläche getaggt. Wenn garnichts da ist, dann kann man auch einen Punkt an die Stelle des Pfahls setzen. Public_transport=platform an einem Node bedeutet also explizit, dass dort nichts außer dem Schild ist. Also können die Leute bei Regen auch nicht ins Häuschen :-)

Nadjita wrote:

Das Stimmt natürlich, aber außer im Wiki habe ich das nocht nicht erlebt. In der freien Wildbahn kam's mir noch nicht über den Weg ;o)

Damals war die gängigste Mappingart, dass man bei gegenüberliegenden Haltestellen einen Punkt auf die Fahrbahn macht und bei weit auseinanderliegenden zwei (oder mehr) Punkte neben die Fahrbahn.

Nadjita wrote:

Genau das hab ich doch gesagt…

Ich wollte nur klarstellen, dass man nicht diese Stelle vermessen darf und da einen Punkt hinsetzen -- das wäre dann ja meist neben der Linie, die die Straße repräsentiert.

MfG
Weide

Weide wrote:

...

geri-oc wrote:

(Besonders auch mit forward/backward - tritt öfters auf)

Nein. forward und backward treten niemals auf, wenn es sich um eine Public-Transport-Relation handelt.

...
MfG
Weide

Und wie unterscheide ich dann auf einer Straße die Haltestellen der unterschiedlichen Richtung?
Für jede Richtung eine Relation?
Dann hat eine Linie mindestens 2 Relationen - wenn die Schulbusroute gefahren wird kommen noch einmal 2 Relationen dazu?

Hier eine "dritte" Meinung:

Schina02 wrote:

1. Wenn ich eine Bushaltestelle auf einer Straße mappen will, dann setze ich direkt auf den highway-Way auf Höhe der Bushaltestelle einen Node mit highway=bus_stop. So weit so gut. Dann gibt es aber auch noch den public_transport:stop_position. Warum brauche ich das extra noch? Im Idealfall ist das doch schon durch highway=bus_stop geklärt oder? Kann mir das jemand erklären?

Dazu kopiere ich einfach mal, was ich vor einiger Zeit jemandem per PN erklärt hatte:

Schon nach dem alten Schema war es richtiger, für jedes Haltestellenschild einen Node mit highway=bus_stop zu erfassen. Ein Node pro gesamte Haltestelle war "schon immer" eher eine Notlösung falls es nicht so genau bekannt ist.

highway=bus_stop ist aber eigentlich veraltet. Aktuell sollte ein public_transport=stop_position an der Stelle, an der etwa die Fahrzeugspitze zum Halten kommt (optimalerweise auf einem Way), und public_transport=platform an Stelle des Mastes oder als Fläche für den Bahn-/Bussteig (als Fläche mit area=yes). Hinzu kommen jeweils Tags zum Erfassen, wofür das jeweils genutzt werden kann (tram=yes/no, bus=yes/no, train=yes/no). Das ganze wird dann in einer Relation vom Typ public_transport=stop_area zusammengefasst.

Oft lässt sich das aber nicht so einfach so genau sagen, weshalb normalerweise immernoch nur highway=bus_stop erfasst wird. Ausserdem werden Haltestellen im neuen Schema (noch) nicht im osm.org-Style dargestellt, weshalb meistens auch noch an der Mastposition (also wenn es keine Fläche ist am public_transport=platform) highway=bus_stop eingetragen wird.

Also nochmal alles zusammengefasst: Erfasse an der Mastposition highway=bus_stop. Wenn du erkennen kannst, wo die Fahrzeugspitze zum Halten kommt, erfasse diese Stelle mit public_transport=stop_position und am highway=bus_stop zusätzlich public_transport=platform. Wenn du einen Bussteig erkennen kannst erfasse diesen als public_transport=platform area=yes (hierbei highway=bus_stop ohne public_transport=stop_position). In letzterem Fall lässt sich auch fast immer zumindest eine Halteposition erkennen.

Und natürlich zum Schluss noch das, was ich auch gerne vergesse: Wenn bei einer Haltestelle irgendwas mit public_transport=* erfasst ist kommen alle Objekte dieser Haltestelle in eine Relation mit type=public_transport=stop_area, die auch z.B. das name=* erhält.

Schina02 wrote:

2. Und wenn ich das einsetze, falls mir die Erklärung einleuchtet, was ist mit Stopposition gemeint? Da wo der Bus mit seiner Front zum Stehen kommt? Oder mit dem Eingangsbereich? Oder mit seinem Mittelpunkt?

Fahrzeugspitze.

Schina02 wrote:

3. Wie mache ich das mit den Relationen für die einzelnen Haltestellen: eine Straße, eine Bushaltestelle für jede Richtung die mehr oder weniger gegenüber liegen, die mache ich in eine Relation (oder doch nicht?). Aber wie weit auseinander dürfen die sein um noch in eine Relation gehören zu dürfen? Und gehört in die Relation auch highway=bus_stop mit rein?

In eine stop_area-Relation darf alles rein, was zur Haltestelle gehört, also auch highway=bus_stop oder amenity=shelter. Eine stop_area stellt eine Haltestelle dar, also üblicherweise alles, was den selben Namen hat. Schon eine kleine Abweichung (z.B. "Käfertal Bahnhof" und "Käfertal Bahnhof (RNV)") ist ein Zeichen dafür, dass es zwei getrennte Haltestellen sind, bei der dann die stop_area über eine stop_area_group zusammengefasst werden.

Schina02 wrote:

4. In die Routen-Relation für die einzelnen Buslinien, was kommt da alles rein? Die Straßen, klar, aber auch highway=bus_stop? Und noch mehr wie die Relation der ganzen Haltestelle oder die Plattform oder was?

Zuerst alle Halte in der richtigen Reihenfolge: Wenn nur ein highway=bus_stop erfasst ist dieses mit der Rolle "stop", sonst erst das p_t=stop_position mit der Rolle "stop" und direkt darauffolgend das p_t=platform mit der Rolle "platform".

Nach allen Halten kommen dann alle genutzen Verkehrswege: Diese müssen ebenfalls in der richtigen Reihenfolge sein (also vom ersten genutzten Way durchgägnig bis zum letzten genutzten Way). Wenn dabei ein Way mehrmals genutzt wird muss er also auch mehrfach enthalten sein.

Und weil darum hier irgendwo gebeten wurde: Für ein Beispiel kannst du im Prinzip jede Buslinie in Mannheim, Ludwigshafen und Heidelberg nutzen (Linien 11 bis 20 und 27 bis 97). Bevorzugt eine ohne fixme=* 😉

@geri-oc: Ja.

geri-oc wrote:

Für jede Richtung eine Relation?
Dann hat eine Linie mindestens 2 Relationen - wenn die Schulbusroute gefahren wird kommen noch einmal 2 Relationen dazu?

Ja. Das ist eine der brandaktuellen Neuerungen des Oxomoa-Entwurfs. Entwickelt AD 2009.

Bevor jemand anders daran erinnern muß: Oxomoa ist längst überholt, aber "eine Relation je Fahrtrichtung" ist bei allen weiteren Entwicklungen geblieben.

geri-oc wrote:

Und wie unterscheide ich dann auf einer Straße die Haltestellen der unterschiedlichen Richtung?
Für jede Richtung eine Relation?
Dann hat eine Linie mindestens 2 Relationen - wenn die Schulbusroute gefahren wird kommen noch einmal 2 Relationen dazu?

Ah. Du meinst die alte Art, sowas zu mappen. Die ist auch OK. Entschuldige bitte, die hatte ich nicht berücksichtigt. Dann gelten die folgenden Regeln (die schon etwas einschränkend sind):

- Es gibt dann nur eine Relation pro Linie. Insbesondere gibt es keine Master-Route.
- alle Nodes sind Haltestellen (und alle Haltestellen sind Nodes).
- alle Ways sind Fahrzeugwege.
- Flächen und Relationen gehören da nicht rein.
- Die Sortierung der Elemente bedeutet nichts.
- eine Haltestelle kann die Rolle "stop" oder "forward_stop" oder "backward_stop" haben. Es gibt kein "platform". Anhängen darf man dabei noch ":1", ":2" usw., um eine Reihenfolge anzugeben.
- Linien haben die Tags "forward", "backward" oder "". Das gibt an, ob das Wegstück in oder gegen die OSM-Richtung durchfahren wird. "" bedeutet dabei "beide Richtungen" in Sinne von "von links nach rechts und von rechts nach links". Anders als bei den Haltestellen hat das "forward" und "backward" hier nichts mit Hin- und Rückweg zu tun.
- Es gibt noch einige "Ergänzungs-Rollen". Da kommen das Rollen wie "forward_stop:17;alternate" vor... da wird's dann langsam hässlich...

Das alte Schema ist für nicht allzu komplizierte Buslinien auch nicht sooo schlecht. Schlimm ist es aber, beides zu vermischen. Dann weiß kein Programm mehr, was eine Linie mit leerer Rolle jetzt bedeutet und ob die Reihenfolge eine Bedeutung hat.

MfG
Weide

Fahrzeugspitze.

Da die Fahrzeugspitze oft Fahrzeugabhängig ist, habe ich mir angewöhnt einen Punkt zu wählen, bei dem man immer Einsteigen kann.

Jimmy_K wrote:

Fahrzeugspitze.

Da die Fahrzeugspitze oft Fahrzeugabhängig ist, habe ich mir angewöhnt einen Punkt zu wählen, bei dem man immer Einsteigen kann.

Bei Schienenfahrzeugen ist die Halteposition über das Signal Ne5 (ESO) bzw. Sh7 (SOStrab) festgelegt. Diese bestimmen, an welcher Stelle ±5m die Fahrzeugspitze zum stehen kommen soll. Das ist also immer gleich und auch ohne ein haltendes Fahrzeug feststellbar. Dass wir nicht erfassen wollen was für Fahrzeuge auf einer Linie verkehren hatten wir ja kürzlich festgestellt.

Bei Bushaltestellen mit Blindenleitstreifen ist die Position der ersten Tür besonders markiert. Dort lässt sich also auch die Fahrzeugspitze relativ genau vor Ort ohne Fahrzeug feststellen. Hinzu kommt, dass die Fahrzeugspitze bei Bussen oft fast die erste Tür ist (Abweichung ca. 1m) und Fahrzeuge bei denen die erste Fahrgasttür weiter hinten ist trotzdem oft genauso halten.

Ausserdem soll sie stop_position eher Navigationsanwendungen als Fahrgästen dienen.

rayquaza wrote:

Jimmy_K wrote:

Fahrzeugspitze.

Da die Fahrzeugspitze oft Fahrzeugabhängig ist, habe ich mir angewöhnt einen Punkt zu wählen, bei dem man immer Einsteigen kann.

Bei Schienenfahrzeugen ist die Halteposition über das Signal Ne5 (ESO) bzw. Sh7 (SOStrab) festgelegt. Diese bestimmen, an welcher Stelle ±5m die Fahrzeugspitze zum stehen kommen soll. Das ist also immer gleich und auch ohne ein haltendes Fahrzeug feststellbar.

Dann schau dir doch mal so eine Örtlichkeit an. Je nachdem wo der Zugang ist gibt es verschiedene dieser Haltetafeln. Kurzzug, 3/4 Zug, Vollzug, 4 Wagen, 6 Wagen, Fahrzeugtypabhängig oder schlicht nach Gesamtlänge in Metern. Und das waren jetzt nur die Beispiele für Berlin.
Eindeutig ist also eindeutig anders!

Es ist trotzdem objektiver feststellbar als eine Stelle an der man "immer" einsteigen kann (was eh nicht Sinn des public_transport=stop_position ist).

Es führt auch zu Konflikten, wenn der Bahnsteig in 2 Richtungen benutzt wird. Dann muss es nämlich 2 stop_position geben.

Jimmy_K wrote:

Es führt auch zu Konflikten, wenn der Bahnsteig in 2 Richtungen benutzt wird. Dann muss es nämlich 2 stop_position geben.

Mehrere stop_positions: Ja. Einen Konflikt sehe ich da allerdings nicht. Es sind eben verschiedene Stellen an denen man hält.

Beim Erfassen von Einstiegsmöglichkeiten (von denen es viel mehr gibt wenn man alle erfassen will) gibt es auch Situationen, bei denen es nicht passt. Z.B. Bahnsteige an denen 423 und 425 halten. Erstere haben die Modulanordnung
FTFFTFFTF, letztere
FFTFFFTFF (F=Fenster, T=Tür) – bei gleicher Fahrzeuglänge, also gleichem Halteplatz. Durch die Untereinanderschreibung sieht man schön, dass die Türen nie zusammen passen, man also danach auch mehrere Positionen erfassen müsste oder den Punkt einfach irgendwo innerhalb der 400m Bahnsteiglänge platziert – da ist die Erfassung der Halteposition sinnvoller und (wie schon geschrieben) nebenbei der eigentlichen Bedeutung entsprechend.

rayquaza wrote:

Mehrere stop_positions: Ja. Einen Konflikt sehe ich da allerdings nicht. Es sind eben verschiedene Stellen an denen man hält.

Ist das auf den Bahnhöfen nicht genau so? Da gibt es doch diese H-Schilder, die dem Lokführer zeigen, wo der Haltepunkt ist. Davon auch manchmal mehrere am selben Gleis für z.B. Kurzzüge.

Keine Ahnung, ob und ggf. wie das bei OSM umgesetzt wird, aber man sollte das bei Bussen und Straßenbahnen identisch machen machen.

ym2c
Walter

wambacher wrote:

Ist das auf den Bahnhöfen nicht genau so? Da gibt es doch diese H-Schilder, die dem Lokführer zeigen, wo der Haltepunkt ist. Davon auch manchmal mehrere am selben Gleis für z.B. Kurzzüge.

Ja, genau dahin sind wir inzwischen abgedriftet 😉

rayquaza wrote:

wambacher wrote:

Ist das auf den Bahnhöfen nicht genau so? Da gibt es doch diese H-Schilder, die dem Lokführer zeigen, wo der Haltepunkt ist. Davon auch manchmal mehrere am selben Gleis für z.B. Kurzzüge.

Ja, genau dahin sind wir inzwischen abgedriftet 😉

jau, kommt davon, wenn man die Chausse nur mal kurz überfliegt. naja, falsch war es immerhin nicht.

Gruss
walter

Ich hatte damit nicht die Türen gemeint, sondern eine Stelle, an welcher in jedem Fall ein Wagen zum Stehen kommt.
Für mich spricht nichts dagegen sämtliche Haltepunkte einzutragen, nur sollten wir ein Mapping-Schema finden, mit welchem die Karten und App-Hersteller etwas anfangen können, denn die Schilder gehören nicht zum public-transport sondern zu railway (siehe taggingvorschlag openrailwaymap)

Lg Jimmy

Anwendungen ist ein gutes Stichwort. Eine mögliche Nutzung der stop_positions wäre die Anzeige der Strecke bis zum nächsten Halt (also im Display für den Fahrer). Als "Position des Haltes" sieht man als Fahrer aus den in Antwort 16 genannten Gründen (und weil man selbst dann etwa an dieser Stelle ist) die Position der Fahrzeugspitze. Für den Anwendungsfall "Wo am Bahnsteig kann ich das Fahrzeug betreten" wäre imo das public_transport=stop_position ungeeignet, da dafür ein Node an der Bahnsteigfläche besser wäre.

In Karten dargestellt werden sollten die stop_positions eigentlich eh nicht (ausser evtl. in Spezialkarten).

Dass die Ne5/Sh7 nicht zum PT-Tagging gehören stimmt, aber bedenke, dass es auch Ne5 an Gleisen ohne Bahnsteig gibt und Bahnsteige ohne Ne5 (aber z.B. mit Empfehlungen oder allgemein üblichen Halteplätzen). Da sollte das auch richtig funktionieren. Ähnliches gilt für Bahnsteige: Es gibt auch Bahnsteige ohne Personenverkehr (die ich zur Klarstellung mit public_transport=no erfasse).

Fürs Mapping finde ich die Erfassung so genauer stop_positions teilweise selbst unschön: An meinem Heimatbahnhof gibt es Empfehlungstafeln für 70m (also "Kurzzüge") und "Vollzüge" halten am Bahnsteigende (zweite stop_position). Welche soll nun für eine Linie auf der beides vorkommt in die route-Relation? 😄

wambacher wrote:

Ist das auf den Bahnhöfen nicht genau so? Da gibt es doch diese H-Schilder, die dem Lokführer zeigen, wo der Haltepunkt ist. Davon auch manchmal mehrere am selben Gleis für z.B. Kurzzüge.

...oder aber wie mein Heimatbahnhof. Da sind keine H-Tafeln... Ja das gibt es... Mein "Informant" bei der DB zuckte mit den Schultern und meinte, daß muß nicht mehr unbedingt sein.

Sven

rayquaza wrote:

Anwendungen ist ein gutes Stichwort. Eine mögliche Nutzung der stop_positions wäre die Anzeige der Strecke bis zum nächsten Halt (also im Display für den Fahrer). Als "Position des Haltes" sieht man als Fahrer aus den in Antwort 16 genannten Gründen (und weil man selbst dann etwa an dieser Stelle ist) die Position der Fahrzeugspitze.

Aber diese vorgeschlagene Anwendung muss fehlschlagen, weil sie Fehzeugtyp abhängig ist.
Nachher wird die Stopposition in einer route aufgenommen, welche völlig unabhängig vom Farhrzeug ist. Denn es interessiert ja keinen ob die Linie früh un spät mit Kuzzügen befahren wird und zum Berufsverkehr Langzüge zum Einsatz kommen.

Welchen Sinn macht so eine Stopposition überhaupt? Eigentlich geht es nur darum eine Möglichkeit zu finden den Weg mit der Zugangsstelle (Mast oder Bahnsteig) zu verbinden. Eine Reihe nachgelagerter System arbeitet einfach mit Punkten auf der befahrenen Strecke und nicht mit Punkten daneben, wo der Fußgänger warten kann.
(Da wären solche Dinge wie der Zugmonitor oder aber auch Importschnittstellen zu PTV Visum und ähnlichen Systemen)
Da aber die Strecke manchmal auch in beiden Richtungen verläuft, lässt sich aus einer Stopposition nicht auf die Seite der Warteposition (pt=platform) schließen.

streckenkundler wrote:

...oder aber wie mein Heimatbahnhof. Da sind keine H-Tafeln... Ja das gibt es... Mein "Informant" bei der DB zuckte mit den Schultern und meinte, daß muß nicht mehr unbedingt sein.

Genau!

http://www.rp-online.de/panorama/deutsc … -1.1311917
http://www.shortnews.de/id/638001/einfa … an-bahnhof

jetzt versteh ich einiges. 😉

Gruss
walter

EDIT: Smily added, da manche anscheinend keinen Spaß erkennen (wollen?)

wambacher wrote:

streckenkundler wrote:

...oder aber wie mein Heimatbahnhof. Da sind keine H-Tafeln... Ja das gibt es... Mein "Informant" bei der DB zuckte mit den Schultern und meinte, daß muß nicht mehr unbedingt sein.

Genau!

http://www.rp-online.de/panorama/deutsc … -1.1311917
http://www.shortnews.de/id/638001/einfa … an-bahnhof

jetzt versteh ich einiges.

Gruss
walter

Nur mal zur Klarstellung: An der sogenannten H-Tafel muss nicht jeder Zug halten. Die Zughalte an bestimmten Bahnhöfen ergeben sich aus dessen Fahrplan. Signal Ne 5 bedeutet "Kennzeichnung des Halteplatzes der Zugspitze bei planmäßig haltenden Zügen".
http://www.tf-ausbildung.de/SignalbuchOnline/ne5.htm

Hallo,
ich habe mich schon lange im Forum nicht mehr aktiv beteiligt, aber viel mit gelesen. 🙁

Nun habe ich eine Frage, die mir trotz intensiver Recherche, unklar ist.

Normalerweise kommt der node stop_position an die Straße (way). Wie ist es nun, wenn die Straße mit area=yes gemappt wurde. Wie muss ich dann verfahren?

Gruß Rainer

surveyor54 wrote:

Normalerweise kommt der node stop_position an die Straße (way). Wie ist es nun, wenn die Straße mit area=yes gemappt wurde. Wie muss ich dann verfahren?

Also ist die "Strasse" ein Platz? Weil wenn eine normale strassenförmige Strasse mit area=yes gemappt ist ist das schon falsch 😉
Bei einem Platz würde ich die stop_position dann auf der Fläche des Platzes an die richtige Stelle setzen (also nicht in den Way einbinden). Das ist aber nicht wirklilch definiert. Je nach den genauen Gegebenheiten kann man vielleicht auch Begründen, dass dort ein Weg über den Platz führt, an vielen Plätzen geht das aber nicht.

Danke,
dann werde ich es so handhaben.
Übrigens, richtig erkannt, die Straße ist ein Platz.

Gruß
Rainer

surveyor54 wrote:

Normalerweise kommt der node stop_position an die Straße (way). Wie ist es nun, wenn die Straße mit area=yes gemappt wurde. Wie muss ich dann verfahren?

Wenn da gar keine Buslinie gemappt ist, ist ziemlich egal.

Sobald es da eine Buslinie gibt, sollte auch ihr Fahrweg gemappt werden und dafür kann man keine Flächen angeben (da die Endpunkte der Fahrwegstücke im Public-Transport-Schema indirekt die Fahrtrichtung definieren). Da gehört also -- notfalls ohne Tags -- ein extra Way hin, der den Fahrweg angibt. Auf diesen Way gehört dann die stop_position.

Weide

viw wrote:

Welchen Sinn macht so eine Stopposition überhaupt?

Ich glaube nicht, dass sie einen Sinn hat. Wenn es ein Routing für ÖPNV-Verkehrsmittel geben könnte (wenn man also aus irgendwelchen Eigenschaften der Knoten und Kanten des Graphen eine irgendwie optimale Route berechnen könnte), dann wäre es sinnvoll. ÖPNV-Routing ohne Fahrplan ist aber Quatsch.

Weide

Ich wollte mal bei uns eine ÖPNV-Route mappen, habe es aber aufgegeben. Angefangen damit dass eine amenity=bus_station in dem System anscheinend nicht vorgesehen ist und der Tatsache dass ich einen wenige Meter langen service-road in 12 Teile teilen müsste für jeden Bussteig, bis zur Problematik mit Kreiseln.

Prince Kassad wrote:

Ich wollte mal bei uns eine ÖPNV-Route mappen, habe es aber aufgegeben. Angefangen damit dass eine amenity=bus_station in dem System anscheinend nicht vorgesehen ist und der Tatsache dass ich einen wenige Meter langen service-road in 12 Teile teilen müsste für jeden Bussteig, bis zur Problematik mit Kreiseln.

Das kommt dadurch, dass die Dokumentation dazu furchtbar ist. Den highway=service müsstest du nämlich nicht so oft aufteilen und amenity=bus_station ist ebendo wie highway=bus_stop kompatibel damit.

Weide wrote:

viw wrote:

Welchen Sinn macht so eine Stopposition überhaupt?

Ich glaube nicht, dass sie einen Sinn hat. Wenn es ein Routing für ÖPNV-Verkehrsmittel geben könnte (wenn man also aus irgendwelchen Eigenschaften der Knoten und Kanten des Graphen eine irgendwie optimale Route berechnen könnte), dann wäre es sinnvoll. ÖPNV-Routing ohne Fahrplan ist aber Quatsch.

Unterscheide zwischen "Fussgänger-Routing mit Benutzung des ÖPV" und "Navigationsanweisungen für den ÖPV". Für letzteres bräucht man die aber mEn auch nur in relativ seltenen Fällen unbedingt, für ersteres sind die stop_positions irrelevant.

Weide wrote:

Sobald es da eine Buslinie gibt, sollte auch ihr Fahrweg gemappt werden und dafür kann man keine Flächen angeben (da die Endpunkte der Fahrwegstücke im Public-Transport-Schema indirekt die Fahrtrichtung definieren).

Doch, kann man: Bei einer Fläche sind dann alle Nodes mögliche Endnodes, und dann bräuchte man eben ein Flächenrouting vom Endnode des vorherigen Ways zu dem richtigen der beiden Endnodes des darauffolgenden Ways.

rayquaza wrote:

Das kommt dadurch, dass die Dokumentation dazu furchtbar ist.

Das auch. Nirgends ist auch nur irgend ein anschauliches Beispiel, wo man wirklich versteht, wie das ganze System nun funktioniert. Stattdessen ist man quasi komplett auf sich alleine gestellt.

rayquaza wrote:

Den highway=service müsstest du nämlich nicht so oft aufteilen und amenity=bus_station ist ebendo wie highway=bus_stop kompatibel damit.

Ich hätte da jetzt ein Beispiel aus dem Ort aufgezeigt, aber ich sehe gerade dass jemand wegen einer Baustelle den kompletten Busbahnhof (mitsamt aller Ways) gelöscht hat. Soviel dazu...

rayquaza wrote:

Unterscheide zwischen "Fussgänger-Routing mit Benutzung des ÖPV" und "Navigationsanweisungen für den ÖPV". Für letzteres bräucht man die aber mEn auch nur in relativ seltenen Fällen unbedingt, für ersteres sind die stop_positions irrelevant.

Ich würde 3 Sachen unterscheiden:

- Passagierrouting vom Start zum Ziel. Das kann man nicht anhand der Streckeneigenschaften machen, man braucht den Fahrplan.

- Passagierrouting beim Umsteigen und am Anfang und Ende der Fahrt. Das ist sinnvoll und man braucht vom ÖPV-Kram nur die Platforms.

- Routing der ÖPV-Fahrzeuge. Da die Route komplett angegeben wird, gibt es nichts zu routen.

Bei keinem der drei spielt die stop_position eine wichtige Rolle.

Doch, kann man: Bei einer Fläche sind dann alle Nodes mögliche Endnodes, und dann bräuchte man eben ein Flächenrouting vom Endnode des vorherigen Ways zu dem richtigen der beiden Endnodes des darauffolgenden Ways.

Ja, seh' ich ein, man könnte. Es steht wohl auch nicht explizit im Vorschlag, dass das verboten ist. Ich hab' nur den Eindruck, dass niemand die Möglichkeit einkalkuliert hat und das es damit unnötig kompliziert würde. Andererseits haben wir diese Komplikationen schon, wenn wir die Besonderheiten der kompletten Kreisverkehre akzeptieren. Schwierig...

Weide

Moin,

rayquaza wrote:

Doch, kann man: Bei einer Fläche sind dann alle Nodes mögliche Endnodes, und dann bräuchte man eben ein Flächenrouting vom Endnode des vorherigen Ways zu dem richtigen der beiden Endnodes des darauffolgenden Ways.

... unter Einbeziehung der Haltesstelle oder Stop-Position.
Die kann ja auch auf der Fläche abseits der optimalen Verbindung zwischen den Endnotes der angrenzenden ways liegen.

Weide wrote:

Andererseits haben wir diese Komplikationen schon, wenn wir die Besonderheiten der kompletten Kreisverkehre akzeptieren. Schwierig...

Wieso Komplikation und schwierig?
Eintrittspunkt, Weg, vorgegebene Wegrichtung und Austrittspunkt sind dort doch eindeutig gegeben.
Aber auch dort müsste eine ggf. abseits liegende Haltestelle mit berücksichtigt werden, ist aber doch auch kein Problem.

stop_position ist im Grunde nur eine Vereinfachung für ÖPNV, um nicht zur Platform-Position routen zu müssen.
Genauso könnte man die way-Segmente in Frage stellen - braucht man doch nur zur Visualisierung der tatsächlich gefahrenen Route.
Weder Passagier noch ÖPNV braucht sie zum "Routing" - das ist doch allein durch die Haltestellen (und den Fahrplan) bestimmt.

Gruß
Georg

Weide wrote:

- Routing der ÖPV-Fahrzeuge. Da die Route komplett angegeben wird, gibt es nichts zu routen.
Bei keinem der drei spielt die stop_position eine wichtige Rolle.

Neben dem von GeorgFausB genannten: Für die Information wo das Fahrzeug halten soll braucht man die da 😉

Weide wrote:

Es steht wohl auch nicht explizit im Vorschlag, dass das verboten ist. Ich hab' nur den Eindruck, dass niemand die Möglichkeit einkalkuliert hat und das es damit unnötig kompliziert würde.

Das ist identisch zum "normalen" Flächenrouting: Das wird auch meist ignoriert.

GeorgFausB wrote:

Genauso könnte man die way-Segmente in Frage stellen - braucht man doch nur zur Visualisierung der tatsächlich gefahrenen Route.
Weder Passagier noch ÖPNV braucht sie zum "Routing" - das ist doch allein durch die Haltestellen (und den Fahrplan) bestimmt.

Ne, ist es nicht. Das hatten wir schonmal irgendwo diskutiert 😉