Home » railML newsgroups » railML.infrastructure » Infrastructure, properties of OCPs
Infrastructure, properties of OCPs [message #198] Tue, 05 August 2008 17:12
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 313
Registered: August 2008
Senior Member
Hello,

I have some small whishes / recommondations on Infrastructure scheme, OCPs. May be in some cases I didn't realise how it is already possible so please give me a short hint.

Infrastructure.OCP.propOperational:
- eSigAvail
I guess this should mean "entry signal available" which in Britisch English would be "home signal available". But what really may be expressed could be what in German is said by the word "Zugfolgestelle". This has few to do with entry/home signals. A "Zugfolgestelle" can also be created by a starter or any other main signal, by a simple board/sign/marker (RETB-board, Trapeztafel, H-Tafel) or by any "referable" location spot. Since the corresponding German word "Zugmeldestelle" has obviously been paraphrased by "orderChangeable" also this "Zugfolgestelle" should be paraphrased anyhow. I would recommend something like "trainFollowingPossible".. And there should be a good annotation...

- orderChangeable
Annotation proposal: "whether the ocp allows change of train's order, e. g. has at least one point; German: Zugmeldestelle"

- type
Should be a set of (station[Bahnhof], crossover[Überleitstelle], junction[Abzweigstelle], block post[Blockstelle], blocking signal[Blocksignal]...)
Somewhere there should also be the possibility to say what kind of traffic an OCP allows. This could be a "none" or any of (passenger, freigt). From the combination of "(Operational)Type" and "KindOfTraffic" follows for example:
type=station, traffic=freight --> Güterbahnhof
type=station, traffic=none --> Betriebsbahnhof
type=none, traffic=passenger --> Haltepunkt

I am aware that these information can also be obtained from TrackElements ("Is there anywhere around a platform? Is there anywhere around a signal?") but hardly in all cases these detailed information are available and necessary. Also, takes a lot of work to scan all tracks which are "anywhere around", whatever that means.

If (type=station) or (orderChangeable=True) there should be the following optional properties:
- whether the OCP has home signals (proposal: homeSignalExisting:Boolean; Annotation:"whether the ocp has home signals / Einfahrsignale")
- whether the OCP has starter signals (proposal: starterExisting:Boolean; Annotation:"whether the ocp has starter signals / Ausfahrsignale")

Again, this is redundant to TrackElements, and in some seldom cases can be different for each track of a station. Therefore, it should be only a simplification for "rough usage" where detailed information is not available nor necessary. Anyway, if these information have to be found at the tracks only, we again would need a link from OCPs to lines/tracks.
- proposal: OCP gets additional attributes: either crossSectionIdRef or lineIdRef/trackIdRef/pos or both (better!)

(Trains should refer to OCPs, therefore OCPs always have to be defined if trains are defined. To get trains with a detailed infrastructure (tracks, elements), there must be a possibility to refer tracks from the OCPs..)

Thank you and regards to all listening,
Dirk.


--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
Previous Topic: Moving of "infrastructureVisualizations"
Next Topic: simple Infrastructure scheme usage as a base for Timetable reference
Goto Forum:
  


Current Time: Mon Oct 14 13:23:13 CEST 2024