Home » railML newsgroups » railml.infrastructure » Platform @belongsToParent and <ownsPlatformEdge>
Platform @belongsToParent and <ownsPlatformEdge> [message #2133] Fri, 08 February 2019 20:46 Go to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 54
Registered: February 2017
Member
Dear all,

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? To me they seem to have the same function, just differing in whether the reference is upwards or downwards. It will be easier for consuming systems if there is just one.

Also, if both reference methods are used, but not identically, how should the reading system interpret this? E.g. <platform id="A"><ownsPlatformEdge @ref="B"/></platform> and <platform id="B" belongsToParent="C"/> and <platform id="C"/>. Are all three platforms then grouped as one, and is there any semantic difference between the two references?

Several other functional infrastructure types have the belongsToParent attribute, but I cannot find one that has a similar owns* construct for referencing other elements of the same type. So I suggest removing the element ownsPlatformEdge.


Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
Re: Platform @belongsToParent and <ownsPlatformEdge> [message #2137 is a reply to message #2133] Mon, 11 February 2019 15:29 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 205
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
Re: Platform @belongsToParent and <ownsPlatformEdge> [message #2142 is a reply to message #2137] Mon, 11 February 2019 18:11 Go to previous message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 54
Registered: February 2017
Member
Dear Christian,

christian.rahmig wrote on Mon, 11 February 2019 15:29

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.

This assumes that the hierarchy is given, but the current model allows doing this in multiple ways. Let's say we have a symmetrical platform between tracks 1 and 2; 200 meters of it is 5 meters wide, 0.76 meters high and made of concrete, while the remaining 150 meters is older with gravel surface, tapering off to 1 meters wide, 0.55 meters high. The hierarchy can be:

Either:
Platform 1/2, length=350m
|- PlatformEdge 1, length=350m
|  |- PlatformEdge 1a, length=200m, width=? (5m or 2.5m?), height=0.76m
|  \- PlatformEdge 1b, length=150m, width=? (somewhere between 0.5m and 5m), height=0.55m
\- PlatformEdge 2, length=350m
   |- PlatformEdge 2a, length=200m, width=? (5m or 2.5m?), height=0.76m
   \- PlatformEdge 2b, length=150m, width=? (somewhere between 0.5m and 5m), height=0.55m


Or:
Platform 1/2, length=350m
|- Platform 1a/2a, length=200m
|  |- PlatformEdge 1a, length=200m, width=? (5m or 2.5m?), height=0.76m
|  |- PlatformEdge 2a, length=200m, width=? (5m or 2.5m?), height=0.76m
\- Platform 1b/2b, length=150m
   \- PlatformEdge 1b, length=150m, width=? (somewhere between 0.5m and 5m), height=0.55m
   \- PlatformEdge 2b, length=150m, width=? (somewhere between 0.5m and 5m), height=0.55m


Or:
Platform 1/2, length=350m
|- PlatformEdge 1a, length=200m, width=? (5m or 2.5m?), height=0.76m
|- PlatformEdge 1b, length=150m, width=? (somewhere between 0.5m and 5m), height=0.55m
|- PlatformEdge 2a, length=200m, width=? (5m or 2.5m?), height=0.76m
\- PlatformEdge 2b, length=150m, width=? (somewhere between 0.5m and 5m), height=0.55m


Or even just:
PlatformEdge 1a, length=200m, width=? (5m or 2.5m?), height=0.76m
+ PlatformEdge 1b, length=150m, width=? (somewhere between 0.5m and 5m), height=0.55m
+ PlatformEdge 2a, length=200m, width=? (5m or 2.5m?), height=0.76m
+ PlatformEdge 2b, length=150m, width=? (somewhere between 0.5m and 5m), height=0.55m

Without an independent grouping element, but instead just references to one platform edge from the other platform edges.

Also, in all these examples, the lower levels of the hierarchy can be skipped. There are also multiple ways to assign <linearLocation>s: either all elements have them (and platforms have one for each track), or only the lower levels have them, or something in between.

christian.rahmig wrote on Mon, 11 February 2019 15:29

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>

If we need or want a strict hierarchy, considering platforms and platform edges as separate entities, then I think it would make the most sense to have them as separate elements. But do we really need to? I would rather keep using one type and leave the hierarchy up to the writing system. One thing we could do to make life a bit easier for the reading systems is to introduce one semantic constraint: If attributes describing a parent <platform> such as length and height are given, they must include other <platform>s that @belongsToParent.

I see that, apart from <ownsPlatformEdge>, there is only one other occurrence of "platformEdge" in the XSD, and that is <stoppingPlace>@platformEdgeRef. Since platformEdge does no longer exist, it is probably better to rename this to @platformRef. The documentation can still specify that the reference can be to a platform edge, in the form of a <platform> element.


Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
Previous Topic: Embedded methods in objects
Next Topic: [railml3] Signal types and functions
Goto Forum:
  


Current Time: Sat Feb 16 15:25:41 CET 2019