Skip to content
michaz edited this page Mar 18, 2015 · 6 revisions

Zwei Möglichkeiten zum Konvertieren von ÖV-Stops: (wie üblich)

Entweder der OSM-Node erzeugt die StopFacility. Die muss an einem Link sein, und dieser Link kann eigentlich nur eine Schleife sein, die von diesem Node zu diesem Node geht. Die Facility und die Schleife könnten unabhängig von Route Relations erzeugt werden. Es gibt die Facility nur einmal.

Oder die Route Relation erzeugt die Facilities. Die Facilities sind dann Route-Spezifisch. Es muss nicht am Netzwerk herumgebastelt werden (d.h. Editieren der Transit-Gegenstände verändert das Netz nicht). Problem an der Einfahrt (an welchen Link kommt der erste Stop?). Wenn wir dann einen neuen Link erzeugen würden, wäre der Vorteil nicht mehr so richtig da.

Kai: Die Koordinaten, die in der StopFacility stehen, sind da, wo der Nutzer einsteigt.

Wir wollen zwei Möglichkeiten unterstützen: *Wir haben den Fahrweg in OSM, und er stimmt auch. *Wir haben keinen Fahweg in OSM, oder er stimmt nicht / ist nicht konsistent.

Gesetzt ist, dass wir das bestehende TransitSchedule-Format auch editieren können wollen. Die StopFacilities werden "platform"-nodes. Für das linkRef-Attribut der StopFacility gibt es keine naheliegende Art, das ins OSM-Schema zu übersetzen. Dafür denken wir uns eine eigene Relation aus.

Der Rest ist klar: die route-Relation von OSM beinhaltet die Platform-Nodes und die Links für den Fahrweg.

Es gilt das offiziell empfohlene OSM Schema


UPDATE 14.01.2015

Für eingelesene / für MATSim erstellte Haltestellen werden wie folgt definiert: TransitStopFacilities entsprechen den Nodes mit Tag "public_transport=platform" Der Knoten mit dem Tag "public_transport=stop_position", der die Halteposition des Fahrzeugs definiert, gibt den Endknoten der Kante an, über die die Haltestelle erreicht wird.

Für jede so definierte Haltestelle gibt es eine Relation, Diese muss die Tags

  • "matsim=stop_relation",
  • "id= ..." sowie
  • "name= ..." beinhalten. Des Weiteren soll diese Relation in der Regel drei Elemente beinhalten:
  • den Knoten "platform" mit der Rolle "platform"- die eigentliche Position der Facility
  • den Knoten "stop_position" mit der Rolle "stop" - Endknoten des zugehörigen Links
  • den Way mit der Rolle "link", der den verknüpften Link darstellt

Um diese Informationen zusammenzuhalten wurde eine Helferklasse definiert (OsmConvertDefaults.Stop), die die drei Elemente der Relation innerhalb eines Objektes zusammenfasst. Für jede Haltestelle wird ein solches Objekt erzeugt und mit einer Id gemapt und im aktuellen Layer "gespeichert".


UPDATE 23.01.2015

Das Konvertieren sowie Editieren einzelner Stops ist nun unabhängig von den Routen und Linien möglich.

TO DO:

  • Anpassen des Converters sowie des Listeners für das Handhaben von Linien und Routen im neuen Schema
Clone this wiki locally