| Re: train relation [message #310 is a reply to message #303] |
Sat, 16 June 2012 18:27   |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hello Dirk and everyone interested,
>> [train relation]
>>
>> What is a real use case for the enumeration value "midOfTrain"? Are
>> there any speed aspects that are valid since half of the train passed
>> its defined position?
>>
>> If it is not the case, we would suggest not to define it.
>
> There are some infrastructure elements which rely to that train
> relation. They are mostly "virtual" and possibly a little bit academic.
> May be you think about real infrastructure elements. Normally, real
> infrastructure elements do not need a "mid-of-train relation".
>
> However, an OCP is probably the most common example for an (virtual)
> infrastructure element which may rely to a mid-of-train relation. If no
> more information is given, you can only assume that "train passes OCP"
> or "train arrives at OCP" or "train departs from OCP" means that the mid
> of the train is exactly at the (virtual) OCP position. For that reasons,
> these virtual OCP positions are normally the (average) mid of the
> platforms.
In the macroscopic infrastructure model, where stations and their
platforms are modelled as OCPs and therefore defined in single points
along the track, also the train can be assumed to be modelled as a
moving point. Consequently, we do not know the part of the train being
related with the speedChange and the enumeration value "midOfTrain" can
be seen as a (virtual) default value.
So, in order to avoid empty entries, I agree with Dirk to define this
value "midOfTrain".
---
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Members
Search
Help
Login
Home
