Home » railML newsgroups » railML.infrastructure » [railML3] Extension of OPEquipment
[railML3] Extension of OPEquipment [message #2196] Wed, 29 May 2019 19:28 Go to next message
Heidrun Jost is currently offline  Heidrun Jost
Messages: 25
Registered: September 2006
Junior Member
Dear all,

in railML 3's infrastructure there are defined elements in the complex
type „OPEquipment“.

Thales needs future extensions of switches and derailers: That means an
element “ownsSwitch” and “ownsDerailer”.

Is it possible to extend the data model in that way?

Best regards,
--
Heidrun Jost
Software Engineer
Transportation Systems
Thales Deutschland GmbH

Phone: +49 (0) 30 688306 423
Schützenstr. 25 – 10117 Berlin – Germany
Re: [railML3] Extension of OPEquipment [message #2216 is a reply to message #2196] Fri, 05 July 2019 14:02 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Heidrun,

Am 29.05.2019 um 19:28 schrieb Heidrun Jost:
> [...]
> in railML 3's infrastructure there are defined elements in the complex
> type „OPEquipment“.
>
> Thales needs future extensions of switches and derailers: That means an
> element “ownsSwitch” and “ownsDerailer”.
> [...]
The child elements of <opEquipment> are all named <owns*> and they shall
be used to link the operational point with the infrastructure components
that are available there. Extending the concept with <ownsSwitch> and
<ownsDerailer> is not a big problem if there is a need for doing so.

The alternative solution would be to define a generic child element
<ownsInfrastructureElement>, which can be used to refer to any
(functional) infrastructure element.

@all: Which solution do you prefer? Thank you for your feedback!

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
Re: [railML3] Extension of OPEquipment [message #2234 is a reply to message #2216] Mon, 26 August 2019 14:30 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear community,

Am 05.07.2019 um 14:02 schrieb Christian Rahmig:
> [...]
>
> @all: Which solution do you prefer? Thank you for your feedback!

What's your opinion on this issue?

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
Re: [railML3] Extension of OPEquipment [message #2641 is a reply to message #2234] Mon, 18 January 2021 17:05 Go to previous message
Heidrun Jost is currently offline  Heidrun Jost
Messages: 25
Registered: September 2006
Junior Member
Dear Christian,

the alternative solution with the generic child element
<ownsInfrastructureElement> would be perfect for us.

We would prefer this solution.

Mit freundlichen Grüßen/Best regards
--
Heidrun Jost
Data Manager
Transportation Systems
Thales Deutschland GmbH

Phone: +49 (0) 30 688306 423
Schützenstr. 25 – 10117 Berlin – Germany

Am 26.08.2019 um 14:30 schrieb Christian Rahmig:
> Dear community,
>
> Am 05.07.2019 um 14:02 schrieb Christian Rahmig:
>> [...]
>>
>> @all: Which solution do you prefer? Thank you for your feedback!
>
> What's your opinion on this issue?
>
> Best regards
> Christian
Previous Topic: [railML3] Natural hazards detection
Next Topic: [railML3] Linking between platform edges and stopping places
Goto Forum:
  


Current Time: Fri Mar 29 15:13:18 CET 2024