Home » railML newsgroups » railml.timetable » Haltezwecke / Stop descriptions
Haltezwecke / Stop descriptions [message #1437] Wed, 02 November 2016 13:26 Go to next message
Mićo Mićić is currently offline  Mićo Mićić
Messages: 14
Registered: November 2016
Junior Member
Hallo zusammen

Eine Frage bezüglich der Halte-Beschreibungen: Im RailML 2.3 kann mit dem Element <stopDescription> ein Halt beschrieben werden. Der effektive Haltezweck lässt sich nur grob mit dem Attribut „onOff" definieren. Bei der SBB kennen wir aber aktuell über 80 Haltezwecke. Wo könnten diese abgebildet werden? Im Attribut „purpose" oder sollte man ein neues Listen-Attribut definieren welches erweiterbar ist? Gibt es hier bereits andere Lösungen?

Eine Liste der SBB Haltezwecke ist angehängt.

Vielen Dank
Mico

----
----

Dear all,

A question regarding the stop descriptions. In RailML 2.3, the element <stopDescription> is used to describe a stop. The effective purpose of the stop can only defined roughly using the attribute "onOff". At the SBB, we have currently more than 80 different stop purposes. How can they be represented? With the attribute "purpose" or should there be defined a new list attribute which can be extended? Are there any other solutions?

A list of all SBB stop descriptions is attached.

Thanks!
Mico


SBB: Haltezwecke / Stop descriptions:
Abwarten Gleisfreigabe Bhf
Abwarten Streckenfreigabe
Abwarten Zugfolgezeit
Auf-/Absteigen Personal
Aufstellen
Beistellen D/V-Lok
Beistellen P-Lok
Beistellen Tfz
Diensthalt
Durchfahrt
Durchfahrt (mit Haltberechnung)
Durchfahrt (ohne Haltberechnung)
Ein-/Auslad
Ein-/Auslad bei Bedarf
Ein-/Aussteigen
Ein-/Aussteigen bei Bedarf
Geschwindigkeitswechsel
Intervention
Kreuzung
Lok-Personalwechsel
Nur Abfuhr
Nur Abfuhr bei Bedarf
Nur Aussteigen
Nur Aussteigen bei Bedarf
Nur Einsteigen
Nur Einsteigen bei Bedarf
Nur Zufuhr
Nur Zufuhr bei Bedarf
Pause Lokpersonal
Schwächen/Trennen
Stärken/Vereinigen
Systemwechsel
Tfz-Wechsel
Trassenwechsel
Umfahren
Umstellen
Wagendurchlauf
Wegstellen
Wegstellen D/V-Lok
Wegstellen P-Lok
Wegstellen Tfz
Wenden mit Tfz-Wechsel
Wenden ohne Tfz-Wechsel
Zu-/Abfuhr
Zu-/Abfuhr bei Bedarf
Zugfolgeänderung
Re: Haltezwecke / Stop descriptions [message #1443 is a reply to message #1437] Tue, 08 November 2016 17:08 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 36
Registered: November 2013
Location: Hanover, Germany
Member
Hello Mico,

what you have described has been the solution for the TPS railML export - we have mapped our internal stop types to the railML attributes (e.g. commercial, stopOnRequest, onOff, etc.Wink and then we provide our internal description as the purpose and not as a separate enumeration.

Best regards,

Philip
Re: Haltezwecke / Stop descriptions [message #1449 is a reply to message #1443] Tue, 22 November 2016 08:33 Go to previous messageGo to next message
Mićo Mićić is currently offline  Mićo Mićić
Messages: 14
Registered: November 2016
Junior Member
Hello Philip,

thank you for the reply. I think this might be also the solution for us.

As discussed at the last telephone conference, the proposal by Vasco to refer to a list of stop descriptions provided by each IM would be also interesting. Do you already have ideas how this could be implemented in RailML?

Best regards,
Mico
Re: Haltezwecke / Stop descriptions [message #1535 is a reply to message #1449] Mon, 27 March 2017 09:49 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 36
Registered: November 2013
Location: Hanover, Germany
Member
Hello all,

following the discussion at the last TT developer meeting I would like to add that the TAF/TAP TSI already includes a so called train activity type. Adding the TAF/TAP train activity types might be used to support the actual list of standard and country specific activities. However, these shall be mapped to the corresponding railML attributes (mapping outstanding).

12.14.7 Use of the Train Activity Type and Associated Trains

The list of Activity Type Codes is split into two types: Common European Codes that are available to be used by all countries and National/Company codes that are only relevant to a specific network and to be used in the RU / IM communication only for that network. In both cases the element size will be 4 alpha-numeric.

Common European Codes will have the structure as follows:
•	4 Digit Code (numeric) that represents the Code List values for the common activities

National Codes will have the structure as follows:
•	The first two characters will represent the country of the network in ISO format e.g. UK
•	The remaining two characters (represented as a numeric) will represent a single unique activity within the network e.g. 01 = Stops shorter than 30 secs
Re: Haltezwecke / Stop descriptions [message #1536 is a reply to message #1535] Fri, 31 March 2017 14:42 Go to previous messageGo to next message
Mićo Mićić is currently offline  Mićo Mićić
Messages: 14
Registered: November 2016
Junior Member
Hello all,

as discussed at the last developer meeting I have created a mapping between the SBB stop descriptions and the railML tt:stopdescription attributes. The corresponding excel file is in the railML.org cloud: https://cloud.railml.org/index.php/s/DXuwoVqlQSFQQ4w

The stop descriptions ("Haltezweck") are probably not all understandable. I will try to clarify them in the next few days.

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.

There are also stop descriptons where none of the enum values are suitable (e.g. for "Kreuzung"). My proposal is to create a new value "NONE". This would clearly define that neither ON nor OFF is possible.

Regards,
Mico
Re: Haltezwecke / Stop descriptions [message #1537 is a reply to message #1536] Fri, 31 March 2017 17:31 Go to previous messageGo to next message
Stefan Jugelt is currently offline  Stefan Jugelt
Messages: 1
Registered: March 2017
Junior Member
Hello all,

I want to contribute to this topic from the point of view of the TAF TSI. In the TAF TSI exists one element dealing with the activities of a train, the element TrainActivityType. The definition is as follows:

<xs:element name="TrainActivityType">
<xs:annotation>
<xs:documentation>Indicates certain treatments or operations required for a train. If national codes are used, the first 2 position will be the ISO country code, followed by 00-99.</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="4"/>
<xs:maxLength value="4"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

The element defines the structure, but not the European codes to be exchanged for the train activity. For the time being there is no legally binding - through the TAF TSI - European code list available.

On the other hand the railway sector (railway undertakings, infrastructure managers) have a responsibility for those elements not defined in the TAF TSI. For the TrainActivity there is a sector supported documentation available at " github.com/smagla/sector-xsd/blob/master/taf_cat_complete_se ctor.xsd ". In this file are the codes for the train activity defined as follows:

0001 Commercial stop RU Board/disembark passenger train, load/unload freight train
0002 Operational stop IM Stops needed by the IM (e.g. overpassing by another train)
0003 Service stop RU/IM Stops which are used for non-commercial activities (e.g. boarding of staff)
0004 System stop RU/IM allowing the RU to change a system (e.g. signalling system, safety system)
0005 Reversing stop RU/IM stop to enable train unit to run in the opposite direction (without change of engine)
0006 Stops for reversing move or driver change ends RU stop to enable train unit to run in the opposite direction (with using another engine at the other end of the train and change of driver)
0007 Stops for locomotive to run round train RU stop to enable train unit to run in the opposite direction (with using the same engine at the other end of the train)
0008 Technical check/inspection coaches/wagons RU/IM e.g. at origin or intermediate station:
brake test, checking load
0009 Change gauge RU/IM continuation on a network with a different gauge with change of bogies or adaptation of the axles (F->E, SVE->FI)
0010 attach engine/unit RU Unit not previously in service
0011 detach engine/unit RU Unit no longer in service
0012 change engine RU
0013 attach coach/wagon RU
0014 detach coach/wagon RU
0015 attach and detach coach/wagon RU
0016 attach train Operational Train (in service)
0017 split train Operational Train (in service)
0018 Parking of vehicle RU e.g. need to park the train/composition midway for several hours
0019 Mail/parcel services RU
0020 shunting RU actual activity of shunting
0021 shunting service RU Request for shunting service (if offered by the IM or a third party)
0022 Terminal service (terminal in the meaning of final destination) RU Request for services at the end of a train run (if offered by the IM or a third party)
0023 Loco driver change RU
0024 Loco driver break RU legal issue, e.g. to respect working law
0025 Crew change RU different to loco driver change as for the change of the crew a platform will be needed
0026 Custom and passport facilities RU
0027 Other stop reason (miscellaneous) RU/IM
0028 Boarding only RU
0029 Disembarking only RU
0030 Stop on request RU
0031 Departure equals to arrival time RU If in some stations only arrival times are published, this activity code may used to indicate that the train cannot continue before the published arrival time in case of an early arrival.
0032 Departure after disembarking RU mainly used at the end of train run, train may continue as soon as all passengers have disembarked
0033 No waiting for connection RU
0034 Watering RU Indicates the IM that a track with water access will be needed.
0035 Heating Indicates the IM that a track with heating equipment will be needed.
0036 Cleaning / disinfecting RU
0037 Treatment on plants and live animals RU Watering, Foddering, Milking, Spraying, Closing ventilation flaps, Opening ventilation flaps
0038 Treatment of perishable goods RU Checking the temperature, Re-icing, Heating, Checking the proper functioning of the mechanical refrigeration equipment, Refuelling machinery, Switching machinery on or off
0039 Administrative operations RU Weighing, Re-forwarding, Submission to phytosanitary inspections
0040 Run Through (Passing Time) IM
0041 Photo run-by / Photo-stop
0042 Train Waiting Waiting according to local rules
0043 Train running with another train RU Where trains have been attached at a previous location on the schedule
0044 Next working service RU Association where there is a need to define a relationship between a train and its next service. The same vehicle is used for the next train service. Also called "train-set turnover"
0045 Previous working service RU Association where there is a need to define a relationship between a train and its previous service. The same vehicle is reused from the previous train service.

The list above is maintained by the sector and can be changed without consulting ERA.

Kind regards,

Stefan Jugelt
Re: Haltezwecke / Stop descriptions [message #1545 is a reply to message #1537] Fri, 07 April 2017 12:59 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 36
Registered: November 2013
Location: Hanover, Germany
Member
Hello Stefan,

thank you very much for the feedback - the details regarding the responsibilities for the code values were not clear to me. Do you have any information on how good the different countries have actually adapted the standard codes instead of using just national codes and/or a combination of both - i.e. are the national codes actually used only to supply activitities that are not covered by the standard ones?

Best regards from Hanover,

Philip
Re: Haltezwecke / Stop descriptions [message #1546 is a reply to message #1536] Fri, 07 April 2017 14:16 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 36
Registered: November 2013
Location: Hanover, Germany
Member
Hello Mico,

I have had a look at the data you have provided and have provided an updated file in the cloud (more details and some filters). I would like to suggest to switch to 'activities' instead of 'descriptions' because the activities at a stop are described and and not the stop itself.

I see the following topics that need further review:
1. the current attributes do not allow a 1:1 mapping of the SBB stop activities
2. there are some ambiguities with regard to the attributes
- an activity might be 'ordered' by the RU for a commercial stop
- onOff is not clearly defined to be relevant to customers/goods only
- no possibility to identify activities for the IM
3. in general I suspect that more than one 'activity' can be supplied for a stop - how shall 'conflicting' attributes be treated in such a case?

Best regards,

Philip
Re: Haltezwecke / Stop descriptions [message #1574 is a reply to message #1546] Thu, 18 May 2017 12:28 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 213
Registered: August 2008
Senior Member
Dear Philip, Mico and all "lurkers",

I can possibly clarify some issues raised by Philip. This concerns the
current situation in railML, their current usage and the background
behind former development; I do want to value the current situation as
being sufficient or not.

> 2. there are some ambiguities with regard to the attributes
> - an activity might be 'ordered' by the RU for a commercial stop

To explain the intention behind the current situation: The term
"ordered" in the attribute /operationalStopOrdered/ refers to the
contractual relationship between IM and TOC.

The term "commercial" of the attribute of the same title in railML
traditionally refers to the contractual relationship between TOC and
end-customer, not to the contractual relationship between IM and TOC.

> - onOff is not clearly defined to be relevant to customers/goods only

May be "not clearly defined", but the intention behind is of course:
Only for commercial stops. Does not make sense for traditional
operational stops (which are not ordered). Theoretical, having an
operational stop for crew change, one could differ between on/off/both
but so far, there was never a practical demand for that and it is very
far-fetched just to raise or reduce the number of crew-members and fix
this in a timetable.

The intention behind onOff was clearly: Passenger information.

I want to add concerning stopOnRequest: Intended for passenger usage
only; makes no sense for "goods only" activities. The real background is
to tell the passenger whether he has to signal his wish for a stop
immediately before. For freight, a customer cannot signal a wish to stop
"immediately before" (by hand or button). At least, he would have to
phone or communicate in a more specialised way a special time period before.

From an operational view (concerning relationship between TOC and IM
and inside TOC and IM), "goods only" activities are always "on request",
so by default they can be omitted if there is no demand. The former
"Bedarfszug" has been made obsolete therefore.

> 3. in general I suspect that more than one 'activity' can be
> supplied for a stop - how shall 'conflicting' attributes be
> treated in such a case?

Concerning this, it is documented:
"It is not intended to write different stop types at the same station.
Concerning the usualities of railway operation: If there are reasons for
both a traffic stop and an operational stop, a traffic stop shall be
declared. If an operational stop becomes necessary by IM as well as by
TOC, it will be declared as an operational stop by TOC (ordered
operational stop)."

I agree that if we will define an enumeration of additional stop
informations (activities), this should be repeatable (several activities
at one stop).

Best regards,
Dirk.
Re: Haltezwecke / Stop descriptions [message #1588 is a reply to message #1536] Thu, 18 May 2017 19:51 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 213
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.
Re: Haltezwecke / Stop descriptions [message #1589 is a reply to message #1588] Wed, 24 May 2017 19:46 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 213
Registered: August 2008
Senior Member
Dear all,

in preparation of the meeting on 1st June I quickly set up a suggestion for the extension of railML from version 2.4 with additional stopping information. It is based on the aforementioned comparison of SBB, ÖBB and DB and what is common between at least two of the three.

I suggest a tAdditionalStopInfo (simple type enumeration, see below) with the following values:

collect, drop, split, join, crewChg, crewBreak, reverse, runAround, engineChg, staple, occupation, block, crossing, station, power, wagonCheck, axleChange, borderCheck, photo, catering, movAuth, releaseLine, shuntPerm, misc, other:...

The full suggestion with explanations and notes is here:
\timetable\railML 2.4\Haltegrund --> Vorschlag Erweiterung Halteinfo ab r2-4.pdf

Examples for usage:
1) Traffic stop for collecting and dropping wagons (freight train):

<stopDescription commercial='true' stopOnRequest='false'>
<stopTimes minimalTime='PT30S'/>
<addStopInfo info='collect'/>
<addStopInfo info='drop'/>
</stopDescription>

2) Operational stop for crew change (daily) and a crossing on Mon-Fri only:

<stopDescription commercial='false' operatingPeriodRef='op_Mon-Fri'>
<addStopInfo info='crewChg'/>
<addStopInfo info='crossing'/>
<addStopInfo info='releaseLine'/>
<addStopInfo info='movAuth'/>
</stopDescription>
<stopDescription commercial='false' operatingPeriodRef='op_Sat+Sun'>
<addStopInfo info='crewChg'/>
</stopDescription>

--> If several <stopDescription>s are given, they must have disjunctive @operatingPeriodRef.
--> All @operatingPeriodRef must be subsets of the <operatingPeriodRef> of the <trainPart>.

---
Definition of the enumeration type:

<xs:simpleType name="tAdditionalStopInfo">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="collect" />
<xs:enumeration value="drop" />
<xs:enumeration value="split" />
<xs:enumeration value="join" />
...
<xs:enumeration value="misc" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="rail:tOtherEnumerationValue" />
</xs:simpleType>
</xs:union>
</xs:simpleType>

All names and titles may be regarded as working titles only.

Best regards,
Dirk.
Re: Haltezwecke / Stop descriptions [message #1600 is a reply to message #1589] Thu, 08 June 2017 21:06 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 213
Registered: August 2008
Senior Member
Dear <infrastructure> readers,

this is a cross-post from <timetable>: I have been told that this may be interesting for you, especially stopping information concerning movement and shunting permissions. If any information or terms are missing or conflicting concerning <IS> intentions, please feel free to contact us or ask me directly.

Please answer in <timetable> forum only.

---
Dear all,

as suggested during the meeting of <TT> developers on 1st June 2017 in Berlin, I have
- extended the mapping of stopping information of railML, SBB, ÖBB, and DB with that of TAF/TAP TSI: [1]
- extended the suggestion for a tAdditionalStopInfo in railML 2.4: [2]

The mapping with TAF/TAP TSI is surprisingly complete. The reason is probably that the TAF/TAP TSI list already contains a merge of the above-mentioned railway companies. Thank you to Stefan Jugelt for contribution and explanations during the meeting.

We now have a relatively exact idea of additional stop descriptions for railML 2.4. Therefore, the next steps should be:

@Philip as coordinator: I am prepared to create a Wiki page from the above documents. Please give me a note at the editorial deadline when you transfer it into XSD.

@Everybody: Please check the enumeration values and terms and make suggestions before (!) the editorial deadline to Philip (for decision) and me (to edit the documents).

With best regards,
Dirk.


[1] https://cloud.railml.org/index.php/f/29739
https://cloud.railml.org/remote.php/webdav/TT%20working%20gr oup/railML%202.4/Haltegrund/Gegen%C3%BCberstellung%20Haltear ten%20railML-SBB-%C3%96BB-DB.xls

[2] https://cloud.railml.org/index.php/f/29890
https://cloud.railml.org/remote.php/webdav/TT%20working%20gr oup/railML%202.4/Haltegrund/Vorschlag%20Erweiterung%20Haltei nfo%20ab%20r2-4.pdf
Re: Haltezwecke / Stop descriptions [message #1608 is a reply to message #1600] Mon, 19 June 2017 14:45 Go to previous messageGo to next message
Mićo Mićić is currently offline  Mićo Mićić
Messages: 14
Registered: November 2016
Junior Member
Hi Dirk,

thank you for the mapping and your proposal for the "additional stop information" element. I have done the "way back" by mapping the additional stop values to the SBB stop descriptions without your excel file to check if I get the same results Smile. As expected, all SBB values could be mapped, except "Trassenwechsel" / "Intervention", which are SBB proprietary, and the value "Aufstellen". In your excel file, "Aufstellen" is mapped to the value "staple". At SBB, the value "Aufstellen" is used to describe that the train is being prepared but not necessary "moved" over staple tracks. So the meaning is not the same.

We have discussed this at the last developer telephone conference (19 June 2017). The opinion of Philip (and me) is that we should allow the explicit declaration of such stop information, even if it is clear that e.g. "Aufstellen" is necessary on every first OCP.

Thus, my proposal is to add a value like "preparation". What do you think about?

Best Regards,
Mico
Re: Haltezwecke / Stop descriptions [message #1610 is a reply to message #1608] Tue, 20 June 2017 00:17 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 36
Registered: November 2013
Location: Hanover, Germany
Member
Hello Dirk and all others,

I would like to add that we discussed the need to agree on the rules how and when to add a new value to the enumeration. We already talked about this at the last TT development meeting in Berlin and as far as I remember your approach (Dirk) was to add a value if it is used in more than one country. We also discussed the fact that some activities might be implicit and there would be no need to supply these at all (e.g. testing the brakes).
However, I in my role as HaCon railML user find it hard to define a good rule to identify the implicit activities that would not be included although they are used in more than one country. So at the end of our phone discussion I suggested to to stick with the use case approach only (i.e. used in more than one country) - which in turn would mean, that the SBB 'Aufstellen' and the ÖBB 'Zugvorbereitung' would result in something like 'trainPreparation'.

@ALL: Please provide feedback whether or not we shall define rules for excluding implicit values or not. With the pros and cons we could then come to a conclusion during the next phone conference and make an amendment to the meeting minutes with the agreed rules.

Best regards,

Philip Wobst
Re: Haltezwecke / Stop descriptions [message #1613 is a reply to message #1610] Wed, 21 June 2017 12:44 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 213
Registered: August 2008
Senior Member
Dear Mićo and Philip,

I understand the obvious difference between "Aufstellen" and "Abstellen".
But as you wrote, any train has to be "aufgestellt" at the first <ocp>.

So if you want to add this value, please specify when SBB sets this value at first <ocpTT> and when not. Where is it depending from?

We should then decide whether to include the value in railML depending on the SBB rule is general or special to SBB.

We should only add values in railML when we can provide a rule when to use the value.

So if you decide to add a value "Aufstellen" in railML 2.4, I will ask you to answer the questions:
- Is my railML file valid if I never set "Aufstellen" at the first <ocpTT> although I do use additional stopping information in general?
- Is my railML file valid if I always set "Aufstellen" at the first <ocpTT>?
(Please document the answers.)

Best regards,
Dirk.
Re: Haltezwecke / Stop descriptions [message #1618 is a reply to message #1613] Fri, 30 June 2017 10:25 Go to previous messageGo to next message
Mićo Mićić is currently offline  Mićo Mićić
Messages: 14
Registered: November 2016
Junior Member
Hi Dirk,

Regarding your Question "...please specify when SBB sets this value at first <ocpTT> and when not. Where is it depending from?": I asked our timetable planners but there is no defined rule when to set the "Aufstellen" value. It differs from one region to another and depends on particular use cases. There are also situations where "Aufstellen" is set "in the middle" of the train with a corresponding comment. In this case, a stop description like 'trainPreparation' would make sense to indicate that there is something to do before the journey can be continued.

Regarding your two questions:
- Is my railML file valid if I never set "Aufstellen" at the first <ocpTT> although I do use additional stopping information in general?
- Is my railML file valid if I always set "Aufstellen" at the first <ocpTT>?


I would not define "hard" rules for the stop descriptions but try to describe all available values so that everyone understand the meaning. So I think there is nothing wrong if someone sets the "Aufstellen" at every first <ocpTT> or don't use it at all. Especially because it is an additional stop description it should be treated as optional value.

Best regards,
Mico
Re: Haltezwecke / Stop descriptions [message #1622 is a reply to message #1618] Fri, 07 July 2017 11:02 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 213
Registered: August 2008
Senior Member
Dear Mićo and dear all,

according to what Mićo wrote last (no rule for "Aufstellen"), I want to plead for excluding it from enumeration values. It should be implemented as "other:Aufstellen" or as "any-attribute". It does not differ from any other value which we do not want to include as "Trassenwechsel" or "Kontrollverwiegen".

Best regards,
Dirk.
Previous Topic: forgotten attribute <operatingPeriod> @dayOffset and its future
Goto Forum:
  


Current Time: Thu Jul 27 14:36:53 CEST 2017