Re: Include track length information in topology [message #2108 is a reply to message #1989] |
Fri, 18 January 2019 16:18 |
christian.rahmig
Messages: 460 Registered: January 2016
|
Senior Member |
|
|
Dear Martin,
Am 15.10.2018 um 14:50 schrieb Martin Karlsson:
> [...]
> Classes SpotLocationOnTrack and LinearLocationOnTrack should
> be removed, along with references from class Entity to them
> (trackPosition and trackSection respectively).
Done.
> TrackNode class should also be removed, with the
> consequences that
> - child classes Switch, BufferStop, Border and Crossing need
> to be reparented from FunctionalInfrastructureEntity
> - relations from Track class should be removed, i.e.
> trackBegin and trackEnd
> - "use" relation from Track class should be removed from
> diagram railML3_IS_FunctionalTypes (the diagram should also
> be renamed to better reflect the remaining information in
> it)
> - the whole diagram
> railML3_IS_Functional_Track-and-Tracknode should be removed
Indeed, TrackNode is an abstract class that does not provide any further
content considering the derived classes. The only purpose of this class
was to limit the possible references in <track>@trackBegin and
<track>@trackEnd.
The parameters <track>@trackBegin and <track>@trackEnd provide a
possibility to explicitly state the borders of the track (like it is
done for the <line> segments with @beginsInOP and @endsInOP).
Alternatively, the <track> is located like any other NetEntity derived
object and thus implicitly defines its borders.
Question to all: Do you want to have an explicit reference from the
<track> to functional infrastructure elements limiting this <track>?
> Another minor observation is about the naming of the new
> attributes, related to physical length, in class
> RTM_AssociatedNetElement. They are now called fromPos and
> toPos, whereas my suggestion was posBegin and posEnd. The
> difference may be insignificant, but since the corresponding
> intrinsic coordinate attributes are called
> intrinsicCoordBegin and intrisicCoordEnd, I think my
> suggestion makes the connection between the two positioning
> views clearer.
Done (implemented with railML 3.1 RC2).
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
|
|
|