Re: Ways to model temporal aspects [message #1732 is a reply to message #1688] |
Tue, 20 March 2018 14:37 |
christian.rahmig
Messages: 472 Registered: January 2016
|
Senior Member |
|
|
Dear Lucien,
thank you very much for your feedback and input for discussion since
there are no easy answers...
Am 11.01.2018 um 11:32 schrieb Lucien Weller:
> [...]
>
> 1) How to exactly model the validity periods of LNE2, LNE5,
> LNE6 and LNE7 ?
I assume "valid" means "valid for operation" or "usable".
> In my opinion there are to ways to do this
>
> Either with @validFrom @validTo of Element netElement it
> self:
>
> [...]
> Or with the subelement state:
>
> <netElement id="LNE2">
> ...
> <state intrinsicPosFrom="0" intrinsicPosTo="1"
> type="inOperation">
> <time>
> <period from="2018-01-01T00:00:00+01:00"
> to="2018-06-30T23:59:59+01:00"/>
> </time>
> </state>
> </netElement>
The first option results directly from the RTM. It is ideal to express
the time when a NetElement instance can be used (for operation). But it
has two drawbacks:
* It cannot be used to express other states, e.g. "under construction" *
It can be defined only once: there is no possibility to define a
NetElement that is valid before and after e.g. some construction blocking.
In order to cope with these drawbacks the <state> element has been
defined. It solves both drawbacks of the RTM model, but builds up some
redundancy to the pure information about validity stated with @validFrom
and @validTo.
My proposal for solution:
I would like to forward the topic to the RTM group and suggest to change
the attributes @validFrom and @validTo into repeatable elements.
Further, the <state> element shall be renamed into <infrastructureState>
and it shall be only used to model states that are not "inOperation". By
doing so, the information about "valid infrastructure" remains with the
RTM based datatypes and for all further (more detailed) states, the
<infrastructureState> remains.
Small example:
<netElement id="LNE8">
<valid from="2018-01-01" to="2018-06-29"/>
<valid from="2018-07-02" to="2018-12-31"/>
...
<infrastructureState type="underConstruction">
<time>
<period from="2018-06-30" to="2018-07-01"/>
</time>
</infrastructureState>
</netElement>
What do you think about that possible solution?
> 2) How to describe the relationship between LNE2 and
> LNE5/LNE6, to express replacement ?
>
> An other requirement we have, is to describe the replacement
> relationship between topological elements replacing each
> other. This is important, to know the position of an object
> after modification of network. Here I added a signal to
> illustrate this, which also can be repositioned by using a
> linear or geodetic reference system. But the problem arises
> also with historical values only having a reference to the
> topology when there where created (by example some measures
> of track state) which should be compared to corresponding
> new values created after transformation of network.
In previous alpha version of railML 3.1 I added a first concept of
change management where an element <change> was used to reference an
@oldEntity and a @newEntity. However, this was only a first draft and
e.g. does not solve the example with the new switch. More discussion is
needed here to come to a better solution, but since the railML 3.1 use
cases "Network Statement" and "Schematic Track Plan" are not that much
interested in these states (except "inOperation"), the topic has been
postponed to a future version of railML 3.
As a starter for the discussion I filed a ticket [1].
[1] https://trac.railml.org/ticket/326
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
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|