Busbahnhof

Hi,

nicht ganz. Schau dir mal die Vorlage an:

http://www.wetzlar.de/showobject.phtml? … 84.1&sub=0
(Ähnlichkeiten sind rein zufällig...)

Ich würde aber die Busse nicht so deutlich darstellen, stattdessen die Haltestelleninsel als Fläche eintragen.

Generell bevorzuge ich die Mastpositionen, und packe die dann in die Linienrelationen.
Das tagging des Busbahnhof-Knotens ist auch ein wenig daneben.

Nebenbei:
Aus den zwei Bahnhöfen der DB sollte man besser einen machen, mit entsprechenden Haltpositionen.

EDIT: Die Einbahnstraße stimmt wohl auch nicht.

gruß,
ajoessen

Entspricht irgendwie nicht ganz den mir bekannten üblichen Varianten.

Bei der Area geht es ja glaube ich primär darum, dass die Fläche überdacht ist, ich kenne keine Taggingweisen dafür. Eine Möglichkeit wäre, die "amenity=bus_station" auf die Area anzuwenden.
Auch verdammt eigen: ""public_transport=station"="bus=yes""
Dann würde ich auch noch das amenity aus der Relation für die Bus Routen rausnehmen, ist glaube ich auch ziemlich unüblich / veraltet.

Die stop_position gehört auf jeden Fall auf eine Straße (und wenn man zu jeder "Parkbucht" einen eigenen 10m langen weg legt, hatte ich auch schon gesehen).

Ich hoffe, dass die Verwendung des Bildes dafür zugelassen wurde, denn das Copyright im Impressum sagt definitiv nein.

Soweit meine Meinung.

EDIT:
@DB Bahnhof: Oder nur die Stop_position und dann eine Bahnhofsrelation.

ajoessen wrote:

Hi,

nicht ganz. Schau dir mal die Vorlage an:

http://www.wetzlar.de/showobject.phtml? … 84.1&sub=0
(Ähnlichkeiten sind rein zufällig...)

Ich würde aber die Busse nicht so deutlich darstellen, stattdessen die Haltestelleninsel als Fläche eintragen.

Meinst Du mit Haltestelleninseln die 'public_transport=platform'. Wenn geschlossen gelten die eh als Flächen.

Hi,

hat mich jetzt doch gefuchst. Würde wie folgt ändern.

- aus den 4 Routen den Node (129416098) des BusBahnhofs (BB) löschen.

- den highway=residential 'Bahnhofstraße', da wo die Einbahnstraße zum BB abzweigt und mündet auftrennen. Die Teile dazwischen aus den 4 Routen entfernen. Die Einbahnstraße des BB am node 1655875160 ebenfalls trennen und den node weiter nach rechts bis auf Höhe des node 1656224112 (stop_position) ziehen, da hier wohl die Route 200 endet. Die entsprechenden Teile der Einbahnstraße dann in die Routen einfügen.

- die Tags des BB-nodes auf die Fläche übertragen und den node löschen. Area=yes an der Fläche löschen.

- die stop_position entsprechend auf den way. Einige davon müßten dann noch den Routen zugeordnet werden, soweit feststellbar. Der node für die Route 200 ist klar.

- die kleinen area=yes Flächen (tagging ist mir eh unklar, war immer der Meinung, daß da noch ein way dazugehört ), würde ich ersatzlos streichen, da offensichtlich reiner Busverkehr.

Was ich an diesen und ähnlichen threads nicht verstehe:
Warum kontaktiert man nicht immer zuerst den Urherber (vor dem öffentlichen Runtermachen)?
Ist das so schwierig, speziell in diesem Falle??

Ich weiß zwar nicht, was das mit öffentlichem Runtermachen zu tun hat, man muss ja zu der Arbeit stehen, die man gemacht hat und vermutlich auch seinen Grund dafür haben. Mir persönlich ist es mir definitiv lieber, über eine Arbeit von mir wird hier im Forum, oder auf der Mailingliste diskutiert und nicht einfach von jemanden, der meint die Wahrheit für sich gepachtet zu haben, ohne mir bescheid zu geben editiert.

Von meiner Seite kann ich sagen, ich hab in grenzwertigen Fällen 2 User angeschrieben und noch von keinem eine Antwort bekommen!

kellerma wrote:

Was ich an diesen und ähnlichen threads nicht verstehe:
Warum kontaktiert man nicht immer zuerst den Urherber (vor dem öffentlichen Runtermachen)?
Ist das so schwierig, speziell in diesem Falle??

Verstehe Deine Reaktion nicht. Hatte geschrieben: Würde ...

Und öffentliches Runtermachen ist das IMHO schon gar nicht.
Du hättest eher auf das was nach 'würde' folgt eingehen sollen. War eigentlich mein Gedanke.
Je nach Ergebnis hätte ich den Urheber in dieser Sache auch angeschrieben oder die Finger davon gelassen.

Andererseits schreibe ich wegen 'intersections' niemand an. Das wäre zu viel Aufwand.
Schafft endlich grundlegende Regeln, dann wäre da IMHO weniger zu tun. Das Wiki selbst ist in vielen Fällen auch keine Hilfe (mehrdeutig, zerfleddert).

BTW, meine Erfahrung mit Anschreiben: 60% antworten.

Radeln wrote:

Meinst Du mit Haltestelleninseln die 'public_transport=platform'. Wenn geschlossen gelten die eh als Flächen.

Josm stellt sie als Ring dar, nicht als Fläche.

gruß,
ajoessen

ajoessen wrote:

Radeln wrote:

Meinst Du mit Haltestelleninseln die 'public_transport=platform'. Wenn geschlossen gelten die eh als Flächen.

Josm stellt sie als Ring dar, nicht als Fläche.

Kann IMHO nicht das Kriterium sein.

Laut Wiki auch als Fläche. Weiter unten steht dann, 'können' mit area=yes bei breiten Bahnsteigen zur besseren Darstellung. Frage mich allerdings, was so was soll. Mappen für Renderer oder JOSM.

Radeln wrote:

ajoessen wrote:

Radeln wrote:

Meinst Du mit Haltestelleninseln die 'public_transport=platform'. Wenn geschlossen gelten die eh als Flächen.

Josm stellt sie als Ring dar, nicht als Fläche.

Kann IMHO nicht das Kriterium sein.

Laut Wiki auch als Fläche. Weiter unten steht dann, 'können' mit area=yes bei breiten Bahnsteigen zur besseren Darstellung. Frage mich allerdings, was so was soll. Mappen für Renderer oder JOSM.

Mapnik stellt Bahn-Plattformen auch nur dann als Fläche dar, wenn area=yes dran steht, sonst als Ring.

Will sagen: Wen es schon 2 Anwendungen gibt, die auf area=yes bestehen, sollte man es nicht als implizit voraussetzen.

Bei Gebäuden ist klar, dass die Linie Weg immer eine Fläche beschreibt, bei Wegen ist es eben nicht eindeutig. Deshalb area=yes dran, und alle wissen Bescheid.

Gruß,
ajoessen

ajoessen wrote:

Radeln wrote:

ajoessen wrote:

Josm stellt sie als Ring dar, nicht als Fläche.

Kann IMHO nicht das Kriterium sein.

Laut Wiki auch als Fläche. Weiter unten steht dann, 'können' mit area=yes bei breiten Bahnsteigen zur besseren Darstellung. Frage mich allerdings, was so was soll. Mappen für Renderer oder JOSM.

Mapnik stellt Bahn-Plattformen auch nur dann als Fläche dar, wenn area=yes dran steht, sonst als Ring.

Will sagen: Wen es schon 2 Anwendungen gibt, die auf area=yes bestehen, sollte man es nicht als implizit voraussetzen.

Bei Gebäuden ist klar, dass die Linie Weg immer eine Fläche beschreibt, bei Wegen ist es eben nicht eindeutig. Deshalb area=yes dran, und alle wissen Bescheid.

Auch bei 'landuse'. Aber auch da findet man area=yes.
Und wenn das so ist, sollte es im Wiki auch eindeutig und nicht so schwammig, wie so vieles, dokumentiert werden.

BTW, betreff Posting #5 hat sich noch keiner klar geäußert. Methode oder Ignoranz?

Radeln wrote:

Hi,

hat mich jetzt doch gefuchst. Würde wie folgt ändern.

- aus den 4 Routen den Node (129416098) des BusBahnhofs (BB) löschen.

Nur, wenn man ersatzweise die Mastpositionen einträgt, und diese in die Routenrelationen einbindet.

- den highway=residential 'Bahnhofstraße', da wo die Einbahnstraße zum BB abzweigt und mündet auftrennen. Die Teile dazwischen aus den 4 Routen entfernen. Die Einbahnstraße des BB am node 1655875160 ebenfalls trennen und den node weiter nach rechts bis auf Höhe des node 1656224112 (stop_position) ziehen, da hier wohl die Route 200 endet. Die entsprechenden Teile der Einbahnstraße dann in die Routen einfügen.

Die Einbahnstraße ist keine, für die Busse, die an Bussteig 1-3 und 10-12 halten. Also "oneway" ganz weg, und alle Busse einmal die Schleife fahren lassen.

- die Tags des BB-nodes auf die Fläche übertragen und den node löschen. Area=yes an der Fläche löschen.

Nei, Bushaltetags sind besser an Knoten aufgehoben. Sonst erscheint die Umrandung als Linienweg.

- die stop_position entsprechend auf den way. Einige davon müßten dann noch den Routen zugeordnet werden, soweit feststellbar. Der node für die Route 200 ist klar.

Wenn man die Mastposition eingetragen hat, ja. Sonst ist mir die stop_position zu weit weg von der Haltestelleninsel. Die Straße ist nun mal ziemlich breit hier.

- die kleinen area=yes Flächen (tagging ist mir eh unklar, war immer der Meinung, daß da noch ein way dazugehört ), würde ich ersatzlos streichen, da offensichtlich reiner Busverkehr.

Ja, die sollen im Ursprungsplan jeweils Busse darstellen -> bewegliche Gegenstände haben nichts in OSM verloren. Man kann natürlich auch Busspuren durch diese Haltebuchten führen, statt dem Weg in der Mitte.

Gruß,
ajoessen

Radeln wrote:

Und wenn das so ist, sollte es im Wiki auch eindeutig und nicht so schwammig, wie so vieles, dokumentiert werden.

ich finde

area yes / no wenn die Platform vom Typ area ist zwingend, wenn es eine Area ist, default: 'no'

schon eindeutig.

Gruß,
ajoessen

ajoessen wrote:

Radeln wrote:

- die Tags des BB-nodes auf die Fläche übertragen und den node löschen. Area=yes an der Fläche löschen.

Nei, Bushaltetags sind besser an Knoten aufgehoben. Sonst erscheint die Umrandung als Linienweg.

Der zentrale BB-node ist hier gemeint und der enthält kein Bushaltetag.

Radeln wrote:

ajoessen wrote:

Radeln wrote:

- die Tags des BB-nodes auf die Fläche übertragen und den node löschen. Area=yes an der Fläche löschen.

Nei, Bushaltetags sind besser an Knoten aufgehoben. Sonst erscheint die Umrandung als Linienweg.

Der zentrale BB-node ist hier gemeint und der enthält kein Bushaltetag.

Jein, Name und Routenmitgliedschaften.

Gruß,
ajoessen

Wenn man die "Busse" entfernen würde, wären somit auch die Haltepositionen der Linien verloren. Bei so einem großen Busbahnhof sind die aber in meinen Augen sehr wichtig. Ein Vorschlag meinerseits, für diesen Fall (keine Ahnung, ob das schon einmal so umgesetzt worden ist):

Jimmy_K wrote:

Wenn man die "Busse" entfernen würde, wären somit auch die Haltepositionen der Linien verloren. Bei so einem großen Busbahnhof sind die aber in meinen Augen sehr wichtig. Ein Vorschlag meinerseits, für diesen Fall (keine Ahnung, ob das schon einmal so umgesetzt worden ist):

Ist ein wenig sehr ausführlich. Ein Weg durch alle Haltebuchten würde m.E. reichen. Es sind ja schliesslich keine baulich abgetrennten Spuren vorhanden.

Die Mastpositionen sind da schon besser, weil örtlich vorhanden/nachprüfbar.

Gruß,
ajoessen

Jetzt weiß ich, was du mit "Mast" meinst (Deutsch->Österreichisch 😉), wie taggst du selbige? Habe die Wiki durchforstet und finde überall nur die Möglichkeit "platform", welche ja schon für den eigentlich Bahnsteig genutzt wird.
Den Bahnsteig aufsplitten (jede Haltebucht eine Platform) und dann alle mittels einem Multipolygon zusammensetzen (kenne ich jetzt so von manchen Bahnhöfen)?

ajoessen wrote:

Jimmy_K wrote:

Wenn man die "Busse" entfernen würde, wären somit auch die Haltepositionen der Linien verloren. Bei so einem großen Busbahnhof sind die aber in meinen Augen sehr wichtig. Ein Vorschlag meinerseits, für diesen Fall (keine Ahnung, ob das schon einmal so umgesetzt worden ist):

Ist ein wenig sehr ausführlich. Ein Weg durch alle Haltebuchten würde m.E. reichen. Es sind ja schliesslich keine baulich abgetrennten Spuren vorhanden.

Die Mastpositionen sind da schon besser, weil örtlich vorhanden/nachprüfbar.

Es geht ja kreuz und quer.

Laut Wiki gehören Haltepunkte auf die Straße und nicht daneben, auch wenn da Haltebuchten sind. Ergibt sich aus dem englischen Wiki. Im deutschen fehlt dieser Hinweis.

ajoessen wrote:

Radeln wrote:

ajoessen wrote:

Nei, Bushaltetags sind besser an Knoten aufgehoben. Sonst erscheint die Umrandung als Linienweg.

Der zentrale BB-node ist hier gemeint und der enthält kein Bushaltetag.

Jein, Name und Routenmitgliedschaften.

Name wäre dann an der Fläche und die Routenmitgliedschaften der einzelnen Haltepunkte müßten dann noch zugeordnet werden, hatte ich ja geschrieben.

Jimmy_K wrote:

Wenn man die "Busse" entfernen würde, wären somit auch die Haltepositionen der Linien verloren.

Verstehe ich nicht.

Jimmy_K wrote:

Jetzt weiß ich, was du mit "Mast" meinst (Deutsch->Österreichisch 😉), wie taggst du selbige? Habe die Wiki durchforstet und finde überall nur die Möglichkeit "platform", welche ja schon für den eigentlich Bahnsteig genutzt wird.
Den Bahnsteig aufsplitten (jede Haltebucht eine Platform) und dann alle mittels einem Multipolygon zusammensetzen (kenne ich jetzt so von manchen Bahnhöfen)?

Nein, den Mast setze ich konsequent als Punkt. Eigentlich wäre pole_position der passende Begriff, aber darunter verstehen die meisten was völlig anderes ;-)
Deshalb eben public_transport=platform als Punkt an der Stelle, wo das Mastschild steht.
Solange das nicht gerendert wird, noch highway=bus_stop dabei.
Und diesen Punkt mit dem Namen "Wetzlar Busbahnhof" (eventuell noch Bussteignummer dazu) versehen als Mitglied in der Routenrelation. Sonst hast du nämlich namenlose Knoten in der Relation und weisst ohne Hinzoomen nicht, welche Haltestelle das nun sein soll.

Den Bahnsteig lasse ich als große Fläche, auch bei Bahnen.

Gruß,
ajoessen

Radeln wrote:

ajoessen wrote:

Radeln wrote:

Der zentrale BB-node ist hier gemeint und der enthält kein Bushaltetag.

Jein, Name und Routenmitgliedschaften.

Name wäre dann an der Fläche und die Routenmitgliedschaften der einzelnen Haltepunkte müßten dann noch zugeordnet werden, hatte ich ja geschrieben.

Mit namenlosen Knoten tust du dir in der Relation keinen Gefallen.

Gruß,
ajoessen

Hallo liebe Mitstreiter. Da ich den ZOB in Wetzlar in seiner jetzigen Form zu "verantworten" habe, möchte ich zuerst einmal deutlich machen das ich Eure Überlegungen in keinster Weise als "runtermachen" empfinde. Wo kämen wir denn da hin, wenn sich jeder Mapper bei einer abweichenden Meinung gleich auf den Schlips getreten fühlen würde. Bei mir ist das zumindest nicht so. 🙂

Im Gegenteil, ich bin froh das Radeln diesen ZOB mal aufgegriffen hat, denn ich war mir beim Eintragen von verschiedenen Dingen nicht ganz sicher wie es richtig sein sollte und hätte früher oder später diese Fragen selbst hier aufgeworfen.
Laut WIKI sind bei einigen Tags verschiedene Dinge möglich, als node, als Fläche, oder auch beides möglich.
Das überspannende Dach gibt es tatsächlich, die tatsächliche Ausführung kann jedoch etwas abweichen (hatte mein Lasermessgerät grad nicht zur Hand 😉 ).

Ob das einbinden der "Stoppunkte" in die Busrouten, auf die Fahrspur oder als separate Haltebucht war mir auch nicht so klar.. Irgendwie ist mir die Geschichte mit den Relations und den dazugehörigen Haltestellen noch nicht so ganz klar.

Die von ajoessen genannte Ähnlichkeit ist nicht zufällig. Wie ihr unter "source" feststellen könnt, hat hier die ansässige Tageszeitung geholfen. Die restlichen Hinweise/Erkenntnisse habe ich von eigenen Begehungen und Fotos. Es gibt dort eine wunderbare Brücke siehe hier, von der man fast schon aus der Vogelperspektive den ZOB vor(unter) sich hat.

Also lange Rede kurzer Sinn, ich würde mich freuen wenn sich die ÖPNV-Spezialisten hier einbringen würden und auch direkt Hand anlegen und den ZOB/Bahnhof (offizielle Schreibweise auch an/in den Bussen!) so "herstellen" wie es richtig ist. Im Juni findet in Wetzlar der Hessentag statt. Es wäre toll wenn der Fall bis dahin erledigt wäre. 🙂

Mir ging es in erster Linie darum die neue Situation am ZOB/Bahnhof zeitnah in OSM zu bringen. Die Eröffnung war gestern (04.03.12)

Das "oneway" war natürlich falsch, habe es entfernt.

Georg

ajoessen wrote:

Radeln wrote:

ajoessen wrote:

Jein, Name und Routenmitgliedschaften.

Name wäre dann an der Fläche und die Routenmitgliedschaften der einzelnen Haltepunkte müßten dann noch zugeordnet werden, hatte ich ja geschrieben.

Mit namenlosen Knoten tust du dir in der Relation keinen Gefallen.

Namenlos? Liniennummer für die Haltepunkte sollte wohl reichen.

ajoessen wrote:

Jimmy_K wrote:

Jetzt weiß ich, was du mit "Mast" meinst (Deutsch->Österreichisch 😉), wie taggst du selbige? Habe die Wiki durchforstet und finde überall nur die Möglichkeit "platform", welche ja schon für den eigentlich Bahnsteig genutzt wird.
Den Bahnsteig aufsplitten (jede Haltebucht eine Platform) und dann alle mittels einem Multipolygon zusammensetzen (kenne ich jetzt so von manchen Bahnhöfen)?

Nein, den Mast setze ich konsequent als Punkt. Eigentlich wäre pole_position der passende Begriff, aber darunter verstehen die meisten was völlig anderes ;-)
Deshalb eben public_transport=platform als Punkt an der Stelle, wo das Mastschild steht.
Solange das nicht gerendert wird, noch highway=bus_stop dabei.
Und diesen Punkt mit dem Namen "Wetzlar Busbahnhof" (eventuell noch Bussteignummer dazu) versehen als Mitglied in der Routenrelation. Sonst hast du nämlich namenlose Knoten in der Relation und weisst ohne Hinzoomen nicht, welche Haltestelle das nun sein soll.

Den Bahnsteig lasse ich als große Fläche, auch bei Bahnen.

Siehe Posting #20. Wenn die Masten so wichtig sind, sollten diese anders gemappt werden, aber bitte nicht als Haltepunkte. Ob nun public_transport=stop_position oder highway=bus_stop oder beides. Gehören auf jeden Fall an die Straße (Posting #20).

Radeln wrote:

ajoessen wrote:

Radeln wrote:

Name wäre dann an der Fläche und die Routenmitgliedschaften der einzelnen Haltepunkte müßten dann noch zugeordnet werden, hatte ich ja geschrieben.

Mit namenlosen Knoten tust du dir in der Relation keinen Gefallen.

Namenlos? Liniennummer für die Haltepunkte sollte wohl reichen.

Dann schau dir mal die Linienrelation an:

der Bus hält an Punkt 23819283, 38291938, 3892000,38293827.
Da weiß man auf Anhieb, wo das ist, und ob die Reihenfolge stimmt? Oder eben nicht.
bei mir steht da der Name der Haltestelle.

Gruß,
ajoessen

Radeln wrote:

Siehe Posting #20. Wenn die Masten so wichtig sind, sollten diese anders gemappt werden, aber bitte nicht als Haltepunkte. Ob nun public_transport=stop_position oder highway=bus_stop oder beides. Gehören auf jeden Fall an die Straße (Posting #20).

Woher nimmst du diese Information?
http://wiki.openstreetmap.org/wiki/Prop … t#Platform

"A public_transport=platform is used to tag a 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."

Außerdem ist area=* explizit als Key value paar eingetragen.

Das ÖPNV-Schema funktioniert so:
1. Die Plattformem bzw. wenn man sie nicht erfassen kann bzw. hat, dann ersatzweise das Haltestellenschild, werden mit public_transport=platform (und, je nach Fall, z.B. bus=yes (an der Plattform macht das aus meiner Sicht noch mehr Sinn, wenn man das taggen möchte, als an den Haltepunkten)) getaggt.
2. Die Halteposition des Verkehrsmittel, die üblicherweise beim Bus auf der Fläche der Fahrbahn liegt, wird mit public_transport=stop_position getaggt.
3. Die Gesamthaltestelle sind alle Objekte aus 1. und 2., die den gleichen Namen haben. Die kommen in eine Relation mit public_transport=stop_area. Damit ist dann die "Haltestelle" als solche (man weis dann den Namen und was alles mit dazu gehört) definiert.
4. Die Route besteht aus einer Abfolge von Wegen und Haltepunkten, die der Bus der Reihe nach abfährt und sollte dann, nach neuem Schema, als eine Relation pro Richtung, ohne spezielle Rollen für die Haltepunkte oder Wege definiert werden sollte. Soweit ich aber gesehen habe, handhabt man es aber bisher nach altem Routen-Schema und nimmt die Haltepunkte anstelle der alten highway=bus_stop's in die Relation auf.

Fabi2 wrote:

Das ÖPNV-Schema funktioniert so:
1. Die Plattformem bzw. wenn man sie nicht erfassen kann bzw. hat, dann ersatzweise das Haltestellenschild, werden mit public_transport=platform (und, je nach Fall, z.B. bus=yes (an der Plattform macht das aus meiner Sicht noch mehr Sinn, wenn man das taggen möchte, als an den Haltepunkten)) getaggt.
2. Die Halteposition des Verkehrsmittel, die üblicherweise beim Bus auf der Fläche der Fahrbahn liegt, wird mit public_transport=stop_position getaggt.
3. Die Gesamthaltestelle sind alle Objekte aus 1. und 2., die den gleichen Namen haben. Die kommen in eine Relation mit public_transport=stop_area. Damit ist dann die "Haltestelle" als solche (man weis dann den Namen und was alles mit dazu gehört) definiert.
4. Die Route besteht aus einer Abfolge von Wegen und Haltepunkten, die der Bus der Reihe nach abfährt und sollte dann, nach neuem Schema, als eine Relation pro Richtung, ohne spezielle Rollen für die Haltepunkte oder Wege definiert werden sollte. Soweit ich aber gesehen habe, handhabt man es aber bisher nach altem Routen-Schema und nimmt die Haltepunkte anstelle der alten highway=bus_stop's in die Relation auf.

Auch das steht hier explizit anders:
http://wiki.openstreetmap.org/wiki/Prop … port#Route
"Each stop is included with two elements (if available): first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform."

4. Die Route besteht aus einer Abfolge von Wegen und Haltepunkten,...

Was meinst du genau mit Haltepunkte? Die Relation der Gesamthaltestelle?

Mich wundert nicht, dass es viele anders (ich will ja gar nicht sagen falsch) Handhaben, da man sich das Wissen aktuell aus 2 Schemas und 3 Proposals (davon die hälfte Englisch) zusammenziehen muss. Irgendwie fehlt mir da eine grundlegende Übersicht.

Hab mich jetzt mal durch [1] und [2] gearbeitet, und bin auch auf ein anderes Ergebnis gekommen. Kann nirgends finden, dass sie keine Rolle haben sollten. Speziell bei [1] wird der stop_position und der Platform eine Role gegeben, je nachdem ob man ein und/oder aussteigen darf.

Mit route, line, route_maste, line_variant sind sich die beiden aber auch nicht einige. Irgendwie sollte sich da mal ein Schema durchsetzen.

[1] http://wiki.openstreetmap.org/wiki/Prop … port#Route
[2] http://wiki.openstreetmap.org/wiki/User … _routes.29

viw wrote:

Fabi2 wrote:

Das ÖPNV-Schema funktioniert so:
1. Die Plattformem bzw. wenn man sie nicht erfassen kann bzw. hat, dann ersatzweise das Haltestellenschild, werden mit public_transport=platform (und, je nach Fall, z.B. bus=yes (an der Plattform macht das aus meiner Sicht noch mehr Sinn, wenn man das taggen möchte, als an den Haltepunkten)) getaggt.
2. Die Halteposition des Verkehrsmittel, die üblicherweise beim Bus auf der Fläche der Fahrbahn liegt, wird mit public_transport=stop_position getaggt.
3. Die Gesamthaltestelle sind alle Objekte aus 1. und 2., die den gleichen Namen haben. Die kommen in eine Relation mit public_transport=stop_area. Damit ist dann die "Haltestelle" als solche (man weis dann den Namen und was alles mit dazu gehört) definiert.
4. Die Route besteht aus einer Abfolge von Wegen und Haltepunkten, die der Bus der Reihe nach abfährt und sollte dann, nach neuem Schema, als eine Relation pro Richtung, ohne spezielle Rollen für die Haltepunkte oder Wege definiert werden sollte. Soweit ich aber gesehen habe, handhabt man es aber bisher nach altem Routen-Schema und nimmt die Haltepunkte anstelle der alten highway=bus_stop's in die Relation auf.

Auch das steht hier explizit anders:
http://wiki.openstreetmap.org/wiki/Prop … port#Route
"Each stop is included with two elements (if available): first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform."

Routen habe ich bisher noch nicht getaggt, nur viele Haltestellen, und natürlich sollte man es im Zweifelsfall so machen, wie das Proposal, einfach wegen der Einheitlichkeit und Auswertbarkeit.
Datentechnisch nötig, und davon bin ich oben ausgegangen, ist es aber nicht. Da muß man nicht in der Routen-Relation irgendwelche Rollen angeben, das ist nur redundant, da die Info, ob es eine Plattform oder ein Haltepunkt ist, ja schon an den Objekten selbst steht. Soll heißen: man geht alle Objekte der Routen-Relation durch und was es jetztlich ist, steht dann direkt am Mitgliedsobjekt. Den Namen der Haltestelle, wenn man nur den Haltepunkt der Route hat, bekommt man dann darüber, daß der Haltepunkt, ja Mitglied einer Gesamthaltestelle (public_transport=stop_area) ist, die dann natürlich einen Namen hat.

Die Taggingpraxis in Bezug auf die Routen war ja auch lange schwamming bis unklar, einfach schon, weil nicht klar war, ob man wie im Orginalentwurf route=line benutzen sollte. Nachdem das ganze dann schon 'ne Weile in Benutzung war, hat man es dann im Proposal zu type=route_master geändert, soweit ich weiß. Im Orginalentwurf (http://wiki.openstreetmap.org/wiki/User … envariante) kommen die überflüssigen Rollen in der Linienrelation auch nicht vor. Die stop_area_group habe ich ja noch vor der Abstimmung gekickt, das mit den Rollen für die Routen habe ich leider erst danach gesehen.

Jimmy_K wrote:

4. Die Route besteht aus einer Abfolge von Wegen und Haltepunkten,...

Was meinst du genau mit Haltepunkte? Die Relation der Gesamthaltestelle?

Da meine ich die Knoten mit public_transport=stop_position.

viw wrote:

Auch das steht hier explizit anders:
http://wiki.openstreetmap.org/wiki/Prop … port#Route
"Each stop is included with two elements (if available): first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform."

Noch 'ne Anmerkung dazu, weil es mir gerade einfällt, was vielleicht der Grund ist, warum auch die Plattform mit in der Routenrelation gelandet ist, die da ja eigentlich nichts drin zu suchen hat, weil sonst müßte der Bus ja auf seiner Route auch die Plattform samt Wartehäuschen, Schild, etc. passieren. ;-) Da gab es doch das Problem, das man für den Fall, das man jemanden genau zum passenden Einstiegspunkt an Haltestelle x routen möchte, nicht weiß, welche Platform denn nun zu dem/den Haltepunkt(en) gehört. Da braucht man noch eine weitere Relation, die eben genau die Zuordnung der Haltepunkte zur passeden Platform abbildet. Nur dann jammern wieder alle, weil das ja noch eine Relation mehr ist.

Fabi2 wrote:

viw wrote:

Auch das steht hier explizit anders:
http://wiki.openstreetmap.org/wiki/Prop … port#Route
"Each stop is included with two elements (if available): first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform."

Noch 'ne Anmerkung dazu, weil es mir gerade einfällt, was vielleicht der Grund ist, warum auch die Plattform mit in der Routenrelation gelandet ist, die da ja eigentlich nichts drin zu suchen hat, weil sonst müßte der Bus ja auf seiner Route auch die Plattform samt Wartehäuschen, Schild, etc. passieren. ;-) Da gab es doch das Problem, das man für den Fall, das man jemanden genau zum passenden Einstiegspunkt an Haltestelle x routen möchte, nicht weiß, welche Platform denn nun zu dem/den Haltepunkt(en) gehört. Da braucht man noch eine weitere Relation, die eben genau die Zuordnung der Haltepunkte zur passeden Platform abbildet. Nur dann jammern wieder alle, weil das ja noch eine Relation mehr ist.

Genau hier liegt das Problem! Es ist selbst bei einfachen Haltestellen mitunter kompliziert. Es kann Haltestellenmasten mit zwei Stoppositionen geben, genauso wie es Stopositionen mit zwei Masten geben kann. Spätestens dann ist nicht mehr klar was jetzt für diesen Fahrtverlauf entscheidend ist.
Ich habe mich bei meinem Tagging bisher immer nur die Masten in die Routenrelation aufgenommen, weil die anderen Dinge für mich bisher keine sinnvolle Information waren. Es gab hier mal die Verfechter, welche sagten, dass man dies brauche um den Weg des Fahrzeugs nachzuvollziehen. Da aber in den meisten Fällen die Stoppositionen weder eingetragen sind noch in der Realität physisch vorhanden sind, habe ich auf die Erfassung verzichtet. Ich habe allefalls Haltestellen auf dem Weg zu solchen umgetagt.
Natürlich hast du auch Recht, wenn du sagst das man sich den Namen aus den Überrelationen holen kann. Solange aber Josm dies nicht macht und andere Auswerter das auch nicht schaffen, wird diese Information immer redundant erfasst werden. Einfach um die Dinge besser zu sehen.

Die "platform" muss in die Relation. Gehen wir mal von der Situation, welche die Diskussion ausgelöst hat, aus:

Wenn jetzt nur der "highway" und die "stop_position" in der Realtion wäre, wodurch sollte eine Navigationslösung wissen, zu welcher "platform" sie dich leiten soll? Die Nähestgelegene fällt aus, da beiderseits der Straße eine Halteposition ist.
Wäre der betreffende Abschnitt der "platform" in der Relation drinnen, müsste einfach nur die nähestgelegene Platform genommen werden und das Navi wüsste wohin.

Jimmy_K wrote:

Die "platform" muss in die Relation. Gehen wir mal von der Situation, welche die Diskussion ausgelöst hat, aus:

Wenn jetzt nur der "highway" und die "stop_position" in der Realtion wäre, wodurch sollte eine Navigationslösung wissen, zu welcher "platform" sie dich leiten soll? Die Nähestgelegene fällt aus, da beiderseits der Straße eine Halteposition ist.
Wäre der betreffende Abschnitt der "platform" in der Relation drinnen, müsste einfach nur die nähestgelegene Platform genommen werden und das Navi wüsste wohin.

.. und wenn man die Mastposition korrekt eingetragenhat, weiß man es auch mit Blick auf die Karte; ganz ohne Navi.

Gruß,
ajoessen

viw wrote:

Fabi2 wrote:

Noch 'ne Anmerkung dazu, weil es mir gerade einfällt, was vielleicht der Grund ist, warum auch die Plattform mit in der Routenrelation gelandet ist, die da ja eigentlich nichts drin zu suchen hat, weil sonst müßte der Bus ja auf seiner Route auch die Plattform samt Wartehäuschen, Schild, etc. passieren. ;-) Da gab es doch das Problem, das man für den Fall, das man jemanden genau zum passenden Einstiegspunkt an Haltestelle x routen möchte, nicht weiß, welche Platform denn nun zu dem/den Haltepunkt(en) gehört. Da braucht man noch eine weitere Relation, die eben genau die Zuordnung der Haltepunkte zur passeden Platform abbildet. Nur dann jammern wieder alle, weil das ja noch eine Relation mehr ist.

Genau hier liegt das Problem! Es ist selbst bei einfachen Haltestellen mitunter kompliziert. Es kann Haltestellenmasten mit zwei Stoppositionen geben, genauso wie es Stopositionen mit zwei Masten geben kann. Spätestens dann ist nicht mehr klar was jetzt für diesen Fahrtverlauf entscheidend ist.

Das Problem ist eigentlich nicht so kompliziert, wenn man es richtig betrachtet.

Wofür sind denn die H-Tafeln/H-Schilder da? Ja, die zeigen doch nur die ungefähre Position des Haltepunktes (beim Bus auf der Plattform) an. Damit kauen die also nur die Info "hier ist der Haltepunkt" noch mal an der Plattform wieder. Deshalb sollte man die meiner Meinung nach auch nur als Ersatz für die noch nicht erfasste Plattform nehmen, weil es eben nur der formale Hinweis auf den Haltepunkt an sich ist.

Damit ist dann auch für die Plattform (public_transport=platform) nicht die Zahl der Haltepunktschilder, sondern die der Bahn-/Bussteige entscheidend. Und wie schon geschrieben, braucht man noch eine zusätzliche Relation (fürs Routing zu den Haltepunkten/Plattformen), die die Zuordnung der Haltepunkte zu der Plattform macht, über die man die dort haltenden Verkehrsmittel normalerweise erreicht.

Dann gibt es, wie du schon geschrieben hast, zuerst den Fall das man einen Bahn-/Bussteig mit mehreren Haltepunkten hat. Da kommen die Haltepunkte und die zugehörige Plattform in die Bahnsteigrelation und der Router weis dann, auf welchem Bahnsteig man ankommt, wenn der Zug von Linie x an Haltepunkt y ankommt.

Das Problem der "zwei Masten" löst man auch über die reale Plattform, da ist ja nur eine, zumindest in Berlin, wo genau dieser Fall gerne bei Endhaltestellen vorkommt. Wenn man schon die beiden Masten hat, kann man auch provisorisch einen Weg zwischen ihnen für die Plattform mappen. Damit hat man dann wieder nur eine Plattform.

Dann gibt's noch den Fall, das die gleichen Hlatepunkte zu mehreren Plattformen gehören können (z.B. Gleis 3 hier: http://osm.org/go/0MbGUPxS7--, da hält die S-Bahn mittig und man kann nach beiden Seiten gleichzeitig aussteigen), da sind dann eben zwei Plattformen mit in der Relation die die Haltepunkt-Plattform-Zuordnung macht.

viw wrote:

Ich habe mich bei meinem Tagging bisher immer nur die Masten in die Routenrelation aufgenommen, weil die anderen Dinge für mich bisher keine sinnvolle Information waren. Es gab hier mal die Verfechter, welche sagten, dass man dies brauche um den Weg des Fahrzeugs nachzuvollziehen. Da aber in den meisten Fällen die Stoppositionen weder eingetragen sind noch in der Realität physisch vorhanden sind, habe ich auf die Erfassung verzichtet. Ich habe allefalls Haltestellen auf dem Weg zu solchen umgetagt.

Ja, die Stoppositionen sind nur ein Modell, wobei auch nicht ganz klar ist, ob damit die Mitte oder der Beginn des Fahrzeuges gemeint ist, ich habe Leute gesehen, die setzten die Spotposition in die Mitte der Bushaltetasche, auch wenn man es eigentlich analog zur Eisenbahn machen, und den Fahrzeugbeginn nehmen, müßte. Momentan geht es auch nicht anders, als eben die Plattform mit aufzunehmen.

viw wrote:

Natürlich hast du auch Recht, wenn du sagst das man sich den Namen aus den Überrelationen holen kann. Solange aber Josm dies nicht macht und andere Auswerter das auch nicht schaffen, wird diese Information immer redundant erfasst werden. Einfach um die Dinge besser zu sehen.

Da hast du auch recht, das ist meines Erachtens auch der Hauptgrund, warum man die redundante Erfassung braucht. Gerade weil man sonst in JOSM leicht was übersieht und mit den redundanten Infos das Handling leichter ist, auch wenn das eigentlich das Wegzeug und nicht dessen Benutzer lösen sollte. Die anderen Auswerten müssen ja nichts ändern, da im Moment alles x-mal erfasst wird. Warum sollten die sich unötige Arbeit bei der Auswertung machen?

ajoessen wrote:

.. und wenn man die Mastposition korrekt eingetragenhat, weiß man es auch mit Blick auf die Karte; ganz ohne Navi.

Und die Anhäufung "Bocholt Bahnhof" findest Du jetzt gut?

http://www.openstreetmap.org/?lat=49.44 … 8&layers=M
- zum Großteil von mir verbrochen -
ist im JOSM erst richtig schlimm ...

Zum Glück haben wir am Bahnhof selbst mit seine 26 Gleisen und 100+ Linien nicht mehr gemacht.
Ein einziges Gewusel!

kellerma wrote:

ajoessen wrote:

.. und wenn man die Mastposition korrekt eingetragenhat, weiß man es auch mit Blick auf die Karte; ganz ohne Navi.

Und die Anhäufung "Bocholt Bahnhof" findest Du jetzt gut?

Warum nicht? Ein guter Renderer schreibts nur dann hin, wenn auch Platz dafür ist:

Ist mir jedenfalls lieber, als erst mühsam alle Relationen durchsuchen zu müssen, ob da irgendwo die Information steht, die ich haben will.

Gruß,
ajoessen

Das meiste wurde ja schon erwähnt.
Die Bus-Linien werden sehr unterschiedlich bezeichnet:
"BUS 200", "11", "24 Gießen-Wetzlar".
Wenn die allen dem gleilchen Verkehrsbund angehören, haben die dann keine einheitliches Schema?

kellerma wrote:

Das meiste wurde ja schon erwähnt.
Die Bus-Linien werden sehr unterschiedlich bezeichnet:
"BUS 200", "11", "24 Gießen-Wetzlar".
Wenn die allen dem gleilchen Verkehrsbund angehören, haben die dann keine einheitliches Schema?

Nö. Das hat leider nichts mit dem Verkehrsverbund zu tun. Im Fahrplanbuch mögen sie noch gleich sein, aber schon die PDF Fahrpläne unterscheiden sich teils deutlich im Aufbau. Warum nicht also auch die Linienbezeichnungen?

viw wrote:

Radeln wrote:

Siehe Posting #20. Wenn die Masten so wichtig sind, sollten diese anders gemappt werden, aber bitte nicht als Haltepunkte. Ob nun public_transport=stop_position oder highway=bus_stop oder beides. Gehören auf jeden Fall an die Straße (Posting #20).

Woher nimmst du diese Information?
http://wiki.openstreetmap.org/wiki/Prop … t#Platform
.

Da bist Du leider auf dem falschen Dampfer. NIcht 'platform' war angesprochen, sondern Haltepunkte (stop_position).
Dazu das Wiki: A public_transport=stop_position is tagged as a Node on the way, even when a bus stops in a bus bay. (http://wiki.openstreetmap.org/wiki/Prop … _Transport)

ajoessen wrote:

Jimmy_K wrote:

Die "platform" muss in die Relation. Gehen wir mal von der Situation, welche die Diskussion ausgelöst hat, aus:

Wenn jetzt nur der "highway" und die "stop_position" in der Realtion wäre, wodurch sollte eine Navigationslösung wissen, zu welcher "platform" sie dich leiten soll? Die Nähestgelegene fällt aus, da beiderseits der Straße eine Halteposition ist.
Wäre der betreffende Abschnitt der "platform" in der Relation drinnen, müsste einfach nur die nähestgelegene Platform genommen werden und das Navi wüsste wohin.

.. und wenn man die Mastposition korrekt eingetragenhat, weiß man es auch mit Blick auf die Karte; ganz ohne Navi.

Gruß,
ajoessen

In deinem Beispiel ist es klar. Aber wenn es um einfache Haltestellen an einer normalen Straße geht ist es nicht mehr klar.
http://www.openstreetmap.org/?lat=51.09 … 8&layers=M
Eine stopposition in der Straßenmitte und je ein Mast links bzw. rechts der Straße. Wenn der Router jetzt nur weiß zur stopposition, dann weiß man nicht auf welche Seite man sich stellen muss.

Fabi2 wrote:

viw wrote:

Ich habe mich bei meinem Tagging bisher immer nur die Masten in die Routenrelation aufgenommen, weil die anderen Dinge für mich bisher keine sinnvolle Information waren. Es gab hier mal die Verfechter, welche sagten, dass man dies brauche um den Weg des Fahrzeugs nachzuvollziehen. Da aber in den meisten Fällen die Stoppositionen weder eingetragen sind noch in der Realität physisch vorhanden sind, habe ich auf die Erfassung verzichtet. Ich habe allefalls Haltestellen auf dem Weg zu solchen umgetagt.

Ja, die Stoppositionen sind nur ein Modell, wobei auch nicht ganz klar ist, ob damit die Mitte oder der Beginn des Fahrzeuges gemeint ist, ich habe Leute gesehen, die setzten die Spotposition in die Mitte der Bushaltetasche, auch wenn man es eigentlich analog zur Eisenbahn machen, und den Fahrzeugbeginn nehmen, müßte. Momentan geht es auch nicht anders, als eben die Plattform mit aufzunehmen.

Wer sagt denn das die Stopposition an der Spitze des Fahrzeuges liegt? Das ist doch der Irrtum. Jedenfalls wenn man damit erreichen möchte, dass sich Menschen mit Mobilitätseinschränkungen richtig positionieren. Denn dann solte diese Stellen jenen Punkt markieren an dem die Tür mit der Rampe ist und die ist nicht immer an der Spitze des Fahrzeuges.
Sollte die Stopposition diese Bedeutung nicht haben, dann ist sie sogar fast sinnfrei. Bis auf Ausnahmen wo der Mast weit weg vom eigentlichen Halt des Fahrzeuges liegt.

viw wrote:

ajoessen wrote:

Jimmy_K wrote:

Die "platform" muss in die Relation. Gehen wir mal von der Situation, welche die Diskussion ausgelöst hat, aus:

Wenn jetzt nur der "highway" und die "stop_position" in der Realtion wäre, wodurch sollte eine Navigationslösung wissen, zu welcher "platform" sie dich leiten soll? Die Nähestgelegene fällt aus, da beiderseits der Straße eine Halteposition ist.
Wäre der betreffende Abschnitt der "platform" in der Relation drinnen, müsste einfach nur die nähestgelegene Platform genommen werden und das Navi wüsste wohin.

.. und wenn man die Mastposition korrekt eingetragenhat, weiß man es auch mit Blick auf die Karte; ganz ohne Navi.

Gruß,
ajoessen

In deinem Beispiel ist es klar. Aber wenn es um einfache Haltestellen an einer normalen Straße geht ist es nicht mehr klar.
http://www.openstreetmap.org/?lat=51.09 … 8&layers=M
Eine stopposition in der Straßenmitte und je ein Mast links bzw. rechts der Straße. Wenn der Router jetzt nur weiß zur stopposition, dann weiß man nicht auf welche Seite man sich stellen muss.

Mein Reden. Deshalb bin ich ja für die Mastpositionen aka pole_position aka platform.[1]

Gruß,
ajoessen

[1] aka = also known as

ajoessen wrote:

Mein Reden. Deshalb bin ich ja für die Mastpositionen aka pole_position aka platform.[1]

Gruß,
ajoessen

[1] aka = also known as

Es gibt aber auch Stellen wo eine Stopposition durchaus sinnvoll sein könnte, wenn es um die Rohlstuhlgerchtigkeit der Haltestelle geht:
http://maps.google.de/?ll=51.057878,13. … 6,,0,13.31

Die Straßenbahn ist am gleichen Mast mit vollbarrierefrei, während der Bus in Straßenrandlage maximal eingeschränkt barrierefrei ist.
Am Trachenberger Platz ist es sogar noch schöner. Dort hält der Stadtbus in Straßenmitte wie die Straßenbahn und ist barrirefrei, während der Regionalbus am Straßenrand hält.

viw wrote:

kellerma wrote:

Das meiste wurde ja schon erwähnt.
Die Bus-Linien werden sehr unterschiedlich bezeichnet:
"BUS 200", "11", "24 Gießen-Wetzlar".
Wenn die allen dem gleilchen Verkehrsbund angehören, haben die dann keine einheitliches Schema?

Nö. Das hat leider nichts mit dem Verkehrsverbund zu tun. Im Fahrplanbuch mögen sie noch gleich sein, aber schon die PDF Fahrpläne unterscheiden sich teils deutlich im Aufbau. Warum nicht also auch die Linienbezeichnungen?

Dann habt Ihr aber einen komischen Verkehrsverbund.
Allein aus Marketinggruenden waer' ich an einen einheitlichen Aufbau interessiert und
nicht jener Busumternehmer kocht sein eigenes Sueppchen.

viw wrote:

Fabi2 wrote:

viw wrote:

Ich habe mich bei meinem Tagging bisher immer nur die Masten in die Routenrelation aufgenommen, weil die anderen Dinge für mich bisher keine sinnvolle Information waren. Es gab hier mal die Verfechter, welche sagten, dass man dies brauche um den Weg des Fahrzeugs nachzuvollziehen. Da aber in den meisten Fällen die Stoppositionen weder eingetragen sind noch in der Realität physisch vorhanden sind, habe ich auf die Erfassung verzichtet. Ich habe allefalls Haltestellen auf dem Weg zu solchen umgetagt.

Ja, die Stoppositionen sind nur ein Modell, wobei auch nicht ganz klar ist, ob damit die Mitte oder der Beginn des Fahrzeuges gemeint ist, ich habe Leute gesehen, die setzten die Stopposition in die Mitte der Bushaltetasche, auch wenn man es eigentlich analog zur Eisenbahn machen, und den Fahrzeugbeginn nehmen, müßte. Momentan geht es auch nicht anders, als eben die Plattform mit aufzunehmen.

Wer sagt denn das die Stopposition an der Spitze des Fahrzeuges liegt? Das ist doch der Irrtum. Jedenfalls wenn man damit erreichen möchte, dass sich Menschen mit Mobilitätseinschränkungen richtig positionieren. Denn dann solte diese Stellen jenen Punkt markieren an dem die Tür mit der Rampe ist und die ist nicht immer an der Spitze des Fahrzeuges.
Sollte die Stopposition diese Bedeutung nicht haben, dann ist sie sogar fast sinnfrei. Bis auf Ausnahmen wo der Mast weit weg vom eigentlichen Halt des Fahrzeuges liegt.

Da darf man nicht "Stopposition" mit "Einstiegsstelle (für Personengruppe x)" verwechseln!

Die Stopposition ist auch nicht sinnfrei, weil die gibt den Ort, in Bezug auf die Route und die Plattform des Verkehrsmittels an, wo es hält. Natürlich hat dieser Haltepunkt auf dem Verkehrsweg genau gar nichts mit der Zahl und der Position der Türen und evtl. Rampen zu tun. Dafür braucht man die Einsteigsstelle.

Die Einstiegstellen für die jeweiligen Personengruppen sind eine Eigenschaft des jeweils konkret dort eingesetzten Verkehrsmittels. Je nach Bauart des Busses ist dann die Rampe vorne, in der Mitte oder er hat gar keine Rampe. Ebenso ist die Zahl der Türen unterschiedlich: beim Bus sind es im Normalfall 2 bis 4 Einstiege, bei der S-Bahn so 3-4 pro Wagen, wobei man dann noch die Wagenzahl mit erfassen müßte, weil kann ja sein, daß da in den Nebenzeiten nur Kurzzüge fahren...

Fabi2 wrote:

viw wrote:

Fabi2 wrote:

Ja, die Stoppositionen sind nur ein Modell, wobei auch nicht ganz klar ist, ob damit die Mitte oder der Beginn des Fahrzeuges gemeint ist, ich habe Leute gesehen, die setzten die Stopposition in die Mitte der Bushaltetasche, auch wenn man es eigentlich analog zur Eisenbahn machen, und den Fahrzeugbeginn nehmen, müßte. Momentan geht es auch nicht anders, als eben die Plattform mit aufzunehmen.

Wer sagt denn das die Stopposition an der Spitze des Fahrzeuges liegt? Das ist doch der Irrtum. Jedenfalls wenn man damit erreichen möchte, dass sich Menschen mit Mobilitätseinschränkungen richtig positionieren. Denn dann solte diese Stellen jenen Punkt markieren an dem die Tür mit der Rampe ist und die ist nicht immer an der Spitze des Fahrzeuges.
Sollte die Stopposition diese Bedeutung nicht haben, dann ist sie sogar fast sinnfrei. Bis auf Ausnahmen wo der Mast weit weg vom eigentlichen Halt des Fahrzeuges liegt.

Da darf man nicht "Stopposition" mit "Einstiegsstelle (für Personengruppe x)" verwechseln!

Die Stopposition ist auch nicht sinnfrei, weil die gibt den Ort, in Bezug auf die Route und die Plattform des Verkehrsmittels an, wo es hält. Natürlich hat dieser Haltepunkt auf dem Verkehrsweg genau gar nichts mit der Zahl und der Position der Türen und evtl. Rampen zu tun. Dafür braucht man die Einsteigsstelle.

Die Einstiegstellen für die jeweiligen Personengruppen sind eine Eigenschaft des jeweils konkret dort eingesetzten Verkehrsmittels. Je nach Bauart des Busses ist dann die Rampe vorne, in der Mitte oder er hat gar keine Rampe. Ebenso ist die Zahl der Türen unterschiedlich: beim Bus sind es im Normalfall 2 bis 4 Einstiege, bei der S-Bahn so 3-4 pro Wagen, wobei man dann noch die Wagenzahl mit erfassen müßte, weil kann ja sein, daß da in den Nebenzeiten nur Kurzzüge fahren...

Immer die Spitze des Zuges als Stopposition erfassen zu wollen ist aus meiner Sicht bei Zügen gar nicht möglich. Denn es gibt im Gleis in großen Bahnhöfen mehr als eine solcher Stopposition. Jetzt muss man also pro Gleis und Richtung mehrere dieser Dinger angeben und die Zahl der Linienvarianten nimmt auch noch zu, da abhängig von der Zuglänge die Halteposition variert. Was also ist der Sinn dieser Stopposition?

S-Bahn Berlin hat 3 Zuglängen, die je nach Zugang des Bahnsteiges an anderer Stelle halten. Bei der großen Bahn mit ihren Zügen ist der Unterschied ob in Doppel oder einfachtraktion gefahren wird sogar noch wesentlich größer.

Ich versuche bei der Stop-Position auch meist die Mitte zu treffen, da die Bus-/Zugspitze kein wirklich interessantes Merkmal ist. Mal am Beispiel der Bahn, es gibt Strecken, wo die Zugspitze an einer anderen Position zum stehen kommte, je nachdem wie lange der Zug ist (da variieren dann schon mal die Stoppositionen um an die 100m).

@ajoessen
Auf der Karte kann man es in diesem Fall schön sehen, für mich hat es dann nur 2 Nachteile:
1) Wenn die Halteposition des Busses sich ändert muss man Relation und Namen der Haltestelle ändern.
2) Eine Automatisierung fürs Routing ist verdammt schwer.

Jimmy_K wrote:

Auf der Karte kann man es in diesem Fall schön sehen, für mich hat es dann nur 2 Nachteile:
1) Wenn die Halteposition des Busses sich ändert muss man Relation und Namen der Haltestelle ändern.
2) Eine Automatisierung fürs Routing ist verdammt schwer.

Äh, nö. Die Liniennummern stehen nicht im Haltestellennamen. Die nimmt sich mkgmap aus den Linienrelationen.
Du musst also beim Fahrplanwechsel nur die Haltestelle in die andere Relation reinhängen:

http://www.openstreetmap.org/browse/node/1457465142
http://www.openstreetmap.org/browse/node/1457465143
http://www.openstreetmap.org/browse/node/1457465144

Leider ist diese Darstellung bei Mapnik nicht so einfach möglich.

Gruuß,
ajoessen

viw wrote:

Immer die Spitze des Zuges als Stopposition erfassen zu wollen ist aus meiner Sicht bei Zügen gar nicht möglich. Denn es gibt im Gleis in großen Bahnhöfen mehr als eine solcher Stopposition. Jetzt muss man also pro Gleis und Richtung mehrere dieser Dinger angeben und die Zahl der Linienvarianten nimmt auch noch zu, da abhängig von der Zuglänge die Halteposition variert. Was also ist der Sinn dieser Stopposition?r.

Das es pro Bahnsteig mehrere Stoppositionen gibt, ist ja gerade bei der Bahn ja der Normalfall. Da hält dann, soweit ich weiß, der Zug mit der Spitze immer an der für ihn passenden H-Tafel. Nur sind eben wie du ja schreibst die Zuglängen unterscheidlich, womit der reale Haltepunkt abhängig vom konkreten Verkehrmittelaufbau ist. Der Verkehrmittelaufbau ist dann wiederum zeitabhängig, also im Endeffekt vom Fahrplan abhängig. In letzter Konsequenz müßte man also für jede "Bahnsteigrelation" (=Plattform mit zu ihr gehörigen Haltepunkten) die konkreten Verkehrmitteltypen mit erfassen, so daß sich daraus der Aufbau des Fahrzeuges ergibt. In Bezug auf die Linienvarianten(relationen) müßte dann drinstehen, zu welchen Betriebszeiten da welche Verkehrsmitteltypen unterwegs sind.

Das wird dann bestimmt lustig für Ottonormalmapper, der ja schon beim "einfachen" ÖPNV-Schema kapituliert. Ist eh mal so eine Frage, wie man die Komplexität der Realtiät handelt, damit die Leute auch noch damit klar kommen.

Entschuldige, habe mir den Platz nicht so genau angesehen und bin davon ausgegangen, dass es im name Tag drinnen steht.
Jetzt besteht nur noch "das Problem", das laut dem aktuellen Schema die stop_position auf der Straße liegen muss.

Jimmy_K wrote:

Ich versuche bei der Stop-Position auch meist die Mitte zu treffen, da die Bus-/Zugspitze kein wirklich interessantes Merkmal ist. Mal am Beispiel der Bahn, es gibt Strecken, wo die Zugspitze an einer anderen Position zum stehen kommte, je nachdem wie lange der Zug ist (da variieren dann schon mal die Stoppositionen um an die 100m).

Was man da als entscheidendes Merkmal für die Stopposition definiert, ob die Mitte oder der Anfang des Verkehrsmittels, ist im Prinzip egal, optimal ist Beides nicht, wichtig ist da eher nur, daß man es einheitlich macht und definiert.

Bei der Bahn ist natürlich die Mitte im Normalfall besser, beim Bus ist eher der Fahrzeuganfang besser, denn es ist schon ein Unterscheid ob da zur Hauptzeit mit normalen großen Bussen gedfahren wird oder in der Nebenzeit bzw. im Nachtverkehr mit Kleinbussen.

Jimmy_K wrote:

Entschuldige, habe mir den Platz nicht so genau angesehen und bin davon ausgegangen, dass es im name Tag drinnen steht.
Jetzt besteht nur noch "das Problem", das laut dem aktuellen Schema die stop_position auf der Straße liegen muss.

Die gibts bei mir ja auch nicht. Highway=bus_stop verwende ich hier im Sinne von public_transport=platform.

Gruß,
ajoessen

Fabi2 wrote:

viw wrote:

Immer die Spitze des Zuges als Stopposition erfassen zu wollen ist aus meiner Sicht bei Zügen gar nicht möglich. Denn es gibt im Gleis in großen Bahnhöfen mehr als eine solcher Stopposition. Jetzt muss man also pro Gleis und Richtung mehrere dieser Dinger angeben und die Zahl der Linienvarianten nimmt auch noch zu, da abhängig von der Zuglänge die Halteposition variert. Was also ist der Sinn dieser Stopposition?r.

Das es pro Bahnsteig mehrere Stoppositionen gibt, ist ja gerade bei der Bahn ja der Normalfall. Da hält dann, soweit ich weiß, der Zug mit der Spitze immer an der für ihn passenden H-Tafel. Nur sind eben wie du ja schreibst die Zuglängen unterscheidlich, womit der reale Haltepunkt abhängig vom konkreten Verkehrmittelaufbau ist. Der Verkehrmittelaufbau ist dann wiederum zeitabhängig, also im Endeffekt vom Fahrplan abhängig. In letzter Konsequenz müßte man also für jede "Bahnsteigrelation" (=Plattform mit zu ihr gehörigen Haltepunkten) die konkreten Verkehrmitteltypen mit erfassen, so daß sich daraus der Aufbau des Fahrzeuges ergibt. In Bezug auf die Linienvarianten(relationen) müßte dann drinstehen, zu welchen Betriebszeiten da welche Verkehrsmitteltypen unterwegs sind.

Das wird dann bestimmt lustig für Ottonormalmapper, der ja schon beim "einfachen" ÖPNV-Schema kapituliert. Ist eh mal so eine Frage, wie man die Komplexität der Realtiät handelt, damit die Leute auch noch damit klar kommen.

Ich denke du machst dir die Sache zu einfach. Welchen Sinn hat denn diese Stopposition nun? Wir sollten hier darüber reden, was mit vertretbarem Aufwand sinnvoll ist. Damit alle daran teilnehmen können. Bisher sehe ich aber noch keinen Sinn die Stopposition überhaupt anzulegen geschweige denn dafür extra neue Linienvarianten, wenn es dann ein längeres Fahrzeug werden wird. Das Gleiche passiert übrigens an Doppelhlatestellen? Da kann das Fahrzeug vorne anhalten oder hinten. In Abhängigkeit der Länge des ersten Fahrzeuges ergeben sich in Dresden schonmal 3 weitere Positionen. Das ist nicht Zielführend oder?

viw wrote:

Fabi2 wrote:

Das es pro Bahnsteig mehrere Stoppositionen gibt, ist ja gerade bei der Bahn ja der Normalfall. Da hält dann, soweit ich weiß, der Zug mit der Spitze immer an der für ihn passenden H-Tafel. Nur sind eben wie du ja schreibst die Zuglängen unterscheidlich, womit der reale Haltepunkt abhängig vom konkreten Verkehrmittelaufbau ist. Der Verkehrmittelaufbau ist dann wiederum zeitabhängig, also im Endeffekt vom Fahrplan abhängig. In letzter Konsequenz müßte man also für jede "Bahnsteigrelation" (=Plattform mit zu ihr gehörigen Haltepunkten) die konkreten Verkehrmitteltypen mit erfassen, so daß sich daraus der Aufbau des Fahrzeuges ergibt. In Bezug auf die Linienvarianten(relationen) müßte dann drinstehen, zu welchen Betriebszeiten da welche Verkehrsmitteltypen unterwegs sind.

Das wird dann bestimmt lustig für Ottonormalmapper, der ja schon beim "einfachen" ÖPNV-Schema kapituliert. Ist eh mal so eine Frage, wie man die Komplexität der Realtiät handelt, damit die Leute auch noch damit klar kommen.

Ich denke du machst dir die Sache zu einfach. Welchen Sinn hat denn diese Stopposition nun? Wir sollten hier darüber reden, was mit vertretbarem Aufwand sinnvoll ist. Damit alle daran teilnehmen können. Bisher sehe ich aber noch keinen Sinn die Stopposition überhaupt anzulegen geschweige denn dafür extra neue Linienvarianten, wenn es dann ein längeres Fahrzeug werden wird. Das Gleiche passiert übrigens an Doppelhlatestellen? Da kann das Fahrzeug vorne anhalten oder hinten. In Abhängigkeit der Länge des ersten Fahrzeuges ergeben sich in Dresden schonmal 3 weitere Positionen. Das ist nicht Zielführend oder?

Ja, was sinnvoll ist bzw. besser: wie man die zusätzliche Komplexität so gestaltet, das das ganze in den Daten auch noch für den uneingearbeiten Mapper handhabbar bleibt, das ist eine gute Frage und da habe ich gerade mal eine Thread datzu aufgemacht. Mit dem Zusammenfreffen an einer Mehrfachhaltestelle kommt man dann an die Grenzen selbst des besten Modells, einfach weil die Reihenfolge da teilweise sehr dem Zufall unterliegt, welche in der Praxis zum Beispiel durch Staus und Ampelwartezeiten beinfußt wird. Andererseits braucht man die Haltepunkte, da die Platformen dafür in der Praxis kein giter Ersatz sind und die Erfassung der Haltestellenschilder ja, wie schon geschrieben, auch nur eine andere Art ist, den Haltepunkt zu taggen. Wenn ist als nicht einheimischer hier mit der S-Bahn ankommen würde, dann würde ich schon gern wissen, ob ich nun die Straße nach links oder rechts zur passenden Bushaltestelle muß, da bringt es mit genau gar nichts, das die alle Köpenick heißen und das es 2 S-Bahn, 2 Bus, und 3 Straßenbahn Plattformen mit diesem Namen gibt, wobei die des Busses eben so 200m auseinander liegen und die S-bahn da in der Mitte liegt. Wie willst du das denn lösen? Da die Platform inn die Relation zu nehmen scheitert spätestens bei z.B. Eckhaltestellen mit 2 um 90° versetzten Haltepunkten und ist modelltechnisch eh nicht korrekt.

Was ich an dieser Diskussion überhaupt nicht verstehe, ist die Tatsache, daß hier Poster, die dem Proposal http://wiki.openstreetmap.org/wiki/Prop … _Transport zugestimmt haben dieses zumindest teilweise (stop_position) in Frage stellen.

Radeln wrote:

Was ich an dieser Diskussion überhaupt nicht verstehe, ist die Tatsache, daß hier Poster, die dem Proposal http://wiki.openstreetmap.org/wiki/Prop … _Transport zugestimmt haben dieses zumindest teilweise (stop_position) in Frage stellen.

Wir sind hier nun mal nicht in der SED.

EDIT: Was heisst noch mal Proposal auf Deutsch?

Gruß,
ajoessen

Der Sinn des zustimmen ist es doch, den Vorschlag in die Tat umzusetzen?! Somit ist der Name dann Geschichte.

Aber gleichzeitig muss es ja nicht heißen, dass man für alles ist, nur weil man zustimmt (schon mal versucht eine Partei zu finden, bei welcher man zu 100% mit dem Wahlprogramm übereinstimmt?)

ajoessen wrote:

Radeln wrote:

Was ich an dieser Diskussion überhaupt nicht verstehe, ist die Tatsache, daß hier Poster, die dem Proposal http://wiki.openstreetmap.org/wiki/Prop … _Transport zugestimmt haben dieses zumindest teilweise (stop_position) in Frage stellen.

Wir sind hier nun mal nicht in der SED.

Die Antwort ist doch hohl.

Jimmy_K wrote:

Der Sinn des zustimmen ist es doch, den Vorschlag in die Tat umzusetzen?! Somit ist der Name dann Geschichte.

Aber gleichzeitig muss es ja nicht heißen, dass man für alles ist, nur weil man zustimmt (schon mal versucht eine Partei zu finden, bei welcher man zu 100% mit dem Wahlprogramm übereinstimmt?)

Ein einzelnes Proposal mit dem Wahlprogramm einer Partei zu vergleichen, ist reichlich übertrieben/daneben.

Warum es daneben ist, kann ich zwar nicht nachvollziehen, aber überall wo etwas von vielen Menschen bestimmt wird, müssen Kompromisse eingegangen werden. D.h. ich würde auch einem Proposal zustimmen, mit welchem ich nur 95% übereinstimme.

Jimmy_K wrote:

Warum es daneben ist, kann ich zwar nicht nachvollziehen, aber überall wo etwas von vielen Menschen bestimmt wird, müssen Kompromisse eingegangen werden. D.h. ich würde auch einem Proposal zustimmen, mit welchem ich nur 95% übereinstimme.

Daneben, weil eine Mücke mit einem Elefanten verglichen wird.
Wäre es bei einer teilweise Zustimmung dann nicht angebracht, die 5% anzusprechen.

BTW, ein geschlossener Kompromiss/Mehrheitsentscheidung gilt doch für alle.

Radeln wrote:

BTW, ein geschlossener Kompromiss/Mehrheitsentscheidung gilt doch für alle.

Du hast immer noch nicht verstanden, wie (und warum) OSM funktioniert.

Gruß,
ajoessen

ajoessen wrote:

Radeln wrote:

BTW, ein geschlossener Kompromiss/Mehrheitsentscheidung gilt doch für alle.

Du hast immer noch nicht verstanden, wie (und warum) OSM funktioniert.

Will ich unter der Prämisse auch nicht.
Daß es so nicht richtig sein kann, abgesehen für eingefleischte Spezialisten oder auch OSM-Professoren, sieht man ja im OSMI.