Jepp und bis heute hat sich da nicht viel getan und alles ist immer noch so unklar wie letztes Jahr
Ich hatte mir die Info von hier https://wiki.openstreetmap.org/wiki/Buses geholt… Wobei das auch nicht gerade super erklärt wurde und ichs mir dann einfach in JOSM bei schon vorhandenen public_transport Realtionen abgeschaut habe.
Was mir beim lesen der Diskusion vom Proposal noch aufgefallen ist, sind die Fußwege auf den man ja eigentlich die public_transport=platform Node setzen soll… Nur mal ganz ehrlich ich Mappe seit 2008 an der Karte rum, nur das sind irgendwie die einzigen Wege die absolut kein Schwein in vollen Umfang mappen will.
Wie sieht das den da bei nen Router aus? Reicht den das wenn nen sidewalk=* auf dem Highway way liegt?
Aus Sicht des Datenmodells sind ja verschatelte Relationen im Moment meist die einzig saubere Lösung für viele Sachen, nur ist das Schema dann weder anfängerfreundlich im Sinne von leicht zu verstehen, noch ist es für Leute die es dann verstanden haben, hakbwegs praktikabel zu editieren. Zur schlechten Editierbarkeit trägt die mäßige Toolunterstützung bei und die wiederum zum Entstehen weiteren halbgarer Teil- und Frickellösungen. Ich denke da auch an die schlechte Relationsunterstützung von geschachtelten Relationen in JOSM, was ja noch mit der beste Editor in dieser Hinsicht ist (Relation anzeigen, zeigt nur die erste Ebene an. Von der Hauptrelation kann man nicht leicht die zugeordenten Kindrelationen auswählen, usw. Durch solche Sachen wird das Handling umstaändlich, obwohl am Ende iregndwie geht.).
Gut, vielleicht läßt sich die Relationsflut über Filter eindämmen, habe ich noch nicht versucht, geht aber sicher, wobei da evtl. ein Suchfeld zum schnellen Filtern vielleicht noch besser wäre, man schreibt da einfach Tagteile rein und AND und key=value wird automatisch zum filtern angenommen. Aber geht sicher auch mit vorbelegten Filtern, die man dann an und aus klickt. Ich würde die entsprechende Ergänzung der Relation (als type=public_transport public_transport=*, um konsitent und kompatibel zum alten Schema zu bleiben) gerne sehen, zusammen mit einer kleinen optionalen Gut-genug-Fahrplanerweiterung. Zwar wurden die Fahrplandaten ja jetzt freigegeben und man kann in Zukunft evtl. auf weitere Freigaben hoffen, aber der dauerhafte Nutzen der angedachten Erweiterung ist aus meiner Sicht größer als der Aufwand der Erfassung, außerdem wird es nicht für alle Netze oder kleine Nischenlinien auf der Welt elektionische Daten geben, wenn überhaupt. Das Ganze wurde schon mal in Verbindung mit dem Entwurf von Netzwolfs erweiterten Öffnungszeiten diskutiert (als z.B. “Mo-Fr 08:00-16:00/20”) und man müßte da nur ein paar Tags für die Betriebszeiten + Taktzeit, sowie den relativen Fahrzeitabstand zwischen den Stationen und die normale durchnittliche Aufenthaltsdauer an den Stationen pro Linienvariante erfassen, schon hat man eine Fahrplanauskunft für Notfälle. Zu den Betriebszeiten kann man alle x Minuten mit dem Verkehrsmittel fahren, im statistischen Mittel beträgt die Umsteigezeit an den Stationen 50% der Taktzeit des nachfolgenden Verkehrsmittels + die reine mittlere Fahrzeit, die ja mit erfaßt ist.
Ausnahmen, z.B. zum Betrieb an bestimmten Tagen, werden bewußt herausgelassen und es ist auch nicht das erklärte Ziel die offizielle Auskuft irgendwie ersetzen zu wollen, sondern nur, wenn man gerade mal am Ar… der Welt ist, herausfinden zu können, wie man jetzt noch weiter kommen kann. Da nur der Bereich der Betriebszeitenn und der ungefähre Takt an sich erfaßt sind, ist es nicht so schlimm bzw. aufwendig, wenn sich innerhalb des Betreibsintervalls mal etwas die Abfahrtszeiten ändern.
Ja, bei größeren und auch verstreuter liegenden Haltestellen, weiß man da im Moment sicher, welche Plattformen/Haltepunkte wirklich zur Hlatestelle gehören. Andernfalls müßte man eine Umkreissuche machen und läuft dann immer noch Gefahr evtl. Teile der Haltestelle zu vergessen.
Was mir an den PT Schema halt gefällt ist nunmal die Möglichkeit das man direkt sehen kann das die und die Linie dort hält und vorallem auf welcher Seite sie hält. Solche Dinge sind zwar momentan noch nicht Relevant, werden es aber hoffentlich irgendwann sein, weswegen ich schon meine, das man die alten Tags gegen das neue Schema austauschen sollte. Ich denke jedenfalls, das es irgendwann auch mal möglich sein wird, das man OSM dafür benutzen kann, auch mal Routen mit den ÖPNV zu planen und spätenstens dann sind solche Daten Goldwert. Wir haben ja jetzt schon den Vorteil gegenüber den offizellen Karten der Verkehrsunternehmen, das wir sagen können dort hält das und das in die Richtung und dort drüben in die andere.
Klar geht das und das wäre auch sehr sinnvoll, der saubere Weg wurde aber leider wie so oft bei OSM, aus Kompatibilitäts- oder Gründen des Verständnisses durch die Mapper, mal wieder geopfert:
In die Relation der Linienvariante kommt nur noch die Strecke und jeweilige die stop_position, was an der stop_position hält ergibt sich implizit durch die Linienvariantenrelationen.
Über die stop_position und die, leider fehlende Bahnsteig-Relation, kann man dann z.B. für den Router, den zugehörigen Bahnsteig/Platform für das weitere Routing ermitteln.
Von der emittelten Platform, kommt man dann über die die stop_area-Relation (wo nur noch die Platformen drin sind) zum Namen,Operator,Network,etc. der Gesamthaltestelle.
Ja, es nervt einfach, wenn man zusehen darf, wie halbe Lösungen gebastelt werden, nur damit die Community, die ja sehr wichtig ist bei Crowdsourcing-Projekten, das Mappingschema noch versteht.
Damit bekommt man dann entweder gar keine Daten oder aber unflektsible Teillösungen, bei der man für die nächste Anwendung dann wieder fast alles neu erfassen/umändern darf.
Das stimmt allerdings, wobei ich die Lösung nun ehrlich gesagt sogar leichter finde
Auch das mit den Segmentieren was im Proposal diskutiert wirde verstehe ich nicht so ganz… Wieso nimmt man dafür nicht einfach AssociatedStreet? Ich meine wir haben schließlich schon die möglichkeit auf die komplette Straße in einer Relation zuzugreifen, wieso macht man sich da dann noch mehr aufwand?
Im Grunde würde die Relation fürs Routing reichen, der Renderer müsste dann halt nur noch Berechnen wie der Bus fährt eben aus den Daten die er durch die route Relation dann bekommt, indem die ganze AssociatedStreet Relationen + die Public_transport Relationen drin stehen.
Irgendwie denken die Leute die das Proposal geschrieben haben viel zu Kompliziert oder haben einfach nie überhaupt was an der Karte gemacht und wissen nicht was schon alles vorhanden ist.
“Wartehaus” ja, aber der Wartebereich selbst hat eine andere Bedeutung und ist nicht direkt übersetzbar. Das Proposal sagt:
Wenn man nach dem PT-Schema dort einen Punkt setzt, dann sagt man damit, dass es dort keine Linie und keine Area einzuzeichnen gibt. Das ist beim highway=bus_stop anders. Daher kann man das eine nicht direkt in das andere übersetzen.
Das war auch schon vorher so. Das ist noch kein Grund irgendwas auszutauschen.
Was soll die stop_area in der Route? Ich sehe keinen Grund, sowas zu wollen. Aber es hängt vermutlich mit dem Folgenden zusammen.
“ref” und “name” sind nicht Bahnsteignummern, sondern beziehen sich auf die gesamte Haltestelle. Das ergibt sich eindeutig aus der Formulierung der Recommendation im Proposal: “recommended if no public_transport=stop_area exists, else optional”. Es gehört also dasselbe rein, wie bei name und ref der stop_area. Es wäre ja auch irre, wenn man beim zweiten Bussteig am Bahnhof das “name=Bahnhof” durch “name=2” ersetzen müsste, wenn man eine stop_area hinzufügt. Das Hinzufügen einer Relation kann doch nicht die Bedeutung eines Tags einer anderen Relation umschalten.
In das PT-Proposal hätten eigentlich Bus- und Bahnsteignummern rein gehört, aber es ist nun einmal nicht drin und man kann platform=2 oder ähnliches nehmen.
Weide
PS: Nicht das jetzt jemand denkt, ich wäre gegen das PT-Schema. Ich bin im Gegenteil dafür und benutze es intensiv.
Die stop_area soll einfach nur zur besseren Übersicht rein, sonst hätten wir wohl auch keinen wirklichen Grund für die PT Relation. Außerdem vereinfacht es die ganze Sache, vorallem FALLS die Leuts sich mal irgendwann zur Segmentierung entschieden sollten.
Aber es stimmt, Platform wäre in dem Fall wirklich angebrachter und man würde das ref nicht verhunzen. Ich sehe auch gerade im Wiki Artikel der Route Relation http://wiki.openstreetmap.org/wiki/Relation:route das es stop:number und platform:number gibt, leider werden die Daten aber nicht vom Renderer ausgewertet. Aber das wäre in dem Fall dann eh Depracted weil man ja die stop_area Relation nutzt und dort nur per Role sagt 1,2,3.
Die Zuordnung von Adressen zu einer Straße ist an sich keine dedizierte Straßenrelation. Außerdem wäre das keine einheitliche Universallöung, da Routen auch über Teilstücke von Straßen verlaufen können. Wenn man bei der Splitterrei ansetzen müßte, dann eher bei dem gesplitte, weil da ein neuses maxspeed=*, etc steht.
Ja klar, aber wie gesagt dafür wird dann Automatisch die Route berechnet da ja vorgegeben ist auf welchen Straße sich der Bus bewegt, also weiß man auch direkt wo genau er abbiegt. Ich wüsste jetzt nicht wo das Problem ist, vorallem da der maxspeed Tag für eine Fahrplan route eh vollkommen unrelevant ist.
Die Route führt über den Trelleborger Weg (http://osm.org/go/0NLU8SOPK–) und es es gibt eine Relation, die die Straße komplett als solche abbilden soll. So und jetzt sag mir mal, wo das Verkehrsmittel genau langfährt?
Das dürfte die beliebte Greifswalder Stadtrundfahrt “Trelleborger Doppelacht” sein. Die könnte man dann gleich noch bei fehlendem Access mit einer Rundtour durch das nahe gelegene ehemalige AKW Lubmin verbinden.
Es gibt doch genug Kraftfahrer, die nur darauf brennen, da access=, maxspeed= und die anderen Schilder alle zu taggen, da kümmere ich mich lieber um die POIs oder eher noch um surface=*. Das im “Zwischenlager” Lubmin nicht nur die Sonne strahl, wissen ja auch alle, die sich dafür interessieren. Natürlich sind die Kühlwassereinleitungen da auch total harmlos, die erhöhten Messwerte sind bestimmt auch nur eine Fehlmessung gewesen, die wurden jedenfalls dementiert. Da kann man an der nahegelegenen Badestelle also gefahrlos baden.
Das war jetzt nur als Scherz ins blaue getippt, weil solche Routingfehler durch Werksgelände tatsächlich schon vorgekommen sind. Keine Ahnung ob da was fehlt. Ich hatte nur mal eben in die Ecke geschaut und mich gewundert, wie nah man da doch anscheinend an das Zwischenlager kommt.
Sag mir lieber erstmal wo da überhaupt die Haltestelle getagged is oO
Außerdem… Ich bin keine Routing Software. Und ja es gibt Ausnahmen… Aber wieviele Straßen sind so gebaut? 1000, 2000? für den Großteil kann man nen Routing Algorthymus nehmen, der die Straßen vorgegeben hat und dann selbst berechnet wie er das ganze von Haltestelle zu Haltestelle zeichnen soll.
Bei solchen Sachen… Gut da muss man dann halt doch nur die einzelnen segmente in die Relation per Hand einfügen.
Hmm, ich sehe da keine verbesserte Übersichtlichkeit.
Der Grund für das Umsteigen auf PT-Relationen ist für mich ein ganz anderer und der hat garnichts mit stop_areas zu tun: Das alte System mit forward, backward und dem völlig anders definierten forward_stop und backward_stop war auch gut, aber für "nicht-ÖPNV-OSM"ler völlig ungenießbar. Mit dem konzeptionell völlig verschiedenen Gebrauch des Wortes “forward” in der “forward”-Role und der “forward_stop”-Role sind sogar erfahrene Mapper oft nicht klargekommen. So wurden die ÖPNV-Relationen immer mehr zum Spezialgebiet einiger weniger, die sich aber hauptsächlich mit Reparaturen der Änderungen anderer Mapper beschäftigen mussten. Die Routen im PT-Schema sind dagegen von jedem ohne wochenlanges Studium zu verstehen und es gibt inzwischen viele Mapper, die eine Straße splitten können ohne den dort laufenden ÖPNV kaputt zu machen.
Ich denke, die “stop:n” werden gewöhnlich richtig ausgewertet: als einfache “stop”. Die Nummer war immer nur als laufende Halt-Nummer innerhalb der Route gedacht und das war eine rein an Mapper gerichtete Information: Man konnte erstens so ausdrücken, dass da noch eine Haltestelle fehlt (wenn “stop:3” nicht vorkommt aber “stop:4”, dann fehlt da eine Haltestelle), zweitens dass eine Haltestelle da ist, aber man nicht weiss nach/vor welcher sie angefahren wird (“stop” ohne Nummer) und drittens war man nicht auf die Reihenfolge der Member angewiesen, die es in den Relationen ja nicht immer gab. “platform” kam erst als “stop:n” eigentlich schon tot war und “platform:n” ist m.E. eine wenig sinnvolle Komplettierung.
Ich rate jetzt einfach mal den Grund: Bei den ÖPNV-Relationen nach dem PT-Schema wird über ein anderes Segmentieren gesprochen. Hier wird ja jede Variante als eigene Relation dargestellt und viele Varianten unterscheiden sich nur in kleinen Teilen. Es gibt also große gemeinsame Stücke und diese gemeinsamen Stücke könnte man zu “Segmenten” zusammenfassen. Es geht also nicht um Segmente im Sinne von “Stücke einer Straße” – es geht um Segmente im Sinne von “gleiche Teilrouten”.
