Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Ich meine es würde schon sehr viel helfen wenn die 'Notwendigkeit' um die stop_position Nodes an die Routen hinzu zu fügen verschwindet. Also nur Platform und Wegteile in die Routerelationen in die richtige Reihenfolge. Erst alle Wege, dann alle Platform. Platform sind für mich auch immer Nodes, nie Way. Wenn ein eigentliches Platform besteht, dann zeichne ich einen Weg dafür mit highway=platform/public_transport=platform oder railway=platform/public_transport drauf. Der geht dann in eine stop_area Relation, zusammen mit stop_position, platform node mit alle Details, shelter, waste_basket und bench und manchmal noch ein Schirm. In Belgien sind alle Attribute an eine Seite der Strasse in ihre eigene stop_area Relation. Und diese stop_area Relation zusammen in eine andere stop_area Relation. Ein Beispiel: https://www.openstreetmap.org/relation/4121654 Ich bin schon einige Jahre damit beschäftigt um alle Haltestellen in Belgien in OSM zu bringen. Hab schon etwas Erfahrung damit. (Die von De Lijn und TEC sind jetzt alle 65000 drin, für MIVB/STIB in Brüssel fehlen noch welche). Ich frage auch schon 2 oder 3 Jahre um das 'neue' Schema zu unterstutzen, aber das würde heissen das 10 extra Felder geladen werden müssen. Hauptsächlich ist es das sie das einfach nicht machen WOLLEN. Na gut. Jetzt sind die letzte etwa 4 alle doppelt getaggt... ohne Hoffnung das highway=bus_stop verschwinden werden kann. In Belgien gibt es 3 Transportbetriebe. An diese Haltestelle Hallepoort fahren die alle entlang. Ich habe für jedes Betrieb ein Platformnode gemacht, weil das einfacher zu unterhalten ist. Das ist warscheinlich kontroversiell... Was warscheinlich auch kontroversiell ist, ist das ich die routerelationen von Segmente aufbauen will. So wird jede Strasse dann Teil sein von 2 solche SegmentRouteRelationen anstatt 62 sowie hier: https://www.openstreetmap.org/way/3991636 Und dann sind die Schulbüsse noch nicht kartiert. Eine für jede Richtung. Das wird viel einfacher zu unterhalten sein und es wird neue Leute weniger Angst machen die zu editieren. Manche werden vielleicht sagen: 3 Nivos (route_master, route, route_segment, Ways) das wird zu komplex sein. Jetzt ist es aber sehr Zeitraubend um die zu reparieren wenn die mal wieder unterbrochen sind. Hoffentlich versteht ihr was ich meine. Mein Deutsch ist nicht so ganz gut. Entschuldigung dafür. Polyglot 2014-11-06 20:18 GMT+01:00 fly : > Das alte Schema hat Schwächen und ist am Ende auch nur eine Sammlung, da > der Streckenverlauf gerade bei Bussen nicht mehr nachvollziehbar ist. > > Unter anderem desshalb wurde das neue Schema erarbeitet. > > Leider wird dieses bis heute auf keiner der auf der Hauptseite > angebotenen Karten unterstützt. Da alle Tram und Stadt-Buslinien auf das > neue/aktuelle Schema umgestellt sind hatte ich mich entschlossen auch > das alte Tagging an den Haltestellen zu entfernen. Pustekuchen, alle > Haltestellen verschwanden, nur die deutsche Seite gab mir Hoffnung. > > Ich sehe das Problem eine Stufe höher angesiedelt, da hier noch nicht > einmal beide System komplett unterstützt werden und somit keine gleichen > Chancen existieren. > > Ob es nun an jeder Bushaltestelle eine stop_position geben muss, kann > man gerne diskutieren, aber wir brauchen die stop_position auch bei > Buslinien und das alte Schema hatte genau Problem mit der > Unterscheidung/Positionierung welche nun gelöst sind. > > Eine Ausnahme für Busse einzuführen macht es auch nicht einfacher und > die Komplexität steigt auch nicht damit, ob es nun jeweils ein Objekt > mit einer Rolle oder zwei Objekte mit ihrer Rolle sind. Das Grundprinzip > der Relation mit Rollen und sowohl platform wie stop_position müß > verstanden werden. > > cu fly > > Am 05.11.2014 um 06:08 schrieb Tirkon: > > Michael Reichert wrote: > > > >> Wenn aber z.B. eine Linie mit kurzen Zügen und eine mit langen Zügen vor > >> der selben Haltetafel halten, dann brauchen die beiden getrennte > >> stop_positions. > > > > Würdest Du mir zustimmen, dass die stop_position nur in sehr wenigen > > Fällen nicht aus den Positionen der Haltestellenschilder bzw. der > > Positionsschilder ABCDEF z.B. durch Fällen des Lotes auf den Verlauf > > der Routenrelation hervorgeht? > > > > Falls ja, bitte ich Folgendes zu bedenken: Das Mappen des ÖPNV > > geschieht derzeit sehr uneinheitlich. Eine große Mehrheit von Mappern > > versteht das derzeitige ÖPNV Schema mit der Aufteilung einer > > Haltestelle in platform und stop_position nicht. Wenn schon OSM-Füchse > > wie die Moderatoren des Podcastes sich nicht damit auskennen, sollte > > man doch schon ins Grübeln kommen. > > > > Es nützt nichts, wenn die "Diplomarbeit von Sebastian > > Schwarz"-Versteher ein Schema beschließen, an deren Abstimmung die > > große Mehrheit der Mapper nicht teilnehmen kann, weil sie deren > > Diskussion nicht versteht. Folglich wird das Modell nicht oder nur > > fehlerhaft umgesetzt. Selbst richtig gemappte Busrouten-Relationen > > werden dann inkons
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Das alte Schema hat Schwächen und ist am Ende auch nur eine Sammlung, da der Streckenverlauf gerade bei Bussen nicht mehr nachvollziehbar ist. Unter anderem desshalb wurde das neue Schema erarbeitet. Leider wird dieses bis heute auf keiner der auf der Hauptseite angebotenen Karten unterstützt. Da alle Tram und Stadt-Buslinien auf das neue/aktuelle Schema umgestellt sind hatte ich mich entschlossen auch das alte Tagging an den Haltestellen zu entfernen. Pustekuchen, alle Haltestellen verschwanden, nur die deutsche Seite gab mir Hoffnung. Ich sehe das Problem eine Stufe höher angesiedelt, da hier noch nicht einmal beide System komplett unterstützt werden und somit keine gleichen Chancen existieren. Ob es nun an jeder Bushaltestelle eine stop_position geben muss, kann man gerne diskutieren, aber wir brauchen die stop_position auch bei Buslinien und das alte Schema hatte genau Problem mit der Unterscheidung/Positionierung welche nun gelöst sind. Eine Ausnahme für Busse einzuführen macht es auch nicht einfacher und die Komplexität steigt auch nicht damit, ob es nun jeweils ein Objekt mit einer Rolle oder zwei Objekte mit ihrer Rolle sind. Das Grundprinzip der Relation mit Rollen und sowohl platform wie stop_position müß verstanden werden. cu fly Am 05.11.2014 um 06:08 schrieb Tirkon: > Michael Reichert wrote: > >> Wenn aber z.B. eine Linie mit kurzen Zügen und eine mit langen Zügen vor >> der selben Haltetafel halten, dann brauchen die beiden getrennte >> stop_positions. > > Würdest Du mir zustimmen, dass die stop_position nur in sehr wenigen > Fällen nicht aus den Positionen der Haltestellenschilder bzw. der > Positionsschilder ABCDEF z.B. durch Fällen des Lotes auf den Verlauf > der Routenrelation hervorgeht? > > Falls ja, bitte ich Folgendes zu bedenken: Das Mappen des ÖPNV > geschieht derzeit sehr uneinheitlich. Eine große Mehrheit von Mappern > versteht das derzeitige ÖPNV Schema mit der Aufteilung einer > Haltestelle in platform und stop_position nicht. Wenn schon OSM-Füchse > wie die Moderatoren des Podcastes sich nicht damit auskennen, sollte > man doch schon ins Grübeln kommen. > > Es nützt nichts, wenn die "Diplomarbeit von Sebastian > Schwarz"-Versteher ein Schema beschließen, an deren Abstimmung die > große Mehrheit der Mapper nicht teilnehmen kann, weil sie deren > Diskussion nicht versteht. Folglich wird das Modell nicht oder nur > fehlerhaft umgesetzt. Selbst richtig gemappte Busrouten-Relationen > werden dann inkonsistent, wenn der Mapper vor Ort bei Verlegung einer > Bushaltestelle nur die platform aber nicht die stop_position > verschiebt. Vielleicht bemerkt er auch (sofern er nicht ID nutzt) die > Routen-Relation, lässt aber wegen der Komplexität dann die Finger von > der Wartung. > > Ergo müssen die Datenjunkies beim Entwurf ihrer Schemata für die große > schweigende Mehrheit der Mapper mitdenken und das Teil ergonomisch und > intuitiv gestalten. Und was ist intuitiver als die Realität, in der > für den Mapper nachvollziehbar der ÖPNV am Schild bzw. Wartefläche > hält? > > Abseits vom Verständnis der Datenkonstruktion kommt noch Folgendes > hinzu: Wer über 20 km mit dem Auto zu einem Bahnhof fahren muss, um > von dort aus nach über zwei Stunden Zugfahrt den nächsten ICE Bahnhof > zu erreichen, der fährt lieber gleich mit dem Auto zum Endziel und > wird die seltene Notwendigkeit einer stop_position niemals live > erleben. Dennoch ist man in der Lage, ein verschobenes > Bushaltestellenschild in seinem Ort auch in OSM zu verschieben. > > Ich selbst kann als Landei die Teilung von Bahnsteigen durch > Buchstaben nur deswegen nachvollziehen, weil ich alle zwei Jahre in > München in einen in Hannover geflügelnden ICE einsteige. > > Was nutzt ein Modell, das zugunsten weniger Spezialfälle so komplex > wird, dass es nicht funktioniert? Es geht hier also nicht um das > Deprecaten eines Tags, sondern um ein Modell, das nicht nur von einer > kleinen Minderheit umgesetzt werden kann. > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
On 05.11.2014 06:08, Tirkon wrote: > [...] +1 -- Andreas Neumann http://Map4Jena.de http://Stadtplan-Ilmenau.de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Michael Reichert wrote: >Wenn aber z.B. eine Linie mit kurzen Zügen und eine mit langen Zügen vor >der selben Haltetafel halten, dann brauchen die beiden getrennte >stop_positions. Würdest Du mir zustimmen, dass die stop_position nur in sehr wenigen Fällen nicht aus den Positionen der Haltestellenschilder bzw. der Positionsschilder ABCDEF z.B. durch Fällen des Lotes auf den Verlauf der Routenrelation hervorgeht? Falls ja, bitte ich Folgendes zu bedenken: Das Mappen des ÖPNV geschieht derzeit sehr uneinheitlich. Eine große Mehrheit von Mappern versteht das derzeitige ÖPNV Schema mit der Aufteilung einer Haltestelle in platform und stop_position nicht. Wenn schon OSM-Füchse wie die Moderatoren des Podcastes sich nicht damit auskennen, sollte man doch schon ins Grübeln kommen. Es nützt nichts, wenn die "Diplomarbeit von Sebastian Schwarz"-Versteher ein Schema beschließen, an deren Abstimmung die große Mehrheit der Mapper nicht teilnehmen kann, weil sie deren Diskussion nicht versteht. Folglich wird das Modell nicht oder nur fehlerhaft umgesetzt. Selbst richtig gemappte Busrouten-Relationen werden dann inkonsistent, wenn der Mapper vor Ort bei Verlegung einer Bushaltestelle nur die platform aber nicht die stop_position verschiebt. Vielleicht bemerkt er auch (sofern er nicht ID nutzt) die Routen-Relation, lässt aber wegen der Komplexität dann die Finger von der Wartung. Ergo müssen die Datenjunkies beim Entwurf ihrer Schemata für die große schweigende Mehrheit der Mapper mitdenken und das Teil ergonomisch und intuitiv gestalten. Und was ist intuitiver als die Realität, in der für den Mapper nachvollziehbar der ÖPNV am Schild bzw. Wartefläche hält? Abseits vom Verständnis der Datenkonstruktion kommt noch Folgendes hinzu: Wer über 20 km mit dem Auto zu einem Bahnhof fahren muss, um von dort aus nach über zwei Stunden Zugfahrt den nächsten ICE Bahnhof zu erreichen, der fährt lieber gleich mit dem Auto zum Endziel und wird die seltene Notwendigkeit einer stop_position niemals live erleben. Dennoch ist man in der Lage, ein verschobenes Bushaltestellenschild in seinem Ort auch in OSM zu verschieben. Ich selbst kann als Landei die Teilung von Bahnsteigen durch Buchstaben nur deswegen nachvollziehen, weil ich alle zwei Jahre in München in einen in Hannover geflügelnden ICE einsteige. Was nutzt ein Modell, das zugunsten weniger Spezialfälle so komplex wird, dass es nicht funktioniert? Es geht hier also nicht um das Deprecaten eines Tags, sondern um ein Modell, das nicht nur von einer kleinen Minderheit umgesetzt werden kann. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Am 19. Oktober 2014 14:30 schrieb Henning Kleen < henning.kl...@informatik.uni-oldenburg.de>: > Zu einer Einbahnstraßenregelung gehört ein Verkehrsschild, ebenso zur > Höchstgeschwindigkeit. > zul. Höchstgeschwindigkeiten gibt es immer, auch ohne Schilder, auf Autobahnen etc. ggf. unbegrenzt. > Man kann es jetzt natürlich so sehen, dass zu einer stop_position auch ein > Haltestellenschild gehört. > ja, würde ich so sehen. > Mein Argument ging eher in die Richtung, dass den Fahrer nichts zwingt, > immer EXAKT an der stop_position zu stoppen, je nach Verkehrssituation > (geparkte Autos, bereits wartende Busse) kann er einige Meter früher oder > später halten. > das ist ein anderes Thema, klar, wenn die Bushaltestelle zugeparkt ist, muss der Bus (geringfügig) woanders halten, genauso wie man auch im Überholverbot an einem Hindernis vorbeifahren darf und dazu kurzfristig die doppelte Linie überfahren. > In so fern ist die stop_position immer nur eine ungefähre Schätzung. Wenn > eine solche Schätzung benötigt wird (für routing, etc.) kann man das meiner > Meinung nach auch wie von Tirkon vorgeschlagen durch das Fällen des Lotes > von der in der Route-Relation enthaltenen platform auf den ebenfalls > enthaltenen way. > +1, alles in unseren Daten ist entweder eine Schätzung, oder "alt" (weil von einer externen Quelle kommend). ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Hallo Christian, Am 2014-10-19 um 22:01 schrieb christian.pietz...@googlemail.com: >> Wie schon gesagt, die Erfassung von Haltepositionen in Bahnhöfen halte ich >> durchaus für gerechtfertigt. Die Positionen der Haltetafeln sollten auf >> jeden Fall erfasst werden, da sie ja Teil der Eisenbahninfrastruktur sind. >> Dass man auch bei Mehrfachbelegungen von Gleisen irgendwie darstellen >> möchte, dass der Zug nach A-Dorf immer vor dem Zug nach B-Stadt sehe ich >> auch so. Von daher sehe ich auch die Notwendigkeit von so etwas wie einer >> "stop_position" für den Bahnverkehr. >> > > für Bahnhöfe könnte man sicher auch auf die stop_positions verzichten, wenn > man das wollte. Wie du schon sagtest, ist das erfassen der > Haltepositionstafeln sinnvoll. Über die Tafeln könnte man dann einfach > wieder bestimmen, wo der Zug hält. Vor Ort seht schließlich auch Zug hält > von Marke E bis G. Oder seh ich das falsch? stop_positions ist üblicherweise bei Bahnen die Fahrzeugmitte. Haltetafeln stehen an der Fahrzeugspitze. Wenn kürzere Züge eingesetzt werden, fährt der Zug trotzdem meist vor bis zur Haltetafel. Das sollte für OSM aber egal sein, wenn es ein und dieselbe Routenrelation ist. Wenn aber z.B. eine Linie mit kurzen Zügen und eine mit langen Zügen vor der selben Haltetafel halten, dann brauchen die beiden getrennte stop_positions. In der Praxis trennt man stop_positions aber nicht, wenn die eine Linie einen Wagen mehr hat als die andere. Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Hallo > Wie schon gesagt, die Erfassung von Haltepositionen in Bahnhöfen halte ich > durchaus für gerechtfertigt. Die Positionen der Haltetafeln sollten auf > jeden Fall erfasst werden, da sie ja Teil der Eisenbahninfrastruktur sind. > Dass man auch bei Mehrfachbelegungen von Gleisen irgendwie darstellen > möchte, dass der Zug nach A-Dorf immer vor dem Zug nach B-Stadt sehe ich > auch so. Von daher sehe ich auch die Notwendigkeit von so etwas wie einer > "stop_position" für den Bahnverkehr. > für Bahnhöfe könnte man sicher auch auf die stop_positions verzichten, wenn man das wollte. Wie du schon sagtest, ist das erfassen der Haltepositionstafeln sinnvoll. Über die Tafeln könnte man dann einfach wieder bestimmen, wo der Zug hält. Vor Ort seht schließlich auch Zug hält von Marke E bis G. Oder seh ich das falsch? mfg hedaja Am 19. Oktober 2014 18:32 schrieb Henning Kleen < henning.kl...@informatik.uni-oldenburg.de>: > Hallo, > > Am 19.10.2014 um 13:19 schrieb Michael Reichert: > > >> Einzig >>> bei Bahnhöfen könnte ich mir vorstellen, dass es sinnvoll sein könnte, >>> die Halteposition zusätzlich zu erfassen, da Züge unterschiedlicher >>> Länge durchaus unterschiedliche Haltepositionen auf ein und dem selben >>> Gleis haben können (kenntlich gemacht durch Haltetafeln >>> http://www.tf-ausbildung.de/SignalbuchOnline/ne5.htm). Ob es >>> erforderlich ist, das in der Genauigkeit in OSM zu erfassen lasse ich >>> mal dahingestellt. >>> >> >> Es ist relevant, das in der Genauigkeit zu erfassen. In nicht wenigen >> Bahnhöfen halten mehrere Züge im selben Gleis hintereinander, weil sonst >> die Gleise nicht ausreichen (z.B. Köln Hbf, Mannheim Hbf, Hamburg Hbf) >> oder es so vorgesehen ist (z.B. Gößnitz [1] oder Montabaur >> (Regionalzüge). Da braucht man dann zwei (Gößnitz) stop_positions, weil >> es nur die beiden Halteplätze gibt, die durch Haltetafeln oder andere >> Signale gekennzeichnet sind, oder gar drei wie in Würzburg Hbf auf Gleis >> 2/3, wo das Gleis sowohl doppelt belegt wird und die Züge dann weiter >> außen halten, aber auch das Gleis nur einfach belegt wird und der Zug >> dann am Treppenabgang hält. >> > Wie schon gesagt, die Erfassung von Haltepositionen in Bahnhöfen halte ich > durchaus für gerechtfertigt. Die Positionen der Haltetafeln sollten auf > jeden Fall erfasst werden, da sie ja Teil der Eisenbahninfrastruktur sind. > Dass man auch bei Mehrfachbelegungen von Gleisen irgendwie darstellen > möchte, dass der Zug nach A-Dorf immer vor dem Zug nach B-Stadt sehe ich > auch so. Von daher sehe ich auch die Notwendigkeit von so etwas wie einer > "stop_position" für den Bahnverkehr. > >> >> Eine andere Frage wäre ob es derzeit irgendwelche Dienste etc. gibt, die >>> sowohl platform als auch stop_position auswerten und diese >>> Unterscheidung auch benötigen. Falls das nicht der Fall ist, so könnte >>> man ja mal versuchen einen Konsens erreichen, die stop_position >>> zukünftig nicht mehr zu erfassen (und als "deprecated" zu markieren). >>> Ich wäre auf jeden Fall dafür. >>> >> >> Jedem, der sich hier äußert und für die Abschaffung oder des Deprecaten >> eines Tags ist, sollte erst mal bittschön die Diplomarbeit von Sebastian >> Schwarz "Öffentlicher Personennahverkehr in OpenStreetMap" [2], die er >> im Jahr 2009 in der Geofabrik geschrieben hat, lesen. >> > Habe die Arbeit zumindest mal quergelesen. Leider habe ich darin nicht > viel über die Notwendigkeit der stop_position gefunden. Mit Ausnahme dieser > Stelle: "Für die Zukunft wird aber in jedem Fall ein Punkt auf der Straße > notwendig sein, auch, um eine Übereinstimmung mit den schienengebundenen > Halten herzustellen, die überwiegend auf den Ways für > die Schienenwege platziert werden." (S. 36). Leider hat der Autor der > Arbeit diese Aussage weder begründet noch belegt. > > Ich bitte darum mich nicht falsch zu verstehen. Mir gefällt das > Public_transport-Schema eigentlich ganz gut und ich habe mich bemüht, das > hier in Oldenburg auch möglichst genau so durchzuziehen. Als ich Tirkons > E-Mail heute sah kam ich allerdings nicht umhin festzustellen, dass er > durchaus nicht unrecht hat. Die Erfassung von "platform" und > "stop_position" stellt zumindest für einen großen Teil der mir bekannten > Bushaltestellen eine gewisse Redundanz dar. In den meisten Fällen ließe > sich die "stop_position" algorithmisch aus den Positionen der "platform" > und der Straße (beides Elemente der Routenrelation) bestimmen. Insofern > enthält die "stop_position" eigentlich nicht wirklich zusätzliche > Information. > > Durchaus möglich, dass es komplexe Fälle gibt, in denen sich eine > Stop-Position nicht aus den übrigen Elementen der Relation berechnen lässt. > In diesen Fällen wäre es dann sinnvoll eine explizite "stop_position" auf > den way zu setzen. Ich hatte Tirkons Mail auch als Frage nach Beispielen in > dieser Richtung verstanden. > > Vielleicht war mein Vorschlag die "stop_position" zu deprecaten auch etwas > zu kurz / missverständlich formuliert. E
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Hallo, Am 19.10.2014 um 13:19 schrieb Michael Reichert: Einzig bei Bahnhöfen könnte ich mir vorstellen, dass es sinnvoll sein könnte, die Halteposition zusätzlich zu erfassen, da Züge unterschiedlicher Länge durchaus unterschiedliche Haltepositionen auf ein und dem selben Gleis haben können (kenntlich gemacht durch Haltetafeln http://www.tf-ausbildung.de/SignalbuchOnline/ne5.htm). Ob es erforderlich ist, das in der Genauigkeit in OSM zu erfassen lasse ich mal dahingestellt. Es ist relevant, das in der Genauigkeit zu erfassen. In nicht wenigen Bahnhöfen halten mehrere Züge im selben Gleis hintereinander, weil sonst die Gleise nicht ausreichen (z.B. Köln Hbf, Mannheim Hbf, Hamburg Hbf) oder es so vorgesehen ist (z.B. Gößnitz [1] oder Montabaur (Regionalzüge). Da braucht man dann zwei (Gößnitz) stop_positions, weil es nur die beiden Halteplätze gibt, die durch Haltetafeln oder andere Signale gekennzeichnet sind, oder gar drei wie in Würzburg Hbf auf Gleis 2/3, wo das Gleis sowohl doppelt belegt wird und die Züge dann weiter außen halten, aber auch das Gleis nur einfach belegt wird und der Zug dann am Treppenabgang hält. Wie schon gesagt, die Erfassung von Haltepositionen in Bahnhöfen halte ich durchaus für gerechtfertigt. Die Positionen der Haltetafeln sollten auf jeden Fall erfasst werden, da sie ja Teil der Eisenbahninfrastruktur sind. Dass man auch bei Mehrfachbelegungen von Gleisen irgendwie darstellen möchte, dass der Zug nach A-Dorf immer vor dem Zug nach B-Stadt sehe ich auch so. Von daher sehe ich auch die Notwendigkeit von so etwas wie einer "stop_position" für den Bahnverkehr. Eine andere Frage wäre ob es derzeit irgendwelche Dienste etc. gibt, die sowohl platform als auch stop_position auswerten und diese Unterscheidung auch benötigen. Falls das nicht der Fall ist, so könnte man ja mal versuchen einen Konsens erreichen, die stop_position zukünftig nicht mehr zu erfassen (und als "deprecated" zu markieren). Ich wäre auf jeden Fall dafür. Jedem, der sich hier äußert und für die Abschaffung oder des Deprecaten eines Tags ist, sollte erst mal bittschön die Diplomarbeit von Sebastian Schwarz "Öffentlicher Personennahverkehr in OpenStreetMap" [2], die er im Jahr 2009 in der Geofabrik geschrieben hat, lesen. Habe die Arbeit zumindest mal quergelesen. Leider habe ich darin nicht viel über die Notwendigkeit der stop_position gefunden. Mit Ausnahme dieser Stelle: "Für die Zukunft wird aber in jedem Fall ein Punkt auf der Straße notwendig sein, auch, um eine Übereinstimmung mit den schienengebundenen Halten herzustellen, die überwiegend auf den Ways für die Schienenwege platziert werden." (S. 36). Leider hat der Autor der Arbeit diese Aussage weder begründet noch belegt. Ich bitte darum mich nicht falsch zu verstehen. Mir gefällt das Public_transport-Schema eigentlich ganz gut und ich habe mich bemüht, das hier in Oldenburg auch möglichst genau so durchzuziehen. Als ich Tirkons E-Mail heute sah kam ich allerdings nicht umhin festzustellen, dass er durchaus nicht unrecht hat. Die Erfassung von "platform" und "stop_position" stellt zumindest für einen großen Teil der mir bekannten Bushaltestellen eine gewisse Redundanz dar. In den meisten Fällen ließe sich die "stop_position" algorithmisch aus den Positionen der "platform" und der Straße (beides Elemente der Routenrelation) bestimmen. Insofern enthält die "stop_position" eigentlich nicht wirklich zusätzliche Information. Durchaus möglich, dass es komplexe Fälle gibt, in denen sich eine Stop-Position nicht aus den übrigen Elementen der Relation berechnen lässt. In diesen Fällen wäre es dann sinnvoll eine explizite "stop_position" auf den way zu setzen. Ich hatte Tirkons Mail auch als Frage nach Beispielen in dieser Richtung verstanden. Vielleicht war mein Vorschlag die "stop_position" zu deprecaten auch etwas zu kurz / missverständlich formuliert. Eventuell wäre eine Präzisierung der Formulierungen im Wiki hilfreicher. Das Problem ist halt, dass sobald man Ausnahmen formuliert ala "stop_positions" nur dann setzen wenn nötig, es den Mappern auch nicht wirklich einfacher machen. Das ist halt eine etwas verfahrene Situation, ich musste hier auch schon einige Male Bushaltestellen reparieren, die von anderen wohlmeinenden Mappern auseinandergenommen wurden. In so fern teile ich Tirkons Ansicht, dass das public_transport mapping durchaus komplex sein kann und eben offenbar nicht von allen nachvollzogen werden kann. Daher hätte eine Vereinfachung durchaus ihren Charme. Ich für meine Person kann aber auch mit dem derzeitigen Schema gut leben. Ich fände es nur irgendwie befriedigender ein besseres Argument für die "stop_position" zu haben als: Bei Bahnlinien braucht man das und wir wollen, dass alle Haltestellen, egal ob Bus, Bahn oder Luftschiffhafen den gleichen Aufbau haben. Viele Grüße Henning ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.op
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Am 19.10.2014 um 13:58 schrieb Martin Koppenhoefer: Am 19.10.2014 um 12:11 schrieb Henning Kleen : Wenn ich darüber nachdenke widerspricht das Mappen der stop_position auch der Regel nur physisch vorhandene Merkmale zu erfassen. die Regel ist mir neu. Weiß allerdings nicht genau, wie Du physisch verstehst, ist z.B. eine Einbahnstraßenregelung, zul. Höchstgeschwindigkeit, Straßenklasse oder Zugangsbeschränkung in Deinem Sinne "physisch"? Für mich sind sie das nicht... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de Zu einer Einbahnstraßenregelung gehört ein Verkehrsschild, ebenso zur Höchstgeschwindigkeit. Man kann es jetzt natürlich so sehen, dass zu einer stop_position auch ein Haltestellenschild gehört. Mein Argument ging eher in die Richtung, dass den Fahrer nichts zwingt, immer EXAKT an der stop_position zu stoppen, je nach Verkehrssituation (geparkte Autos, bereits wartende Busse) kann er einige Meter früher oder später halten. In so fern ist die stop_position immer nur eine ungefähre Schätzung. Wenn eine solche Schätzung benötigt wird (für routing, etc.) kann man das meiner Meinung nach auch wie von Tirkon vorgeschlagen durch das Fällen des Lotes von der in der Route-Relation enthaltenen platform auf den ebenfalls enthaltenen way. Ich stimme Dir allerdings zu, dass wir durchaus Dinge mappen, die physisch eigentlich nicht vorhanden sind (z.B. die Routen des ÖPNV). Gruß Henning ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
> Am 19.10.2014 um 12:11 schrieb Henning Kleen > : > > Wenn ich darüber nachdenke widerspricht das Mappen der stop_position auch der > Regel nur physisch vorhandene Merkmale zu erfassen. die Regel ist mir neu. Weiß allerdings nicht genau, wie Du physisch verstehst, ist z.B. eine Einbahnstraßenregelung, zul. Höchstgeschwindigkeit, Straßenklasse oder Zugangsbeschränkung in Deinem Sinne "physisch"? Für mich sind sie das nicht... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Hallo, Am 2014-10-19 um 12:11 schrieb Henning Kleen: > Wenn ich darüber nachdenke widerspricht das Mappen der stop_position > auch der Regel nur physisch vorhandene Merkmale zu erfassen. Im > Gegensatz zu einem Haltestellenschild oder einem Bahnsteig ist die > genaue Halteposition nicht an ein physisches Merkmal geknüpft. Wir haben gerade hier in Karlsruhe auf dem Hackweekend in der Geofabrik auch darüber geredet. Jochen Topf, der auch da ist, hat gerade gemeint, es sei schon ein "physikalisches Merkmal", wo der Bus (stop_position) hält. Man müsse einfach mal an der Haltestelle stehen und warten, bis ein Bus kommt. Dem stimme ich so zu. > Einzig > bei Bahnhöfen könnte ich mir vorstellen, dass es sinnvoll sein könnte, > die Halteposition zusätzlich zu erfassen, da Züge unterschiedlicher > Länge durchaus unterschiedliche Haltepositionen auf ein und dem selben > Gleis haben können (kenntlich gemacht durch Haltetafeln > http://www.tf-ausbildung.de/SignalbuchOnline/ne5.htm). Ob es > erforderlich ist, das in der Genauigkeit in OSM zu erfassen lasse ich > mal dahingestellt. Es ist relevant, das in der Genauigkeit zu erfassen. In nicht wenigen Bahnhöfen halten mehrere Züge im selben Gleis hintereinander, weil sonst die Gleise nicht ausreichen (z.B. Köln Hbf, Mannheim Hbf, Hamburg Hbf) oder es so vorgesehen ist (z.B. Gößnitz [1] oder Montabaur (Regionalzüge). Da braucht man dann zwei (Gößnitz) stop_positions, weil es nur die beiden Halteplätze gibt, die durch Haltetafeln oder andere Signale gekennzeichnet sind, oder gar drei wie in Würzburg Hbf auf Gleis 2/3, wo das Gleis sowohl doppelt belegt wird und die Züge dann weiter außen halten, aber auch das Gleis nur einfach belegt wird und der Zug dann am Treppenabgang hält. > Eine andere Frage wäre ob es derzeit irgendwelche Dienste etc. gibt, die > sowohl platform als auch stop_position auswerten und diese > Unterscheidung auch benötigen. Falls das nicht der Fall ist, so könnte > man ja mal versuchen einen Konsens erreichen, die stop_position > zukünftig nicht mehr zu erfassen (und als "deprecated" zu markieren). > Ich wäre auf jeden Fall dafür. Jedem, der sich hier äußert und für die Abschaffung oder des Deprecaten eines Tags ist, sollte erst mal bittschön die Diplomarbeit von Sebastian Schwarz "Öffentlicher Personennahverkehr in OpenStreetMap" [2], die er im Jahr 2009 in der Geofabrik geschrieben hat, lesen. Viele Grüße Michael, der gerade die OpenRailwayMap-Stile mit Signalicons flutet [1] http://www.openrailwaymap.org/?lang=de&lat=50.8931541704866&lon=12.4292799054342&zoom=14&style=standard [2] http://kahlfrost.de/dateien/diplomarbeit.pdf -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Hallo, ich habe vor einer Weile den kompletten ÖPNV (Bus) in Rostock umgestellt, da er für eine lange Zeit nicht nicht aktuallisiert wurde und sehr fragmentiert war. Dabei habe ich das OXOMOA Schema verwendet. Ich halte die Verwendung von pt=stop_position und pt=platform sehr sinnvoll. Beispiel 1: Bei uns gibt es z.B. einige Haltestellen bei denen Straßenbahnen und Busse gleichzeitig halten. Entweder neben einander mit der Platform in der Mitte, oder Hintereinander, wobei in der Regel die Straßenbahnen vorne steht. In diesen Fällen hat man zwei pt=stop_position an einer pt=platform. Beispiel 2: Je nach Abstraktionsgrad kann eine pt=platfrom als Node, Way oder Area dargestellt werden (wobei Area Interressant fürs Rendering ist) und pt=stop_position z.B. für des Line Diagramm (http://overpass-api.de/api/sketch-line?network=VVW&ref=23&operator=RSAG) interressant ist. Natürlich ließe sich das beim Line Diagramm auch irgentwie durch eine Relation mit den pt=platform darstellen. Aber mit pt=stop_position erschein mir das sinnvoller. Nur mal eine weitere Meinung Gruß Hubert > -Original Message- > From: Henning Kleen [mailto:henning.kl...@informatik.uni-oldenburg.de] > Sent: Sonntag, 19. Oktober 2014 12:12 > To: winfi...@gmail.com; Openstreetmap allgemeines in Deutsch > Subject: Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und > stop_postion > > Ich stimme Tirkon vollkommen zu, halte die Aufteilung in > stop_postition und platform auch für redundant. Dem Proposal nach sind > allerdings sowohl stop_position also auch platform in allen relevanten > Relationen nur "recomended" und nicht "mandatory", so dass ein > Public_transport konformes Mapping auch gegeben wäre, wenn eines der > beiden Elemente fehlt (Sinnvollerweise die stop_position). Es scheint > nur einen gewissen Konsens zu geben, sowohl stop_position, als auch > platform zu erfassen (Ich selbst habe das in Oldenburg auch so > gemacht). > Wenn ich darüber nachdenke widerspricht das Mappen der stop_position > auch der Regel nur physisch vorhandene Merkmale zu erfassen. Im > Gegensatz zu einem Haltestellenschild oder einem Bahnsteig ist die > genaue Halteposition nicht an ein physisches Merkmal geknüpft. Einzig > bei Bahnhöfen könnte ich mir vorstellen, dass es sinnvoll sein könnte, > die Halteposition zusätzlich zu erfassen, da Züge unterschiedlicher > Länge durchaus unterschiedliche Haltepositionen auf ein und dem selben > Gleis haben können (kenntlich gemacht durch Haltetafeln http://www.tf- > ausbildung.de/SignalbuchOnline/ne5.htm). Ob es erforderlich ist, das in > der Genauigkeit in OSM zu erfassen lasse ich mal dahingestellt. > Eine andere Frage wäre ob es derzeit irgendwelche Dienste etc. gibt, > die sowohl platform als auch stop_position auswerten und diese > Unterscheidung auch benötigen. Falls das nicht der Fall ist, so könnte > man ja mal versuchen einen Konsens erreichen, die stop_position > zukünftig nicht mehr zu erfassen (und als "deprecated" zu markieren). > Ich wäre auf jeden Fall dafür. > > Henning > Am 19.10.2014 um 11:05 schrieb Jo: > > Ich meine das ist historisch so entstanden. Für Zuge auf Schienen war > > es angeblich 'logischer' um das als Node auf dem Weg zu machen. > Damals > > gab es auch nur ein Way für alle Schienen. > > > > Für Autobuse war es für mich jedenfalls immer logischer um 2 Nodes > > neben den Weg zu haben. Deswegen sind die stop_positions für mich > > weniger wichtig und habe ich neben die 5 Haltestellen in Belgien > > nicht für jede die stop_position hinzugefügt. > > > > Wo ich die aber wohl hinzugefügt habe, ist das meistens nicht auf die > > Position wo die Lotlinie auf dem Weg fällt. Man könnte die wohl so > > determinieren wenn man die unbedingt braucht, und wenn die nicht in > > OSM anwesend sind. > > > > Jedenfalls würde ich die nicht wegstimmen. Wenn ich Haltestellen find > > die auf dem Weg mappiert sind, konvertiere ich das zu stop_position + > > bus/tram=yes und setze die HS neben den Weg So sind allen froh. > > > > Jo > > > > 2014-10-19 5:33 GMT+02:00 Tirkon : > > > >> Das OXOMOA Schema und seine Abarten werden nur von einer kleinen > >> Minderheit von Mappern verstanden. Dabei ist insbesondere die > >> Aufteilung einer Haltestelle in platform und stop_position dem > >> intuitiven Veständnis abträglich und zudem unnötig. Denn aus der > >> platform kann die stop_position durch Fällen des Lots auf die Straße > >> ermittelt werden. > >> > >> Wenn eine Bushaltestelle vorübergehend verlegt wird, dann wird in > der > >> Realität das Bushaltestellenschild (platform / bus_stop) durch ein > >> Kreuz ung
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Ich stimme Tirkon vollkommen zu, halte die Aufteilung in stop_postition und platform auch für redundant. Dem Proposal nach sind allerdings sowohl stop_position also auch platform in allen relevanten Relationen nur "recomended" und nicht "mandatory", so dass ein Public_transport konformes Mapping auch gegeben wäre, wenn eines der beiden Elemente fehlt (Sinnvollerweise die stop_position). Es scheint nur einen gewissen Konsens zu geben, sowohl stop_position, als auch platform zu erfassen (Ich selbst habe das in Oldenburg auch so gemacht). Wenn ich darüber nachdenke widerspricht das Mappen der stop_position auch der Regel nur physisch vorhandene Merkmale zu erfassen. Im Gegensatz zu einem Haltestellenschild oder einem Bahnsteig ist die genaue Halteposition nicht an ein physisches Merkmal geknüpft. Einzig bei Bahnhöfen könnte ich mir vorstellen, dass es sinnvoll sein könnte, die Halteposition zusätzlich zu erfassen, da Züge unterschiedlicher Länge durchaus unterschiedliche Haltepositionen auf ein und dem selben Gleis haben können (kenntlich gemacht durch Haltetafeln http://www.tf-ausbildung.de/SignalbuchOnline/ne5.htm). Ob es erforderlich ist, das in der Genauigkeit in OSM zu erfassen lasse ich mal dahingestellt. Eine andere Frage wäre ob es derzeit irgendwelche Dienste etc. gibt, die sowohl platform als auch stop_position auswerten und diese Unterscheidung auch benötigen. Falls das nicht der Fall ist, so könnte man ja mal versuchen einen Konsens erreichen, die stop_position zukünftig nicht mehr zu erfassen (und als "deprecated" zu markieren). Ich wäre auf jeden Fall dafür. Henning Am 19.10.2014 um 11:05 schrieb Jo: Ich meine das ist historisch so entstanden. Für Zuge auf Schienen war es angeblich 'logischer' um das als Node auf dem Weg zu machen. Damals gab es auch nur ein Way für alle Schienen. Für Autobuse war es für mich jedenfalls immer logischer um 2 Nodes neben den Weg zu haben. Deswegen sind die stop_positions für mich weniger wichtig und habe ich neben die 5 Haltestellen in Belgien nicht für jede die stop_position hinzugefügt. Wo ich die aber wohl hinzugefügt habe, ist das meistens nicht auf die Position wo die Lotlinie auf dem Weg fällt. Man könnte die wohl so determinieren wenn man die unbedingt braucht, und wenn die nicht in OSM anwesend sind. Jedenfalls würde ich die nicht wegstimmen. Wenn ich Haltestellen find die auf dem Weg mappiert sind, konvertiere ich das zu stop_position + bus/tram=yes und setze die HS neben den Weg So sind allen froh. Jo 2014-10-19 5:33 GMT+02:00 Tirkon : Das OXOMOA Schema und seine Abarten werden nur von einer kleinen Minderheit von Mappern verstanden. Dabei ist insbesondere die Aufteilung einer Haltestelle in platform und stop_position dem intuitiven Veständnis abträglich und zudem unnötig. Denn aus der platform kann die stop_position durch Fällen des Lots auf die Straße ermittelt werden. Wenn eine Bushaltestelle vorübergehend verlegt wird, dann wird in der Realität das Bushaltestellenschild (platform / bus_stop) durch ein Kreuz ungültig gemacht und ein provisorisches an der Ersatzhaltestelle aufgestellt. Die stop_position ergibt sich auch hier in der Realität durch das Fällen des Lotes auf die Straße. Der Mapper vor Ort kann also intuitiv das Haltestellenschild mappen und fertig. Es würde dann zur Konstruktion einer funktionierenden ÖPNV Relation ausreichen. Daher: Kann mir irgendjemand erklären, warum es bei OSM diese Zweiteilung geben muss und man nicht mit der Angabe der platform auskommen kann? http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
Ich meine das ist historisch so entstanden. Für Zuge auf Schienen war es angeblich 'logischer' um das als Node auf dem Weg zu machen. Damals gab es auch nur ein Way für alle Schienen. Für Autobuse war es für mich jedenfalls immer logischer um 2 Nodes neben den Weg zu haben. Deswegen sind die stop_positions für mich weniger wichtig und habe ich neben die 5 Haltestellen in Belgien nicht für jede die stop_position hinzugefügt. Wo ich die aber wohl hinzugefügt habe, ist das meistens nicht auf die Position wo die Lotlinie auf dem Weg fällt. Man könnte die wohl so determinieren wenn man die unbedingt braucht, und wenn die nicht in OSM anwesend sind. Jedenfalls würde ich die nicht wegstimmen. Wenn ich Haltestellen find die auf dem Weg mappiert sind, konvertiere ich das zu stop_position + bus/tram=yes und setze die HS neben den Weg So sind allen froh. Jo 2014-10-19 5:33 GMT+02:00 Tirkon : > Das OXOMOA Schema und seine Abarten werden nur von einer kleinen > Minderheit von Mappern verstanden. Dabei ist insbesondere die > Aufteilung einer Haltestelle in platform und stop_position dem > intuitiven Veständnis abträglich und zudem unnötig. Denn aus der > platform kann die stop_position durch Fällen des Lots auf die Straße > ermittelt werden. > > Wenn eine Bushaltestelle vorübergehend verlegt wird, dann wird in der > Realität das Bushaltestellenschild (platform / bus_stop) durch ein > Kreuz ungültig gemacht und ein provisorisches an der Ersatzhaltestelle > aufgestellt. Die stop_position ergibt sich auch hier in der Realität > durch das Fällen des Lotes auf die Straße. Der Mapper vor Ort kann > also intuitiv das Haltestellenschild mappen und fertig. Es würde dann > zur Konstruktion einer funktionierenden ÖPNV Relation ausreichen. > > Daher: Kann mir irgendjemand erklären, warum es bei OSM diese > Zweiteilung geben muss und man nicht mit der Angabe der platform > auskommen kann? > > http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
On 19.10.14 05:33, Tirkon wrote: > Kann mir irgendjemand erklären, warum es bei OSM diese > Zweiteilung geben muss und man nicht mit der Angabe der platform > auskommen kann? IMO war die Überlegung die, dass man im einen Medium (ÖV, egal ob schienen- oder straßengebunden) bis zur stop_position routen kann, dort hat man einen definierten Übergang zur platform und kann dann zu Fuß weiterrouten. Aber ich stimme Dir zu, dass man diesen Übergang durch eine lotrechte gedachte Verbindung lösen könnte (vom Gleis zur Straße oder zum Gehsteig oder von der [Bus-]Haltestelle als "fliegendem" POI zur Straße und/oder zum Gehsteig). /al ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
