Home » railML newsgroups » railml.timetable » addendum to <stopDescription> in railML2.4
addendum to <stopDescription> in railML2.4 [message #1646] Sat, 23 September 2017 18:39 Go to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 216
Registered: August 2008
Senior Member
Dear all,

we have noted only now that, for some reason, there is currently an /operatingPeriodRef/ at <stopDescription> but <stopDescription> is not repeatable. That is remarkable because one should think that it does not make much sense to reduce the operating days of a stop by using that /operatingPeriodRef/ without knowing what happens at the remaining days.

Example:
- <trainPart> operates daily
- <stopDescription>.operatingPeriodRef refers to Mon-Fri.
- What happens at Sat+Sun?

Normally there should be one more <stopDescription> for the remaining days. But that is currently not allowed by schema. It could also hardly mean "pass through" at the remaining days since the stop type (attribute <ocpTT>./ocpType/ =pass/stop) is excluded at a higher level.

However, we assume that this will be solved with the extended stop information at railML 2.4. We already have planned and discussed the possibility to make <stopDescription> depending on operatingDays before, especially in Berlin on 2 June 2017 (see also examples in "Vorschlag Erweiterung Halteinfo ab r2-4.pdf").

From iRFP, we would need a possibility to encode platform references (names, labels) depending on operating days. Currently we use <ocpTT>.trackInfo for the platform names. So it would be nice if there could be a kind of platform name, platform info or track info at <stopDescription> and <stopDescription> at <stopDescription> when <stopDescription> will be enumerable for operating days. However, if not, we could easily make an extension there.

Best regards,
Dirk.
Re: addendum to <stopDescription> in railML2.4 [message #1647 is a reply to message #1646] Mon, 25 September 2017 10:17 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 38
Registered: November 2013
Location: Hanover, Germany
Member
Dear Dirk,

following our discussion during todays TT devoloper phone conference I would like to give some feedaback. I believe that separate trainParts provide all the means to provide the information you are describing - even if it might seem like a large overhead. However, the description of the operatingPeriodRef in the Wiki already suggests that the use will potentially created inconsistent data and for that reason it might be a good idea to discuss Vascos suggestion to make the attribute deprecated in 2.4.

Best regards,

Philip
Re: addendum to <stopDescription> in railML2.4 [message #1648 is a reply to message #1647] Mon, 25 September 2017 10:40 Go to previous messageGo to next message
Joachim.Rubröder is currently offline  Joachim.Rubröder
Messages: 30
Registered: September 2004
Member
Dear Dirk,

using multiple stopDescription elements with (hopefully) disjunctive operating periods for modelling stops on different platforms for different days would technically be possible and sounds as being a useful shortcut for some use cases.

But we already have a way of modelling this in railML 2.3 by using different trainParts. So this change would provide a second method to describe the same thing. This would include the endless discussion about the better way and difficulties for the importing systems to deal with both ways and mismatching operating periods.

We currently use the existing method with different train parts. So I would also vote for handling this case within a version 3.x instead of a hasty model change for 2.4.

Best regards,
Joachim
Re: addendum to <stopDescription> in railML2.4 [message #1649 is a reply to message #1648] Wed, 27 September 2017 22:49 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 216
Registered: August 2008
Senior Member
Dear Joachim and Philip,

> So I would also vote for handling this case within a
> version 3.x instead of a hasty model change for 2.4.

I never wanted something hasty and I surely did not want a model change. Where do you take that idea from?

I only wanted to give the already existing attribute <stopDescription>.operatingPeriodRef a function and therefore a sense.
Since there is such an attribute, I assumed that it should be used instead of copying <trainPart>s only for the stop description. I did not invite this attribute! So where is the model change?

And concerning hasty: We already have a documented approach to this since end of Mai 2017 ("Vorschlag Erweiterung Halteinfo ab r2-4.pdf") and discussed it in Berlin. Nobody talked about a hasty model change then, in Berlin.

I could accept to copy the <trainPart>. But that would mean we need to set the <stopDescription>.operatingPeriodRef as deprecated urgently. And I want to remember that with the new additional stopping information, I doubt that copying the <trainPart> is accepted in any way. It is surely not a common practice.

I think we can now decide between "purism" or following practices to raise acceptance.

Dirk.
Previous Topic: Haltezwecke / Stop descriptions
Next Topic: forgotten attribute <operatingPeriod> @dayOffset and its future
Goto Forum:
  


Current Time: Wed Oct 18 18:47:34 CEST 2017