4

Nee, ich bin schon über ein Jahr dabei.

Sagen wir es so: ca. 70% der innerstädtischen Haltestellen wurden durch mich erfasst und bei vielleicht der vorhandenen 10-15% fehl(t)en Daten wie die stop_positions etc., da mache ich dann natürlich die 8 Linien nach Möglichkeit dann alle nach neuem Schema.

Nein, das widerspricht sich nicht, es aus von allen Modellen aus meiner Sicht eben das ausgereifteste auch wenn es Definitionslücken hat, die anderen Modelle sind schmatisch noch schlechter, was heißen soll, daß man mit ihnen die Realität nur noch ungenauer abbilden kann, wenn man keine gleichbleibenden Linienverläufe hat.

Für die einzelne Richtungen/Varianten, würde ich durchaus type=route
und route=bus/… nehmen. Das ist genau ein klassisches Beispiel für eine
Routenrelation, sprich eine Wegführung über vorhandene Straßen/Wege.

Ja, das ist vergleichsweise aufwendig im Unterschied zu einer einfachen forward/backward-Relation pro Richtung, aber wenn der Bus bzw. das Fahrzeug nun mal eben so fährt, dann sollte man es auch wiedergeben können. Ja genau, das Schema ist auch prima um Fahrpläne zu erfassen, was mit einer der Gründe für die Benutzung dieses Schemas war. Das ist auch einfacher als man denkt und der Nutzer Netzwolf (http://www.netzwolf.info/kartografie/osm/bus_und_bahn/) hat es auch schon mit seinem eigenen, nicht gerade sehr übersichtlichen, Fahrplanerfassungsschema realisiert.

Pro Linienvariante braucht man nur folgende Sachen zu erfassen:

  1. Den Fahrzeitabstand zwischen den Haltestellen.
  2. Für eine Haltestelle der Linienvariante alle Abfahrtszeiten.
  3. Die Referenz, welche Haltestelle auf der Linie das ist.
  4. Zusätzlich die erste, die letzte Fahrt und bei Taktfahrplänen die mehrheitlich benutze Taktzeit.
  5. Die Ausnahmen und wochentags-/datumsbezogenen Sonderregelungen.

Aus 1.-3. und 5. kann man dann den Fahrplan berechnen und aus den Mindestangaben unter 1. und 4. auch dann noch eine gute Routenplanung machen, wenn der Fahrplan sich geringfügig geändert hat. Die Fahrzeiten zwischen den Haltestellen ändern sich ja nicht und die mittlere Wartezeit beim Umsteigen ist die Hälfte der Taktzeit des Gefährtes, auf das man da wartet.

Für 1.-4. läßt sich im Unterschied zu 5. auch schnell ein Taggingschema finden, ich hatte da mir schon ein Schmierzettel-Proposal gemacht.

Ist das schon aktiv in Benutzung und wenn ja wo? Dortmund sehe ich mir an.

Stimmt, das ist logisch.

Danke für den Hinweis, ich habe schon krampfhaft nach Städten gesucht, die das neue Schema benutzen. Ich werde mir Dortmind ansehen.

Gut, ich wußte nur nicht, ob der Rückschluß von der stop_position auf die Gesamthaltestelle über die API hinzubekommen ist, da das geht, reicht es ja auch so wie es in Dortmund gemacht wurde. Wichtig ist für die Linienvariante ja nur, wo das gefährt hält und wie der Halt heißt, bekommt man über die Haltestellenrelation heraus. Das z.B. eine “normale” Haltestelle aus zwei Haltepunkten mit entsprechenden Schildern/Häuschen besteht, ist doch korrekt und für den Nutzer ist ja nur entscheidend, wo denn an Haltestelle X jetzt genau sein Gefährt abfährt. Das da evtl. dann noch die Haltestellenaustattung auf der Karte angezeigt wird spielt modelltechnisch keine Rolle und der die Anwendung benutzende Mensch sieht ja dann das da gleich neben dem Abfahrtspunkt noch eine Häuschen mit Bank und Abfalleimer ist.

Was ist denn bitte eine Alternativroute? Nach deiner Auffassung muß man ja jede Route für sich betrachten, da sich sich ja zumindest in der Streckenführung und den Halten, wenngleich auch nicht immer in der Bennennung unterscheiden, sind es ja damit auch eigenständige Routen. Alternate=yes/no ist aus dieser Sicht nur sinnvoll, wenn die Gesamtlinie auch eine Route ist, sonst muß man da ja nicht extra unterscheiden.