Home » railML newsgroups » railML.infrastructure » Extension suggestion for on which (track)side of a crosSection the referenced ocp is
Extension suggestion for on which (track)side of a crosSection the referenced ocp is [message #1881] Sat, 14 July 2018 17:45 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
crossSection@nor:ocpRepSide

We see a need to map the ocp in relation to the track (s).
Today the ocp is linked to the crosssection so it knows on which pos/abspos it is placed. But it does not know on which side of the track/crossSection it is placed. Thus, we suggest an optional attribute with the enumeration values "left" or "right" (as seen in track direction)

This for the following use case: Network statement and schematic track plan and nice to have for capacity planning.

We see the need in the simple example. When you load the simple example, which does not contain visualisation coordinates, into NorRailView, the system places the OCP's on top of the tracks. This not in accordance with the schematic track plan of the simple example where the OCP is placed below the tracks.

I know this posting will raise a lot of questions of what constitutes and ocp. So I keep it somewhat open with using "Rep" in nor:OcpRepSide. "Rep" can stand for "representative", meaning the dispatcher (the dot in the simple example drawing) . It can also stand for "representation" as some tools use building icons to place the ocp as an object in the tool. This does not mean that there is a real building there. Thus, the use of "representation".

In the Norwegian national version of network statement (SJN http://orv.jbv.no/sjn/doku.php?id=strekningsbeskrivelse:fork laringer_og_forkortelser) we also declare on which side of a line the station/stoppingPoint is placed.

We will implement this as a Norwegian (nor:) extension in railML2.3. We suggest to implement the attribute also in railML2.4.
Re: Extension for (track)side of referenced ocp [message #1883 is a reply to message #1881] Tue, 24 July 2018 12:33 Go to previous messageGo to next message
Tobias Bregulla is currently offline  Tobias Bregulla
Messages: 20
Registered: June 2017
Junior Member
Dear Torben,

thank you very much for this interesting idea!

Am 14.07.2018 um 17:45 schrieb Torben Brand:
> We see a need to map the ocp in relation to the track (s).
> Today the ocp is linked to the crosssection so it knows on
> which pos/abspos it is placed. But it does not know on which
> side of the track/crossSection it is placed.
For Bahnkonzept we would welcome such an extension of the railML
standard from V2.4, since we also record these values in our databases
and thus could also output them in conformity with standards.

However, from a practical point of view there are still some questions
that should be carefully documented in the wiki to ensure uniform
application.

> Thus, we
> suggest an optional attribute with the enumeration values
> "left" or "right" (as seen in track direction)
> This for the following use case: Network statement and
> schematic track plan and nice to have for capacity
> planning.
Of course, further values would have to be included in the list in order
to be able to depict the usual positional relationships:
- left: station/interlocking building on the left side of the track
- right: station/interlocking building on the left side of the track
- both: station/interlocking building on both sides of the track
- above: station/interlocking building above the tracks
(Example: Berlin-Gesundbrunnen)
- below: station/interlocking building under the tracks
- front: station/interlocking building before the end of the tracks
(Example: dead end stations like Leipzig main station as well as
all major Parisian and London long-distance stations)
- none: operating stations without station/interlocking buildings
such as stopping points or modern German stations (e.g. Allersberg; see
https://upload.wikimedia.org/wikipedia/commons/7/78/Train_st ation_NALB_Allersberg_DE_2007-02-16.jpg)

- unknown: Location of the reception building/interlocking is not known

> I know this posting will raise a lot of questions of what
> constitutes and ocp. So I keep it somewhat open with using
> "Rep" in nor:OcpRepSide. "Rep" can stand for
> "representative", meaning the dispatcher (the dot in the
> simple example drawing) . It can also stand for
> "representation" as some tools use building icons to place
> the ocp as an object in the tool. This does not mean that
> there is a real building there. Thus, the use of
> "representation".
The wiki should describe as clearly as possible when a station building
and a interlocking building or signal box are to be indicated
(sequence?). It should also be noted that:
- the location of the station building does not give any information
about platforms and their location,
- The location of the (same) building must be consistent for different
legs of a station,
- (other conditions?).

I would definitely suggest to add the possibility of naming the station
building (including language name), as this is often shown in schematic
plans and can give hints for the user.

The naming shall be discussed as I know the term "station building"
rather than "representation building"; but this shall be
discussed/decided by native speakers.

What does the community think about it?

Best regards,

Tobias and the Bahnkonzept team
Re: Extension suggestion for on which (track)side of a crosSection the referenced ocp is [message #1918 is a reply to message #1881] Tue, 21 August 2018 17:32 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Torben and all,

so far, an <ocp> was not intended to be a station, building or any other material object. It was simply intended to be a _virtual_ cross-section, a reference place to measure run-times in timetables, so a "linkable container" to reference infrastructure from timetables.

Concerning infrastructure itself (i. e. "material" things), railML was rather intended to be a microscopic model. Any real objects as signal boxes, station buildings etc. should be modelled as own <element>s, not as part of <ocp>. Otherwise, we would get much redundancy, since many of such objects already are available as <element>s and also need to be modelled as <element>s.

Of course it is possible to make compromises and also to leave the original intention. But please take into account always to avoid redundancy as much as possible. The more we try to make railML to be a "Swiss army knife", the more difficult it will be to use and to understand. Therefore, at the end, this could also lead to reduced acceptance.

Please consider that there are many <ocp>s which are not linkable to any station building nor signal box.

Please consider that one station building or signal box is normally linked to more than one track, possibly of different lines.

Please consider that station buildings and signal boxes may also be placed between, above or below tracks.

> In the Norwegian national version of network statement ...
> we also declare on which side of a line the
> station/stoppingPoint is placed.

Why? Which functionality do you want to express by that? In railML, you already have <platforms> which can be placed left and/or right of <track>s. Wouldn't it be equal or even better to use the already existing <platform> railML elements for the purpose you intend?

Ok, I will keep back from this discussion in future, only asking for much sensibility and thinking twice before adding more <ocp> properties.

Best regards,
Dirk.
Re: Extension suggestion for on which (track)side of a crosSection the referenced ocp is [message #1935 is a reply to message #1918] Thu, 30 August 2018 11:29 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Dirk, dear Torben,

thank you for the fruitful discussion on that topic.

I think, we have to distinguish between different aspects addressed in
this issue:

(1) representation side of an OCP

If you want to state where to draw the station building in a schematic
track plan, the information shall be stored in the (revived)
infrastructure visualization schema of railML. Reason for this: the
graphical representation may be different for the same "built reality".

The <ocpVis> element currently contains child elements <position> and
<size>. One idea could be to add either in <position> an attribute @side
or have it directly under <ocpVis>.

(2) Where is the station building?

I agree with Dirk that OCP is usable for station infrastructure
modelling only to a very limited extent. The building itself (if
existing) may be modelled in a railML 3 infrastructure schema in detail.
It will then get also attributes for specifying its position and size etc.

(3) Where is the (virtual) center of the OCP?

The center of the OCP is a virtual point and from operational
perspective it is defined by the place where the operation/control is
done. This is not necessarily the station building. The right question
here: In which direction does the train driver has to look to see the
(virtual) operator. From my understanding it makes sense to have the
possibility to model this information. Since it is an information that
differs from track to track depending on their orientation and location,
I agree with having such an attribute then at <crossSection> element.
Instead of @ocpRepSide I prefer a name @ocpCenterSide, but of course I
am open for any other proposal as well.

So, any comment and feedback is appreciated...

Best regards
Christian

Am 21.08.2018 um 17:32 schrieb Dirk Bräuer:
> Dear Torben and all,
>
> so far, an <ocp> was not intended to be a station, building or any other material object. It was simply intended to be a _virtual_ cross-section, a reference place to measure run-times in timetables, so a "linkable container" to reference infrastructure from timetables.
>
> Concerning infrastructure itself (i. e. "material" things), railML was rather intended to be a microscopic model. Any real objects as signal boxes, station buildings etc. should be modelled as own <element>s, not as part of <ocp>. Otherwise, we would get much redundancy, since many of such objects already are available as <element>s and also need to be modelled as <element>s.
>
> Of course it is possible to make compromises and also to leave the original intention. But please take into account always to avoid redundancy as much as possible. The more we try to make railML to be a "Swiss army knife", the more difficult it will be to use and to understand. Therefore, at the end, this could also lead to reduced acceptance.
>
> Please consider that there are many <ocp>s which are not linkable to any station building nor signal box.
>
> Please consider that one station building or signal box is normally linked to more than one track, possibly of different lines.
>
> Please consider that station buildings and signal boxes may also be placed between, above or below tracks.
>
>> In the Norwegian national version of network statement ...
>> we also declare on which side of a line the
>> station/stoppingPoint is placed.
>
> Why? Which functionality do you want to express by that? In railML, you already have <platforms> which can be placed left and/or right of <track>s. Wouldn't it be equal or even better to use the already existing <platform> railML elements for the purpose you intend?
>
> Ok, I will keep back from this discussion in future, only asking for much sensibility and thinking twice before adding more <ocp> properties.
>
> Best regards,
> Dirk.
>


--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Extension suggestion for on which (track)side of a crosSection the referenced ocp is [message #1939 is a reply to message #1935] Thu, 30 August 2018 17:25 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

Am 30.08.2018 um 11:29 schrieb Christian Rahmig:
> [...]
> (3) Where is the (virtual) center of the OCP?
>
> The center of the OCP is a virtual point and from operational
> perspective it is defined by the place where the operation/control is
> done. This is not necessarily the station building. The right question
> here: In which direction does the train driver has to look to see the
> (virtual) operator. From my understanding it makes sense to have the
> possibility to model this information. Since it is an information that
> differs from track to track depending on their orientation and location,
> I agree with having such an attribute then at <crossSection> element.
> Instead of @ocpRepSide I prefer a name @ocpCenterSide, but of course I
> am open for any other proposal as well.

I filed a Trac ticket [1] for this point.

[1] https://trac.railml.org/ticket/340

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Extension suggestion for on which (track)side of a crosSection the referenced ocp is [message #1945 is a reply to message #1935] Mon, 03 September 2018 16:52 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Christian,

> The center of the OCP is a virtual point and from operational perspective it is defined by the place where the operation/control is done.
....
> In which direction does the train driver has to look to see the (virtual) operator.

If it is a virtual place and a virtual operator, one cannot see it/her/him.

Please explain what you mean with "where the operation/control is done".

In my opinion, as I already wrote, an <ocp> is a reference place to measure run-times in timetables, so a "linkable container" to reference infrastructure from timetables. It has not necessarily any link to an operator.

We have many <ocp>s at places which are remote controlled (blocking signals can be <ocp>s!) or which are not controlled at all (simple passenger halts).

Dirk.
Previous Topic: railML 2.3 infrastructure extension proposal - locks
Next Topic: Re-factoring of <infraAttributes>
Goto Forum:
  


Current Time: Thu Mar 28 18:14:24 CET 2024