| Re: railML 3 infrastructure model [message #553 is a reply to message #550] |
Wed, 02 April 2014 01:31  |
anthony.smith
Messages: 1
Registered: April 2014
|
Junior Member |
|
|
Author
Anthony Smith, Enterprise Architect at BLS AG, Genfergasse 11, 3000 Bern,
Switzerland.
Email anthonysmith(at)blsch
Input
The following analysis has been made in February 2014 upon the given UIC
RailTopoModel documents in January 2014.
Goal
⢠Provide feedback to the UIC working-group on this subject
Introduction
In Switzerland there is a need for a common exchange format such as UIC
RailTopoModel.
Beginning in 2005, SBB has created a unified topology database called
"UNO" serving several business cases such as timetable-planning or
train-disposition. UNO has a concept and implementation that - as far as I
can see now - is compatible with the new UIC RailTopoModel. It's base
concept is a Node-/Edge Graph Model where other data such as signalization
can be easily linked. Topology information changes over time and therefore
the concept and implementation requires a solid "time dimension" approach,
which has been implemented.
The following analysis has been made having the concepts of "UNO" in mind
which has been industry proven over the last 7 years.
Summary
The current model provides the base to build upon, but extra detail work
needs to be done.
Open Questions
⢠Definition: I don't know if I got it right. Does a linear element on
the MICRO level represent a physical rail track (edge) and a non linear
element a junction point (node)?
⢠Chapter MICRO mentions, that only linear elements are used on this
level. But further down the same chapter NonLinearElements are also
mentioned. I do not understand, if the MICRO level only exists of linear
elements (edges), but no non linear elements (nodes). Or the other way
round: Why shall the MICRO level only contain linear elements, but no non
linear elements such as junction points? If I would define such a model,
rail tracks and junction points would be on the MICRO level. All other
details higher up the levels.
Things to discuss / improve
⢠As discussed on 16th of January 2014, status information (valid from,
valid to, construction status, â¦) and time dimension needs to be an
integral part of the new model. Objects need to be able to reference other
objects without loosing this relation when detail information has been
changed.
⢠To serve different business purposes, more than one MESO and even
more MACRO variations need to be implemented. All having the same MICRO
level.
⢠So far it has not been defined, what kind of concrete objects shall
be implemented on which level (MICRO, MESO or MACRO). To avoid future
implementation-variations in RailML, this needs to be further specified.
The generic definition of Operational Points and line is not sufficient.
⢠The geodesic and intrinsic positioning systems can be used as
foundation localization systems. As mentioned in the document, linear
positioning system can have anomalies! Therefore this system should never
be used as a foundation, but as supplemental system. To use the intrinsic
positioning system, the length of an edge (linear element) must be given.
⢠For the geodesic positioning system the standard WGS84 must be
mandatory, as all other systems - such as the different swiss national
systems LV03 and LV95 - can be derived of WGS84. This standard must be
part of the conceptual model and not just part of the RailML specification.
⢠Linear elements are rail sections / trails. Please specify where a
rail section starts as this is a very important detail. Does a rail
section start within a junction point or at its border?
⢠The UUID needs to be further specified. See also TAF / TAP
specifications.
Best regards,
Anthony
--
----== posted via PHP Headliner ==----
|
|
|
|
Members
Search
Help
Login
Home
