| 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   |
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
|
|
|
|
Members
Search
Help
Login
Home
