| Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1752 is a reply to message #1730] |
Mon, 09 April 2018 10:59   |
Christian Rößiger
Messages: 61
Registered: March 2015
|
Member |
|
|
Hello,
Am 19.03.2018 um 10:59 schrieb Milan Wölke:
> 1) Anpassung des Tags <state> des <track> und damit erst mit railML 2.4
> verfügbar.
> Beschreibung und Beispiel:
> http://forum.railml.org/userfiles/2018-02-14_irfp_gleissperr ungen-zeitlicher-einschraenkung-railml24.pdf
>
>
> 2) Ohne Anpassung des Schema, durch Nutzung des Tags <specialService>
> der <operatingPeriod>, und damit bereits mit railML 2.3 nutzbar.
> Beschreibung und Beispiel:
> http://forum.railml.org/userfiles/2018-02-22_psi_abbildung-z eitraum-operatingperiod-railml2x.pdf
We prefer solution no. 1 for the following reasons:
- Solution No. 2 requires very special information when specifying
periodic availabilities (case 4), or requires renouncement of bit masks.
- It is not clear how an illustration of an availability with undefined
<timetablePeriod> (only regular traffic days) can look like in solution
No. 2.
- The task of the <operatingPeriod> is, in our view, to define on which
days an event takes place. The start time and the duration of the event
is defined, for example, for a <trainPart> outside the
<operatingPeriod>. This should be the case for all uses of the
<operatingPeriod> for the sake of consistency. Therefore, the
<operatingPeriod> should contain no information at all on times, but
only on days.
- Solution No. 1 allows the use of all aspects of the <operatingPeriod>
(bitmaps, undefined <timetablePeriod>, only regular traffic days, etc.)
for the mapping of availabilities and enables a uniform mapping of all
use cases.
Best regards
Christian Rößiger
--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
|
|
|
|
Members
Search
Help
Login
Home
