[Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion

So Okt 19 20:01:06 UTC 2014

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.Kleen at 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. 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>