| joined continue: "Platforms and ramps for railML 2.2" and "Haltetafel / stop post" [message #292 is a reply to message #286] |
Wed, 04 April 2012 19:40   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
....here we are again from the neighbouring thread.
This is the continuation of both the topics "Platforms and ramps for
railML 2.2" and "Haltetafel / stop post" as ordered by the overall "Lady
Of Common RailML".
> So I suggest defining a new ocsElement named <stopPost>. Like the other
> ocsElements, it is an optional element and it will be placed in a
> container <stopPosts>.:
I agree.
> 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.
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)
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).
- 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.
> - train length
> - axle count
> - wagon count
> - verbal definition (S-Bahn Berlin)
> Does anybody know, whether only one of the above constraints may be
> defined or also combinations of them occur?
In Germany, only a train length is allowed in nowadays. But there may be
axle count at older signs or in other countries.
We should allow combinations to ease future discussions...
> 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).
> ...but I think that we should keep both elements <stopPost> and
> <serviceSection> or <platform> since it provides us more flexibility in
> extending this first approach to the platform problem.
No objection.
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
