| Re: Haltezwecke / Stop descriptions [message #1588 is a reply to message #1536] |
Thu, 18 May 2017 19:51   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Mićo and other timetable developers,
I have complemented the mapping between railML and SBB stop descriptions
from Mićo with that of ÖBB and DB. The result is in the cloud at
\timetable\railML 2.4\Haltegrund --> Gegenüberstellung Haltearten
railML-SBB-ÖBB-DB.xls
Anybody who wants to contribute to the development having no access yet
can surely apply for one.
Thank you, Mićo and Philip for the excellent work in advance.
Now, from my opinion, we could make the following next steps:
- Since a specification of stoppings in railML is needed, we should
start with the stopping information common between the three (or two of
the three) railways. These would be about 30 values (rows 28-64 of the
Excel table). It could become a repeatable list of enumeration
additional and optional to the basic stop types (railML: ocpType= und
<stopDescription>).
If wanted, I can quickly create a suggestion for such an enumeration. It
would cover 98% of the SBB's stop types. (All except two: Trassenwechsel
and Intervention. These two would have to be implemented as "other:...".)
- We should use the term "stop description" rather then "reason" or
such ("Haltezweck") since it is rather an additional information. It
leads to all activities one can do during a stop without being
necessarily reasons for the stop. (E. g. a "brake check" or "finishing
train for departure" can hardly be reasons for a stop; also
"intermediate parking" is rarely a reason for but rather a consequence
of a stop.) Part of the very special "stop descriptions" should
therefore, in my opinion, be deferred and be implemented later on demand
at another place in railML.
- I personally wonder that we come as far as "stop for catering"
(wherein at least 2/3 of the railways are united) but the
security-relevant stops for (virtual) token exchange / train messages
are not included so far. So, from a professional expertise, I suggest to
count these stop descriptions here too. At least these operational stop
descriptions should be distinguishable by operating days.
Hopefully this is a support for further development. Looking forward
your replies,
with best regards,
Dirk.
P.S.:
> Question regarding the attribute "onOff":
> The railML attribute onOff is an enum with the allowed
> values "BOTH", "ON" or "OFF". What value should be set for
> stops where e.g. the train crew changes (Haltezweck:
> "Auf-/Absteigen Personal")? This is a stop for BOTH but not
> for the passengers.
"onOff" is intended for traffic stops (commercial, "public" stops) only.
"Auf-/Absteigen Personal" is not a public stop therefore it shall be
implemented as @commercial=false, @operationalStopOrdered=true or false.
This is to be regarded as implicit by definition.
> There are also stop descriptons where none of the enum values are suitable (e.g. for "Kreuzung").
Again same answer: "Kreuzung" (only) is not public. A stop which is both
for passenger exchange and crossing, is (per definition) a public stop
and therefore you can use @onOff=both/on/off. If you want to use "none",
it is per definition a non-public stop with implicitly no on/off.
|
|
|
|
Members
Search
Help
Login
Home
