Home » railML newsgroups » railML.infrastructure » Haltetafel / stop post
| Re: Haltetafel / stop post [message #421 is a reply to message #385] |
Thu, 08 November 2012 12:16   |
thomas.kauer
Messages: 15
Registered: January 2004
|
Junior Member |
|
|
Dear Christian, dear Dirk
at the SBB we work most time with an absolut "H" independt of train length
or with number of units where the length refers to the usualy used
vehicle-type in the region (but this value is not indicated). There are
also AxleCount and Length ("m") real stop posts. They all indicate where
the train header has to stop.
But they are normaly not used as min/max - if you get a 100m and a 200m
stop post, a train of 150m has to stop in the middle.
In different programms there are also virtual stop post in use. They can
be marked with the enumarations below (front/middle/end) for the same
reasons as discussed. There are no real stop posts but there are rules for
the station that tell where the train has to stop in that station.
There are also situations where on real stop post is valid for the track
on both sides - in this case there will be added an virtual one in the
same place but with position on the other track.
Special problems with stop posts in ETCS are not yet fixed as far as I
know.
Best regards
Thomas
Dirk Bräuer wrote:
>
> Dear Christian,
>
> the summary of attributes/parameters for <stopPost> sounds good. Some
> short notes:
>
> 1) I think we need one more attribute/parameter defining the relation of
> the stop post to the train. (There were earlier discussions about that
> feature.) It should be something with the enumerations "frontOfTrain" /
> "mittleOfTrain" / "endOfTrain":
>
> Most "normal" stop posts we know (from Germany) are valid for the front of
> the train and are non-virtual. But this is not always the case. For
> instance in Czech Republic, there are virtual stop posts valid for the end
> of the train. The virtual stop post stands at the beginning of the
> platform because the stairs/elevators are at the beginning of the
> platform. This virtual stop post is valid for the end of the train, which
> means that the train should not move further forward that that its last
> door is at the rear end (=beginning) of the platform. This is to avoid an
> unnecessary long walk for the passengers.
>
> Such virtual stop posts are programmed in the Czech "black boxes" (ATO),
> and they are therefor "really" existing in software (in practice).
>
> It is also a matter of some national ETCS instances but (unfortunately, in
> my opinion) not very common in Germany due to the "relying on old INDUSI
> philosophy". But that should not mean that we forget or ignore it in
> RailML.
>
> 2) Concerning the attributes trainLength, axleCount, wagonCount I would
> prefer a clarification of the relation: maxAxleCount, maxTrainLength,
> maxWagonCount. Theoretically you could then also add the other boundaries:
> minAxleCount, minTrainLength, minWagonCount but they would not have
> equivalence in practice as far as I know - but again: We should not rely
> too much at German experience but in case of doubt rather be a little bit
> more theoretical.
>
> 3) Concerning the attribute "validForMovements" is should be possible to
> enumerate more than one value.
>
> Would be nice if you could consider these notes before releasing 2.2.
>
> Thank you,
> Best regards,
> Dirk.
>
>
--
----== posted via PHP Headliner ==----
|
|
|
|
Current Time: Wed May 08 21:53:12 CEST 2024
|
Members
Search
Help
Login
Home
