Interoperable-data / ERA-Ontology-3.1.0

Extended version of the ERA Railway Infrastructure Ontology
4 stars 3 forks source link

Missing definition: Signals Grid #16

Open gdschut opened 2 months ago

gdschut commented 2 months ago

Before an objecttype can be placed in any model, the definition should be clear and understandable by all. So every class (objecttype) in the model should have a definition.

https://linkedvocabs.org/data/era-ontology/3.1.0/doc/index-en.html#SignalsGrid What is the definition of "Signals Grid" ?

Interoperable-data commented 2 months ago

Thank you @gdschut for the issue. We will add the comments and the relevant definitions for the newly added object properties and classes.

gatemezing commented 1 month ago

Dear @gdschut , here is a definition for SignalsGrid here https://linkedvocabs.org/data/era-ontology/3.1.0/doc/index-en.html#SignalsGrid

Certiman commented 3 weeks ago

@gdschut the definition tries to provide for parts of the OP which are operationally managed by the same interlocking or connecting a set of lines for instance, and usage is not mandatory (all switches are then just part of the OP, without further refinement into a SignalsGrid.).

I've added it to provide a way to link PARTS of an OP to such a SignalsGrid, as I know of extremely complicated OP's with several such grids within them, procuring for line-to-line operation, and being managed by redundant interlocking systems. All remarks are welcome.

gdschut commented 2 weeks ago

Thanks. It is clear to me this does not belong to RINF, correct? Than it is of no interest for me.

Still wondering why it is called a signalsgrid, as according to the definition it is basically a "Group of switches and crossings", and related to the interlocking, but that might be because I'm missing the right knowledge for this.

As this is for no interest to RINF, for me the issue can be closed. Please let this item out of RINF discussions about microlevel or timedimension etc.

Certiman commented 2 weeks ago

Well, the knowledge about what Signals, Switches and Crossings "work together" is IM knowledge. It is indeed mostly used then in the signal box operation, in order to determine the fall-back routes when losing that part of the OP. It is this fall-back info which RU's need to know as well and our idea with the SignalGrid is to allow using it in the Rule Book (TSI OPE 4.2.1.2.1) context (answering the CQ: "what parts of the OP can become technically unavailable").

For sure, the RINF-context is indirect only and we have no link with D.2 (Route Book), so if it leads more to confusion than stgh else or this is out of scope of RU relevant info...

(the word grid ("rooster" in SNCB terms) is borrowed from ENE, as it also cuts up the network into smaller switchable and isolatable parts.)