| Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1948 is a reply to message #1851] |
Mon, 03 September 2018 18:59   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Christian and Torben,
> * Mark value "blockPost" as DEPRECATED
? As you can see from [1], we use 'blockPost' for combined blocking signals which are locally staffed. Despite this is an old-fashioned model, there are still some of these "Blockstelle" (as for instance the example BBAE 'Bärhaus') and we do not know how many years they will still exist. So marking "blockPost" as DEPRECATED, does it mean we are not allowed to encode them this way in railML any-more?
> * Adding new value "siding"
> 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.
Ok, but this means redundancy: We then can find a siding either with the new value "siding" or with the old kind we did encode it so far.
Please avoid redundancy because it means much more effort for importing interfaces and therefore, raises implementation costs and reduces acceptance!
> @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.
Yes, we also encode passing times for such sidings in Germany. As this is already done since many years, it is no reason for a new enumeration value.
Any <ocp> can be referred from <TT>. Please explain what you mean with "to differentiate them as <propOperational> @operationalType="siding" in the TT as well".
> From operational perspective it is complete although not mentioning the term "siding", but for use case "SCTP" we need further information about the siding. In particular, we want to know about the number and length of the tracks included in this siding.
Yes, ok, no objection. But here, we discuss only the attributes of the (macroscopic) railML element <ocp>. The <ocp> is only the virtual container for the crossSection. You can still encode all the <track>s, <switches> etc. and therefore model the infrastructure of the "siding" in any meso- or microscopic level you prefer. Do you intend to name the number and length of the tracks in the macroscopic <ocp> additionally, redundantly to meso <tracks> and the microscopic <switches>?
Dirk.
[1]
https://wiki.railml.org/index.php?title=Dev:Types_of_ocps#Bl ockstelle_.E2.80.A2_Locally_staffed_block_post
|
|
|
|
Members
Search
Help
Login
Home
