Home » railML newsgroups » railml.infrastructure » Infrastructure registers
Infrastructure registers [message #1547] Mon, 10 April 2017 14:56 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 45
Registered: January 2016
Member
Dear all,

with railML version 2.2 we introduced the OCP sub-element <designator>
with its attributes @register and @entry (see [1]). At the 31st railML
Conference in Berne on 22.03.2017, the introduction of timetable related
register references has been discussed. In order not to mix registers
with different purposes, it is necessary to distinguish between
infrastructure and timetable registers. Therefore, it has been suggested
to rename @register into @infrastructureRegister in order to indicate
what kind of register shall be referenced (see [2] for more details).

[1] https://trac.railml.org/ticket/112
[2] https://trac.railml.org/ticket/310

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
Re: Infrastructure registers [message #1580 is a reply to message #1547] Thu, 18 May 2017 15:46 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 212
Registered: August 2008
Senior Member
Dear Christian,

sorry but I don't understand the necessity. May be you can further explain?

From my understanding, the kind of register is (adequately) specified
by the parent element of <designator>. If it is a <designator> of an
<ocp>, the station registers are needed. If it is a <designator> of a
different parent element, a different register is needed.

As is can also happen to have different registers as sub-elements of
<infrastructure> in future (such as registers of line numbers), I would
not recommend naming the station lists @infrastructureRegister. I would
name them @ocpRegister. But this would, as I said, be redundant to the
parent's element name.

I agree that the file "Registers.xml" should not be named such in
future. It should be named "Registers_of_OCPs.xml" or such. But this
does not need to have consequences for the XSD, does it?

Best regards,
Dirk.
Re: Infrastructure registers [message #1594 is a reply to message #1580] Mon, 29 May 2017 14:03 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 45
Registered: January 2016
Member
Dear Dirk,

Am 18.05.2017 um 15:46 schrieb Dirk Bräuer:
> [...]
> From my understanding, the kind of register is (adequately) specified by
> the parent element of <designator>. If it is a <designator> of an <ocp>,
> the station registers are needed. If it is a <designator> of a different
> parent element, a different register is needed.
>
> As is can also happen to have different registers as sub-elements of
> <infrastructure> in future (such as registers of line numbers), I would
> not recommend naming the station lists @infrastructureRegister. I would
> name them @ocpRegister. But this would, as I said, be redundant to the
> parent's element name.

thank you very much for your feedback. The idea behind was to
distinguish between registers of the different railML sub-domains
(infrastructure, timetable, etc.). You are absolutely right with your
statement that there are different types of infrastructure related
registers, e.g. for OCPs and for asset management. Therefore, I suggest
to add a new attribute @type in the codelist InfrastructureRegisters.xml
(before: Registers.xml). Using this attribute, it shall be possible to
distinguish between OCP registers, and other infrastructure registers.

The result in InfrastructureRegisters.xml may look like this:

<register code="DfA">
<name xml:lang="de-CH">Datenbank Feste Anlagen</name>
<organization xml:lang="en">Swiss Federal Railways on behalf of
Federal Office of Transport</organization>
<type>assets</type>
</register>

<register code="DIDOK">
<name xml:lang="en">List of station names</name>
<organization xml:lang="en">Swiss Federal Railways on behalf of
Federal Office of Transport</organization>
<type>ocp</type>
</register>

<register code="DB640">
<name xml:lang="de-AT">Dienstbehelf Nr. 640</name>
<organization xml:lang="de-AT">ÖBB</organization>
<type>all</type>
</register>

The question to be answered: what kind of infrastructure related
registers have to be specififed. For the initial version I suggest the
following types:
* asset
* ocp
* networkStatement
* all (?)

Any comments etc. appreciated...

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
Re: Infrastructure registers [message #1595 is a reply to message #1594] Wed, 31 May 2017 18:23 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 212
Registered: August 2008
Senior Member
Dear Christian,

> The question to be answered: what kind of infrastructure related registers have to be specified.

From the timetable view, we regularly see the combination "lines and stations". We use "ocpRegister" for stations (and other <ocp>s) and we use the attribute <line @code> for lines. So for the sake of completeness, as we have an "official" register for <ocp>s, we should also have an "official" register for line codes. Both have the same functional background: Defining a unique route through the network.

So my answer to your question is: Please add a register for <line @code>. We use mostly the instance "VzG-Nummern of DB Netz AG". Others would be "VZG-Nummern of ÖBB Infrastruktur AG (5 digit)". I know such codes (also none-numeric ones as in the UK) from other countries but I do not know the official names.

> * asset
> * ocp
> * networkStatement
> * all (?)

To be honest: I don't know where to use "asset", "networkStatement" nor "all" but possibly I do not need to know. May be it would be helpful if you could name the parent element and attribute in future.

> Therefore, I suggest to add a new attribute @type in the codelist InfrastructureRegisters.xml (before: Registers.xml).

I would prefer to have a different codelist for each register even in infrastructure, for clearness.

Best regards,
Dirk.
Previous Topic: More detailed 'speed change' definitions
Next Topic: Re: Haltezwecke / Stop descriptions
Goto Forum:
  


Current Time: Fri Jun 23 15:44:20 CEST 2017