You are not logged in.

Announcement

*** NOTICE: forum.openstreetmap.org is being retired. Please request a category for your community in the new ones as soon as possible using this process, which will allow you to propose your community moderators.
Please create new topics on the new site at community.openstreetmap.org. We expect the migration of data will take a few weeks, you can follow its progress here.***

#126 2015-02-11 20:38:51

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 436

Re: Diskussion über Public Transport Version 2.1

Weide wrote:

Wir haben ja derzeit die Situation, dass die unabsichtlichen Beschädigungen an PTv2-Routen durch das Auftrennen von Wegen in ganz anderen Zusammenhängen (meist Lane-Edits und Fußgängerinseln und meist in JOSM) zu einigen Stunden Reparaturarbeiten pro Tag allein in NRW führen. Diese Reparaturen sind gewöhnlich ziemlich leicht durchführbar, aber sie kosten auch mit viel Routine viel Zeit und sie bringen keinen Fortschritt sondern beseitigen nur Rückschritte. Die Verursacher bekommen von der ganzen Angelegenheit nichts mit, da die von ihnen verarbeiteten Objekte nicht geändert werden müssen.

Du beschreibst nur eine Seite. Viele Mapper achten darauf, mit ihren Änderungen keinen Schaden an den ÖPNV-Relationen zu verursachen. Die einen passen die Relationen selbst an und brauchen dafür sehr viel Zeit, weil sie ungeübt sind und viel nachlesen müssen, die anderen verzichten darauf, solche Straßen zu bearbeiten. Die Verursacher, also die Ersteller der ÖPNV-Relationen, bekommen von der ganzen Angelegenheit nichts mit, da man den erstellten Changesets die Mehrarbeit nicht ansieht und die nicht erstellten Changesets gar nicht sichtbar sind.

Wir arbeiten also mit Datenstrukturen, die sehr ungüstige Zusammenhänge schaffen.

Ja!

Dazu werden die von vielen Mappen ja ohnehin gewünschten Segmente eingesetzt. (Diese geben gemeinsame Routenstücke von mehreren Varianten an und vermeiden so vielfache Angaben derselben Sache.)

Das wäre schon ein Fortschritt. Allerdings fügt man damit dem ÖPNV-Schema eine weitere Abstraktionsebene hinzu und macht die Kontrolle der Relationen abhängig vom Editor komplizierter.

Konsequent wäre es, nur die Haltestellen zu erfassen und die stupide Arbeit einem Router bei der Auswertung überlassen.
Damit würde man sowohl den Mappern, die ÖPNV-Relationen erstellen und pflegen, als auch jenen, die die Straßen editieren, viel Arbeit abnehmen.
Die Datenstrukturen wären zudem weniger anfällig gegen unabsichtliche Zerstörung.

Offline

#127 2015-02-11 20:50:15

Nadjita
Member
From: Misburg, Hannover
Registered: 2013-07-12
Posts: 538

Re: Diskussion über Public Transport Version 2.1

Wie kann man denn mit dem Auftrennen eines Weges eine PTv2-Route kaputt machen? Auftrennen macht doch nur Abbiegeverbote und destination_signs kaputt. Das Zusammenführen ist in meinen Augen das Problem. Das ist eine der riskantesten Aktionen in OSM (und eine rein kosmetische), wobei die neueren JOSM-Versionen wenigstens mit dem mehrfachen Vorkommen in einer Relation klar kommen. Wie es sich da mit anderen Editoren verhält weiß ich ja nicht.

Aber davon ab fände ich es schade, wenn man Segmente auf eine noch höhere PT-Version verschieben müsste. Ich habe hier Buslinien, die aus insgesamt 10 Einzelvarianten bestehen mit eigentlich nur einer handvoll Variationen, wenn man Bausteine nehmen würde. Wenn dann jemand einen Baustein beschädigt, müsste man auch nicht gleich alle Relationen fixen, sondern nur den einen Baustein. Aber ohne guten Editor-Support in JOSM sehe ich schwarz für Segment-Bausteine.

Offline

#128 2015-02-11 21:16:35

seichter
Member
Registered: 2011-05-21
Posts: 3,337

Re: Diskussion über Public Transport Version 2.1

Nadjita wrote:

Aber ohne guten Editor-Support in JOSM sehe ich schwarz für Segment-Bausteine.

Ich habe Segmente für ÖPNV-Stammlinien (Innenstadt, Busbahnhof) verwendet und darin keine Schwierigkeiten gesehen.
Es gibt allerdings Anwendungen, die mit geschachtelten Relationen nicht zurechtkommen.

Offline

#129 2015-02-11 21:21:23

Nadjita
Member
From: Misburg, Hannover
Registered: 2013-07-12
Posts: 538

Re: Diskussion über Public Transport Version 2.1

Ich meine eher, dass man selbst den Überblick verliert, ob die Segmente überhaupt (noch) aneinanderpassen und dadurch auch, ob die Reihenfolge stimmt. In JOSM könnte ich mir das aufklappbar im Routeneditor vorstellen *träum*

Offline

#130 2015-02-11 21:35:09

seichter
Member
Registered: 2011-05-21
Posts: 3,337

Re: Diskussion über Public Transport Version 2.1

Nadjita wrote:

Ich meine eher, dass man selbst den Überblick verliert, ob die Segmente überhaupt (noch) aneinanderpassen und dadurch auch, ob die Reihenfolge stimmt. In JOSM könnte ich mir das aufklappbar im Routeneditor vorstellen *träum*

Der OSM Relation Analyzer http://ra.osmsurround.org/ kann die Zusammenhängigkeit auch bei geschachtelten Relationen darstellen (konnte es zumindest damals).
Im JOSM-Relationen-Editor wäre das Feature natürlich viel effizienter angesiedelt.

Offline

#131 2015-02-11 21:37:20

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 3,046
Website

Re: Diskussion über Public Transport Version 2.1

Nadjita wrote:

Wie kann man denn mit dem Auftrennen eines Weges eine PTv2-Route kaputt machen? Auftrennen macht doch nur Abbiegeverbote und destination_signs kaputt. Das Zusammenführen ist in meinen Augen das Problem. Das ist eine der riskantesten Aktionen in OSM (und eine rein kosmetische), wobei die neueren JOSM-Versionen wenigstens mit dem mehrfachen Vorkommen in einer Relation klar kommen. Wie es sich da mit anderen Editoren verhält weiß ich ja nicht.

Das Auftrennen ist ein Problem, wenn nicht genügend Mitglieder der Relation geladen sind. Im Folgenden gehe ich von JOSM aus. Angenommen, der Editor hat von einer Relation nur eine Way geladen. Wenn man nun diesen Way aufsplittet, woher soll der Editor dann wissen, dass er Teil 1 vor Teil 2 oder Teil 2 vor Teil 1 in die Relation einsortieren soll? Wenn die angrenzenden Member (also das erste vor und nach dem zu teilenden Way) geladen sind, dann kann er das selbst ermitteln (außer die Relation ist so kaputt, dass die gerade an der Stelle ein Loch hat).

Bei iD kann ich mir vorstellen, dass Teil 2 des gesplitteten Ways einfach hinten am Relationsende angehängt oder hinter Teil 1 einsortiert wird. Wer möchte, darf gerne mal Versuche machen und die Erkenntnisse hier posten.

Einen großen Teil der Routen-Fehler, die durch Aufsplitten der Ways entstehen, dürfte man verhindern können, wenn JOSM einfach das Aufsplitten solcher Ways nur erlauben würde, wenn der Vorgänger und Nachfolger in der Routenrelation geladen sind. Eine Fehlermeldung im Stil "Der Way kann nicht geteilt werden, weil er Mitglied einer Relation ist und noch nicht genügend Mitglieder der Relation geladen sind. [fehlende Ways nachladen] [Way nicht aufteilen]" ([Buttonbeschriftung]) dürfte JOSM-Nutzer nicht verstören (die sind ja, um es im iD-Sprech auszudrücken, verstörende Popus gewohnt). Im Falle von iD wäre es egal, wenn der Editor sich schnell im Hintergrund den Vorgänger und Nachfolger von der API holt, da das Onlineeditor ist. (In JOSM braucht man einen Netzwerkverbindung nur zum Down- und Upload)

Nadjita wrote:

Aber davon ab fände ich es schade, wenn man Segmente auf eine noch höhere PT-Version verschieben müsste. Ich habe hier Buslinien, die aus insgesamt 10 Einzelvarianten bestehen mit eigentlich nur einer handvoll Variationen, wenn man Bausteine nehmen würde. Wenn dann jemand einen Baustein beschädigt, müsste man auch nicht gleich alle Relationen fixen, sondern nur den einen Baustein. Aber ohne guten Editor-Support in JOSM sehe ich schwarz für Segment-Bausteine.

Das Wiedereinführen von Segmenten ist halt ein tiefer Eingriff in die Datenstruktur. Wir diskutieren hier erstmal über Version 2.1, die ja möglichst auch noch abwärtskompatibel zu 2.0 sein soll. :-)


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#132 2015-02-11 21:49:07

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Nadjita wrote:

Wie kann man denn mit dem Auftrennen eines Weges eine PTv2-Route kaputt machen?

Die Reihenfolge der Wege in der Relation gibt die Durchfahrrichtung indirekt an. Steht da
Weg A
Weg B
Weg C
dann fährt der Bus erst durch A, dann durch B und dann durch C. Jetzt trennen wir B auf und erhalten die Teile X und Y. Nehmen wir an, dass X das Stück von B ist, dass zuerst durchfahren wurde. Die richtige Reihenfolge ist dann also
Weg A
Weg X
Weg Y
Weg C

Beim Bus in der Gegenrichtung stand da
Weg C
Weg B
Weg A
und jetzt muss da
Weg C
Weg Y
Weg X
Weg A
stehen.

Es muss also einmal das B durch XY und einmal durch YX erstetzt werden.

Das macht der JOSM nur dann richtig, wenn er zum Zeitpunkt des Auftrennens A und C und die Relation schon geladen hatte. Sonst ersetzt er B beide Male durch XY und damit ist eine der beiden Relationen falsch, Scotty muss den Bus zweimal beamen und er fährt in den Daten ein kleines Stückchen von Süd nach Nord statt wie in der Realität von Nord nach Süd.

Das kann man verhindern, wenn man vor jedem Auftrennen ("p") den zu trennenden Weg und seine beiden Endpunkte anwählt und Alt-Ctrl-D macht.

Da das sehr häufig bei großen Straßen (wegen der lanes) passiert und da notorisch auch viele Busse fahren, kann man ganz leicht ein Dutzend Relationen beschädigen ohne was zu merken.

Weide

Offline

#133 2015-02-11 21:52:51

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Nakaner wrote:

Bei iD kann ich mir vorstellen, dass Teil 2 des gesplitteten Ways einfach hinten am Relationsende angehängt oder hinter Teil 1 einsortiert wird. Wer möchte, darf gerne mal Versuche machen und die Erkenntnisse hier posten.

Hab ich gemacht. Der ID hat alles richtig gemacht. Diesen Fehler hab ich bei meinen Reparaturarbeiten auch fast nur im Zusammenhang mit JOSM gefunden.

Weide

Edit: PS: Beim Längssplitten (Fußgängerinseln vor Kreuzungen. Aus einem Weg werden zwei benachbarte Oneways) muss man es in jedem Editor per Hand korrigieren und das geht im ID m.W. einfach nicht.

Last edited by Weide (2015-02-11 22:13:21)

Offline

#134 2015-02-11 22:03:58

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

seawolff wrote:

Konsequent wäre es, nur die Haltestellen zu erfassen und die stupide Arbeit einem Router bei der Auswertung überlassen.

Ein Router kann die Strecke nur raten, reagiert empfindlich auf Baustellen etc. und ist bei teilweise erfassten Routen schlechter als nichts. Da würde ich eher komplett auf den Fahrweg verzichten. Wenn mehrere Mapper mal hier und mal da was beitragen, dann geht das ohne Fahrwege nur ganz schlecht, weil man keinen Überblick über den Erfassungszustand bekommt. Man sieht nicht, ob der Bus an dieser Abbiegung einfach durchfährt oder ob er noch einen Schlenker durch A-Dorf macht und da nur noch keiner Haltestellen erfasst hat.

Weide

Offline

#135 2015-02-11 22:05:59

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Nakaner wrote:

Wir diskutieren hier erstmal über Version 2.1, die ja möglichst auch noch abwärtskompatibel zu 2.0 sein soll. :-)

Sollten wir dann mal für 3 extra was aufmachen?

Weide

Offline

#136 2015-02-11 23:25:41

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 3,046
Website

Re: Diskussion über Public Transport Version 2.1

Hallo Weide,

Weide wrote:
Nakaner wrote:

Wir diskutieren hier erstmal über Version 2.1, die ja möglichst auch noch abwärtskompatibel zu 2.0 sein soll. :-)

Sollten wir dann mal für 3 extra was aufmachen?

Ja, wir sollten trennen in kleine Änderungen, z.B.
- Wiedereinführung von light_rail (?)
- service=* an Routenrelationen (bei der Bahn zur Unterscheidung der Zuggattungen von S und RB bis ICE)
- Unterstützung mehrerer Plattformen für eine Stop-Position (wenn z.B. der Bahnsteig zur Hälfte gepflastert ist und die andere Hälfte unbefestigt und niedriger)

und große Änderungen, z.B.
- Segemente (ob wir das überhaupt wollen, ist eine andere Frage)
- Idee/Konzepte wie der PTv3-Entwurf von Weide
- spezielle fahrweglose Relationen für Verkehrsmittel, die keinen festen Fahrweg haben (Flächenrufbusse)

Kleine Änderungen sollten Änderungen sein, die nur einen geringen Aufwand für dem Mapper bei der Konvertierung einer Route von v2 nach v2.1 mit sich bringen und für die kein großer Programmieraufwand anfällt bzw. die zu keinen großen Problemen führen, wenn man sie nicht in seiner Auswertung berücksichtigt. Große Änderungen müssen nicht unbedingt abwärtskompatibel sein und können auch für den Mapper einen erhöhten Aufwand bedeuten.

Es wäre also eine gute Idee die großen Änderungen in einem separaten Thread zu diskutieren.

Wer von euch hat eigentlich vor zur FOSSGIS zu kommen? Man könnte sich dort im Rahmen eines BOF treffen.

Viele Grüße

Michael


PS Deine Erklärung, wie man mit JOSM Routen beschädigt, ist richtig gut.

Last edited by Nakaner (2015-02-12 00:07:43)


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#137 2015-02-12 07:11:11

Swen Wacker
Member
From: Lüneburg
Registered: 2014-07-25
Posts: 339

Re: Diskussion über Public Transport Version 2.1

seawolff wrote:

Konsequent wäre es, nur die Haltestellen zu erfassen und die stupide Arbeit einem Router bei der Auswertung überlassen.

Denkbar wäre auch eine Trennung der Relationen in "angefahrene Haltestellen dieser Linie" und "einzelne Streckenverläufe"

Ich quäle mich gerade durch den Buslinien Lüneburgs mit ihren zig Varianten je Streckenverlauf. Dabei empfinde ich als wenig motivierend, dass die Streckenverläufe bei allen OSM-basierten ÖPNV-Anwendungen, die ich kenne, allein bunte Striche in der Landschaft sind. Was ja anderseits auch klar ist, da eine Darstellung "zeige den Streckenverlauf der nächsten Fahrt der Linie 5003 jetzt" oder "zeige mir das befahrene Streckennetz an einem Samstagvormittag" aus den OSM-Daten schon deshalb nicht abstrahierbar wäre, weil eine Tagging-Differenzierung der unterschiedlichen Varianten nicht erfolgt und auch kaum möglich erscheint "course_variant=So, während der NI-Schulferien, Fahrten um 07.16, 09.16 und 18.14".

Andererseits motiviert (mich) die Verknüpfung der Haltestellendaten mit einem Fahrplan, wie sie openptmap macht, sehr. Deshalb dachte ich auch schon mehrfach: "Relationen trennen in Haltestellen und Streckenverlauf".

Last edited by Swen Wacker (2015-02-12 07:19:45)

Offline

#138 2015-02-12 08:06:01

Thoschi
Member
Registered: 2013-07-19
Posts: 767

Re: Diskussion über Public Transport Version 2.1

Ich finde es ebenfalls müßig, jede Linienvariation als eigene Route zu definieren. Aber ist es nicht das, was man zum routen braucht? Ich stelle mir vor, für ganz Deutschland einen Routenplan zu haben, der aber die Strecken nicht wie bei diesem hier als gerade Strecke sondern als richtigen Streckenverlauf auf Basis der OSM Karte darstellt. Die Basisdaten (einschl. Erfassung der Routen) dafür können nur von OSM kommen, die Fahrpläne vom jeweiligen Netzbetreiber. Was geregelt werden müsste, ist dann die regelmäßige Pflege der Routen. DAS ist kurzfristig allerdings nicht zu machen.

Offline

#139 2015-02-12 08:09:29

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

seawolff wrote:

Du beschreibst nur eine Seite. Viele Mapper achten darauf, mit ihren Änderungen keinen Schaden an den ÖPNV-Relationen zu verursachen. Die einen passen die Relationen selbst an und brauchen dafür sehr viel Zeit, weil sie ungeübt sind und viel nachlesen müssen, die anderen verzichten darauf, solche Straßen zu bearbeiten. Die Verursacher, also die Ersteller der ÖPNV-Relationen, bekommen von der ganzen Angelegenheit nichts mit, da man den erstellten Changesets die Mehrarbeit nicht ansieht und die nicht erstellten Changesets gar nicht sichtbar sind.

Ja, da stimme ich Dir zu.

Schuld sind weder die Ersteller der Routen, die ja nur Daten erfassen wollen, noch die Leute, die mit dem JOSM Routen beschädigen, die sie oft nicht mal auf dem Bildschirm haben. Deshalb  sind Datenstrukturen wichtig, die unempfindlich gegen Splitten sind.

Ein ähnliches (aber seltenes) Problem haben wir übrigens bei Multipolygonen. Auch da kann bei den erlaubten Berührungen der Ränder durch Splitting ein MP beschädigt werden, wenn dabei ein Knoten mit mehreren Verbindungsmöglichkeiten entsteht.

Weide

Offline

#140 2015-02-12 08:13:33

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Swen Wacker wrote:

Dabei empfinde ich als wenig motivierend, dass die Streckenverläufe bei allen OSM-basierten ÖPNV-Anwendungen, die ich kenne, allein bunte Striche in der Landschaft sind.

Früher hatten wir wenigstens noch bunte Striche und bunte Pfeile. Die Pfeile galten für die Streckenstücke, die nur in einer Richtung durchfahren wurden. Ich fand das damals sehr hilfreich -- die Streckenpläne waren so wie sie sein sollten.

Mit der Einführung von PTv2 sind die Pfeile "verstorben":

1.: für die PTv2-Routen ist es schwer rauszukriegen. Man muss quer über alle Varianten anhand des Kontextes analysieren. (Wenn die Route nicht komplett und fehlerfrei ist, kann das richtig kompliziert werden.)

2.: für die PTv1-Routen wurde durch Verwechslung mit PTv2-Eigenschaften der Datenbestand entwertet. Eigentlich sind PTv1-Routen Linienpläne. Es gibt nur eine Relation pro Linie und jede Straße taucht nur einmal auf. Dann musste man nur die Straße in der Relation finden und hatte:
Rolle "forward": Linie mit Pfeil in OSM-Richtung des Wegs
Rolle "backward": Linie mit Pfeil gegen die OSM-Richtung des Wegs
Rolle "": Linie ohne Pfeil (Bus fährt von links nach rechts und von rechts nach links)
Richtige PTv1-Routen sind sehr selten geworden.

Weide

Offline

#141 2015-02-12 08:26:38

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Thoschi wrote:

Ich finde es ebenfalls müßig, jede Linienvariation als eigene Route zu definieren. Aber ist es nicht das, was man zum routen braucht? Ich stelle mir vor, für ganz Deutschland einen Routenplan zu haben, der aber die Strecken nicht wie bei diesem hier als gerade Strecke sondern als richtigen Streckenverlauf auf Basis der OSM Karte darstellt.

Das ist im Grunde PTv1. Eine Straßenliste mit Durchfahrrichtungsergänzungen(den Rollen "forward", "backward" und "" für bidirektional)

PTv2 kam, weil einige Sachen nicht aus dem Streckenplan hervorgehen. Auf dem Plan kann es so aussehen, als ob der Bus von A-Dorf nach B-Dorf fährt. Tatsächlich gibt es aber nur die Varianten "ohne die beiden Dörfer", "über A-Dorf" und "über B-Dorf", aber eben nicht "über beide". Oder etwa Sprungbusse (bin ich in Schweden mal drauf reingefallen), die auf derselben Strecke die meisten Haltestellen auslassen.

Weide

Offline

#142 2015-02-12 08:55:25

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

seawolff wrote:

   

Dazu werden die von vielen Mappen ja ohnehin gewünschten Segmente eingesetzt. (Diese geben gemeinsame Routenstücke von mehreren Varianten an und vermeiden so vielfache Angaben derselben Sache.)

Das wäre schon ein Fortschritt.

Es ging mir aber nicht darum, dass man etwas Arbeit spart weil man auf weniger Relationen Rücksicht nehmen muss. Ich will die ganze Rücksichtnahme-auf-ÖPV-Arbeit beim Splitten beseitigen. Derartige Segmente würden ohne Reihenfolgeinformation funktionieren und daher müsste man beim Splitten keine Rücksicht auf sie nehmen.

Weide

Offline

#143 2015-02-12 10:43:44

Weide
Member
Registered: 2009-04-05
Posts: 1,491

Re: Diskussion über Public Transport Version 2.1

Nakaner wrote:

Ja, wir sollten trennen in kleine Änderungen, z.B.
- Wiedereinführung von light_rail (?)
- service=* an Routenrelationen (bei der Bahn zur Unterscheidung der Zuggattungen von S und RB bis ICE)
- Unterstützung mehrerer Plattformen für eine Stop-Position (wenn z.B. der Bahnsteig zur Hälfte gepflastert ist und die andere Hälfte unbefestigt und niedriger)

und große Änderungen, z.B.
- Segemente (ob wir das überhaupt wollen, ist eine andere Frage)
- Idee/Konzepte wie der PTv3-Entwurf von Weide
- spezielle fahrweglose Relationen für Verkehrsmittel, die keinen festen Fahrweg haben (Flächenrufbusse)

Kleine Änderungen sollten Änderungen sein, die nur einen geringen Aufwand für dem Mapper bei der Konvertierung einer Route von v2 nach v2.1 mit sich bringen und für die kein großer Programmieraufwand anfällt bzw. die zu keinen großen Problemen führen, wenn man sie nicht in seiner Auswertung berücksichtigt. Große Änderungen müssen nicht unbedingt abwärtskompatibel sein und können auch für den Mapper einen erhöhten Aufwand bedeuten.

Es wäre also eine gute Idee die großen Änderungen in einem separaten Thread zu diskutieren.

Ich mache dann mal einen neuen Thread auf "Diskussion über Public transport Version 3"

Weide

Offline

#144 2015-02-12 10:50:11

Polyglot
Member
From: Belgium
Registered: 2011-11-25
Posts: 243

Re: Diskussion über Public Transport Version 2.1

Ist das nur für Deutschland/deutschsprächige Gebiete? Sonst wäre es vielleicht besser das auf English zu machen.

Jo

Offline

#145 2015-02-12 13:05:14

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 3,046
Website

Re: Diskussion über Public Transport Version 2.1

Polyglot wrote:

Ist das nur für Deutschland/deutschsprächige Gebiete? Sonst wäre es vielleicht besser das auf English zu machen.

Wir können uns hier ja auf einen Vorschlag einigen und diesen mit allen Pro- und Kontraargumenten, die im Laufe der Zeit aufgetaucht sind, anschließend international zur Diskussion stellen.


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#146 2015-02-12 19:54:41

Prince Kassad
Member
Registered: 2013-10-18
Posts: 2,391

Re: Diskussion über Public Transport Version 2.1

Darf ich mal einen Vorschlag einwerfen?
Ein Attribut für elektronische Anzeigetafeln wäre sehr sinnvoll. Diese sind zunehmend auch bei Bushaltestellen verbreitet und können sehr nützlich sein, vor allem weil dort Verspätungen und Umleitungen erscheinen, die man aus dem Fahrplan (logischerweise) nicht herauslesen kann.

Offline

#147 2015-02-12 20:31:13

Swen Wacker
Member
From: Lüneburg
Registered: 2014-07-25
Posts: 339

Re: Diskussion über Public Transport Version 2.1

Prince Kassad wrote:

Ein Attribut für elektronische Anzeigetafeln wäre sehr sinnvoll.

+1

http://taginfo.openstreetmap.org/keys/p … lay#values

Last edited by Swen Wacker (2015-02-12 20:31:31)

Offline

#148 2015-02-12 21:01:56

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 3,046
Website

Re: Diskussion über Public Transport Version 2.1

Prince Kassad wrote:

Darf ich mal einen Vorschlag einwerfen?
Ein Attribut für elektronische Anzeigetafeln wäre sehr sinnvoll. Diese sind zunehmend auch bei Bushaltestellen verbreitet und können sehr nützlich sein, vor allem weil dort Verspätungen und Umleitungen erscheinen, die man aus dem Fahrplan (logischerweise) nicht herauslesen kann.

+1

Das kann problemlos in PTv2.1 aufnehmen, da es 100 % abwärtskompatibel ist. Ich würde es an die Plattform taggen. Welches Tag schlägst du vor?


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#149 2015-02-12 21:22:36

mapper999
Member
Registered: 2014-02-16
Posts: 36

Re: Diskussion über Public Transport Version 2.1

Nakaner wrote:
Prince Kassad wrote:

Darf ich mal einen Vorschlag einwerfen?
Ein Attribut für elektronische Anzeigetafeln wäre sehr sinnvoll. Diese sind zunehmend auch bei Bushaltestellen verbreitet und können sehr nützlich sein, vor allem weil dort Verspätungen und Umleitungen erscheinen, die man aus dem Fahrplan (logischerweise) nicht herauslesen kann.

+1

Das kann problemlos in PTv2.1 aufnehmen, da es 100 % abwärtskompatibel ist. Ich würde es an die Plattform taggen. Welches Tag schlägst du vor?

Hallo,

ich hab vor kurzem auch nach einem Tag für Anzeigetafeln gesucht und bin auf departures_board="" gestoßen. Dabei hab ich die folgenden Werte benutzt:
- realtime -> Anzeige der Abfahrtszeit in Minuten ("in 1 min" typisch bei Straßenbahnen und Bussen)
- delay -> Anzeige von Verspätungen ("heute ca. 5min später", typisch für kleinere Bahnhöfe und Haltepunkte der DB)
- timetable -> Anzeige der fahrplanmäßigen Abfahrtszeit ("10:00" wenn keine Informationen zu Verspätungen angezeigt werden)
- delay;timetable -> Anzeige sowohl der planmäßigen Abfahrtszeit als auch von Verspätungen (typisch für größere Bahnhöfe)

Ich hab meistens direkt die Stelle, an der die Anzeigetafel steht, getaggt, zusätzlich mit public_transport=departures_board.
Ich denke man könnte hier analog zu bin=yes, shelter=yes, amenity=waste_basket und amenity=shelter vorgehen und es sowohl an den Bahnsteig als auch an die konkrete Position taggen.

Ich wollte das Schema eigentlich schon länger mal dokumentieren, bin aber bisher noch nicht dazugekommen.
Einige so getaggte Anzeigetafeln findet ihr in diesem Bereich.
Die könnte man vielleicht als Basis für eine weitere Diskussion verwenden.

Offline

#150 2015-02-12 21:56:00

surveyor54
Member
From: Rhein-Main-Gebiet
Registered: 2010-05-23
Posts: 415

Re: Diskussion über Public Transport Version 2.1

Im Wiki steht es schon länger als passenger_information_display=*

http://wiki.openstreetmap.org/wiki/DE:T … us_stop.29

Offline

Board footer

Powered by FluxBB