Home » railML newsgroups » railml.infrastructure » Mapping of availability periods of the infrastructure by TT:operatingPeriod
Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1730] Mon, 19 March 2018 10:59 Go to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 1
Registered: March 2018
Junior Member
English Summary: The railML.org Timetable Developers Group is currently
working on the question of how temporary restrictions of the topology
could be mapped in railML 2.4, whereby these restrictions should also
only affect parts of operating days. The background to this is a request
as to how slow speeding sections or line closures could be mapped, which
are only to apply at certain times of the day. For example, during a
track maintenance phase only at night.
In principle, such a mapping could take place via <states> of <tracks>
in the infrastructure. Here you can specify an operatingPeriodRef to set
a time limit. Unfortunately, however, not yet limited to parts of a day
of operation.

In the Timetable developer group 2 approaches were considered how such a
temporal limitation could be modeled. Two PDF examples in German are
available for discussion in German or English.


Hallo,

die railML.org Timetable-Entwickler-Gruppe beschäftigt sich derzeit u.
a. mit der Frage, wie zeitlich begrenzte Einschränkungen der Topologie
in railML 2.4 abgebildet werden könnten, wobei diese Einschränkungen
auch nur Teile von Betriebstagen betreffen können sollen. Hintergrund
ist eine Anfrage, wie Langsamfahrstellen oder Streckensperrungen
abgebildet werden könnten, die lediglich zu bestimmten Tageszeiten
gelten sollen. Also etwa während einer Bauphase nur nachts.

Prinzipiell könnte eine solche Abbildung über <states> der <tracks> in
der Infrastruktur erfolgen. Hier kann man unter Angabe einer
operatingPeriodRef eine zeitliche Einschränkung vornehmen. Leider aber
noch nicht beschränkt auf Teile eines Betriebstags.

In der Timetable Entwicklergruppe wurden 2 Ansätze betrachtet, wie eine
solche, im Idealfall sekundengenaue, zeitliche Einschränkung modelliert
werden könnte.

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

Was ist die Meinung der Community? Gibt es noch andere Ansätze, die uns
nicht eingefallen sind?

Best regards / Freundliche Grüße,

Milan

Milan Wölke
Dipl.-Inf. (FH)
Technischer Projektleiter

PSI TransCom GmbH
Dircksenstraße 42-44
10178 Berlin
Deutschland

www.psitranscom.de
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 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 26
Registered: March 2015
Junior 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
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1754 is a reply to message #1752] Mon, 09 April 2018 12:25 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 42
Registered: November 2013
Location: Hanover, Germany
Member
Dear all,

this topic has been posted in the forum in order to obtain feedback from the community. However, there has been no feedback so far. Please provide this feedback as the next steps for an implementation in railML 2.4 would need to take place within the next two weeks.
Please let us know if
1. you prefer a specific scenario for your use case and why
2. both scenarios would work for your use cases
3. this does not apply for your use cases and you have no preferences

Best regards,

Philip Wobst
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1756 is a reply to message #1754] Mon, 09 April 2018 16:12 Go to previous messageGo to next message
seybold is currently offline  seybold
Messages: 1
Registered: February 2016
Junior Member
My preference is also no1 because
- it seems cleaner
- there is no additional dependencies from infrastructure to timetable schema
- immediate availability is not an issue for me

Best regards
Bernhard Seybold
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1761 is a reply to message #1756] Fri, 13 April 2018 11:24 Go to previous messageGo to next message
Heribert Neu is currently offline  Heribert Neu
Messages: 7
Registered: January 2018
Junior Member
Hello,

The first solution has the advantage that it leaves the operating period element unchanged and thus also the concept of defining the operating days remains clear and simple.
From SBB's point of view, it would be worth considering defining the lock periods outside the IS subschema in RailML 3 with references to the IS elements. The following points would argue in favour of this:
1. locking periods come from operative work. Maintenance and infrastructure planning are separate departments and their data is maintained in separate systems.
2. With the desired possibility of referencing external data (especially for IS data), you could also define blocking periods without also transferring the IS elements.

Best regards
Heribert Neu

SBB AG
Informatik
Haslerstrasse 30, CH-3000 Bern 65
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1762 is a reply to message #1761] Fri, 13 April 2018 18:38 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 12
Registered: February 2017
Junior Member
I agree with the previous posters that the first solution is the preferable one. However, I would rename @validToDayOffset to @endDay or @endDayOffset, to associate it closer with @endTime (and more similar to e.g. @arrival and @arrivalDay in TT). The proposed name sounds more like a truncation of the bitMask of the operatingPeriod.

I also agree with Heribert Neu that ideally these unavailable periods should be defined outside the IS.

There is one use case that this proposal does not address, which is to designate a part of the infrastructure as closed from a given date and time, or to include infrastructure which is not yet in use with an "available from" date. If this can be defined elsewhere, please let me know. If not, should we include a @fromDate and @toDate in the <state> as well, or use another element to separate this use case from the operational one?

Best regards
Thomas Nygreen
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1771 is a reply to message #1754] Mon, 23 April 2018 14:23 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 163
Registered: January 2016
Senior Member
Dear all,

I created a Trac ticket [1] to summarize the current state of discussion
and proposed solution as agreed on in Berlin last week.

[1] https://trac.railml.org/ticket/329

Best regards
Christian

Am 09.04.2018 um 12:25 schrieb Philip Wobst:
> Dear all,
>
> this topic has been posted in the forum in order to obtain
> feedback from the community. However, there has been no
> feedback so far. Please provide this feedback as the next
> steps for an implementation in railML 2.4 would need to take
> place within the next two weeks.
> Please let us know if 1. you prefer a specific scenario for your use
> case and why
> 2. both scenarios would work for your use cases
> 3. this does not apply for your use cases and you have no
> preferences
>
> Best regards,
>
> Philip Wobst


--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1772 is a reply to message #1754] Mon, 23 April 2018 14:51 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 163
Registered: January 2016
Senior Member
Dear all,

may I briefly summarize the solution that we agreed on in Berlin last
week with a short example:

<infrastructure ...>
<track ...>
<states>
<state disabled="true" operatingPeriodRef="opp01"
startTime="22:00:00" endTime="06:00:00" endDayOffset="1"/>
</states>
...
</track>
</infrastructure>

<timetable ...>
<operatingPeriods>
<operatingPeriod id="opp01" startDate="2018-04-28"
endDate="2018-04-29"/>
</operatingPeriods>
</timetable>

This example describes the (non-repeating) closing of the track from
Saturday, 10 pm, to Sunday, 6 am.

Any comments from your side?

Best regards
Christian

Am 09.04.2018 um 12:25 schrieb Philip Wobst:
> Dear all,
>
> this topic has been posted in the forum in order to obtain
> feedback from the community. However, there has been no
> feedback so far. Please provide this feedback as the next
> steps for an implementation in railML 2.4 would need to take
> place within the next two weeks.
> Please let us know if 1. you prefer a specific scenario for your use
> case and why
> 2. both scenarios would work for your use cases
> 3. this does not apply for your use cases and you have no
> preferences
>
> Best regards,
>
> Philip Wobst


--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1776 is a reply to message #1772] Sun, 29 April 2018 22:14 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 26
Registered: March 2015
Junior Member
Hello Christian,

I did not take part in the meeting in Berlin, but your example looks
understandable to me. However, I have 2 comments on using the
<operatingPeriod>:

- The attributes startDate and endDate only define the validity period
of the <operatingPeriod>, i.e. for which period the <operatingPeriod>
contains data. The actual days on which an activity takes place (in your
example the non-availability) must be defined using the bitMask attribut
and / or the <operatingDay> / <specialService> elements.

- According to railML-Wiki the attributes startDate / endDate are used
to limit the validity of a <operatingPeriod> compared to its
<timetablePeriod>, i.e. if startDate / endDate is used for a
<operatingPeriod>, a suitable <timetablePeriod> should also be given for
this <operatingPeriod>.

Best regards
Christian Rößiger

Am 23.04.2018 um 14:51 schrieb Christian Rahmig:
> Dear all,
>
> may I briefly summarize the solution that we agreed on in Berlin last
> week with a short example:
>
> <infrastructure ...>
>   <track ...>
>     <states>
>       <state disabled="true" operatingPeriodRef="opp01"
> startTime="22:00:00" endTime="06:00:00" endDayOffset="1"/>
>     </states>
>     ...
>   </track>
> </infrastructure>
>
> <timetable ...>
>   <operatingPeriods>
>     <operatingPeriod id="opp01" startDate="2018-04-28"
> endDate="2018-04-29"/>
>   </operatingPeriods>
> </timetable>
>
> This example describes the (non-repeating) closing of the track from
> Saturday, 10 pm, to Sunday, 6 am.
>
> Any comments from your side?
>
> 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
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1778 is a reply to message #1776] Mon, 30 April 2018 14:31 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 12
Registered: February 2017
Junior Member
Christian Rößiger wrote on Sun, 29 April 2018 22:14

- According to railML-Wiki the attributes startDate / endDate are used
to limit the validity of a <operatingPeriod> compared to its
<timetablePeriod>, i.e. if startDate / endDate is used for a
<operatingPeriod>, a suitable <timetablePeriod> should also be given for
this <operatingPeriod>.


This is noted as a requirement on the wiki page for timetablePeriod[1]:

A railML file may but needs not necessarily to have a timetable period. A railML file may also have more than one timetable period but each train part (and therefore also each train) can refer to only one timetable period.

railML files without timetable period do either not have an element <timetablePeriod> at all or only elements <timetablePeriod> without startDate and endDate. If there is no timetable period defined the elements <operatingPeriod> must also not have attributes startDate, endDate and bitMask and must also not have sub-elements specialService.

startDate and endDate may be used together only, so there are no "open" periods allowed. The numerical difference of the attributes startDate and endDate defines the length of the attribute bitMask of the elements <operatingPeriod> (= startDate - endDate + 1).


[1] https://wiki.railml.org/index.php?title=TT:timetablePeriod

Best regards
Thomas Nygreen
Meanings of "disabled" (Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod) [message #1782 is a reply to message #1772] Thu, 03 May 2018 00:11 Go to previous messageGo to next message
Tobias Bregulla is currently offline  Tobias Bregulla
Messages: 15
Registered: June 2017
Junior Member
- German version below -

Dear Christian, dear railML community!

For the next version of our infrastructure data aggregator for railways
(project name VIA; publicly available at http://via.bahnkonzept.de/) we
would also like to include the opening hours of lines and operating
points of a railway network. Again we would like to use railML as input
and output format.

Background: Many lines or operating stations - especially with older
technology and local staff - are not available 24 hours a day and 365
days a year, but only if scheduled and long-term train services are
planned. In order to be able to run trains even at short notice, the
opening hours of lines and operating points of a railway network must be
known.

Therefore, we would like to urgently suggest to clarify at least the
meaning of this property "disabled" in railML (see below) or to allow
several properties. A switch, operating point or signal can be switched
on, but not usable (no staff on site) or switched off and therefore not
usable (important for counting the operating hours, for example). Which
of the two states represents the "disabled" property and how can it be
distinguished?

Best regards,

Tobias Bregulla and the whole Bahnkonzept team

- German version -

Für die nächste Version unseres Infrastrukturdaten-Aggregators für
Eisenbahnen (Projektname VIA; öffentlich verfügbar unter
http://via.bahnkonzept.de/) möchten wir auch wieder die Öffnungszeiten
von Strecken und Betriebsstellen eines Eisenbahnnetzes einbinden. Auch
dabei möchten wir natürlich wieder auf railML als Eingabe- und
Ausgabeformat setzen.

Hintergrund: Viele Strecken oder Betriebsstellen – vor allem mit älterer
Technik und Personal vor Ort – sind nicht 24 Stunden am Tag und 365 Tage
im Jahr verfügbar, sondern nur, wenn planmäßig und längerfristig
Zugverkehr vorgesehen ist. Um auch kurzfristig Züge verkehren lassen zu
können, müssen die Öffnungszeiten von Strecken und Betriebsstellen eines
Eisenbahnnetzes bekannt sein.

Von daher möchten wir dringend anregen, wenigstens die Bedeutung dieser
Eigenschaft "disabled" in railML klarzustellen oder mehrere
Eigenschaften zuzulassen. So kann eine Weiche, Betriebsstelle oder
Signal zwar eingeschaltet, aber nicht benutzbar (kein Personal vor Ort)
sein oder auch ausgeschaltet und damit nicht benutzbar (wichtig zum
Beispiel für eine Zählung der Betriebsstunden). Welche der beiden
Zustände stellt die Eigenschaft "disabled" dar und wie kann es
unterschieden werden?

(Gegenwärtiger) Link zu den Stationsöffnungszeiten der DB Netz:
https://fahrweg.dbnetze.com/fahrweg-de/kunden/betrieb/dienst ruhen_und_ausschaltzeiten-1392400

Am 23.04.2018 um 14:51 schrieb Christian Rahmig:
> <infrastructure ...>
>   <track ...>
>     <states>
>       <state disabled="true" operatingPeriodRef="opp01"
> startTime="22:00:00" endTime="06:00:00" endDayOffset="1"/>
>     </states>
>     ...
>   </track>
> </infrastructure>
>
>
> This example describes the (non-repeating) closing of the track from
> Saturday, 10 pm, to Sunday, 6 am.
Re: Meanings of "disabled" (Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod) [message #1802 is a reply to message #1782] Wed, 23 May 2018 09:10 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 26
Registered: March 2015
Junior Member
Dear Tobias,

since the <state> element is located in the <infrastructure> domain of
railML, I assume that it was originally intended to indicate
restrictions due to infrastructure work or not yet / no longer available
infrastructure. I have assumed, however, that the same means can also be
used to map infrastructure elements that are "operationally" closed. For
this reason, periodically recurring periods are also planned for this
element. The gradation of 'disabled' would then have to be derived from
the type of source of the railML data or from the usecase.
However, the purpose of the disabled attribute is also unclear to me. If
you assume that an infrastructure element without <state> element is
always available, you can only define restrictions with the <state>
element, i.e. it only makes sense to use "disabled=true". However, if
the infrastructure is not available by default, only "disabled=false"
may be used. The attribute "disabled" is therefore completely
unnecessary in this form.
I therefore take a very positive view of proposals for a more
comprehensible implementation.

Kind 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
Re: Meanings of "disabled" (Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod) [message #1843 is a reply to message #1802] Mon, 18 June 2018 09:35 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 163
Registered: January 2016
Senior Member
Dear Christian and Tobias,

Am 23.05.2018 um 09:10 schrieb Christian Rößiger:
> [...]
> However, the purpose of the disabled attribute is also unclear to me. If
> you assume that an infrastructure element without <state> element is
> always available, you can only define restrictions with the <state>
> element, i.e. it only makes sense to use "disabled=true". However, if
> the infrastructure is not available by default, only "disabled=false"
> may be used. The attribute "disabled" is therefore completely
> unnecessary in this form.
> I therefore take a very positive view of proposals for a more
> comprehensible implementation.

I had a look at the implementation in railML 2.3 and my understanding of
the topic is the following one:

* The attribue <state>@disabled is used to mark an infrastructure
element not being available for operation (no matter for which reason)
* In practical usage, we assume that modelled infrastructure is
available for operation --> "default value" of <state>@disabled would be
"false".
* The attribute <state>@disabled is used to explicitly mark
infrastructure elements not being available (@disabled="true").

For railML 2.x I suggest to keep this implementation except there are
users who urgently need to have some changes implemented related to the
<state>.

My proposal for railML 3.x would be to change the <state> modelling:
Instead of the boolean parameter @disabled I prefer having an
enumeration value with different types of states. For example,
infrastructure element can be
* planned
* underConstruction
* inOperation
* removed
* disabled

Do you have any further states in mind?

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1845 is a reply to message #1776] Mon, 18 June 2018 13:42 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 163
Registered: January 2016
Senior Member
Hello Christian,

may I briefly summarize your findings in an updated version of the example:

<infrastructure ...>
<track ...>
<states>
<state disabled="true" operatingPeriodRef="opp01"
startTime="22:00:00" endTime="06:00:00" endDayOffset="1"/>
</states>
...
</track>
</infrastructure>

<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?

Best regards

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org

Am 29.04.2018 um 22:14 schrieb Christian Rößiger:
> [...]
> - The attributes startDate and endDate only define the validity period
> of the <operatingPeriod>, i.e. for which period the <operatingPeriod>
> contains data. The actual days on which an activity takes place (in your
> example the non-availability) must be defined using the bitMask attribut
> and / or the <operatingDay> / <specialService> elements.
>
> - According to railML-Wiki the attributes startDate / endDate are used
> to limit the validity of a <operatingPeriod> compared to its
> <timetablePeriod>, i.e. if startDate / endDate is used for a
> <operatingPeriod>, a suitable <timetablePeriod> should also be given for
> this <operatingPeriod>.
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1849 is a reply to message #1845] Tue, 19 June 2018 08:43 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 26
Registered: March 2015
Junior Member
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"

Many Greetings
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
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1854 is a reply to message #1849] Fri, 22 June 2018 13:09 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 163
Registered: January 2016
Senior Member
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

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
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 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 26
Registered: March 2015
Junior 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
Re: Mapping of availability periods of the infrastructure by TT:operatingPeriod [message #1872 is a reply to message #1855] Mon, 09 July 2018 14:28 Go to previous message
Ferri Leberl is currently offline  Ferri Leberl
Messages: 17
Registered: September 2016
Junior Member
Dear All,

Changes from https://trac.railml.org/changeset/805/railML documented in the Wiki.

The changes are visible on https://wiki.railml.org/index.php?title=IS:state_states_trac k&oldid=8463 but temporarily hidden in the current version https://wiki.railml.org/index.php?title=IS:state_states_trac k&oldid=8464 until https://wiki.railml.org/index.php?title=Template:Current is switched.

Please let me know, whether the changes are correct.

Yours, Ferri
Previous Topic: etcsTrainCategory
Next Topic: Signal characteristics (de: Signaleigenschaften)
Goto Forum:
  


Current Time: Thu Sep 20 23:51:19 CEST 2018