| New reflected thoughts towards infrastructure extension proposal operational properties of an OCP [message #1625 is a reply to message #1457] |
Fri, 14 July 2017 09:46  |
Torben Brand
Messages: 156
Registered: March 2016
|
Senior Member |
|
|
Some ocps have areas (usually stations) as others are point based (usually stopping point). But it is up to the user to define this. They can do this through referencing tracks under the existing sub element <ocp/propEquipment/trackRef>.
See aIso discussion under "line section": An alternative to lineSection type "openSection" (NO:"linjen",DE:"freihe Strecke" railML wiki "open track", term to be fixed), could be to add a new <propOperationa @operationalType="openSection". I do not recomended this, as the open section is not an ocp and ocps can overlap the open section. Thus a solution in lineSection is recomended. What do you think?
In Norway we also have ocp's on main signals in large stations that have alternative entry routes from the same neighbour ocp into the station. This is a sort of mesoscopic modelling where there is missing a microscopic route allocation defining the path into the station. Thus I suggest to add an new value for ocp @operationalType:"other:mainSignal"
I also like to suggest to add a macroscopic attribute to all ocp's a @timingPoint [absPos mileage].
Today the timing point can only be defined in an ocp microscopically on the track level as a <crossSection> which have to be defined per track. For macroscopic models the new approach would be simpler. Also historically an ocp (in Norway) has an absPos mileage timing point, where the local dispatcher used to sit. Today's remote controlled stations have no longer local dispatchers, but retain the same timing point for timetable purposes. But also additional timing points have been allocated to TVD's, for automatic time registration purposes. If we have the @timingPoint we could allocate the ocp general TT mileage there. This is used in timetabling and is deemed sufficient there. But for the use case simulation we would like to use the timing points of the TVD's. We could then use todays <crossSections> to define the automatic timing points. An alternative is to use both <crosssection>@type:"station" for the macroscopic timing point and <crosssection>@type:"autoblock" for the microscopic automatic time registration point (but I am uncertain if this is the correct use of the value "autoblock"). But this solution would lose the macroscopic advantage.
Ps. Could anyone describe the values "autoblock" and "block" @type <crossSection>? I could not find anything either in wiki, forum nor schema.
We in Norway still think it's important to have a seperate operationalType for "siding". Mapping the ocp like Dirk describes with describing the ocp's caracteristics in 6 lines with the attributes describing it in propOperational, propEquipment and propService seems less efficient as to define one unique term. We suggest to differentiate between "Anschlusstelle" and "Ausweichanschlusstelle" through use of @ensuresTrainSequence. We define all passing times for "sidings" ocp's in the TT in Norway today. So it would be usefull to differentiate them as <propOperational @operationalType="siding" in the TT as well.
I propose to retract my suggestion for a new <propOperational>@operationalType:"halt". The purpose of this was to model stopping points within stations. I think that this can be sufficient modelled through using the existing @operationalType:"stoppingPoint" in combination with a set value for <ocp>@ocpParentRef. This will indicate that the stopping point is part of another ocp presumably a station and thus in Norway a "stoppested" (stopping point within a station).
|
|
|
|
Members
Search
Help
Login
Home
