OpenStreetMap Forum

Fabi2

Member

Registered: 2010-03-21

Posts: 1,093

Re: Das "leidige" Thema Public_transport...

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.

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.

---

Healthcare 2.0
Quotentroll für den Fortschritt

Keichi

Member

Registered: 2012-09-20

Posts: 64

Re: Das "leidige" Thema Public_transport...

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.

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.

Fabi2

Member

Registered: 2010-03-21

Posts: 1,093

Re: Das "leidige" Thema Public_transport...

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?

Last edited by Fabi2 (2012-09-21 19:56:48)

---

Healthcare 2.0
Quotentroll für den Fortschritt

geokyf

Member

Registered: 2012-07-27

Posts: 147

Re: Das "leidige" Thema Public_transport...

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.

Fabi2

Member

Registered: 2010-03-21

Posts: 1,093

Re: Das "leidige" Thema Public_transport...

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.

---

Healthcare 2.0
Quotentroll für den Fortschritt

geokyf

Member

Registered: 2012-07-27

Posts: 147

Re: Das "leidige" Thema Public_transport...

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.

Keichi

Member

Registered: 2012-09-20

Posts: 64

Re: Das "leidige" Thema Public_transport...

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?

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: Das "leidige" Thema Public_transport...

Hi,

Die stop_area soll einfach nur zur besseren Übersicht rein...

Hmm, ich sehe da keine verbesserte Übersichtlichkeit.

...sonst hätten wir wohl auch keinen wirklichen Grund für die PT Relation...

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.

... das es stop:number und platform:number gibt, leider werden die Daten aber nicht vom Renderer ausgewertet

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.

Weide

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: Das "leidige" Thema Public_transport...

Hi,

Auch das mit den Segmentieren was im Proposal diskutiert wirde verstehe ich nicht so ganz.

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".

Weide