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.
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.
Langfristige Beobachtung des Verkehrsmittels? Nicht dein ernst? Wer macht den sowas?
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.
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.
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?
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.
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
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):
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:
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.
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.
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.
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.
“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.
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.
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)
Mentz legt in OSM nichts fest! Nach unserem Anfangskonflikt mit Mentz hat sich da eigentlich auf dieser Basis ein gutes Verhältnis entwickelt.
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…
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.
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:
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.
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.
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.
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.
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.
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.
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.
Solange das Ergebnis stimmt und der der die OSM-Karte verwendet richtig hin findet passt das 