Home » railML newsgroups » railml.infrastructure » railML 3 infrastructure model
railML 3 infrastructure model [message #550] Tue, 04 February 2014 22:06 Go to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear railML infrastructure community,

some of you may have already noticed the website about the initialized
development of railML 3.0 (cp. [1]). With this thread, I want to
communicate the current state to all of you, railML infrastructure users
and developers, who yet don't know what's new with railML 3.0.

Why do we need railML 3? In the past years, resulting from discussions
in the forum as well as from application examples, we discovered some
infrastructure elements and parameters, which are difficult to define in
the railML 2.x model. Some of these aspects have been transformed into
Trac tickets that can be found in [2]. The underlaying topology is
considered to be a central problem as it is not flexible enough for a
modular modelling of coordinates and track elements.
Last year, the railML partner TrafIt (cf. [3]) analysed the requirements
for a generic railway topology model considering the requirements of all
the different stakeholders and their applications as well as existing
model examples. This feasibility study was assigned and financed by the
UIC and the result has been presented at the 24th railML.org conference
in Paris on September 18, 2013 (cp.[4]). The final report of this study
is available at [5].

Based on the results of the feasibility study, the French infrastructure
manager RFF, together with the Belgium infrastructure manager Infrabel,
initiated the development of a first version for a generic railway
topology model. I reviewed the development process as the railML
infrastructure coordinator. The result named as UIC RailTopoModel, which
is documented in [6], can be considered more as a first than a final
version of a new railway topology approach. Now it is up to all of you
to discuss the model here in the forum. It is our aim to create a
solution that all of you can understand, support and apply, and
therefore we need your feedback on the development. Please share it with
the community here in the forum.

What is the UIC RailTopoModel? This model is a topology approach based
on a "connexity graph" as described in [7]. Simplified, this "connexity
graph" is a node-edge-model where nodes and edges are both modelled as
"NetElements" linked by "Connections". The node-edge-model itself is a
common concept of graph theory (cf. [8]). A major concern of the model,
which has been already pointed out in the feasibility study, is the
generic character of the topology model providing the same structure for
different levels of detail. Further, the different levels of detail
should be convertible using aggregation methods.
The UIC RailTopoModel is considered to be one central component of the
railML 3.0 infrastructure model. However, the railway network's topology
is only one part of the basic layer, while the coordinate positions,
which are required by many applications focusing on geometry or
visualization, form the other part. Last, but not least, we should not
forget that there are also applications, which may exchange
infrastructure data without both coordinates and topology, based on
railML. Therefore, the UIC RailTopoModel is only one component of the
future railML 3.0 infrastructure approach, although a very central one.
Considering its importance, we should discuss about it alltogether.

Thank you and best regards
Christian

[1] http://railml.org//index.php/railml3-entwicklung.html

[2]
http://trac.railml.org/query?version=3.0&col=id&col= summary&col=status&col=owner&col=type&col=pr iority&col=milestone&order=priority

[3] http://railml.org//index.php/entwickler.html?show=48

[4]
http://documents.railml.org/events/slides/2013-09-17_uic_nis si-erim_presentation.pdf

[5]
http://railml.org/tl_files/railML.org/documents/science/2709 13_trafIT_FinalReportFeasibilityStudyRailTopoModel.pdf

[6]
http://railml.org/tl_files/railML.org/documents/science/2012 13_UIC_RailTopoModel_DraftDec13.pdf

[7] http://library.witpress.com/pages/PaperInfo.asp?PaperID=1975 9

[8] http://en.wikipedia.org/wiki/Graph_(mathematics)

--
Christian Rahmig
railML.infrastructure coordinator
Re: railML 3 infrastructure model [message #551 is a reply to message #550] Wed, 05 February 2014 21:55 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Liebe (deutsch-sprachige) railML-Infrastruktur-Gemeinde,

meinen gestrigen Forum-Post zur Ankündigung eines railML 3
Infrastruktur-Modells möchte ich an dieser Stelle gern noch einmal in
Deutsch wiederholen:

Einige von euch haben vielleicht schon die Webseite gesehen, auf der die
Entwicklung von railML 3.0 angekündigt ist (vgl. [1]). Mit diesem Thread
möchte ich den aktuellen Stand nun all jenen unter euch Nutzern und
Entwicklern des railML-Infrastruktur-Schemas darlegen, die ihr noch
nicht wisst, was railML 3.0 bringen wird.

Warum brauchen wir ein railML 3? In den vergangenen Jahren haben wir
resultierend aus den Diskussionen im Forum und auf den
railML.org-Treffen sowie aus verschiedenen Anwendungsbeispielen einige
Infrastruktur-Elemente und -parameter identifiziert, die im railML
2.x-Schema gar nicht oder nur mühsam modelliert werden können. Einige
dieser Aspekte wurden in Trac-Tickets überführt, die in [2] zu finden
sind. Das der railML-Infrastruktur zu Grunde liegende Topologie-Konzept
wird dabei als ein zentrales Problem verstanden, da es momentan nicht
flexibel genug ist, um Koordinaten und Strecken-Elemente unabhängig
voneinander abzubilden.
Im letzten Jahr hat die Firma TrafIt (siehe [3]) als langjähriger
railML-Partner die Anforderungen der verschiedenen Nutzer und ihrer
Anwendungen an ein generisches Topologie-Modell für Schienennetze
erfasst und dabei auch bestehende Modell-Beispiele untersucht. Diese
Machbarkeitsstudie wurde von der UIC in Auftrag gegeben und finanziert.
Das Ergebnis wurde im Rahmen des 24. railML.org-Treffens in Paris am 18.
September 2013 vorgestellt (vgl. [4]). Der Abschlussbericht der Studie
ist in [5] verfügbar.

Basierend auf den Ergebnissen aus der Machbarkeitsstudie hat der
französische Infrastruktur-Betreiber RFF in Zusammenarbeit mit dem
belgischen Pendant Infrabel die Entwicklung einer ersten Version eines
generischen Topologie-Modells für Gleisnetze initiiert. Ich habe den
Prozess in meiner Funktion als Infrastruktur-Koordinator begleitet. Das
Ergebnis, welches den Namen "UIC RailTopoModel" trägt und welches in [6]
im Detail dokumentiert ist, kann mehr als eine erste anstatt der finalen
Version eines neuen Topologie-Ansatzes verstanden werden. Jetzt liegt es
in eurer Hand, das Modell hier im Forum ausführlich zu diskutieren.
Unser Ziel ist eine Lösung, die ihr alle versteht, unterstützt und
anwenden könnt. Daher benötigen wir euer Feedback zur laufenden
Entwicklung: Bitte teilt es mit der railML-Infrastruktur-Gemeinde hier
im Forum!

Was ist das "UIC RailTopoModel"? Es handelt sich hierbei um einen
Topologie-Ansatz basierend auf einem "connexity graph" wie er in [7]
beschrieben wird. Vereinfacht gesagt ist dieser "connexity graph" ein
Knoten-Kanten-Modell, bei dem Knoten und Kanten gleichermaßen als
"NetElements" modelliert werden, die durch "Connection" miteinander
verbunden sind. Das Knoten-Kanten-Modell selbst ist ein aus der
Graphentheorie stammendes bewährtes Konzept (vgl. [8]). Ein zentrales
Anliegen des Modells, welches auch bereits in der Machbarkeitsstudie
herausgestellt wurde, ist der generische Charakter der
Topologie-Modellierung, der sicherstellt, dass die Topologie unabhängig
vom Aggregations-Level stets gleich strukturiert ist. Zusätzlich sollte
zwischen den verschiedenen Abstraktions-Ebenen durch Anwendung von
Aggregations-Methoden eine Konvertierung möglich sein.
Das UIC RailTopoModel stellt eine zentrale Komponente im
Infrastruktur-Modell des zukünftigen railML 3.0 dar. Gleichsam ist die
Topologie des Gleisnetzes nur ein Teil der "Basis-Schicht", während die
Koordinaten-Positionen, die von vielen Anwendungen mit dem Fokus auf
Geometrie und Visualisierung benötigt werden, den anderen Teil bilden.
Schließlich sollten wir auch jene Anwendungen nicht vergessen, die
Infrastruktur-Daten ohne einen Bezug zu Topologie und Koordinaten unter
Nutzung des railML-Formats austauschen wollen. Aus diesem Grund ist das
UIC RailTopoModel nur ein - wenn auch sehr zentraler - Baustein für ein
zukünftiges railML 3.0 Infrastruktur-Schema. Gemessen an seiner
Wichtigkeit sollten wir alle gemeinsam darüber diskutieren.

Vielen Dank und viele Grüße
Christian

On 04.02.2014 22:06, Christian Rahmig wrote:
> Dear railML infrastructure community,
>
> [...]
>
> [1] http://railml.org//index.php/railml3-entwicklung.html
>
> [2]
> http://trac.railml.org/query?version=3.0&col=id&col= summary&col=status&col=owner&col=type&col=pr iority&col=milestone&order=priority
>
> [3] http://railml.org//index.php/entwickler.html?show=48
>
> [4]
> http://documents.railml.org/events/slides/2013-09-17_uic_nis si-erim_presentation.pdf
>
>
> [5]
> http://railml.org/tl_files/railML.org/documents/science/2709 13_trafIT_FinalReportFeasibilityStudyRailTopoModel.pdf
>
>
> [6]
> http://railml.org/tl_files/railML.org/documents/science/2012 13_UIC_RailTopoModel_DraftDec13.pdf
>
>
> [7] http://library.witpress.com/pages/PaperInfo.asp?PaperID=1975 9
>
> [8] http://en.wikipedia.org/wiki/Graph_(mathematics)
>

--
Christian Rahmig
railML.infrastructure coordinator
Re: railML 3 infrastructure model [message #552 is a reply to message #551] Fri, 21 March 2014 11:33 Go to previous messageGo to next message
Benedikt.Wenzel is currently offline  Benedikt.Wenzel
Messages: 1
Registered: March 2014
Junior Member
Gemäß des vorliegenden Dokumentes scheint RailTopoModel eine sehr
durchdachte und
umfassende Abbildung von Infrastrukturdaten auf verschiedensten
Detailstufen zu ermöglichen.
Jedoch sehe ich die damit einhergehende Komplexität und die gebotenen
Freiheiten auch als
Gegenargumente für die Verwendung in railML3 an.
Das Modell erfordert viel Erklärung und ist damit insbesondere auf der
Anwenderebene schwer
zu vertreten.
Zudem bringt die umfassende Abbildung wieder mehr Freiheitsgrade in der
Modellierung und
steigert damit das Potential für railML-Dialekte. Die Wahrscheinlichkeit
für die Kompatibilität
zwischen Tools, die prinzipiell railML unterstützten, wird dadurch noch
stärker gefährdet.

Ein Beispiel: der Tunnel kann nun als Punkt-, Linien- oder Flächenobjekt
abgebildet werden, je nach
Bedarf. Wenn eine Anwendung nun railML-Daten in Empfang nehmen soll, muss
sie entweder alle
drei Definitionsarten unterstützen beim Import (Aufwand!) oder einige
ausschließen (Inkompatibel!).
Der Abstimmungsbedarf zwischen einem railML-Sender und -Empfänger wird
deutlich erhöht.

Ein weiteres Beispiel ist die erweiterte Klasse "orientedRelation" zur
Abbildung der Befahrbarkeit
von Kantenfolgen. Da halte ich den "connections"-Ansatz, welche die
möglichen Kantenpaare
über einen Knoten festlegt, für wesentlich praktischer und
nachvollziehbarer. Sicherlich lassen
sich noch weitere Beispiele finden.

Vielleicht würde auch schon eine beispielhafte Modellierung eines simplen
Bahnhofs mit
Überholungsgleisen, zwei Weichenverbindungen und wenigen Elementen in
RailTopoModel
hilfreich sein, um einen besseren Eindruck zur tatsächlichen
Praxistauglichkeit zu erhalten.

Viele Grüße,
Benedikt Wenzel


--
----== posted via PHP Headliner ==----
Re: railML 3 infrastructure model [message #553 is a reply to message #550] Wed, 02 April 2014 01:31 Go to previous message
anthony.smith is currently offline  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 ==----
Previous Topic: Speed Panels: types and reference to <speedChange>
Next Topic: Feedback UIC RailTopoModel
Goto Forum:
  


Current Time: Fri Aug 18 04:57:06 CEST 2017