| Continuation: different stop types / Mehrere Betriebshalt-HaltegruÌnde usw. [message #2462] |
Tue, 16 June 2020 11:03 |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
This is a continuation of a post
Re: Semantic constraint TT:007 Mehrere Betriebshalt-Haltegründe usw.
of Heidrun Jost and me from 07./14.04.2020 which was a bit out-of-topic since it mixed Semantic constraint TT:007 with different stop types, therefore I start a new post here.
---
Dear all,
during the last days there was a discussion on how to encode different stop types in r3 and a suggestion in the cloud.
For me it seems that this leads to a loss in r3 against r2: In r2, we can encode different <stopDescription>.<stopActivities> (any possible mixture) and we can aggregate them into one final stop type at <stopDescription>@ocpType/@commercial.
With the suggestion for r3, it seems we loose the aggregation. But I think the aggregation is essential at least for some use cases. So, I do not want to support nor accept any such loss in r3 against r2. In general, for the sake of acceptance, I think that r3 must allow everything which was possible (and used) in r2 except in case of error correction. But the aggregation of stop types (<stopDescription>@ocpType/@commercial) has not been proved as a mistake.
Semantic explanation of the need for aggregation of stop types:
Whatever the real reasons for stops of trains may be, in traditional timetables a stop has one final designation: It is either an operational stop or a traffic stop, possibly a traffic stop on request. Even if there are several reasons at the same time, the stop has one designation. Why only one designation? I cannot be sure but I think its to give the operational staff a short and quick hint to make short and quick decisions. The operator/dispatcher/signal worker should not be forced to make a research first before (s)he can make a decision.
Which designation a stop has if there are several reasons (like traffic stop on request combined with a train crossing) depends on the local/national operating rules. However, the essential point for railML is not the question why there is only one final designation and which one applies. The essential point is, that as long as there is such a stop type designation/aggregation in praxis, there should be a possibility to encode it in railML. And more important, since this is possible in r2, it should be possible in r3 as well.
Summary and suggestion:
* In r2, we can encode
- different <stopDescription>.<stopActivities>,
- an designation/aggregation into one final stop type at <stopDescription>@ocpType/@commercial.
- Both "levels" are optional.
* In r3, at least the same should be possible. If there should be a third level (in-between the two existing), ok, no obligation. If you want to make them more optional, ok, no obligation. But please do not drop anything.
With best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
