Re: [Talk-de] Verkehrsinseln und Mehrzweckspur in der Fahrbahnmitte
Hi Tirkon, irgendwie hatte ich mir ja schon gedacht, dass es um die Ortsdurchfahrt in Moordorf geht bei der Beschreibung (Gütereisenbahn, Verkehrsinseln, etc). Da ich die Gegend auch selbst kenne will ich auch mal meinen Senf dazugeben. Ich persönlich finde die Lösung mit zwei getrennten ways für die beiden Richtungen als suboptimal. Mir gefällt Martins Vorschlag auch deutlich besser und beschreibt meiner Ansicht nach auch am besten die tatsächliche Situation vor Ort. Diese Lösung macht nicht zuletzt auch dem Router deutlich, dass ein Linksabbiegen zu einem Grundstück jederzeit möglich ist (das würde bei zwei getrennten Ways so nicht funktionieren. Die Rechtsabbiegespuren würde ich auch mit turn:lanes erfassen und erst ab dem Beginn der baulichen Trennung durch einen eigenen Way mappen, wenn es eine bauliche Trennung (Verkehrsinsel etc.) gibt. Am 11.12.2014 um 03:40 schrieb 715371: Hallo Tirkon, Am 10.12.2014 um 17:07 schrieb Tirkon: 715371 osmu715...@gmx.de wrote: Ersteinmal würde ich IMHO so Abbiegespuren wie diese hier https://www.openstreetmap.org/way/260670943 mit turn:lanes (https://wiki.openstreetmap.org/wiki/Key:turn:lanes) erfassen. Ansonsten würde ich den Vorschlag von Martin als elegant empfinden. Durch das Tagging könnte man diese Mittelspur, falls interessant, auch mal auswerten. +1 Viele Grüße 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
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 tirko...@yahoo.de: 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
Am 19.10.2014 um 13:58 schrieb Martin Koppenhoefer: Am 19.10.2014 um 12:11 schrieb Henning Kleen henning.kl...@informatik.uni-oldenburg.de: 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
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
