fromLoc, toLoc, tripPurpose, dayType, hourOfDay, tripTime, tripFare, nChanges
Attribute, die die Relation spezifizieren:
fromLoc: ID des Startortes. Z.B. eine Zonen-ID.
toLoc: ID des Zielortes.
tripPurpose: Bezeichnung des Reisezweckes. Zeile wird für jeden Reisezweck wiederholt.
dayType: Typ des Tages (Wochentag, Sonntag, …). Zeile wird für jeden Tagestyp wiederholt.
hourOfDay: Tagesstunde. Zeile wird für jede Tagesstunde wiederholt. Die Verflechtungsmatrix aus der VVP 2030 liegt nur in der Dimension „Personenfahrten/Jahr“ vor. Die Aufgliederung nach Tagestypen und Tagesstunden erfolgt nur in den sektoralen Matrizen für den Verkehrsträger Straße.
Attribute der Relation:
tripTime: Reisezeit; hierbei handelt es sich um Tür-zu-Tür-Reisezeiten. Die Rechenregeln zur Ermittlung der Tür-zu-Tür-Reisezeiten werden zurzeit noch im Detail mit den Bearbeitern der Lose 3, 4 und 5 der VVP 2030 abgestimmt.
tripFare: Reisepreis. Kommentare (Mann et al):
* tatsächlicher Preis ist aufgrund der Angebotsstruktur der DB AG mit einer Vielzahl von Sonder- bzw. Sparpreisen nicht ermittelbar. Stattdessen werden mittlere Preise für die Stufen A (ICE oder vergleichbare Produkte), B (IC/EC oder vergleichbare Produkte) und C (SPNV) angesetzt. Werdenin einer Relation sinnvoll nutzbare Routen mit unterschiedlichen Preisstufen angeboten, erfolgt eine Mittelung mit der Nutzungswahrscheinlichkeit der betreffenden Routen.
* solange der Preis nicht in den privaten Nutzen eingeht, ist dieses Attribut gar nicht notwendig, da es dann einen reinen Transfer darstellen würde.
nChanges: Anzahl der Umsteigevorgänge. Kommentare (Mann et al):
* Infolge von Neu- und Ausbaumaßnahmen beim Verkehrsträger Eisenbahn können Änderungen bei den Linienführungen und damit auch bei den Umsteigehäufigkeiten entstehen. Fraglichh ist allerdings, ob diese in der NKA monetär bewertet werden sollen (und wenn ja, mit welchem Satz). Ich persönlich bin der Auffassung, dass der Änderung von Umsteigehäufigkeiten wie schon im derzeitigen Bewertungsverfahren kein geldwerter volkswirtschaftlicher Nutzen beigemessen werden sollte.
Grundsätzlicher Kommentar (Mann):
Die oben skizzierte Schnittstelle zwischen Prognose und Bewertung erscheint mir wenig zweckmäßig. Neben der Gliederung nach Relationen müsste noch eine weitere Untergliederung nach den in der jeweiligen Relation genutzten Routen erfolgen. Der Aufwand für den Transfer dieses „Datenfriedhofs“ erscheint mir bei weitem zu aufwändig. Die Aggregation der relationsbezogenen Daten zu den für die Bewertung benötigten Mengengerüsten sollte daher bei der Verkehrsprognose angesiedelt werden, da die betreffenden Arbeitsschritte hier ohnehin durchzuführen sind. Folgende aggregierte Größen werden (vorbehaltlich der Ergebnisse des Sondergutachtens „Reisezeit“) für die Bewertung von Reisezeitersparnissen benötigt:
* Reisezeitdifferenzen (Tsd. Stunden je Jahr) im SPV unterschieden nach Fahrtzwecken und ggf. Klassen von Einzelreisezeitdifferenzen (für den Fall, dass kleine Einzelreise-zeitdifferenzen mit einem geringeren Kostensatz bewertet werden sollen; zu klären in dem gesonderten Forschungsvorhaben zu den Zeitkostensätzen)
* Mindestanforderung bei der Differenzierung nach Fahrtzwecken: Geschäft und sonstige Fahrtzwecke, weitere Unterteilung nach den Fahrtzwecken Arbeit, Ausbildung, Einkauf / Erledigung, Urlaubsverkehr und sonstiger Privatverkehr möglich
* für die Anwendung der „rule of the half“ Ermittlung der Reisezeitdifferenzen bezogen auf das Nachfrageniveau des Bezugsfalles und das des Planfalles
* für den Fall der Bewertung von Transportzeitdifferenzen im SGV zum SPV analoge Angaben differenziert nach Gütergruppen/Lkw-Typen anstelle von Fahrtzwecken
Sollte der Verzicht auf die Bewertung der Salden der Umsteigehäufigkeiten nicht konsensfähig sein, wäre eine entsprechende Aufbereitung analog zu den Reisezeiten erforderlich. Weiterhin sollte in der Arbeitsgemeinschaft entschieden werden, ob die „rule of the half“ Grundlage unseres Grobkonzeptes werden soll (wäre mein Plädoyer). Anderenfalls wäre eine Alternative in operationaler Form zu entwerfen.
