Home » railML newsgroups » railML.infrastructure » Platforms and ramps for railML 2.2
| Re: joined continue: "Platforms and ramps for railML 2.2" and "Haltetafel / stop post" [message #294 is a reply to message #292] |
Wed, 04 April 2012 23:42   |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hello Dirk,
>> Further attributes for describing the stop post may be optional:
>> - "serviceSectionRef" for referencing the service section, where the
>> stop post is situated.
>> - "stopPostType" for specifying the stop post element.
>
> I agree with your suggestion and also with Susanne's advice:
>
>> Please do not repeat the elements' name in the attribute. 'Type' is
>> often used for 'datatype'. Let's find a more concise term. Which
>> enumeration should be offered behind this attribute?
>
> I don't think that we should name it 'type' at all. We should give it
> only attributes for these properties which are really (physically)
> existing at the sign post itself. Any properties which rely to the
> platform rather then to the stop post should be written at the
> <serviceSection> or <platform> element.
I absolutely agree with your statement.
> The attributes of a stop post should be from my side:
> --> "id"
> --> "pos"
> --> "serviceSectionRef" (optional, see below)
> --> direction (at the track - up or down) (mandatory)
> --> additional conditions (this relies to Susannes train length, axle
> count, wagon count, verbal remark) (optional)
> --> 'sign code' or 'rule number' or so (this shall allow to define the
> 'Ne5' or 'So8' of DS/DV301 or something like that)
> --> valid for train categories (categoryRefs, none, one or more)
Still I do not fully understand the idea behind the additional
conditions "axle count", "wagon count" and "verbal remark" (cp. post in
subject "Haltetafel / stop post").
The sign code is important, but I would use the parameter "code" for it,
which already exists for any ocsElement.
> Concerning the attributes, we should ask us the questions:
> - Should it be possible to define a <stopPost> as 'virtual'? Virtual
> means that there is no real stop post sign but it is a place where one
> could or should stay (where trains have to stop). This may be important
> for the reference of a train to a <stopPost>: If a train has to stop at
> a platform where there is no <stopPost> (may be because the starter
> signal directly standing at the end or simply because somebody of DB
> Projektbau has forgotten to plan it) - what shall the <trainPart> in
> RailML do? My recommendation: Allow virtual <stopPosts> with an attribute
>
> --> "virtual" (Boolean).
That is an interesting idea. The question is if there physically exists
a "substitute" for the stop post, which can be used for stopping a
train. Since we always talk about infrastructure, I'd rather see a
physical element providing the function of a stop post instead of
defining virtual elements. However, we need to analyse this problem.
> - Do we want to include an attribute whether the <stopPost> is valid for
> shunting movements and/or trains? This would include the German "Ra10"
> into stop posts. In Germany, we do normally not think that a Ra10 is a
> Haltetafel but one could have the opinion that the word Halttafel does
> include "RangierHALTTAFEL" ;-). However, in other countries these
> "shunting limits" may be more naturally stop posts. I would recommend to
> include them, which brings us to an attribute
>
> --> "validForMovements" (enumeration: FreightTrains, PassengerTrains,
> AllTrains, Shunting, both?).
>
> (It is all 'Arbeitstitel' only.)
>
> The reason for "PassengerTrains" and "AllTrains" is: In Germany normally
> a H-Tafel is valid for passenger trains only except if there is no
> starter signal in the track where it is valid for all trains.
Another important idea that you are bringing up here. For clarification
we have to ask ourselves whether we in fact talk about a combination of
two different signs/signals just at the same position along the track or
about a certain feature of a stop post, which cannot be found in a
separate context.
>> Connected with the last two attributes, the following two questions
>> need to be answered:
>> 1. Does any stop post exist, which is not referenced to a service
>> section (or platform)?
>
> Yes, of course. There are stop posts in tracks w/o platform. In Germany
> at least they must be in main tracks which have no starter signal. (In
> these cases, the stop post replaces the starter signal, making it to a
> very important security technology element. For instance, the overlap
> starts at the stop post.)
>
> There may be also stop posts in tracks w/o platform but with starter if
> there is a Reisendenzugang over the track (leading to a platform at
> other tracks).
Since there are stop posts without any reference to a <platform> or
<serviceSection> element, the parameter "serviceSectionRef" can only be
optional as you already mentioned.
Best regards
---
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Current Time: Wed Apr 24 14:47:36 CEST 2024
|
Members
Search
Help
Login
Home
