| Re: [railML2] Extension of annotations for passenger information within trains [message #2684 is a reply to message #2674] |
Mon, 22 March 2021 16:28   |
Milan Wölke
Messages: 139
Registered: April 2007
|
Senior Member |
|
|
Hi Thomas,
again, thanks for your valuable input.
First, let me respond to the part that is rather easy to respond to. Regarding an origin and destination text other than the last station we actually already have something in railML, that is being introduced with railML 2.5. For each train part you can specify this either as text (translatable), or code (to be resolved by the importing system) or ocpRef. Apart from a differentiation for various display types this should cover your requirements, from what I can see. Please review and let us know if that matches your expectations ( https://svn.railml.org/railML2/branches/railML2.5-dev/schema / - /railML/timetable/trainParts/trainPart/origin and /railML/timetable/trainParts/trainPart/destination).
Regarding the line of a train and its passenger info meta data we already have another post open, as far as I know, so we should discuss these points there ( https://www.railml.org/forum/index.php?t=msg&th=782& start=0&).
Regarding the current station, I have to admit I'm a bit confused. I would interprete your requirement here, that you need a way to determine a valid station name for displays and announcements of the next station. I would presume the next station itself would be determined by your system on its own. Regarding how to specify these aspects, I would propose to introduce a new root element below timetable (/railML/timetable/passengerInfoForInfrastructure - the name could be debated), that would reference the actual ocps of the infrastructure and provide the necessary passenger info details. From my point of view that would be a working theory at first. Once the actual structure of this was specified and discussed, we could ask the infrastructure group to incorporate that model into infrastructure itself, as in my opinion that is rather an infrastructure dependent content than a timetable dependent one.
<railML>
<timetable>
<passengerInfoForInfrastructure>
<ocpPIs>
<ocpPI ocpRef="..." code="...">
<text xml:lang="...">...</text>
<text xml:lang="...">...</text>
</ocpPI>
</ocpPIs>
<platformPIs>
<platformPI>...</platformPI>
</platformPIs>
<trackPIs>
<trackPI>...</trackPI>
<trackPIs>
</passengerInfoForInfrastructure>
</timetable>
</railML>
That would be the general outline of this new section. In contrast to your approach I would simply add this to the file and not reference it from neither trainPart nor ocpTT. Since ocpTT is referencing an ocp anyway, it should be possible to determine the mapped passenger information by checking for entries in passengerInfoForInfrastructure that refer to that ocp. If the infrastructure group decides to incorporate this description it would be even more clear but even if infrastructure does not follow up on this, I think that would be enough.
As you can see this would also be the place to provide the necessary info for platforms and maybe even tracks. Tracks however poses a bit of an issue here as it is possible in railMl 2.x to specify a track using the trackInfo attribute of the ocpTT, without the need for an microscopic infrastructure. That means that there is no reference of any infrastructure element, whatsoever. Judging from your use case, can we assume that a microscopic infrastructure is available anyway?
Regarding the target you are suggesting, could you provide us with a list of necessary values for that enumeration. For the annotations we have the option to specify one or more additionalNames. This could be used to classify texts as well. For example you could specify it like this:
<ocpPIs>
<ocpPI ocpRef="ocpHH" code="...">
<additionalName name="FrontDisplayText"/>
<text xml:lang="...">...</text>
<text xml:lang="...">...</text>
</ocpPI>
<ocpPI ocpRef="ocpHH" code="...">
<additionalName name="SideDisplayText"/>
<text xml:lang="...">...</text>
<text xml:lang="...">...</text>
</ocpPI>
<ocpPI ocpRef="ocpHH" code="...">
<additionalName name="InteriorDisplayText"/>
<text xml:lang="...">...</text>
<text xml:lang="...">...</text>
</ocpPI>
</ocpPIs>
Regarding your example, could you explain, what the class is specifying, that is given for a track annotation?
I hope this input will further the discussions on this topic so that we can better discuss this in one of our next developer phone calls. Obviously input from the community would be very helpful for coming to a conclusion here quickly, too, so I would kindly ask anyone who is concerned with railML timetable or passenger information in particular to comment on this so we can consider it when discussion the actual modelling.
Thanks in advance.
Best regards, Milan
Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
[Updated on: Mon, 22 March 2021 16:34] Report message to a moderator |
|
|
|
Members
Search
Help
Login
Home
