public_transport=station Konflikt

Schwierige Sache. Mir persönlich ist aus der Praxis auch nur nur die sehr gängige Variante bekannt, dass der railway=station bzw railway=halt bei Personenbahnhöfen zusätzlich mit transport=station getaggt wird. dies entspricht in der Regel einer Node, kann aber auch ein Bahnhofsgebäude umfassen. Ich sehe da auch keinen direkten Widerspruch zu https://wiki.openstreetmap.org/wiki/DE: … %3Dstation.
Letzendlich sehe ich aber auch dass Problem, dass beim Taggigschema der Openrailwaymap railway und public_transport Tags gleichgesetzt werden, die aber nicht genau das selbe bezeichnen. Ich hatte in diesem zusammenhang schon mal auf die Doppelnutzung einer Realation als railway=facility und public_transport=stop_area mit teilweise inkompatiblen Definitionen hingewiesen, was allerdings keine erkennbare Reaktion hervorgerufen hat.

Zum Taggen von Eisenbahninfrastruktur gibt es eine zentrale, ausführliche und halbwegs verständliche und widerspruchsfreie Wikiseite, die von allen relevanten Nutzergruppen als maßgeblich anerkannt wird. Das ist bei public_transport leider völlig anders. Da gibt es viele widersprüchliche Angaben und viele verstreute Seiten. Vielleicht ist es mittlerweile anders, aber mein Wissenstand ist, das es keine einzige deutschsprachige Seite im OSM Wiki gibt, die das PTv2 Schema, wie es von Benutzer Weide Definiert wird, vollständig und verständlich wiedergibt. Wie will man da erwarten, dass es jemand korrekt umsetzt? Ich nehme an, dass man bei der Openrailwaymap wie so viele andere auch, einfach PTv2 falsch verstanden hat und dieses falsche Verständnis sowohl in die Wikiseite als auch in die Mappingpraxis eingeflossen ist. Das diese Fehler auf public_transport Seite trotz zig-tausendfacher Anwendung viele Jahre lang niemandem aufgefallen sind, spricht meiner Meinung nach auch eine klare Sprache. Offenbar ist es nicht gelungen, PTv2 einer relevanten Nutzerschicht verständlich zu machen oder nützlich erscheinen zu lassen was angesichts der von mir angesprochenen Defizite in der Vermittlung auch wenig verwunderlich erscheint.

Ich denke man hätte sich ganz am Anfang gemeinsam Gedanken über die sinnvolle Koexistenz der railway* und public_transport tags machen müssen. Ob man jetzt Jahrelang gelebte Praxis nachträglich korrigieren kann weiß ich nicht, aber es dürfte nicht leicht sein.

Vielleicht aufschlussreich zum Thema ÖPNV, PTv2 usw. von der diesjährigen FOSSGIS 2017

2017 - ÖPNV-Mapping in OpenStreetMap
https://www.youtube.com/watch?v=v5IE_l40MkI

miche101 wrote:

Vielleicht aufschlussreich zum Thema ÖPNV, PTv2 usw. von der diesjährigen FOSSGIS 2017

2017 - ÖPNV-Mapping in OpenStreetMap
https://www.youtube.com/watch?v=v5IE_l40MkI

Interessantes Viedeo, das ich noch gar nicht kannte. Ich frag mich allerdings, warum immer gerade das mappen der Linienverläufe in Frage gestellt wird, da gerade die Linienverläufe eines der wenigen PT-Features mit hohem Nutzen in der Praxis ist.

Trockennasenaffe wrote:

...das PTv2 Schema, wie es von Benutzer Weide Definiert wird...

Äh ... definiert hab ich da nichts. Nichts in PTv2 stammt von mir außer vielleicht der Bezeichnung "PTv2", die im Original nicht vorkommt. Ich habe es nur gründlich durchgelesen.

Weide wrote:

Trockennasenaffe wrote:

...das PTv2 Schema, wie es von Benutzer Weide Definiert wird...

Äh ... definiert hab ich da nichts. Nichts in PTv2 stammt von mir außer vielleicht der Bezeichnung "PTv2", die im Original nicht vorkommt. Ich habe es nur gründlich durchgelesen.

Sorry, das war vielleicht missverständlich ausgedrückt. Ich wollte damit sagen, dass die einzige geschlossene, verständliche und halbwegs vollständige Darstellung von PTv2 in deutscher Sprache die ich kenne, deine Ausführungen dazu sind 🙂

Trockennasenaffe wrote:

miche101 wrote:

Vielleicht aufschlussreich zum Thema ÖPNV, PTv2 usw. von der diesjährigen FOSSGIS 2017

2017 - ÖPNV-Mapping in OpenStreetMap
https://www.youtube.com/watch?v=v5IE_l40MkI

Interessantes Viedeo, das ich noch gar nicht kannte. Ich frag mich allerdings, warum immer gerade das mappen der Linienverläufe in Frage gestellt wird, da gerade die Linienverläufe eines der wenigen PT-Features mit hohem Nutzen in der Praxis ist.

Ja, Linienverläufe haben einen gewissen Nutzen. Der einzige für mich nachvollziehbare Nutzen besteht aber nur darin, dass man eine Liniennetzkarte rendern kann (z.B. openptmap.org) und ganz allgemein weiß, welche Gegenden durch welche Linien erschlossen werden. Dazu reichen PTv1-Relationen aber völlig aus.

Der Mehraufwand, jede Linienvariante zu erfassen, steht in keinem Verhältnis zum zusätzlichen Nutzen. Es wird nämlich niemand alleine mit OSM seine Bus- und Bahnfahrten planen, alleine schon deshalb, weil es in OSM keine Fahrplaninformationen gibt. Das Hauptproblem ist jedoch der hohe Erfassungs- und Pflegeaufwand, was in meinem Vortrag hoffentlich rübergekommen ist.

Ich hatte eigentlich gehofft, mit meinem Vortrag noch einmal eine Diskussion über das ÖPNV-Mapping in Gang zu setzen, bei der es zu irgendwelchen Ergebnissen kommt. Feedback habe ich bisher jedoch nicht wirklich bekommen und auch der Workshop am OSM-Samstag war nicht wirklich zufriedenstellend und hat keinerlei Ergebnisse hervorgebracht. Manche Teilnehmer haben mein Anliegen scheinbar nicht wirklich verstanden, sondern stattdessen eine noch detailliertere Erfassung vorgeschlagen (z.B. die Erfassung von Taktungen). Ich sehe deshalb nicht, dass es in absehbarer Zeit noch zu irgendeinem Konsens im ÖPNV-Mapping kommen wird. Deshalb beschränke ich mich nur noch auf die Haltestelleninfrastruktur.

Gruß
Alex

rurseekatze wrote:

Deshalb beschränke ich mich nur noch auf die Haltestelleninfrastruktur.

Das ist sicher am sinnvollsten.

Ich verwende dann den QR-Code zur Haltestelle oder die Website des Verkehrsunternehmen:
http://www.openstreetmap.org/way/476960 … 4&layers=H

Und diese aktuell halten (share_taxi=yes ist auch seit April weggefallen - habe ich gerade bemerkt.)

OK, noch zur eigentlichen Frage in diesem Thread:

Weide wrote:

Bei einigen Wikis im Eisenbahnbereich hat man dagegen eine völlig andere Bedeutung, die am deutlichsten im deutschen Openrailmap-Tagging Wiki wird: public_transport=station ist ein Ergänzungstag für Nodes mit railway=station mit dem man angibt, dass an diesem Bahnhof Personenverkehr stattfindet. http://wiki.openstreetmap.org/wiki/DE:O … ap/Tagging

Hmm, auf den ersten Blick macht das Tagging wenig Sinn, denn nicht-Personenbahnhöfe werden ohnehin nicht als railway=station oder railway=halt getaggt.

Jedenfalls wäre es konsequent, dass wir aus dem OpenRailwayMap-Schema das public_transport=station entfernen, da sich die OpenRailwayMap ja eigentlich auf die Infrastruktur beschränkt. Die Abgrenzung wäre also railway=* für die Infrastruktur und public_transport=* für den Verkehr. Aus diesem Blickwinkel macht das Doppeltagging dann doch wieder Sinn, indem das railway=station den Bahnhof als Infrastruktur kennzeichnet und das public_transport=station den Bahnhof als Verkehrsstation.

Ob das public_transport=station nun am gleichen Node oder einer separaten Fläche hängt, ist mir persönlich eigentlich egal, solange das railway=station ein Node bleibt. Andererseits erzeugt man durch eine Erfassung in zwei Objekten gewisse Redundanzen.

Auf jeden Fall aber sollten public_transport=station und railway=station nicht gemeinsam an einer Fläche getaggt sein, da die Ausdehnung eines Bahnhofs aus ÖPNV-Sicht eine völlig andere ist als aus Sicht der Bahninfrastruktur.

Trockennasenaffe wrote:

Zum Taggen von Eisenbahninfrastruktur gibt es eine zentrale, ausführliche und halbwegs verständliche und widerspruchsfreie Wikiseite, die von allen relevanten Nutzergruppen als maßgeblich anerkannt wird. Das ist bei public_transport leider völlig anders. Da gibt es viele widersprüchliche Angaben und viele verstreute Seiten. Vielleicht ist es mittlerweile anders, aber mein Wissenstand ist, das es keine einzige deutschsprachige Seite im OSM Wiki gibt, die das PTv2 Schema, wie es von Benutzer Weide Definiert wird, vollständig und verständlich wiedergibt. Wie will man da erwarten, dass es jemand korrekt umsetzt? Ich nehme an, dass man bei der Openrailwaymap wie so viele andere auch, einfach PTv2 falsch verstanden hat und dieses falsche Verständnis sowohl in die Wikiseite als auch in die Mappingpraxis eingeflossen ist. Das diese Fehler auf public_transport Seite trotz zig-tausendfacher Anwendung viele Jahre lang niemandem aufgefallen sind, spricht meiner Meinung nach auch eine klare Sprache. Offenbar ist es nicht gelungen, PTv2 einer relevanten Nutzerschicht verständlich zu machen oder nützlich erscheinen zu lassen was angesichts der von mir angesprochenen Defizite in der Vermittlung auch wenig verwunderlich erscheint.

Dass public_transport=station nur für Flächen verwendet werden soll, habe ich das erste Mal auch erst von Weide gehört... Bei PTv2 gibt es eben immer wieder Überraschungen 😉

Trockennasenaffe wrote:

Ich denke man hätte sich ganz am Anfang gemeinsam Gedanken über die sinnvolle Koexistenz der railway* und public_transport tags machen müssen. Ob man jetzt Jahrelang gelebte Praxis nachträglich korrigieren kann weiß ich nicht, aber es dürfte nicht leicht sein.

Das Problem habe ich ja schon oben beschrieben: Die verkehrliche und die infrastrukturelle Sicht unterscheiden sich teilweise, deshalb sollte das irgendwo getrennt voneinander erfasst werden, was dann aber wieder zu Redundanzen führt. Deshalb haben sich damals solche Hilfskonstrukte entwickelt, die aber wie man nun sieht nicht immer zu einer sauberen Trennung führen.

Um das ganze noch einmal strukturiert anzugehen: Wo genau gibt es derzeit Überschneidungen zwischen railway und public_transport? Beim Durchsehen des Taggingschemas habe ich folgende Punkte identifiziert:

• railway=station vs. public_transport=station
  
• railway=facility vs. public_transport=stop_area
  
• railway=platform vs. public_transport=platform
  
• railway=stop vs. public_transport=stop_position
  

Bei den Bahnsteigen sehe ich keine Probleme, da es dort keine unterschiedlichen Auffassungen von der Ausdehnung gibt. Das doppelte Tagging ist hier lediglich zur Abwärtskompatibilität gedacht, bzw. um die Daten einfacher auswerten zu können (Filtern nach railway=* ist einfacher als public_transport=platform + train=yes/subway=yes/... abzufragen).

Bei stop/stop_position ist die Situation identisch. Dort ist es so, dass railway=stop weiter gefasst ist als public_transport=stop_position. railway=stop ist praktisch das public_transport=stop_position für Stellen ohne ÖPNV, was vor allem für das Routing oder die Erzeugung von Streckengraphen wie in der Wikipedia von Bedeutung ist.

Bei station und facility/stop_area sehe auch ich die hier schon angesprochenen Probleme. Zu den Bahnhöfen hatte ich oben ja schon etwas geschrieben. Was die facilities betrifft, stellen wohl vor allem die Rollen ein Problem dar. Wobei sich die Frage stellt, ob man railway=facility nicht wieder ganz aus dem Schema wirft. Ich weiß gerade nicht genau, wie oft das erfasst wurde, aber ich selbst habe das nur am Anfang mal ein paar Mal eingetragen. Mittlerweile trage ich das aber gar nicht mehr ein, da es bislang auch von keiner Anwendung ausgewertet wird.

Gruß
Alex

rurseekatze wrote:

Bei den Bahnsteigen sehe ich keine Probleme, da es dort keine unterschiedlichen Auffassungen von der Ausdehnung gibt. Das doppelte Tagging ist hier lediglich zur Abwärtskompatibilität gedacht, bzw. um die Daten einfacher auswerten zu können (Filtern nach railway=* ist einfacher als public_transport=platform + train=yes/subway=yes/... abzufragen).

Warum einen highway/railway als *=platform - doppelt als public_transport=platform - eintragen?

Ich sehe das Problem:

Ein Fußweg kann eine public_transport=platform sein.
Auch ein Bahnsteig ist normalerweise ein "Fußweg" und kann somit auch zum Routing verwendet werden.

Dieser Fußweg mit name Gleis 1 oder Gleis 2 kann dann Bestandteil eines Bahnsteiges sein und auch in einer Relation (Route/Fläche) genutzt werden.

Ist auf alle Fälle "richtiger" als die "separaten highway/railway" mit den Fußwegen "zu verbinden".

Man kann auch Probleme suchen, wo keine sind.

Für railway gilt das railway-Schema, für public_transport gilt das public_transport-Schema.

Der Schnittpunkt station wird bei railway an den Bahnhofszentralpunkt gesetz,
das public_transport=station gehört an die Fläche oder falls diese nicht angelegt ist, kann es an den Bahnhofszentralpunkt gesetzt werden.

Gruß Axel

rurseekatze wrote:

Ja, Linienverläufe haben einen gewissen Nutzen. Der einzige für mich nachvollziehbare Nutzen besteht aber nur darin, dass man eine Liniennetzkarte rendern kann (z.B. openptmap.org) und ganz allgemein weiß, welche Gegenden durch welche Linien erschlossen werden. Dazu reichen PTv1-Relationen aber völlig aus.

Ja, aber nicht nur eine Karte mit allen Linien. Auch wenn ich sehen möchte wo eine einzelne Linie lang fährt ist das sehr nützlich. Das bietet sonst auch fast keiner. Wir auch auf Wikipedia bei Artikeln zu einzelnen Linien genutzt. Es stimmt, dass dafür auch PTv1-Relationen reichen. Bei der Infrastruktur würde ich aber schon gerne die Neuerungen von PTv2 behalten. Nur PTv2 einzustampfen halte ich daher für keine Lösung. Ich glaube auch wenn wir jetzt sagen, nachdem vieles mit PTv2 gemappt ist, wir schmeißen das wieder weg und gehen wieder zurück, würden uns niemand mehr ernst nehmen und das noch die letzten engagierten PT Mapper vergraulen. Ich denke wenn man mittelfristig von PTv2 weg will, braucht man ein PTv3, wie auch immer das sein soll. Bis dahin verspreche ich mir durchaus Verbesserung durch besseren Tools. Ich finde z.B. der vergleichsweise neue "PT Assistant" ist schon eine riesige Erleichterung beim reparieren der ständig kaputt gehenden Relationen.

Vielleicht bringt die laufende Open-Data Welle bei den Verkehrsunternehmen in den nächsten Jahren neue Erkenntnisse, welche Daten in welcher Form für welche Anwendungen nützlich sind und damit frischen Wind in die Diskussion. Solange hingegen noch völlige Uneinigkeit herrscht, wohin die Reise gehen soll und warum, wird man wahrscheinlich keine Einigkeit, sondern nur noch mehr Frustration erzeugen, wenn man wieder eine neue Sau durchs Dorf treibt.

rurseekatze wrote:

Dass public_transport=station nur für Flächen verwendet werden soll, habe ich das erste Mal auch erst von Weide gehört... Bei PTv2 gibt es eben immer wieder Überraschungen

Wenn ich einige Wikis lese, dann verstehe ich das. Wenn ich das PTv2-Original lese, dann nicht: Man klickt da auf "Station" und es beginnt mit "A Station is an area..."

rurseekatze wrote:

Das doppelte Tagging ist hier lediglich zur Abwärtskompatibilität gedacht, bzw. um die Daten einfacher auswerten zu können (Filtern nach railway=* ist einfacher als public_transport=platform + train=yes/subway=yes/... abzufragen).

PTv2 braucht kein Doppeltagging, denn in PTv2 gelten die alten Tags alle weiter und man muss die neuen nicht verwenden. Nur bei den Bussen gab es da ein Problem das zu den neuen Tags geführt hat: Es darf pro Anhalten des Busses nur ein highway=bus_stop geben und das darf nur an einen Node. Wollte also jemand beides mappen oder eine Linie oder Fläche benutzen, dann musste es dafür ein neues Tag geben. Das ist public_transport=platform oder stop_position. (highway=platform gab es damals noch nicht. Es wäre damals auch sinnlos gewesen, denn PTv1 konnte es nicht verwenden. Da galt ganz einfach und brutal Node=Haltestelle und Linie=Fahrweg und Rollen benutzen wir als freie Zusatztags.)

Nach PTv2 ist "railway=platform" also ein "muss" und "public_transport=platform" kann man dranschreiben, wenn es einem Freude macht.

Im PTv2-Original findet man übrigens "xxx=yes" ausschließlich bei stops. Für platforms ist es nicht vorgesehen.

axelr wrote:

... falls diese nicht angelegt ist, kann es an den Bahnhofszentralpunkt gesetzt werden.

Nein. Es heißt nicht "falls sie nicht gemappt ist" sondern "falls diese unbekannt ist". Das habe ich in Mitteleuropa noch nicht gesehen.

Es ist ohnehin meist nicht sehr sinnvoll, "public_transport=station" bei normalen Bahnhöfen zu verwenden. Bahnhöfe sind fast immer gewidmete Gelände ... da kann auch ein Bot eine konvexe Hülle um Bahnsteige und das Gebäude ziehen. Inhaltlich sinnvoll ist sowas da, wo ein gemeinsames Gelände für mehrere stop_areas existiert oder wo eine stop_area aus einem gewidmeten Gelände (z.B. U-Bahn-Bahnhof) und einigen in den Straßenverkehr integrierten Teilen (für Tram und Bus) besteht.

geri-oc wrote:

Ich sehe das Problem:
...

Die Probleme sind leider da ... aber sie verschwinden bei vernünftigem Mapping fast überall.

Die meisten dieser Probleme kommen aus PTv2-Irrtümern:
- Man muss immer einen stop haben
- Man muss immer eine platform haben
- Platforms müssen linien- oder flächenförmig sein
- An eine Busplatform gehört highway=platform
Alles das ist nicht PTv2.

Die simple Bushaltestelle mit zwei einander gegenüberliegenden Haltestellen ist einfach und komplett als ein Node auf der Straße mit highway=bus_stop und name=Karlshof erledigt. Das kommt dann in die PTv2-Routen mit der Rolle "stop". (Wenn man gern hätte, das JOSM die Rolle automatisch einträgt, dann braucht man auch noch public_transport=stop_position)

Liegen die beiden Haltestellen deutlich versetzt, dann legt man zwei genauso getaggte Nodes neben die Straße und sie kommen mit der Rolle "platform" in die PTv2-Routen. (Wenn man gern hätte, das JOSM die Rolle automatisch einträgt, dann braucht man auch noch public_transport=platform. (Ganz pingelig betrachtet ist das nach PTv2 falsch ... aber der Fehler hat keine schädlichen Auswirkungen))

In solche Nodes kann man problemlos auch wichtige Zusatzinformationen wie "tactile_paving", "bench" und "shelter" eintragen, sofern diese Sachen nicht bereits anderswo gemappt sind. Natürlich steckt in einem Node nicht die Länge der Haltestelle ... aber bei Bussen ist das anders als bei Bahnen auch für Gehbehinderte ziemlich egal.

rurseekatze wrote:

Ich hatte eigentlich gehofft, mit meinem Vortrag noch einmal eine Diskussion über das ÖPNV-Mapping in Gang zu setzen, bei der es zu irgendwelchen Ergebnissen kommt. Feedback habe ich bisher jedoch nicht wirklich bekommen und auch der Workshop am OSM-Samstag war nicht wirklich zufriedenstellend und hat keinerlei Ergebnisse hervorgebracht. Manche Teilnehmer haben mein Anliegen scheinbar nicht wirklich verstanden, sondern stattdessen eine noch detailliertere Erfassung vorgeschlagen (z.B. die Erfassung von Taktungen). Ich sehe deshalb nicht, dass es in absehbarer Zeit noch zu irgendeinem Konsens im ÖPNV-Mapping kommen wird. Deshalb beschränke ich mich nur noch auf die Haltestelleninfrastruktur.

Schade das es zu diesem Thema keine Diskussion in Gang gesetzt hat 🤔 . Vor allem der Punkt alle Linienvarianten einzeln zu erfassen sehe ich nicht ein... ich mache zur Zeit PTv2 lite 😉 ... eine Relation für die eine Richtung eine andere für die Gegenrichtung und mehr nicht...

mfg Miche

Trockennasenaffe wrote:

rurseekatze wrote:

Ja, Linienverläufe haben einen gewissen Nutzen. Der einzige für mich nachvollziehbare Nutzen besteht aber nur darin, dass man eine Liniennetzkarte rendern kann (z.B. openptmap.org) und ganz allgemein weiß, welche Gegenden durch welche Linien erschlossen werden. Dazu reichen PTv1-Relationen aber völlig aus.

Ja, aber nicht nur eine Karte mit allen Linien. Auch wenn ich sehen möchte wo eine einzelne Linie lang fährt ist das sehr nützlich. Das bietet sonst auch fast keiner. Wir auch auf Wikipedia bei Artikeln zu einzelnen Linien genutzt. Es stimmt, dass dafür auch PTv1-Relationen reichen. Bei der Infrastruktur würde ich aber schon gerne die Neuerungen von PTv2 behalten. Nur PTv2 einzustampfen halte ich daher für keine Lösung. Ich glaube auch wenn wir jetzt sagen, nachdem vieles mit PTv2 gemappt ist, wir schmeißen das wieder weg und gehen wieder zurück, würden uns niemand mehr ernst nehmen und das noch die letzten engagierten PT Mapper vergraulen. Ich denke wenn man mittelfristig von PTv2 weg will, braucht man ein PTv3, wie auch immer das sein soll. Bis dahin verspreche ich mir durchaus Verbesserung durch besseren Tools. Ich finde z.B. der vergleichsweise neue "PT Assistant" ist schon eine riesige Erleichterung beim reparieren der ständig kaputt gehenden Relationen.

Meine Kritik an PTv2 bezieht sich auch überwiegend auf die Linienvarianten. Das Haltestellentagging sehe ich nicht so als Problem an. Zwar finde ich, dass es auch dort Vereinfachungen geben könnte (stop_areas bei 90% aller Bushaltestellen überflüssig, stop_positions bei 90% der Bushaltestellen automatisiert ermittelbar), aber das verursacht meiner Meinung alles nicht einen so großen Aufwand wie die ganzen Linienvarianten.

Mit besseren Tools wie z.B. Routing und Qualitätssicherung könnte man schon den Aufwand zur Erfassung und Pflege reduzieren, was etwa das Zusammenklicken des Routenwegs oder die Reparatur von kaputten Relationen betrifft. Allerdings hilft das nicht wirklich bei den Linienvarianten weiter, denn da besteht der Aufwand darin, dass man diese Daten nur sinnvoll erfassen kann, indem man schlicht Fahrpläne abschreibt.

Trockennasenaffe wrote:

Vielleicht bringt die laufende Open-Data Welle bei den Verkehrsunternehmen in den nächsten Jahren neue Erkenntnisse, welche Daten in welcher Form für welche Anwendungen nützlich sind und damit frischen Wind in die Diskussion. Solange hingegen noch völlige Uneinigkeit herrscht, wohin die Reise gehen soll und warum, wird man wahrscheinlich keine Einigkeit, sondern nur noch mehr Frustration erzeugen, wenn man wieder eine neue Sau durchs Dorf treibt.

Mit offenen Fahrplandaten wäre es natürlich einfacher, die Daten bei uns aktuell zu halten, indem man automatisierte Vergleiche der Datensätze machen könnte, um veraltete Daten zu erkennen. Das wäre in einer Art uns Weise wie die Straßenlistenauswertungen vorstellbar. Dann wäre die Erfassung einzelner Linienvarianten auch eher umsetzbar als nun. So lange aber keine Fahrplandaten zur Verfügung stehen, sehe ich den Aufwand für OSM als zu hoch an.

Weide wrote:

rurseekatze wrote:

Das doppelte Tagging ist hier lediglich zur Abwärtskompatibilität gedacht, bzw. um die Daten einfacher auswerten zu können (Filtern nach railway=* ist einfacher als public_transport=platform + train=yes/subway=yes/... abzufragen).

PTv2 braucht kein Doppeltagging, denn in PTv2 gelten die alten Tags alle weiter und man muss die neuen nicht verwenden. Nur bei den Bussen gab es da ein Problem das zu den neuen Tags geführt hat: Es darf pro Anhalten des Busses nur ein highway=bus_stop geben und das darf nur an einen Node. Wollte also jemand beides mappen oder eine Linie oder Fläche benutzen, dann musste es dafür ein neues Tag geben. Das ist public_transport=platform oder stop_position. (highway=platform gab es damals noch nicht. Es wäre damals auch sinnlos gewesen, denn PTv1 konnte es nicht verwenden. Da galt ganz einfach und brutal Node=Haltestelle und Linie=Fahrweg und Rollen benutzen wir als freie Zusatztags.)

Nach PTv2 ist "railway=platform" also ein "muss" und "public_transport=platform" kann man dranschreiben, wenn es einem Freude macht.

Hä? Wozu hat man denn dann public_transport=platform eingeführt, wenn das dann doch nicht nötig ist? Ich hatte PTv2 immer so verstanden, dass die neuen Tags diese älteren Tags ersetzen sollen.

Weide wrote:

Im PTv2-Original findet man übrigens "xxx=yes" ausschließlich bei stops. Für platforms ist es nicht vorgesehen.

OK, das ist mir jetzt auch neu. Ich habe die Verkehrsmittel bisher immer bei stops und platforms getaggt. Warum die Verkehrsmittel nur bei den stops aber nicht bei den platforms genutzt werden sollen, erschließt sich mir nicht wirklich. Ich finde das eher auch unlogisch und fände es anders herum sinnvoller. Ohne die alten Tags wie highway=bus_stop oder railway=platform wäre dann überhaupt nicht auswertbar, ob ein Node mit public_transport=platform nun eine Bushaltestelle oder ein Bahnsteig ist.

Weide wrote:

axelr wrote:

... falls diese nicht angelegt ist, kann es an den Bahnhofszentralpunkt gesetzt werden.

Nein. Es heißt nicht "falls sie nicht gemappt ist" sondern "falls diese unbekannt ist". Das habe ich in Mitteleuropa noch nicht gesehen.

Es ist ohnehin meist nicht sehr sinnvoll, "public_transport=station" bei normalen Bahnhöfen zu verwenden. Bahnhöfe sind fast immer gewidmete Gelände ... da kann auch ein Bot eine konvexe Hülle um Bahnsteige und das Gebäude ziehen. Inhaltlich sinnvoll ist sowas da, wo ein gemeinsames Gelände für mehrere stop_areas existiert oder wo eine stop_area aus einem gewidmeten Gelände (z.B. U-Bahn-Bahnhof) und einigen in den Straßenverkehr integrierten Teilen (für Tram und Bus) besteht.

Laut https://wiki.openstreetmap.org/wiki/Tag … %3Dstation kann public_transport=station auch bei Nodes verwendet werden, was ich grundsätzlich nicht falsch finde. Allerdings ist es einfach eine redundante Informationen, einen Node mit railway=station auch nochmal als public_transport=station zu taggen, da gibt es keinen Mehrwert an Information.

Allerdings sehe ich auch eine Fläche mit public_transport=station als überflüssig an, weil es zum einen auch als konvexe Hülle aus den Mitgliedern der stop_area erzeugt werden kann.

miche101 wrote:

Schade das es zu diesem Thema keine Diskussion in Gang gesetzt hat 🤔 . Vor allem der Punkt alle Linienvarianten einzeln zu erfassen sehe ich nicht ein... ich mache zur Zeit PTv2 lite 😉 ... eine Relation für die eine Richtung eine andere für die Gegenrichtung und mehr nicht...

Wie genau gehst du denn da vor? Gerade in ländlichen Gegenden gibt es ja bei vielen Linien gar keine "Hauptroute", sondern fast jede Fahrt nimmt einen etwas anderen Weg. Erfasst du in diesen Fällen nur den Verlauf einer einzigen Fahrt, die du für wichtig hältst? Oder packst du auch noch die Fahrwege der Alternativrouten mit in die Relation (was ja dann PTv1 wäre, da bei PTv2 die Wege in der Relationen einen lückenlosen Verlauf bilden müssen).

Gruß
Alex

rurseekatze wrote:

Wie genau gehst du denn da vor? Gerade in ländlichen Gegenden gibt es ja bei vielen Linien gar keine "Hauptroute", sondern fast jede Fahrt nimmt einen etwas anderen Weg. Erfasst du in diesen Fällen nur den Verlauf einer einzigen Fahrt, die du für wichtig hältst? Oder packst du auch noch die Fahrwege der Alternativrouten mit in die Relation (was ja dann PTv1 wäre, da bei PTv2 die Wege in der Relationen einen lückenlosen Verlauf bilden müssen).

Ganz einfach... ich nehme den Fahrplan der Aushängt und füge eine nach der anderen wie sie aufgelistet sind auf dem Fahrplan zur Relation hinzu.. gleichzeitig füge ich noch die Wege hinzu die von der einen zu anderen gehen.. (Haltestellen für eventueller Gegenrichtung füge ich gleich in umgekehrter Reihenfolge hinzu... für spätere Gegenrichtungs-Relation)

Danach wird hochgeladen.. dann schau ich ob ich im Graph ein Loch habe z.B. :
http://ra.osmsurround.org/analyzeRelati … Id=3084863

Dann schau ich die Relation nochmal an ob ich noch was hinzufügen muss an Varianten (Meist Abkürzungen)
https://www.openstreetmap.org/relation/3084863

Dann nochmal schauen ob Löcher drin sind 🙂 Dann wenn es passt, kopiere ich die Relation und ändere diese für die Gegenrichtung ab.. (Aus der ersten Relation entferne ich die Haltestelle für den Rückweg). Master-Relation mach ich auch 😉

Ist für mich einfacher weil: An der Haltestelle zwei nicht unbedingt gleiche Fahrpläne aushängen. In meinem Beispiel gibt es in Freising Einbahnstraßen Regelungen die einen schon ein bisschen verwirren. Wenn man aus beiden Richtungen eine Relation machen möchte. So nehme ich erst den einen Fahrplan in die Hand und dann den anderen.

Durch das ich die Haltestellen am Anfang eine nach der anderen aufliste kann ich auch besser vergleichen und sehen was fehlt, zu viel ist usw..

Sollte ich was vergessen.. naja bin ja auch nur ein Mensch 🙄

Die einzelnen Linien einzutragen ist m.E. zu aufwendig - vor allem die Aktualisierung dazu.

Bei uns verkehren 3-4 Linien parallel; fast jede Fahrt einer Linie hat einen anderen Verlauf (bis zu 6 verschiedene). Die Rückfahrten verlaufen dann auch wieder auf verschiedenen Wegen - mal über das Dorf oder den Ortsteil - dann wieder übers nächste. Auch die Ziele sind je nach Fahrt unterschiedlich.

Da finde ich das Haltestellen mappen mit den Verlinkungen zu den Fahrten wesentlich effektiver.

Das beantwortet noch nicht so recht meine Frage. Ich bezog mich auf

miche101 wrote:

Schade das es zu diesem Thema keine Diskussion in Gang gesetzt hat hmm . Vor allem der Punkt alle Linienvarianten einzeln zu erfassen sehe ich nicht ein... ich mache zur Zeit PTv2 lite wink ... eine Relation für die eine Richtung eine andere für die Gegenrichtung und mehr nicht...

Du erfasst also nicht alle Linienvarianten, sondern immer nur eine Hin- und eine Gegenrichtung, wenn ich das richtig verstehe. Aber was machst du bei Fahrplänen wie http://www.suedbadenbus.de/suedbadenbus … 6_7240.pdf? Dort kommt man ja nicht mit zwei Relationen aus, da es keine "Teleskoplinien" sind und es auch keine "Hauptroute" und einzelne unbedeutende Kurse gibt. Und genau das ist ja mein Kritikpunkt, dass es bei solchen Linien extrem komplex wird, weil man unzählige unterschiedliche Verläufe erfassen muss.

Gruß
Alex

Hi Alex,

Da würde ich auch nur eine vor und zurück... Für die Erfassung müsste ich mir des Ding aber Ausdrucken und mit Textmaker arbeiten.

MFG Miche

rurseekatze wrote:

Ich hatte PTv2 immer so verstanden, dass die neuen Tags diese älteren Tags ersetzen sollen.

In PTv2 steht ganz klar:
This proposal does not replace, deprecate or obsolete the already existing and well known tags. The usage of the proposed tags is recommended but not mandatory.

Hä? Wozu hat man denn dann public_transport=platform eingeführt, wenn das dann doch nicht nötig ist?

Durch PTv2 wurden erstmals linien- und flächenförmige Haltestellenobjekte für Routen zugelassen und man konnte erstmalig sowohl stops als auch platforms mappen. Bei den Bussen gab es aber nur highway=bus_stop - Nodes. Es durfte außerdem pro Bushalt nur einmal auftreten. public_transport=platform war also unter Umständen nötig.

Ohne die alten Tags wie highway=bus_stop oder railway=platform wäre dann überhaupt nicht auswertbar, ob ein Node mit public_transport=platform nun eine Bushaltestelle oder ein Bahnsteig ist.

An vielen Steigen halten sowohl Straßenbahnen als auch Busse und an manchen sogar Züge und Busse. Für den Passagier ist es immer derselbe Steig ... egal worauf er wartet. So unlogisch finde ich das nicht.

Laut https://wiki.openstreetmap.org/wiki/Tag … %3Dstation kann public_transport=station auch bei Nodes verwendet werden, was ich grundsätzlich nicht falsch finde.

Ja, es gibt Umstände unter denen ein Node in Frage kommt. Die hatten wir früher mal, als ein gesamter Bahnhof noch als einfacher Node gemappt wurde.

miche101 wrote:

Da würde ich auch nur eine vor und zurück... Für die Erfassung müsste ich mir des Ding aber Ausdrucken und mit Textmaker arbeiten.

Aber welche? Genau das ist ja das Problem, mit PTv2 kann man praktisch immer nur im höchsten Detaillierungsgrad erfassen oder gar nicht.

Weide wrote:

rurseekatze wrote:

Ohne die alten Tags wie highway=bus_stop oder railway=platform wäre dann überhaupt nicht auswertbar, ob ein Node mit public_transport=platform nun eine Bushaltestelle oder ein Bahnsteig ist.

An vielen Steigen halten sowohl Straßenbahnen als auch Busse und an manchen sogar Züge und Busse. Für den Passagier ist es immer derselbe Steig ... egal worauf er wartet. So unlogisch finde ich das nicht.

Mal angenommen, es gibt einen Node mit public_transport=platform, aber ohne eines der "alten" Tags. Wie soll man dann wissen, ob da nun ein Bushaltestellen- oder ein Straßenbahnsymbol gerendert werden soll?

Gruß
Alex

rurseekatze wrote:

Aber welche? Genau das ist ja das Problem, mit PTv2 kann man praktisch immer nur im höchsten Detaillierungsgrad erfassen oder gar nicht.

Dann halt PTv1 plus 😉 Alles was vorwärts ist in eine Relation und alles was rückwärts ist in eine andere 🙂

Aber ich sehe das Problem eher hier:
http://www.openstreetmap.org/note/75017 … &layers=TN

-> es gibt sehr viele Haltestelle noch nicht einmal... irgendwie erfasst sind.
2. noch nicht einmal irgendwo festgehalten wurde das diese oder welche fehlen.
3. in machen Ecken fährt auch keiner hin 🤔
4. andere Ecken funktionieren noch bessern und da wurde fast jeder Fehler schon gelöst.

Des weitern:
https://wiki.openstreetmap.org/wiki/M%C … _700_-_799

das ist fast bei München(wo ganz viele Mapper sind) und doch so verweist die Relationen bzw. in den ganzen Jahren nicht einmal irgendwie angelegt worden 🤔

rurseekatze wrote:

Mal angenommen, es gibt einen Node mit public_transport=platform, aber ohne eines der "alten" Tags. Wie soll man dann wissen, ob da nun ein Bushaltestellen- oder ein Straßenbahnsymbol gerendert werden soll?

Da PTv2 vorschreibt, dass sowohl die stops als auch die platforms in die Routen müssen (soweit sie vorhanden sind), kann man die Routen nachsehen.

Was für ein Symbol kommt denn an Steige, die mehrere Verkehrsmittel haben? Anders gesagt: Lässt sich die Trennung überhaupt durchhalten?

Weide wrote:

, kann man die Routen nachsehen.

Aber nur wenn überhaupt eine Route vorhanden ist. Und wenn nicht aus versehen die Route beschädigt bzw. gelöscht wurde.. 🙄

Weide wrote:

as für ein Symbol kommt denn an Steige, die mehrere Verkehrsmittel haben? Anders gesagt: Lässt sich die Trennung überhaupt durchhalten?

Vielleicht das alte allgemeine Haltestellenschild zum Rendern (aller) Haltestellen verwenden?

geri-oc wrote:

Vielleicht das alte allgemeine Haltestellenschild zum Rendern (aller) Haltestellen verwenden?

Das wäre ein Rückschritt in die Steinzeit.

Normalweise, je nachdem was für eine Karte man machen möchte, das Ranghöchste Verkehrsmittel..

Man sollte schon noch das taggen dürfen was man vor Ort vorfindet... und wenn das ein Bushaltestellenschild ist, ist das eben ein Bushalteschild... egal was alles da noch hält. Da Bushaltestellen sich meist an Straßen befinden.. kann da alles halten was die Straße benutzen kann. Also ja zu highway=busstop, bus=yes oder wie auch immer..

Bei Busbahnhöfen finde ich immer noch den bus_routes=* wichtig... obwohl dieser leider abgesetzt wurde. Weil man kann nicht erwarten das wenn ein Busbahnhof umnummeriert wurde dass der Aufnehmende auch alle Relationen abändert. 🤔 Das ist oft mit sehr viel Arbeit verbunden.

miche101 wrote:

Das wäre ein Rückschritt in die Steinzeit.

Finde ich nicht. Es erkennt einfach die Tatsache an, dass die harte Einteilung in Tramsteig, Bussteig, ... die Realität nicht so ganz trifft.

miche101 wrote:

Man sollte schon noch das taggen dürfen was man vor Ort vorfindet... und wenn das ein Bushaltestellenschild ist, ist das eben ein Bushalteschild... egal was alles da noch hält.

Natürlich sollte man taggen dürfen, was man so vorfindet. Aber wir haben kein Tag für Haltestellenschilder! highway=bus_stop ist kein Tag für Haltestellenschilder sondern für Haltestellen. Wenn da kein Schild steht aber eine Bushaltestelle da ist (z.B. in Spanien), dann kommt da highway=bus_stop hin. Und wenn (z.B. Düsseldorf-Benrath S) an jeder Haltestelle zwei Schilder stehen, dann kommen da keine zwei highway=bus_stop hin. Und wenn da Schild auf der falschen Straßenseite steht weil es auf der richtigen Seite zu spät sichtbar wäre (hab ich in Schweden gefunden), dann kommt das highway=bus_stop eben nicht auf die Seite mit dem Schild.

Dann muss ich meine ganzen Bushaltestelleschilder wieder rauslöschen die ich die letzten 9 Jahre gemapt habe? Weil ich hab immer den Standpunkt des Schildes gemapt... Ja eigentlich das Schild.

Haltestellen hab ich da keine gesehen, vielleicht ein Häuschen und eine Bank wo man mutmaßen kann das des dazugehört.

Was ist eine Haltestelle? Wie definiert man das... Ist das physisch vor Ort auffindbar, oder vor Ort nachprüfbar durch erfragen vor Ort? Wenn nein dann gehört es nicht in OSM.

miche101 wrote:

Was ist eine Haltestelle? Wie definiert man das... Ist das physisch vor Ort auffindbar, oder vor Ort nachprüfbar durch erfragen vor Ort? Wenn nein dann gehört es nicht in OSM.

Als Haltestelle würde ich eine Stelle definieren, an der ein öffentliches Verkehrsmittel regelmäßig zum Fahrgastwechsel hält. Dies ist grundsätzlich vor Ort durch langfristige Beobachtung des Verkehrsmittels nachprüfbar, auch wenn es im Einzelfall praktikablere Möglichkeiten geben mag.

Mit Ausnahme des Verkehrsweges sehe ich nicht, dass irgendeine physikalische Haltestelleninfrastruktur dafür zwingend vorhanden sein muss.

Das Verkehrsunternehmen könnte statt eines Haltestellenschildes die Position der Haltestelle auch durch eine Fahrbahnmarkierung kennzeichnen lassen oder lediglich im Fahrplan festlegen (z.B. Angabe einer Hausnummer oder Kreuzung) oder sich einfach darauf verlassen, dass die Anlieger schon wissen werden, wo der Bus regelmäßig hält.

Ein Haltestellenschild mag hinreichend für die Annhme sein, dass sich dort eine Halltestelle befindet und in Deutschland mag es sogar eine notwendige Voraussetzung sein.

slhh wrote:

...Ein Haltestellenschild mag hinreichend für die Annhme sein, dass sich dort eine Halltestelle befindet...

Da kenne ich diverse Gegenbeispiele ;-)

miche101 wrote:

Dann muss ich meine ganzen Bushaltestelleschilder wieder rauslöschen die ich die letzten 9 Jahre gemapt habe? Weil ich hab immer den Standpunkt des Schildes gemapt... Ja eigentlich das Schild.

Ist doch völlig OK, wenn man die Position des Haltestellenschildes als Position der Bushaltestelle nimmt. Es gibt aber eben auch Ausnahmen wie z.B. zwei Schilder oder gar kein Schild an einer Haltestelle. Dann spielt es eben eine Rolle, dass es genau genommen nicht um das Schild sondern um seine Bedeutung geht.

slhh wrote:

Dies ist grundsätzlich vor Ort durch langfristige Beobachtung des Verkehrsmittels nachprüfbar, auch wenn es im Einzelfall praktikablere Möglichkeiten geben mag.

Langfristige Beobachtung des Verkehrsmittels? Nicht dein ernst? Wer macht den sowas? 🤣

slhh wrote:

Das Verkehrsunternehmen könnte statt eines Haltestellenschildes die Position der Haltestelle auch durch eine Fahrbahnmarkierung kennzeichnen lassen oder lediglich im Fahrplan festlegen (z.B. Angabe einer Hausnummer oder Kreuzung) oder sich einfach darauf verlassen, dass die Anlieger schon wissen werden, wo der Bus regelmäßig hält.

Fahrbahnmarkierungen würden wieder physisch vor Ort aufzufinden sein. Des andere wäre vor Ort zu erfragen.
Was würde man dann machen wenn der Bus dort hält wo Leute stehen und warten, ohne festen Platz. Einfach irgendwo an der Straße an der dieser Bus fährt zu stehen um eine bestimmte Zeit.

slhh wrote:

Ein Haltestellenschild mag hinreichend für die Annhme sein, dass sich dort eine Halltestelle befindet und in Deutschland mag es sogar eine notwendige Voraussetzung sein.

Ja für mich als Benutzer und nicht nur als Mapper.. ja eigentlich das wichtigste, wo? muss ich hin, das ist mein Ziel auch optisch schon oft von weit zu sehen und für die eine Richtung müsste ich da hin für die andere müsste ich da hin.. Der Rest ist erst einmal egal.

Mir reden hier schon noch um so kleine Dinger oder, so Bushaltestellen... Da gibt es oft nur ein Schild mit Fahrplan sonst nichts 😉 Ja was soll man da auch Aufnahmen.

Weide wrote:

Ist doch völlig OK, wenn man die Position des Haltestellenschildes als Position der Bushaltestelle nimmt. Es gibt aber eben auch Ausnahmen wie z.B. zwei Schilder oder gar kein Schild an einer Haltestelle. Dann spielt es eben eine Rolle, dass es genau genommen nicht um das Schild sondern um seine Bedeutung geht.

Ja zwei Schilder wird es schon kompliziert.. wo muss ich stehen wenn ich da mitfahren will? Je Fahrtrichtung können dieses weit voneinander entfernt sein... da ist es als Fußgänger schon interessant wo muss ich hin.. Wo genau muss ich am Bußbahnhof hin? usw.

Oder wie meinst du das, wie nimmst du eine Bushaltestelle auf? Kreierst du irgendeinen Mittelpunkt der "Haltestelle".. der sich vielleicht wenige Meter vom Schild unterscheidet und von der GPS Ungenauigkeit verschlungen wird?

miche101 wrote:

Ja zwei Schilder wird es schon kompliziert.. wo muss ich stehen wenn ich da mitfahren will? Je Fahrtrichtung können dieses weit voneinander entfernt sein... da ist es als Fußgänger schon interessant wo muss ich hin.. Wo genau muss ich am Bußbahnhof hin? usw.

Da hab ich mich unklar ausgedrückt. Ich meinte nicht verschiedene Haltestellen innerhalb der Gesamthaltestelle oder des Busbahnhofs. Ich meinte eine Einzelhaltestelle an die gerade mal ein einzelner Bus passt, also z.B. "Benrath S Steig 5". Die hat zwei gleichlautende Schilder ... eins mehr an dem einen Ende und das andere mehr an dem andern. Trotzdem gehört an jede der Einzelhaltestellen im Busbahnhof nur jeweils ein highway=bus_stop. Sich nach den Schildern zu richten ist eben eine gute Faustregel ... nicht mehr und nicht weniger.

@Weide

ja es gibt keine Regel ohne Ausnahme. In dem Fall macht es Sinn.. Busbahnhöfe sind so ihr eigener Fall.. ganz schlimm wenn da herum geändert wird 🤔 Solange das Ergebnis stimmt und der der die OSM-Karte verwendet richtig hin findet passt das 🙂

Mfg Miche

Da ich schon oft bei Bahnhöfen über MENTZ stolpere, sollte man sich vielleicht einmal an diese zu ÖPNV wenden. Sie verwenden ja auch Schlüssel und Werte die keiner im WIKI findet.

ES sind zwar z.B, highway, railway, platform alle an einem way als Fläche (was ich für falsch halte):

http://www.openstreetmap.org/relation/3 … 2/13.43389

Wären die beiden Bahnsteige hw=footway mit jeweiliger ref=2 oder ref=3 getaggt und diese als Bestandteil des Bahnsteiges in der Relation wäre auch ein Routing sinnvoller:

http://www.openstreetmap.org/directions … 5/13.43411

Dann kann der Bahnsteig (Fußweg) auch ein public_transport=platform für ÖPNV-Map tragen und die Fläche des Bahnsteiges railway=platform, public_transport=platform für die Railway-Map.

Diese Bahnsteige können dann zum Fernbahnhof Ostbahnhof - und in Verbindung mit anderen ÖPNV Verkehrsmitteln zum Knoten Ostbahnhof verbunden werden.

Nur müsste dann auch MENTZ auf Vorschläge, Hinweise reagieren und das im WIKI (ÖPNV) festschreiben.

miche101 wrote:

Langfristige Beobachtung des Verkehrsmittels? Nicht dein ernst? Wer macht den sowas? 🤣

Regelmäßige Nutzer, Fahrzeugführer des Verkehrsmittels, Regelmäßige andere Nutzer des Verkehrsweges und Anlieger der Haltestellen machen dies eigentlich ganz automatisch. Für Andere dürfte es praktischer sein, diese Personen zu befragen.

miche101 wrote:

Was würde man dann machen wenn der Bus dort hält wo Leute stehen und warten, ohne festen Platz. Einfach irgendwo an der Straße an der dieser Bus fährt zu stehen um eine bestimmte Zeit.

Diesen Fall werden die Entwickler des Taggingshemas wohl vergessen haben. Vermutlich sind die Verhältnisse in ihrer Heimatregion zu geregelt. Die sauberste Lösung wäre vermutlich in der Rolle des Fahrwegs zu kennzeichnen, dass ein Bedarfshalt erfolgen kann. EWnn es für den ganzen Linienverlauf gilt, würde natürlich auch ein Tag an der Linienrelation genügen.

geri-oc wrote:

ES sind zwar z.B, highway, railway, platform alle an einem way als Fläche (was ich für falsch halte):

Das halte ich auch für falsch.

geri-oc wrote:

Wären die beiden Bahnsteige hw=footway mit jeweiliger ref=2 oder ref=3 getaggt und diese als Bestandteil des Bahnsteiges in der Relation wäre auch ein Routing sinnvoller:

Zum Einen sollte der Router die Leute nicht auf der Bahnsteigkante balancieren lassen und zum Anderen wäre dies Tagging für den Rooter.
Ein guter Router sollte über die Bahnsteigfläche routen.
Auch die Querwege zur Verbindung mit der Platform sind eigentlich falsch. Hier wäre es wohl korrekt, die Treppenbereiche per Multipolygon-Inner aus dem Bahnsteig auszuschneiden und den Fussweg (die Treppe) dann mit dem Inner und damit der Bahnsteigfläche zu verbinden.

geri-oc wrote:

ES sind zwar z.B, highway, railway, platform alle an einem way als Fläche (was ich für falsch halte):

http://www.openstreetmap.org/relation/3 … 2/13.43389

"highway, railway, platform" sind nicht an einem way sondern an dem Multipolygon.

Das "highway=platform" ist Quatsch, denn das Ding ist klar nur für Züge. Das "area=yes" ist auch Quatsch, denn Multipolygone können nur Flächen sein und area=yes gehört nur an Objekte, die ohne das Tag Flächen oder Linien sein könnten.

geri-oc wrote:

Wären die beiden Bahnsteige hw=footway mit jeweiliger ref=2 oder ref=3 getaggt und diese als Bestandteil des Bahnsteiges in der Relation wäre auch ein Routing sinnvoller:

OK. Das Flächenrouting funktioniert nicht. Das ist ein Routing-Problem und es muss entweder gelöst werden oder wir müssen in OSM generell auf begehbare Flächen verzichten ... was nicht passieren wird.

Außerdem meinen die Routing-Engines augenscheinlich, dass man auf einem Bahnsteig nicht gehen kann. Das ist einfach ein Irrtum.

geri-oc wrote:

Dann kann der Bahnsteig (Fußweg) auch ein public_transport=platform für ÖPNV-Map tragen und die Fläche des Bahnsteiges railway=platform, public_transport=platform für die Railway-Map.

OK, dann hätten wir da an einem Bahnsteig drei Platforms -- falls ich das richtig verstanden habe.

Das kann PTv2 nicht. Jeder stop und jede platform, an der ein Verkehrsmittel hält, muss in die Route, sonst ist das Nachschlagen der Linien zu einer Haltestelle kaputt. Pro Anhalten des Fahrzeugs kann eine PTv2-Route aber nur maximal einen stop und eine platform aufnehmen, sonst geht die Haltestellenliste der Route kaputt. Ein Konzept mit solchen Platforms ist möglich, aber kann man es erst nach Ablösung von PTv2 realisieren. (In meinem PTv3-Vorschlag geht sowas)

geri-oc wrote:

Nur müsste dann auch MENTZ auf Vorschläge, Hinweise reagieren und das im WIKI (ÖPNV) festschreiben.

Mentz legt in OSM nichts fest! Nach unserem Anfangskonflikt mit Mentz hat sich da eigentlich auf dieser Basis ein gutes Verhältnis entwickelt.

slhh wrote:

Die sauberste Lösung wäre vermutlich in der Rolle des Fahrwegs zu kennzeichnen, dass ein Bedarfshalt erfolgen kann. EWnn es für den ganzen Linienverlauf gilt, würde natürlich auch ein Tag an der Linienrelation genügen.

In der Rolle geht es nicht. Sowas ging in PTv1, weil PTv1 eigentlich keine Rollen hatte und brauchte und man da dann einfach Zusatzangaben in der Rolle unterbringen konnte. In PTv2 hat man wie in Abbiegerelationen usw. aber echte Rollen, die für die Interpretation benötigt werden. Wenn man da was anderes reinschreibt oder was zusätzliches, dann ändert man die Auswerteregeln und macht korrekte Programme kaputt. Auswerteprogramme dürfen sich darauf verlassen, dass man in PTv2 mit einem Auszug der Relationsmember mit leerer Rolle die Liste der Fahrwege bekommt.

Tags an der Linie oder Variante wären sinnvoll. Da gibt es ja einige Varianten für "Zwischendurchstops": "Ein- und Aussteigen", "nur Aussteigen", "nur für Frauen", "erst ab 19:00". Da müssten wir mal überlegen, wie man die ganzen Kombinationen sinnvoll in ein oder mehrere Tags packen kann...

Weide wrote:

OK. Das Flächenrouting funktioniert nicht. Das ist ein Routing-Problem und es muss entweder gelöst werden oder wir müssen in OSM generell auf begehbare Flächen verzichten ... was nicht passieren wird.

Scheint prinzipiell ein lösbares Problem zu sein, wenn auch nicht ganz triviel: https://www.youtube.com/watch?v=6zzPzZg … Iffh6HfM7r

Weide wrote:

Außerdem meinen die Routing-Engines augenscheinlich, dass man auf einem Bahnsteig nicht gehen kann. Das ist einfach ein Irrtum.

Bahnsteige sind natürlich immer begehbar, aber eventuell nicht ohne rechtliche Einschränkungen. Meines Wissens nach sind Bahnsteige kein öffentlicher Raum, obwohl das gerade bei kleinen Haltepunkten nicht ersichtlich ist und Bahnsteige sogar hin und wieder im Hinblick als Zweitnutzung als Verbindungsweg angelegt werden.

Weide wrote:

Mentz legt in OSM nichts fest! Nach unserem Anfangskonflikt mit Mentz hat sich da eigentlich auf dieser Basis ein gutes Verhältnis entwickelt.

Ich meinte auch nicht das Mentz etwas festlegen soll, sie sollten aber ihre eingeführten (z.B. sinnvollen Schlüssel = Anzeigetafel - destination_display) im WIKI - http://wiki.openstreetmap.org/wiki/DE:Public_transport - mit aufführen:

https://taginfo.openstreetmap.org/keys/ … ort#values

Damit wird schon etwas auf Vereinheitlichung eines Schlüssels hingearbeitet. Und da sie sich hauptsächlich mit ÖPNV beschäftigen und auch Daten nutzen, wäre eine Art "Moderator für ÖPNV" angebracht.

Trockennasenaffe wrote:

Scheint prinzipiell ein lösbares Problem zu sein, wenn auch nicht ganz triviel: https://www.youtube.com/watch?v=6zzPzZg … Iffh6HfM7r

Ja. Einige der Verfahren sind evtl. für OSM nicht so geeignet. Wir haben wegen unterschiedlicher Namen oder Bodenbeläge oder wat-weiss-ich ja auch Flächen, die an Flächen statt an Wege grenzen. Da kann man dann nicht mehr davon ausgehen, dass Anfang und Ende der optimalen Route auf vorhandenen Nodes liegen. Ein paar Algorithmen entfallen dann schon. Der Rest kann heftig in die Rechenzeit gehen.

Vielleicht sollten wir doch mal ganz offiziell unsichtbare Routing-Support-Wege zulassen. Wie in dem Vortrag gesagt wurde sind die jetzigen Lösungstricks ein wirklich störendes Problem für das echte Flächenrouting. Wenn man sowas dagegen offiziell zulässt, dann sind sie beim Rendern und beim Flächenrouting leicht zu ignorieren und das hätte auch noch einen großen Nutzen für den ÖPNV:

Wenn man als Fußgänger einfach einen Weg von A nach B sucht und stolpert dabei über eine querliegende Fußgängerzonenfläche, dann denkt man "wat n Blödsinn" und sucht sich selbst einen Weg. Wenn das bei Fahrplanauskünften passiert, dann bekommt man einfach eine schlechtere Verbindung mit Umsteigen in Düsseldorf statt in Köln. Dass das Ganze am Mapping des Bahnhofsvorplatzes in Köln liegt ist dann praktisch unsichtbar.

Weide wrote:

Dass das Ganze am Mapping des Bahnhofsvorplatzes in Köln liegt ist dann praktisch unsichtbar.

Funktioniert auch in Dresden gut: http://www.openstreetmap.org/#map=17/51.05974/13.74228

Dann würde es mit hw=footway an der Kante des Bahnsteiges auch besser funktionieren:

http://www.openstreetmap.org/directions … 63/6.95897

(Und so genau ist Routing (noch) nicht, das ich auf der Kante entlang balancieren muss.)

Weide wrote:

Ja. Einige der Verfahren sind evtl. für OSM nicht so geeignet. Wir haben wegen unterschiedlicher Namen oder Bodenbeläge oder wat-weiss-ich ja auch Flächen, die an Flächen statt an Wege grenzen. Da kann man dann nicht mehr davon ausgehen, dass Anfang und Ende der optimalen Route auf vorhandenen Nodes liegen. Ein paar Algorithmen entfallen dann schon. Der Rest kann heftig in die Rechenzeit gehen.

Wenn ich das richtig sehe, würde sich das lösen lassen in dem in der Vorverarbeitung der Daten zum Routing, benachbarte, begehbare Flächen zusammengefasst würden.

Weide wrote:

Vielleicht sollten wir doch mal ganz offiziell unsichtbare Routing-Support-Wege zulassen. Wie in dem Vortrag gesagt wurde sind die jetzigen Lösungstricks ein wirklich störendes Problem für das echte Flächenrouting. Wenn man sowas dagegen offiziell zulässt, dann sind sie beim Rendern und beim Flächenrouting leicht zu ignorieren und das hätte auch noch einen großen Nutzen für den ÖPNV:

Wenn solche Wege geduldet werden, sollte da in der Tat ein tag dran, dass sie vom rendern ausschließt. Ich bezweifle allerdings, dass solche Hilfswege generell die Lösung sind. Sobald man komplexere Flächen hat, wäre die Anzahl der Hilfswege um von jedem sinnvollen Startpunkt kürzt-möglich zu jeden sinnvollen Endpunkt zu kommen sehr groß. Die Bereitschaft, Diese konsequent anzulegen, zu warten und überhaupt das Konzept zu verstehen dürfte gering sein. Triviale Fälle sind auf der anderen Seite auch gut automatisiert zu behandeln.

Insgesamt würde ich sagen, dass ich stark anzweifle, dass Menschen im allgemeinen deutlich besser darin sind Wege über Flächen zu finden als Maschinen. Ich denke, dass bisher nur zu wenig Aufwand investiert wurde, brauchbare Algorithmen zu implementieren.

Hier noch ein Video zum Flächenrouting von Roland Olbricht: https://www.youtube.com/watch?v=-ogblIKiN5M

Weide wrote:

Vielleicht sollten wir doch mal ganz offiziell unsichtbare Routing-Support-Wege zulassen.

Ein Tag zur Kennzeichnung solcher Wege halte ich für sinnvoll. Allerdings sehe ich bei begehbaren Flächen in der Regel keine Notwendigkeit solche Wege für Fussgänger anzulegen. Ein Fussgängerrouter routet über kurze Entfernungen und sollte dabei ein Flächenrouting beherschen. Wir sollten den Router-Entwicklern keinen Grund liefern, dieses niedrig zu priorisieren, zumal die Routing-Support-Wege hier im Allgemeinen auch keine guten Resultate ermöglichen dürften.

Weide wrote:

In der Rolle geht es nicht. Sowas ging in PTv1, weil PTv1 eigentlich keine Rollen hatte und brauchte und man da dann einfach Zusatzangaben in der Rolle unterbringen konnte. In PTv2 hat man wie in Abbiegerelationen usw. aber echte Rollen, die für die Interpretation benötigt werden. Wenn man da was anderes reinschreibt oder was zusätzliches, dann ändert man die Auswerteregeln und macht korrekte Programme kaputt. Auswerteprogramme dürfen sich darauf verlassen, dass man in PTv2 mit einem Auszug der Relationsmember mit leerer Rolle die Liste der Fahrwege bekommt.

Grundsätzlich dürfen sich Auswerteprogramme gar nicht darauf verlassen, dass OSM Tagging Schemas unveränderlich sind, sofern man von unangekündigten plötzlichen Massenedits absieht. Insbesondere bei Änderungen, auf die die Auswerter mit minimalen Code-Änderungen reagieren können, sollten wir uns absolut keine Gedanken über Inkompatibilitäten von Auswerteprogrammen machen.

Da PTv1 Rollen für die Fahrwege verwendet und PTv2 nicht, wäre die Ergänzung sogar einfacher in PTv2 zu integrieren. Aber natürlich können wir auch mehrere Eigenschaften durch geeignete Syntax in einer Rolle kodieren, falls nötig.

Da ich für die Erweiterung keine hohe Priorität sehe, würde ich sie eher in ein generell überarbeitetes PTv3 (oder PTv2.x) einfließen lassen, wenn wir die Erweiterung haben wollen.
Unnötig oft müssen wir die Auswerter auch nicht mit Inkompatibilitäten ärgern und PTv1 und PTv2 sehe ich ohnehin als gescheitert an.
Die allgemein nötigen Änderungen halte ich für umfangreich genug, dass es ein PTv3 geben muss, eventuell ist aber ein PTv2.x als Vorbereitung dazu sinnvoll.

slhh wrote:

Da PTv1 Rollen für die Fahrwege verwendet und PTv2 nicht, wäre die Ergänzung sogar einfacher in PTv2 zu integrieren. Aber natürlich können wir auch mehrere Eigenschaften durch geeignete Syntax in einer Rolle kodieren, falls nötig.

Nein. Andersrum wird ein Schuh draus. PTv1 verwendet keine Rollen als Rollen und PTv2 verwendet sie. Die leere Rolle ist eine Rolle wie alle anderen.

Die Rolle gibt ja an, was das Objekt in der Relation soll. Typisch ist z.B. "from", "via" und "to" in Abbiegerelationen.

PTv1 verwendet keine Rollen. Haltestellen werden daran erkannt, dass sie Nodes sind. Fahrwege werden daran erkannt, dass sie Ways sind. Die Rollen sind also unbenutzt und werden daher gern zum Speichern von ergänzenden Angaben verwendet. Wenn da etwas unverständliches drin steht, dann ist nicht die Relation kaputt sondern nur die Ergänzungsangabe. Deshalb ist es nicht weiter schlimm, wenn da jemand als Rolle "forward:stop:17:alternate:summer" einträgt.

Ganz anders ist es in Relationen mit Rollenverwendung wie Abbiegerelationen oder PTv2-Relationen. Wenn man bei solchen Relationen die für bestimmte Zwecke festgelegten Rollen nicht benutzt, dann sollte man nicht mit einer Auswertung rechnen. Wenn jemand statt "via" in einer Abbiegerelation "viax" verwendet, dann fehlt das "via" und das ist ein Fehler. Genauso ist es in PTv2-Relationen. Die Objekte werden anhand ihrer Rollen erkannt und wenn da nicht die Rolle "platform" oder "platform_entry_only" oder "platform_exit_only" steht, dann ist es keine platform und wenn da nicht die Rolle "" steht, dann ist es kein Fahrweg.