| Re: [railML2] Extension of annotations for passenger information within trains [message #2685 is a reply to message #2684] |
Wed, 24 March 2021 13:47  |
Christian Rößiger
Messages: 62
Registered: March 2015
|
Member |
|
|
Hello Milan and Thomas,
it was very helpful for me to see how the proposed extensions should be
used in an XML example. I agree with Milan on many points in this.
Am 22.03.2021 um 16:28 schrieb Milan Wölke:
> 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.
Just one addition to this: The railML 2.5 elements <origin> and
<destination> mentioned by Milan are subelements of <trainPart> (not of
<train>). This is the right place from my point of view, because
different <origin>s and <destinations> can occur for a coupled/shared
<train> at the same time.
> 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.
Good suggestion.
What bothered me about Thomas' design was that sometimes the
<annotation> is referenced directly from the <trainPart> and sometimes
the <ocpTT> initially references the <ocp> and from there the
<annotation>. I would prefer a unified solution (direct reference from
the <trainPart> or <ocpTT> to the <annotation>), what is provided by
Milans proposal. Another argument for this is, that different trains may
use different <annotation>s at the same station, e.g. due to different
display sizes or requirements of the railway undertaking. I would
therefore rather avoid referencing <annotation>s from an <ocp>.
> 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>
For this aspect, I would prefer the use of a "real" enum, as suggested
by Thomas ("target" attribute). This way, at least the most common
values can be defined in the schema.
As a consequence of this approach, we would need different annotation
types with different attributes, e.g.:
- annotation (standard, without further special attributes)
- ocpAnnotation (with additional attribute "target")
- trackAnnotation (with additional attribute "class")
So far my ideas.
Best Regards
Christian
--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
|
|
|
|
Members
Search
Help
Login
Home
