| Re: train stablings [message #1804 is a reply to message #1803] |
Wed, 23 May 2018 12:34   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear all,
the <TT> Developer Telco on 23rd May 2018 brings us to the following state of this issue:
- Solution B implies solution A.
- There has already been an agreement to support solution A at the Berlin <TT> Developer Meeting on 19th April 2018.
- Whether solution A (alone) or B (including A) is the better one depends on how detailed information shall be expressed and whether a circulation planning is affected in general. Therefore, there is the suggestion to allow both A and B and leave the final decision to the use case.
- For solution A (alone), the question has been discussed whether to provide an additional "mission" attribute at the train as part of railML. (This relates to the extension "ns4:trainPathIndicator=SOBO" in Heriberts example.) The conclusion was that no necessity for such an attribute as part of railML is seen. The <train[Part]> with one <ocpTT> explains itself alone enough. It does not matter here whether this <train[Part]> arrives or departs as a train or shunting operation. Who wants to express more, shall select solution B.
- There is the decision to allow solution B by removing the preventing restrictions (allow <rostering>s without <circulation>s and <block>s) from railML 2.4.
Best regards,
Dirk.
---
Hallo allerseits,
nach der <TT>-Entwickler-Telco vom 23.05.2018 stehen wir bezüglich dieser Anforderung an folgender Stelle:
- Lösung B setzt Lösung A voraus.
- Über die Unterstützung von Lösung A bestand bereits am 19.04.2018 in Berlin Einigkeit.
- Ob allein Lösung A zu wählen ist oder auch Lösung B, hängt vor davon ab, wie detailliert ausgedrückt werden soll und ob eine Umlaufplanung tangiert wird. Es besteht daher der Vorschlag, beides zu erlauben und die finale Entscheidung dem UseCase zu überlassen.
- Für Lösung A wird die Erweiterung um eine "mission" (des abgestellten <trainPart>s, bezieht sich auf die Erweiterung "ns4:trainPathIndicator=SOBO" in Heriberts Beispiel) als railML-Attribut nicht zwingend für notwendig erachtet. Der Ein-OCP-<TrainPart> spricht für sich; es muss nicht zwingend ausdrückbar sein, ob dieser als Zug- oder Rangierfahrt "kommt" und "fährt". Wer mehr ausdrücken will, soll zu Lösung B greifen.
- Es wird entschieden, zur Ermöglichung von Lösung B die ihr entgegenstehenden Restriktionen unter <rostering> ab railML 2.4 aufzuheben.
Viele Grüße,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
