Dear Thomas,
Am 11.02.2019 um 18:11 schrieb Thomas Nygreen:
> [...]
> 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
Option 1 is my favourite.
In case we want to remove the attribute @ownsPlatformEdge, the related
platform edges have to reference their parent platform via @belongsToParent.
>
> 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.
I would expect platform edges to be modelled / located as linear
elements, while a platform is more likely seen as an areal object. For
operational purposes it is necessary to have linear coordinates (mileage
values) for the platform edges.
>
> 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>
Alternative 3:
<platformEdge> as child element of <platform>
In that case, a <platformEdge> cannot exist alone (without a platform).
>
> 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 don't understand how you mean this, sorry.
>
> 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.
Agreed. A <stoppingPlace> can refer to the platform edge it belongs to
also via @platformRef.
How about the idea from above: adding a boolean flag @isPlatformEdge to
distinguish between a platform and a platform edge?
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
|
Members
Search
Help
Login
Home
