Forum: railML.infrastructure » Infrastructure registers

Home » railML newsgroups » railML.infrastructure » Infrastructure registers

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Infrastructure registers [message #1547]

Mon, 10 April 2017 14:56

christian.rahmig
Messages: 460
Registered: January 2016

Senior 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

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: Infrastructure registers [message #1580 is a reply to message #1547]

Thu, 18 May 2017 15:46

Dirk Bräuer
Messages: 313
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.

Report message to a moderator

Re: Infrastructure registers [message #1594 is a reply to message #1580]

Mon, 29 May 2017 14:03

christian.rahmig
Messages: 460
Registered: January 2016

Senior 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

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: Infrastructure registers [message #1595 is a reply to message #1594]

Wed, 31 May 2017 18:23

Dirk Bräuer
Messages: 313
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.

Report message to a moderator

Re: Infrastructure registers [message #1667 is a reply to message #1594]

Mon, 20 November 2017 16:19

christian.rahmig
Messages: 460
Registered: January 2016

Senior Member

Dear all,

the described problem may be solved with version 2.4. The related Trac
ticket #310 is available in [1].

I would like to have your feedback on answering the main question: Do
you prefer having one codelist including all the different existing
registers for providing codes and designators to railway infrastructure
elements, or would you like to have separated codelists?

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

Thank you very much and best regards
Christian

Am 29.05.2017 um 14:03 schrieb Christian Rahmig:
> 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

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: Infrastructure registers [message #1682 is a reply to message #1667]

Fri, 15 December 2017 13:24

Philip Wobst
Messages: 47
Registered: November 2013
Location: Hanover, Germany

Member

Am 20.11.2017 um 16:19 schrieb Christian Rahmig:
> Dear all,
>
> the described problem may be solved with version 2.4. The related Trac
> ticket #310 is available in [1].
>
> I would like to have your feedback on answering the main question: Do
> you prefer having one codelist including all the different existing
> registers for providing codes and designators to railway infrastructure
> elements, or would you like to have separated codelists?

Dear all,

the current proposal is to have one register only for all known
registers and without a distinction by type. Please provide feedback for
this as soon as possible.

Best regards,

Philip Wobst

Report message to a moderator

Re: Infrastructure registers [message #1683 is a reply to message #1667]

Fri, 15 December 2017 19:51

christian.rahmig
Messages: 460
Registered: January 2016

Senior Member

Dear all,

based on the feedback I got in direct talks with some of you and from
the coordinators' meeting last Tuesday I propose the following solution
to the topic:

We remain with one codelist Registers.xml that is open for putting any
kind of existing railway related register (OCP, Assets, etc.), e.g.
"Dienststellendokumentation" or the "Primary Location Code for TAF/TAP
TSI". Every register can be identified by a unique code, e.g. "DIDOK" or
"PLC" for the abovementioned registers. We don't distinguish different
types of registers as the categorization of registers is not 100% clear
in every case. What we may think of instead is adding a field for
putting a link or a contact address, so that interested people can be
re-directed in finding out more information about the referenced
register on their own.

What do you think about this proposal?

Best regards
Christian

Am 20.11.2017 um 16:19 schrieb Christian Rahmig:
> Dear all,
>
> the described problem may be solved with version 2.4. The related Trac
> ticket #310 is available in [1].
>
> I would like to have your feedback on answering the main question: Do
> you prefer having one codelist including all the different existing
> registers for providing codes and designators to railway infrastructure
> elements, or would you like to have separated codelists?
>
> [1] https://trac.railml.org/ticket/310
>
> Thank you very much and best regards
> Christian
>
> Am 29.05.2017 um 14:03 schrieb Christian Rahmig:
>> 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

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: Infrastructure registers [message #1685 is a reply to message #1683]

Wed, 27 December 2017 14:28

Dirk Bräuer
Messages: 313
Registered: August 2008

Senior Member

Dear Christian,

> What do you think about this proposal?

To be honest: Not good. I miss a clear and easy understandable structure. As far as I understand, with your suggestion, one could use the same value for <designator @register=...> in registers for <ocp>s, <line>s and so on. So, someone could write <designator register='DB640'> at a <line> element despite there are no lines listed in DB640. This could not be checked by a validator algorithm. It would not be formally invalid but it would be semantically invalid.

Rather, I would prefer railML being a standard which brings us as most clarity as possible.

With best regards,
Dirk.

Report message to a moderator

Re: Infrastructure registers [message #1731 is a reply to message #1685]

Mon, 19 March 2018 14:51

christian.rahmig
Messages: 460
Registered: January 2016

Senior Member

Dear all,

the aim of the coordinated collection of registers is to ensure a clear
assignment of the corresponding codes. railML.org can notify these
corresponding registers on the assistance of the corresponding
international, national or company-specific register owners. railML.org
cannot and will not check the content of the data structures or concrete
contents of the registers. In this respect, railML.org cannot guarantee
that the content of the register mentioned is suitable for the purpose
of exchange. If you have any questions or requests for changes, please
contact the relevant, named register owner [1]. railML.org will be happy
to assist you in making contact.

[1] http://wiki.railml.org/index.php?title=Dev:Registers

Best regards
Christian

Am 27.12.2017 um 14:28 schrieb Dirk Bräuer:
> Dear Christian,
>
>> What do you think about this proposal?
>
> To be honest: Not good. I miss a clear and easy understandable structure. As far as I understand, with your suggestion, one could use the same value for <designator @register=...> in registers for <ocp>s, <line>s and so on. So, someone could write <designator register='DB640'> at a <line> element despite there are no lines listed in DB640. This could not be checked by a validator algorithm. It would not be formally invalid but it would be semantically invalid.
>
> Rather, I would prefer railML being a standard which brings us as most clarity as possible.
>
> With 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

Report message to a moderator

Re: Infrastructure registers [message #1747 is a reply to message #1731]

Wed, 28 March 2018 11:03

Dirk Bräuer
Messages: 313
Registered: August 2008

Senior Member

Dear Christian,

thank you addressing me as a speaker for all the railML community (which I am, of course, not).

> railML.org cannot guarantee that the content of the register mentioned is suitable for the purpose of exchange.

This was not the point nor the intention behind my last message.

Rather, railML.org has a set of register values like "DB640", "RL100" etc. which are clearly intended for the use at <ocp>. Please note: The value for the attribute "register=", _not_ the contents of a DB 640 or a Ril 100!

I do not expect railML.org to be responsible for the contents of such registers.

I do only prefer railML.org to formally ensure that the enumeration values for the attribute "register=" can only be set to registers which are clearly intended to be used at exactly this occurrence of "register", namely at <ocp>s, not for that at <line>s.

Dirk.

Report message to a moderator

Re: Infrastructure registers [message #1749 is a reply to message #1747]

Tue, 03 April 2018 10:48

christian.rahmig
Messages: 460
Registered: January 2016

Senior Member

Dear Dirk,

> I do only prefer railML.org to formally ensure that the enumeration values for the attribute "register=" can only be set to registers which are clearly intended to be used at exactly this occurrence of "register", namely at <ocp>s, not for that at <line>s.

Why do you want to have this clear separation?
Will it help to rename the attribute <ocp>@register into
<ocp>@ocpRegister? This may be useful in future if we extend the
designator concept to lines, too, having an attribute
<line>@lineRegister? Both attributes may point to registers listed in
the codelist Registers.xml.

Would this work for you?

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

Report message to a moderator

Re: Infrastructure registers [message #2109 is a reply to message #1749]

Fri, 18 January 2019 16:33

christian.rahmig
Messages: 460
Registered: January 2016

Senior Member

Dear all,

the topic remains open. For railML 3.1, we decided to keep the
implementation like in railML 2.4. However, the ideas for changing the
implementation are written down in the Trac ticket #310 [1], which has
been moved to version 3.x. Still, any feedback is very much welcome.

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

Best regards
Christian

Am 03.04.2018 um 10:48 schrieb Christian Rahmig:
> Dear Dirk,
>
>> I do only prefer railML.org to formally ensure that the enumeration
>> values for the attribute "register=" can only be set to registers
>> which are clearly intended to be used at exactly this occurrence of
>> "register", namely at <ocp>s, not for that at <line>s.
>
> Why do you want to have this clear separation?
> Will it help to rename the attribute <ocp>@register into
> <ocp>@ocpRegister? This may be useful in future if we extend the
> designator concept to lines, too, having an attribute
> <line>@lineRegister? Both attributes may point to registers listed in
> the codelist Registers.xml.
>
> Would this work for you?
>
> 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

Report message to a moderator

Previous Topic:	Use the concept of layer for splitting the data
Next Topic:	meaning of 'up' and 'down' in mileageChange.dir and track.mainDir

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Wed Sep 11 11:33:09 CEST 2024