| Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1855 is a reply to message #1854] |
Mon, 25 June 2018 13:29   |
Christian Rößiger
Messages: 61
Registered: March 2015
|
Member |
|
|
Dear Christian,
I understand that for a mapping of the temporal validity of the <state>
element the restrictions of the <operatingPeriod> seem quite complex.
However, the use of the 'bitmask' attribute is not mandatory. I could
therefore imagine a representation without using the bitmask:
<operatingPeriod id="opp01" timetablePeriodRef="ttp01">
<operatingDay operatingCode="0000000" />
<specialService type="include" startDate="2018-04-28"
endDate="2018-04-29"/>
</operatingPeriod>
I'm not sure if the <operatingDay> element can be omitted in this
example, since it describes an empty set. The railML Wiki does not
provide any hints in this context. For formal reasons, I still consider
it necessary to reference a <timetablePeriod>.
To clarify the content of your example once again:
2 restrictions are defined:
- 28.04.2018, 22.00 - 29.04.2018, 06.00 and
- 29.04.2018, 22.00 - 30.04.2018, 06.00
Many Greetings
Christian Rößiger
Am 22.06.2018 um 13:09 schrieb Christian Rahmig:
> Dear Christian,
> dear railML community,
>
> Am 19.06.2018 um 08:43 schrieb Christian Rößiger:
>> Hello Christian,
>>
>> Am 18.06.2018 um 13:42 schrieb Christian Rahmig:
>>> <timetable ...>
>>> <timetablePeriods>
>>> <timetablePeriod id="ttp01" startDate="2017-12-15"
>>> endDate="2018-12-14"/>
>>> </timetablePeriods>
>>> <operatingPeriods>
>>> <operatingPeriod id="opp01" startDate="2018-04-28"
>>> endDate="2018-04-29" bitmask="0000011" timetablePeriodRef="ttp01"/>
>>> </operatingPeriods>
>>> </timetable>
>>>
>>> Is that correct?
>>
>> Almost ;-) But: The length of the bitmask must correspond to the length
>> of the <timetablePeriod>, not that of the <operatingPeriod>.
>>
>> See: https://wiki.railml.org/index.php?title=TT:operatingPeriod, section
>> "constraints", attribute "bitmask"
>
> To be honest: this does not make any sense to me. Wouldn't it be better
> to just leave out the timetablePeriod and the bitmask? Maybe it is a
> better idea to model the time aspect for _infrastructure availability_
> independent from the timetable related <operatingPeriod>. Otherwise I
> see too many constraints that are not needed for the purpose of
> describing the time of closing e.g. a <track>.
>
> Any comments from the community?
>
> Best regards
> Christian
>
--
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
