| train relation [message #303] |
Thu, 26 April 2012 20:46  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Hello Susanne and all others,
> [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.
"If no more information is given" means the very "rough" infrastructure
model of a historic graphic timetable where there is one vertical line for
a whole station but nothing more. Of course, nowadays one should have more
detailed information (here: length and place of platforms) but we should
not fix that into RailML.
In a way you could say that "midOfTrain" is to be used to describe a
intersection form rough to detailed infrastructure models: You do not know
the exact situation but you have to make an estimation and you have to
describe the estimation in RailML. With that problem, sometimes
"midOfTrain" is the most neutral estimation you can make.
So, whether to keep that enumeration value or not depends on where it is
used and whether we want to allow a kind of "estimated flabbiness" or
force exact usage.
Best regards,
Dirk.
|
|
|
|
| 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
|
|
|
|
| Re: train relation [message #366 is a reply to message #310] |
Sat, 22 September 2012 09:18 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Dear railML users,
> 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".
With the implementation of trac ticket [1] the type "tTrainRelation"
with the values 'headOfTrain', 'midOfTrain' and 'endOfTrain' has been
defined for railML 2.2. It is used for the attribute "trainRelation" in
element <speedChange> to refer to the part of the train from where on
the speed change is valid.
Normally, a speed restriction that is higher than the train's current
speed will be valid when the end of the train has passed the speed
change while a speed restriction that is lower than the train's current
speed will be valid already when the head of train passes the
speedChange. In order to cover all special cases, e.g. as described
above, the trainRelation attribute allows for all three possibilities.
[1] https://trac.assembla.com/railML/ticket/41
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Members
Search
Help
Login
Home
