| Re: railML 3 infrastructure model [message #552 is a reply to message #551] |
Fri, 21 March 2014 11:33   |
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 ==----
|
|
|
|
Members
Search
Help
Login
Home
