Wiki Änderung pt=platform

geri-oc · 2019-08-08T09:08:15.000Z

Man kann sich ja die Vorschläge der MENTZ Gmbh ansehen, die m.E. sehr anschaulich die Problematik erklären. Vor allem ist da auch ein Anwender, der “Fehler” oder “Korrekturen” erkennt und der auch mit der OSM-Gemeinschaft zusammenarbeitet.

https://wiki.openstreetmap.org/wiki/DE:MENTZ_GmbH

ma-rt-in · 2019-08-08T10:29:44.000Z

Maarten Deen:

Ich wurde die änderung schnellstens rückgängig machen. Der benutzer Famosm hat meiner meinung nach zu wenig OSM geschichte um das zu entscheiden.

+++++1

Fabi2 · 2019-08-11T15:46:41.000Z

Ich bin dafür die Probleme von Pulic_Transport zu verbessern und es evtl. minimal zu erweitern.

Das Hauptproblem ist (hatte ich auch schon vor Jahren mal geschrieben), das es keine Relation für die Beziehung zwischen Haltepunkten (stop_positions) und der Platform (public_transport=platform) gibt, das führt dazu, das unnötigerweise die Platformen mit in die Haltestellenrelation (stop_area) aufgenommen werden müssen, da sonst eben genau diese Beziehung nicht ersichtlich ist.

Die Erweiterung gibt es fast schon vollständig, da einige Leute die unter anderem von mir benutzte Erweiterung für die route-Relationen aufgegriffen haben: soll heißen: interval=* und service_times=, duration= bzw. exeptions= (gibts schon für access, dann was anderes Passendes). Wofür sollen die gut sein? Na für die Gut-Genug-Fahrplanauskunft.

Nein, das soll keine Ersatz für eine echte Anbindung an die Datenbanken der Nahverkehrsunternehmen sein, sondern nur näherungsweise (mit vertretbarem Aufwand den maximalen Nutzen erreichen) die Routenplanung ermöglichen. Anhand der service_times=* weiß man wann die (Teil-)linie überhaupt fährt, durch das Intervall weiß man wie lange man im Mittel auf die nächste Abfahrt warten muß. Das Intervall
war ursprünglich in Minuten gedacht und wurde laut Taginfo auch lange so benutzt, nur hat das jetzt jemand im Wiki nur unötig verkompliziert (einfach als Minuten belassen und auch Minuten-Bruchteile erlauben wie z.B. 0.5 wäre echt besser, Selbiges gilt für duration=*) anhand der Dauer kann man ähnlich wie bei der Hausnummerninterpolation ungefähr die Fahrzeit berechnen.

Über exceptions=* kann man versuchen wenigstens manche häugfigen Ausnahmen (mehr als Klassen-Tag gedacht wie z.B.: PHE, SHE für public holiday execption bzw. school holiday execption), bzw. die Wahrscheinlichkeit das es überhaupt Ausnahmen gibt (z.B. über die Angabe der Tage hinter den Ausnahmetags), erfassen. Das Ausnahmetagging muß man mal bei Bedarf noch ordentlich ausarbeiten.

Fabi2 · 2019-08-11T17:20:10.000Z

Ich sehe gerade das es für interval=* schon eine Wikiseite (https://wiki.openstreetmap.org/wiki/DE:Key:interval) gibt, sowie auch für duration=* (https://wiki.openstreetmap.org/wiki/Key:duration). Es wäre da sicher echt hilfreich, wenn man sich da mal auf ein Datenformat zur angabe der service_times=* einigen könnte!

Also entweder das klassische Öffnungszeitenformat, für das Netzwolf und ich damals schon eine Intervall-Erweiterung erdacht haben, weil wäre ja nicht so, das wir die Intervallangabe nicht schon vor Jahren durchdisskutiert haben (siehe https://wiki.openstreetmap.org/wiki/DE:Key:opening_hours/specification da gibt es z.B. “Mo-Fr 16:00-18:00/10” für Montag bis Freitag 16:00-18:00 alle 10 Minuten).

Aber gut, daß es noch interval:conditional mit gänzlich anderem Format (https://wiki.openstreetmap.org/wiki/DE:Conditional_restrictions) und https://wiki.openstreetmap.org/wiki/Key:duration mit Zeitangaben nach ISO 8601 gibt, wäre ja sonst auch zu einfach für den Mapper!

Wenn man einfach nur service_times=* mit dem üblichen inzwischen gut unterstützten Öffnungszeitenformat genommen hätte. Ab 100 Minuten darf man dann wohl scheinbar die Stunden ausschreiben, jedenfalls steht nichts von beliebiger Länge für den Minutenwert drin, und was bringt es überhaupt da noch andere Formate als die Minuten zu unterstützen? Die Software darf nur umständlich erst eine paar mal checken, was jetzt genau das Format ist, wobei man ja den Minutenwert z.B. bei duration=* für die transsibirische Eisenbahn o.ä. auf ein paar Tage hochsetzen kann.

Zum Ausgangsposting, kann ich nur sagen: “Name ist das was auf dem Schild (primär) steht und wenn es keins gibt, dann der aus dem Fahrplan”.

Weide · 2019-08-11T20:13:16.000Z

Fabi2:

Das Hauptproblem ist (hatte ich auch schon vor Jahren mal geschrieben), das es keine Relation für die Beziehung zwischen Haltepunkten (stop_positions) und der Platform (public_transport=platform) gibt, das führt dazu, das unnötigerweise die Platformen mit in die Haltestellenrelation (stop_area) aufgenommen werden müssen, da sonst eben genau diese Beziehung nicht ersichtlich ist.

-Die stop_area macht diese Beziehungen aber nicht ersichtlich.

-Nur die Routen geben solche Beziehungen an. Deshalb ist die Nennung beider Teile in den Routen auch verpflichtend soweit diese existieren. In anderen Routen können die Beziehungen anders sein. In den Routen gibt es Pärchen oder Singles … außerhalb der Routen sind das n:m-Beziehungen.

-Es kann daher keine separaten Relationen geben, die die Beziehungen angeben.

Fabi2 · 2019-08-11T20:39:23.000Z

Weide:

Fabi2:

Das Hauptproblem ist (hatte ich auch schon vor Jahren mal geschrieben), das es keine Relation für die Beziehung zwischen Haltepunkten (stop_positions) und der Platform (public_transport=platform) gibt, das führt dazu, das unnötigerweise die Platformen mit in die Haltestellenrelation (stop_area) aufgenommen werden müssen, da sonst eben genau diese Beziehung nicht ersichtlich ist.

-Die stop_area macht diese Beziehungen aber nicht ersichtlich.

-Nur die Routen geben solche Beziehungen an. Deshalb ist die Nennung beider Teile in den Routen auch verpflichtend soweit diese existieren. In anderen Routen können die Beziehungen anders sein. In den Routen gibt es Pärchen oder Singles … außerhalb der Routen sind das n:m-Beziehungen.

-Es kann daher keine separaten Relationen geben, die die Beziehungen angeben.

Hoffentlich bessere/genauere Erklärung: Man mappt die stop_positions, als Knoten, diese kommen dann in eine neue Relation, zusammen mit dem Bahnsteig, zu dem sie gehören, also wenn z.B. der Zug in der Mitte hält und es auf beiden Seiten des Gleises einen Bahnsteig gibt (siehe z.B. den S-Bahnhof Berlin Warschauer Straße), dann werden zwei von diesen neuen Relationen angelegt, einer mit dem linken Bahnsteig und einer mit dem rechten Bahnsteig, wo dann die z.B. zwei Haltepunkte (für Kurzzüge und Normalzüge) drin sind.

Diese beiden neuen Relationen kommen dann in die stop_area-Relation. In die Routen-Relation kommen dann nur noch die Stop-Positions, die die (Teil)route anfährt.

Dieser Abstraktionsschritt fehlt im Pulic_Transport-v2-Schema. Deshalb muß man dann in jeder Teilroutenrelation immer wieder die Bahnsteige (public_transport=platform) mit aufnehmen, weil man sonst nicht weis, zu welchen Bahnsteig die Haltepunkte gehören.

Ich kenne persönlich keinen Fall, wo es z.B. nur stop_positions gibt, das definiert meines achtens auch das Public_Transport_v2-Schema, denn selbst beim Bus gibt es das Haltestellenschild bzw. den Gehweg, falls du darauf hinaus willst.

geri-oc · 2019-08-12T06:14:52.000Z

Sollte in OSM nicht nur die Haltestelle und die Linienführung?

Und das ist schon kompliziert genug aktuell zuhalten. Bei den Veränderungen der Haltestellen/Linienführung durch Baustellen oder jährlich neue Fahrpläne.

Statt Intervalle oder Betriebszeiten in OSM ist es sinnvoller über die stopid=33001141 (VVO) den aktuellen Fahrplan zu verlinken: https://www.vvo-online.de/de/fahrplan/aktuelle-abfahrten-ankuenfte/abfahrten?stopid=33001141

Weide · 2019-08-12T11:20:07.000Z

Fabi2:

Ich kenne persönlich keinen Fall, wo es z.B. nur stop_positions gibt, das definiert meines achtens auch das Public_Transport_v2-Schema, denn selbst beim Bus gibt es das Haltestellenschild bzw. den Gehweg, falls du darauf hinaus willst.

Ja, leider ist “überall sowohl stop als auch platform und überall eine stoparea drumrum und überall public_transport=… dran” die Mappingrealität. Aber diese Objektanlegerei liegt nicht an PTv2! Es spiegelt nur die weit verbreiteten Gerüchte über PTv2 wieder. Hier mal ein paar extreme nach PTv2 korrekte Beispiele:

Eine simple Haltestelle für beide Richtungen auf der Landstraße lässt sich durch einen einzigen Node auf der Straße mit “highway=bus_stop” und “name=Humtata” mappen und das ist völlig korrektes PTv2. In die Routen kommt er mit der Rolle “stop”. Keine stop_area. Kein “public_transport=…”

Bekommt eine der Seiten einen Regenschutz und man will ihn nicht getrennt mappen, dann nimmt man statt des Nodes auf der Fahrbahn zwei Nodes auf den Seiten neben der Fahrbahn. Sie haben die o.g. Tags und der eine hat noch “shelter=yes”. In die Routen kommt der jeweils passende Node mit der Rolle “platform”.

Aber die meisten Mapper denken, dass man statt dem einem Node im ersten Beispiel in PTv2 einen Verhau aus 5 Objekten braucht. Und das Ganze ohne ein einziges Bit an Information über die Realität hinzuzufügen. Die “normalen” Mapper laufen uns weg, weil wir solche unnötig komplizierten Dinge machen. Mir hat mehr als ein Mapper (sinngemäß) gesagt “Wenn ich ne Bäckerei sehe, dann trag ich die ein … aber um Bushaltestellen mache ich einen großen Bogen”

Bei den zusätzlichen Relationen sehe ich noch nicht, wie man mit (legitimerweise) fehlenden Stops umgeht und wie man bei je nach Linie verschiedenen Platforms zu einem Stop die richtige finden soll. Das ist z.B. wichtig, wenn nur eine Platform für Rollifahrer ok ist. Es hätte aber den Vorteil, dass man die Nutzung mehrerer Steige gleichzeitig abbilden könnte.

chris66 · 2019-08-22T07:47:56.000Z

Zur Info: Die Änderung wurde mittlerweile im Wiki revertiert.

Tirkon · 2019-08-25T19:31:42.000Z

Fabi2:

Das Hauptproblem ist (hatte ich auch schon vor Jahren mal geschrieben), das es keine Relation für die Beziehung zwischen Haltepunkten (stop_positions) und der Platform (public_transport=platform) gibt, das führt dazu, das unnötigerweise die Platformen mit in die Haltestellenrelation (stop_area) aufgenommen werden müssen, da sonst eben genau diese Beziehung nicht ersichtlich ist.

Das Hauptproblem ist die Existenz einer stop_position im ÖPNV Modell. Man kann sie einfach ohne einen Verlust an Informationen weglassen.

Schauen wir uns einmal die Realität an. An der Haltestelle steht ein Haltestellenschild. Das nimmt der Fahrgast wahr. Wie ermittelt der Fahrgast nun eine nicht gekennzeichnete Halteposition? Er fällt vom Haltestellenschild aus das Lot auf die Route und weiß, wo Bus oder Bahn hält. Wenn eine Haltestelle vorübergehend verschoben wird, wird das Original-Haltestellenschild durchge-X-t und an der Ersatzhaltestelle ein provisorisches Haltestellenschild aufgestellt. Ein Autofahrer in Deutschland weiß dann auch, dass er nach dem Fällen des Lotes auf die Route 15 Meter vor und hinter dem Punkt nicht parken darf, damit das Procedere an der Haltestelle problemlos ablaufen kann.

Kurzum: Das Haltestellenschild definiert Ort der Haltestelle und auch den Ort der Halteposition.

An großen Bahnhöfen haben wir zudem die Schilder mit Buchstaben, die den Bahnsteig aufteilen. Anhand dieser Buchstaben kann der Fahrgast wiederum das Lot auf die Route fällen und weiß wo sein Zug hält. Man könnte also auch den Ort dieser Schilder mappen. Auch von einer public_transport=platform kann man das Lot fällen.

Was der Fahrgast kann, kann OSM oder dessen Anwender auch, nämlich das Lot vom Schild auf auf die Route fällen.
OSM Beispiel hierfür: https://tools.geofabrik.de/osmi/?view=addresses&lon=9.73525&lat=52.37495&zoom=18&overlays=buildings,buildings_with_addresses,postal_code,entrances_deprecated,entrances,no_addr_street,street_not_found,place_not_found,misformatted_housenumber_lenient,nodes_with_addresses_defined,nodes_with_addresses_interpolated,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads,nearest_areas,addrx_on_nonclosed_way

Umgekehrt kann aus der Halteposition der Standort des Haltestellenschildes nicht eindeutig bestimmt werden. Das Mappen des Schildes beinhaltet demnach mehr Informationen. Von daher braucht man nur die Schilder zu mappen, die der normale Fahrgast und Mapper wahrnimmt. Der Mapper muss nicht für den OSM Anwender das Lot zur Bestimmung der Halteposition fällen. Damit lösen sich auch die Probleme bezüglich der Verknüpfungsrelation. Was nicht existiert, braucht auch nicht verknüpft zu werden.

Es beseitigt auch das Problem, dass der weniger erfahrene Mapper bei Verlegung der Haltestelle nur eine der beiden Positionen verlegt und beispielsweise den Haltepunkt an der alten Stelle belässt. Überhaupt macht der Verzicht auf die Halteposition das ÖPNV Datenmodell übersichtlicher und bleibt so für mehr Mapper nachvollziehbar.

Es mag möglicherweise noch vereinzelt Fälle geben, in der die Halteposition dennoch unverzichtbar ist. Wenn das so ist, möge man mir die Fälle schildern. Man könnte dann überlegen, ob man sie dann für solche Ausnahmefälle auch zulässt. Ich würde aber auch dann dafür plädieren, das nicht zu tun. Das Vollständigkeitssyndrom bei OSM wird sonst dafür sorgen, dass dies auch an anderer Stelle geschieht. Es ist besser, den wenigen Fällen auch keine Halteposition zu verpassen und dafür der überwältigenden Mehrheit der Haltestellen zumindest in einem Punkt ein besser funktionierendes Modell zu verpassen.

Fazit: Verbannt man die Halteposition aus dem ÖPNV Modell, kann man nur gewinnen.

Weide · 2019-08-26T08:04:07.000Z

Tirkon:

Das Hauptproblem ist die Existenz einer stop_position im ÖPNV Modell. Man kann sie einfach ohne einen Verlust an Informationen weglassen.

Da haben wir in PTv2 schon. Kann jeder sofort weglassen. In PTv2 hat jeder Mapper die Wahl zwischen drei Möglichkeiten: nur stop, nur platform oder beide. (Diese Wahl hat man nur beim Mappen. In die Route muss zwingend alles Gemappte)

Tirkon:

Kurzum: Das Haltestellenschild definiert Ort der Haltestelle und auch den Ort der Halteposition.

Es definiert nicht … es ist nur ein guter Anhaltspunkt. Wenn das Schild aus irgendwelchen Gründen woanders steht, dann mappen wir die Haltestelle trotzdem da wo sie ist. Ich hab sogar schonmal ein Schild auf der gegenüberliegenden Straßenseite gesehen, weil der Busfahrer es in der Kurve sonst vielleicht zu spät gesehen hätte (In der Gegenrichtung fuhr da kein Bus)

Tirkon:

Es mag möglicherweise noch vereinzelt Fälle geben, in der die Halteposition dennoch unverzichtbar ist. Wenn das so ist, möge man mir die Fälle schildern.

Wo die Platform als Linie oder Fläche gemappt ist kann das highway=bus_stop nur in den Node auf dem Weg gehen, da nur Nodes für highway=bus_stop zulässig sind. Jede andere Position würde eine zweite Platform definieren, die gemäß PTv2 ebenfalls in die Route eingetragen werden muss und damit fälschlicherweise einen zweiten Haltevorgang des Verkehrsmittels definiert.

Tirkon:

Fazit: Verbannt man die Halteposition aus dem ÖPNV Modell, kann man nur gewinnen.

Das Verbot von Stops würde PTv1 für illegal erklären. Fragmentarisches Wissen über eine Buslinie (“Ich bin mit Linie X von meiner Blockhütte zum Einkaufen und zurück gefahren”) kann man in PTv1 viel besser als in PTv2 formulieren.

Wir sind uns aber völlig einig, dass die meisten Stops entfernt werden könnten (und übrigens auch die meisten stop_areas). Aber genau das ist in PTv2 vorgesehen.

miche101 · 2019-08-26T08:12:59.000Z

Tirkon:

Man kann sie einfach ohne einen Verlust an Informationen weglassen.

ja in wahrscheinlich 95% alle Fälle… bei größeren Bahnhöfen kann es machmal zu unklarheiten kommen… hier kann es nochbleiben und die platform ergänzen, aber der Rest dann entfallen.

Aber diese stop_postion fügt auch schaden zu… wie hier:
https://www.openstreetmap.org/node/4449275441/history

Ein Bussteg wo vorne und hinten ein Bus hält… hab da zwei Node gemacht, weil sonst müsste man den Steg teilen was ich auch nicht “richtig” finde… in den Node war die ganze Information… wurde dann gelöscht… hab ich jetzt gerade gesehen. Wurde aber nicht in die stop_postion eingetragen .

ToniE · 2019-08-26T08:21:36.000Z

miche101:

wurde dann gelöscht… hab ich jetzt gerade gesehen. Wurde aber nicht in die stop_postion eingetragen sad .

Oops. Ich schau’ mal was ich da “angestellt” habe und korrigiere das gegebenenfalls.

miche101 · 2019-08-26T08:24:17.000Z

ToniE:

Oops. Ich schau’ mal was ich da “angestellt” habe und korrigiere das gegebenenfalls.

Der ref=512,515 wäre ganz gut…

ToniE · 2019-08-26T08:25:51.000Z

ToniE:

miche101:

wurde dann gelöscht… hab ich jetzt gerade gesehen. Wurde aber nicht in die stop_postion eingetragen sad .

Oops. Ich schau’ mal was ich da “angestellt” habe und korrigiere das gegebenenfalls.

oder meintest Du diesen hier? https://www.openstreetmap.org/node/4449275442
Der ist in der Tat in keinerlei Relation eingebunden.

miche101 · 2019-08-26T08:27:49.000Z

Hier war der highway=bus_stop

https://www.openstreetmap.org/?mlat=48.2960920&mlon=11.8968570#map=19/48.29610/11.89681

ja das ist die Stop_position davon

ToniE · 2019-08-26T08:54:37.000Z

miche101:

Hier war der highway=bus_stop

https://www.openstreetmap.org/?mlat=48.2960920&mlon=11.8968570#map=19/48.29610/11.89681

ja das ist die Stop_position davon

Laut GTFS-Daten des MVV gibt es genau dort keine Platform.

https://ptna.openstreetmap.de/gtfs/DE/BY/MVV/platforms.gpx

miche101 · 2019-08-26T11:04:05.000Z

ToniE:

Laut GTFS-Daten des MVV gibt es genau dort keine Platform.

https://ptna.openstreetmap.de/gtfs/DE/B … tforms.gpx

Dann musst dir das auch mal vor Ort anschauen… GTFS sind nicht immer “perfekt”… oft mit heißer Nadel für Google gemacht

https://www.google.de/maps/@48.2963092,11.896848,3a,59y,176.3h,91.15t/data=!3m8!1e1!3m6!1sAF1QipOgKTeMnu5WY6xmk0k0OnLxu8XfcFCC8PsptUYX!2e10!3e11!6shttps:%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipOgKTeMnu5WY6xmk0k0OnLxu8XfcFCC8PsptUYX%3Dw203-h100-k-no-pi-0-ya202.22258-ro0-fo100!7i8704!8i4352

ToniE · 2019-08-26T11:07:24.000Z

miche101:

ToniE:

Laut GTFS-Daten des MVV gibt es genau dort keine Platform.

https://ptna.openstreetmap.de/gtfs/DE/B … tforms.gpx

Dann musst dir das auch mal vor Ort anschauen…

https://www.google.de/maps/@48.2963092,11.896848,3a,59y,176.3h,91.15t/data=!3m8!1e1!3m6!1sAF1QipOgKTeMnu5WY6xmk0k0OnLxu8XfcFCC8PsptUYX!2e10!3e11!6shttps:%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipOgKTeMnu5WY6xmk0k0OnLxu8XfcFCC8PsptUYX%3Dw203-h100-k-no-pi-0-ya202.22258-ro0-fo100!7i8704!8i4352

Oops, voi dawischt! Es gibt eine Welt neben MVV. Die Haltestelle scheint zu RVO oder sonstwas zu gehören.

miche101 · 2019-08-26T11:09:38.000Z

ToniE:

Die Haltestelle scheint zu RVO oder sonstwas zu gehören.

Nee des ist der “dritte” Bus_stop… für den Stadtbus Erding. Also 2x MVV und einmal Stadtbus