Home » railML newsgroups » railML.infrastructure » Platform @belongsToParent and <ownsPlatformEdge>
Re: Platform @belongsToParent and <ownsPlatformEdge> [message #2137 is a reply to message #2133] Mon, 11 February 2019 15:29 Go to previous messageGo to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Thomas, dear all,

Am 08.02.2019 um 20:46 schrieb Thomas Nygreen:
> [...] Two or more <platform> elements can be grouped either by
> each part referencing the "main" platform using the
> belongsToParent attribute, or by the "main" platform listing
> all the parts using the ownsPlatformEdge element. Or both.
> Are they both needed? [...]

This "redundancy" issue results from the past where we had two separate
elements: <platform> and <platformEdge>. A <platform> could refer to all
<platformEdge> objects that represent the interface between a train (on
the track) and the platform. This is a reference from an object to an
object part.

The hierarchical reference between objects of the same type (platform to
platform or platform edge to platform edge) shall be done using the
attribute @belongsToParent. One example for this type of referencing:
grouping together platform edges with different height to a long
platform edge.

> [...] So I suggest removing the element
> ownsPlatformEdge.

Well, regarding the redundancy, I agree with you. But then we need to
think about alternatives of how to distinguish between platforms and
platform edges.

Alternative 1:
Introduce a boolean flag in <platform>: @isPlatformEdge

Alternative 2:
Re-Introduce the functional infrastructure element <platformEdge>

So, what do you prefer or do you have a third solution proposal?

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
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Extra attributes on signal in RailML2.3 norwegian extention
Next Topic: [railML3] NID_CTRACTION for electrification model
Goto Forum:
  


Current Time: Mon May 06 04:21:54 CEST 2024