Home » railML newsgroups » railml.timetable » Additional commercial attributes from TAP TSI for timetables
Additional commercial attributes from TAP TSI for timetables [message #963] Wed, 14 May 2014 18:00 Go to next message
stefan.jugelt is currently offline  stefan.jugelt
Messages: 5
Registered: May 2014
Junior Member
Dear all,

as proposed during the railML-conference in Braunschweig, I would suggest
some changes for railML to incorporate requirements from the TAP TSI,
mainly for the commercial timetable.

The goal of the introductions of these attributes is to allow the creation
of TAP TSI compliant timetable data in EDIFACT, using railML-timetables as
source files.

For this purpose the following attributes shall be modified:

- rail:tPlaceCategory shall be modified in such a way that the values of
the corresponding TAP TSI code list B.4.9039 can be accomodated.
- rail:tServiceType shall be modified in such a way that the values of
the corresponding TAP TSI code list B.4.7161 can be accomodated.

1. Add the following values to the enumeration "rail:tPlaceCategory":

sleeperFirstClass
sleeperSecondClass
seatingFirstClass
seatingSecondClass
couchetteFirstClass
couchetteSecondClass
recliningSeats
restaurant
singleSleeperFirstClass
specialSleeperFirstClass
doubleSleeperFirstClass
VehicleTransport
T2SleeperSecondClass
T3SleeperSecondClass
T4SleeperSecondClass
singleSleeperShowerFirstClass
doubleSleeperShowerFirstClass
noSmoking
suitableForHeavilyDisabled
babyCompartment
cyclesAllowed
suitableForWheelchairs
videoEntertainment
miniBar
panoramaCoach
telephone
powerSupplySockets
pullmanCoach
bar
familyCarriage
foodVendingMachine
premiumClass
preferente
tourista
singleSleeperSecondClass
doubleSleeperFirstClassShowerWC
T3secondClassShowerWC
doubleSleeperSecondClass
doubleSleeperSecondClassShowerWC
C2DoiubleSleeperSecondClass
C4SleeperSecondClass
C6SleeperSecondClass
wheelchairSecondClass
C5SleeperSecondClass

I would propose that the values "class3, "standing", "foldingSeat",
"impairedToilet", "toilet" shall remain from the current railML version
2.2.

2. Add the following values to the enumeration "rail:tServiceType":

breakfast
dinner
lunch
servicesForChildren
buffet
firstClassRestaurant
hotFoodservice
MealIncludedForFirstClassPassengers
trolley
snack
onboardAssistance
videoEntertainment
businessServices
nurseryService
buffet
servicesForArmyFamilies
postbox, postOffice
mealAtSeat
selfService
overnightStayOnboardAllowed
baggageStorage
noBaggageStorage
audioEntertainment

I would propose that the value "WLAN" will remain.

Furthermore the following addtional informations about the provided
accomodations and services for the TAP TSI should be discussed:

1. The availiability of the above mentioned services (e.g. only available
from June to August, even if the train is running the whole timetable
persiod). This information is not covered be the current railML data model.
2. The reservation status for a place or a service (e.g. reservation
mandatory)

Kind regards,

Stefan Jugelt

--
----== posted via PHP Headliner ==----
Re: Additional commercial attributes from TAP TSI for timetables [message #964 is a reply to message #963] Wed, 14 May 2014 19:22 Go to previous messageGo to next message
Joachim Rubröder is currently offline  Joachim Rubröder
Messages: 88
Registered: April 2007
Member
Dear Stefan,
thanks for your input. We like to stay compliant with TAP TSI.

I therefore created a ticket for the further discussion and as preparation
for the implementation:
https://trac.railml.org/ticket/250#ticket

Kind regards,
Joachim

-------------------------------------
Joachim Rubröder
Schema Coordinator: railML.timetable

--
----== posted via PHP Headliner ==----
Re: Additional commercial attributes from TAP TSI for timetables [message #1299 is a reply to message #964] Mon, 21 September 2015 18:02 Go to previous messageGo to next message
stefan.jugelt is currently offline  stefan.jugelt
Messages: 5
Registered: May 2014
Junior Member
Dear all,

as agreed during our railml timetable meeting last week I have created for
the proposed attribues one example for the coding of places and services
for a train part:

Example:
<?xml version="1.0" encoding="UTF-8"?>
<!--Sample XML file generated by XMLSpy v2015 sp2
(http://www.altova.com)-->
<railml xmlns="http://www.railml.org/schemas/2013"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.railml.org/schemas/2013 railML.xsd">
<metadata>
<organizationalUnits>
<railwayUndertaking id="CompanyCode_1080" code="1080"/>
</organizationalUnits>
</metadata>
<infrastructure id="inf-0815">
<operationControlPoints>
<ocp id="enee_8010085">
<designator entry="8010085" register="ENEE"/>
</ocp>
<ocp id="enee_8010205">
<designator entry="8010205" register="ENEE"/>
</ocp>
</operationControlPoints>
</infrastructure>
<timetable id="tt-0815">
<trainParts>
<trainPart id="TrainPart-0815-1">
<formationTT>
<passengerUsage>
<!-- 100 seats in 1st class -->
<places category="seatingFirstClass" count="100"/>
<!-- 300 seats in 2nd class -->
<places category="seatingSecondClass" count="300"/>
<!-- Snack trolley available -->
<service name="trolley" count="1"/>
</passengerUsage>
</formationTT>
<ocpsTT>
<ocpTT ocpRef="enee_8010085" ocpType="begin"/>
<ocpTT ocpRef="enee_8010205" ocpType="end"/>
</ocpsTT>
<organizationalUnitBinding>
<railwayUndertaking ref="CompanyCode_1080"/>
</organizationalUnitBinding>
</trainPart>
</trainParts>
</timetable>
</railml>

Some further explanations:
1. The code values for the rail:places/@category shall be stored in an
external code list, not in an enumeration in railML.
2. The code values are available in the files "Codelist_B.4.7161.xml"
(servies) and "Codelist_B.4.9039.xml" (places).
3. The enumeration for the accomodation classes in "tPlaceCategory" and
"tServces" are not needed anymore.

Please check the example and provide your comments.

Kind regards,

Stefan Jugelt

--
----== posted via PHP Headliner ==----
Re: Additional commercial attributes from TAP TSI for timetables [message #1300 is a reply to message #1299] Mon, 28 September 2015 12:54 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 36
Registered: November 2013
Location: Hanover, Germany
Member
Dear all,

@Stefan: Thank you for the example file for further discussion. I do
have some questions/feedback:

1. additional attribute for 2.3
I believe the agreement of our meeting was to create a new and TSI
specific attribute - e.g. 'tapTsiCode' - so that the original railML 2.2
data representation is not affected. See #2 for sample.

2. Use of the number and not string code
Should we actually use a string as a code or should we use the actual
number value of the code? I would suggest to use the actual number code
value instead of a string because the code could be interpreted directly
if the default TAP TSI codes are used. Furthermore, it would allow for
at least a limited amount of verification - i.e. number from 1 to 999 as
a valid code reference instead of any string. A set of default mapping
for the existing railML enumeration categories could be provided in the
Wiki.

<formationTT>
<passengerUsage>
<!-- 100 seats in 1st class -->
<places category="class1" tapTsiCode="4" count="100"/>
<!-- 300 seats in 2nd class -->
<places category="class2" tapTsiCode="5" count="300"/>
<!-- Snack trolley available -->
<service name="trolley" tapTsiCode="25" count="1"/>
</passengerUsage>
/formationTT>

3. Documentation and versions
For me it is still not clear where the code list is 'published' and how
different versions can be managed between a railML provider and consumer.
Within the railML release there should be a codelist-schema xsd for the
file but the actual code list. It would then be up to the
provider/consumer to agree on an actual code list version - either
online or provided within their interface process.


Regarding external code lists in general I have found a similar approach
used by the ISO 20022 used by the financial industry
(https://www.iso20022.org/external_code_list.page):

"... Unlike other ISO 20022 code sets, the codes are not included in the
message schema with the message element they type. The purpose of
externalising these codes is to be able to update the code sets (for
example, add new codes) without impacting the messages themselves and,
hence, without requiring the development of a new version of the
messages that use these code sets."

Best regards,

Philip Wobst

Am 21.09.2015 um 18:02 schrieb Stefan Jugelt:
> Dear all,
>
> as agreed during our railml timetable meeting last week I have created for
> the proposed attribues one example for the coding of places and services
> for a train part:
>
> Example:
> <?xml version="1.0" encoding="UTF-8"?>
> <!--Sample XML file generated by XMLSpy v2015 sp2
> (http://www.altova.com)-->
> <railml xmlns="http://www.railml.org/schemas/2013"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.railml.org/schemas/2013 railML.xsd">
> <metadata>
> <organizationalUnits>
> <railwayUndertaking id="CompanyCode_1080" code="1080"/>
> </organizationalUnits>
> </metadata>
> <infrastructure id="inf-0815">
> <operationControlPoints>
> <ocp id="enee_8010085">
> <designator entry="8010085" register="ENEE"/>
> </ocp>
> <ocp id="enee_8010205">
> <designator entry="8010205" register="ENEE"/>
> </ocp>
> </operationControlPoints>
> </infrastructure>
> <timetable id="tt-0815">
> <trainParts>
> <trainPart id="TrainPart-0815-1">
> <formationTT>
> <passengerUsage>
> <!-- 100 seats in 1st class -->
> <places category="seatingFirstClass" count="100"/>
> <!-- 300 seats in 2nd class -->
> <places category="seatingSecondClass" count="300"/>
> <!-- Snack trolley available -->
> <service name="trolley" count="1"/>
> </passengerUsage>
> </formationTT>
> <ocpsTT>
> <ocpTT ocpRef="enee_8010085" ocpType="begin"/>
> <ocpTT ocpRef="enee_8010205" ocpType="end"/>
> </ocpsTT>
> <organizationalUnitBinding>
> <railwayUndertaking ref="CompanyCode_1080"/>
> </organizationalUnitBinding>
> </trainPart>
> </trainParts>
> </timetable>
> </railml>
>
> Some further explanations:
> 1. The code values for the rail:places/@category shall be stored in an
> external code list, not in an enumeration in railML.
> 2. The code values are available in the files "Codelist_B.4.7161.xml"
> (servies) and "Codelist_B.4.9039.xml" (places).
> 3. The enumeration for the accomodation classes in "tPlaceCategory" and
> "tServces" are not needed anymore.
>
> Please check the example and provide your comments.
>
> Kind regards,
>
> Stefan Jugelt
>
Re: Additional commercial attributes from TAP TSI for timetables [message #1305 is a reply to message #1300] Wed, 14 October 2015 18:36 Go to previous messageGo to next message
stefan.jugelt is currently offline  stefan.jugelt
Messages: 5
Registered: May 2014
Junior Member
Dear all,

Philip Wobst wrote:
>
> Dear all,
>
> @Stefan: Thank you for the example file for further discussion. I do
> have some questions/feedback:
>
> 1. additional attribute for 2.3
> I believe the agreement of our meeting was to create a new and TSI
> specific attribute - e.g. 'tapTsiCode' - so that the original railML 2.2
> data representation is not affected. See #2 for sample.
>

Philip you are right, the agreement was to use a new TAP TSI specific
attribute for railML and not to change the enumeration "category" in
railML.

> 2. Use of the number and not string code
> Should we actually use a string as a code or should we use the actual
> number value of the code? I would suggest to use the actual number code
> value instead of a string because the code could be interpreted directly
> if the default TAP TSI codes are used. Furthermore, it would allow for
> at least a limited amount of verification - i.e. number from 1 to 999 as
> a valid code reference instead of any string. A set of default mapping
> for the existing railML enumeration categories could be provided in the
> Wiki.
>

I would suggest to use numeric values for the tapTsiCode-attribute. A
restruiction to up to 999 entries is more than enough. I f we agree to
this approach I would provide the mapping TAP TSI <--> railML.

> <formationTT>
> <passengerUsage>
> <!-- 100 seats in 1st class -->
> <places category="class1" tapTsiCode="4" count="100"/>
> <!-- 300 seats in 2nd class -->
> <places category="class2" tapTsiCode="5" count="300"/>
> <!-- Snack trolley available -->
> <service name="trolley" tapTsiCode="25" count="1"/>
> </passengerUsage>
> /formationTT>
>

The proposal is OK. The numbers reflect the current usage of these entries
in the TAP TSI.

> 3. Documentation and versions
> For me it is still not clear where the code list is 'published' and how
> different versions can be managed between a railML provider and consumer.
> Within the railML release there should be a codelist-schema xsd for the
> file but the actual code list. It would then be up to the
> provider/consumer to agree on an actual code list version - either
> online or provided within their interface process.


The website with the actual version of the TAP TSI:
http://www.era.europa.eu/Document-Register/Pages/TAP-TSI.asp x . The code
lists will be available soon as XML-file on this website. We are waitung
for the final approval.

Kind regards,

Stefan Jugelt




--
----== posted via PHP Headliner ==----
Re: Additional commercial attributes from TAP TSI for timetables [message #1350 is a reply to message #1305] Fri, 04 March 2016 11:06 Go to previous message
Philip Wobst is currently offline  Philip Wobst
Messages: 36
Registered: November 2013
Location: Hanover, Germany
Member
stefan.jugelt wrote on Wed, 14 October 2015 18:36
Dear all,
...

The website with the actual version of the TAP TSI:
http://www.era.europa.eu/Document-Register/Pages/TAP-TSI.asp x . The code
lists will be available soon as XML-file on this website. We are waitung
for the final approval.

Kind regards,

Stefan Jugelt


The Directory of passenger code lists for the ERA technical documents used in TAP TSI version 1.3.1 is now available as PDF and XSD via the ERA website (see link above).
The new TAP TSI attributes in railML 2.3 for places/services have been updated to reflect the type definition in the ERA XSD:
railml/rollingstock/vehicles/vehicle/wagon/passenger/places/@tapTsiType9039Code
railml/rollingstock/vehicles/vehicle/wagon/passenger/service /@tapTsiType7161Code
railml/timetable/trainParts/trainPart/formationTT/passengerU sage/places/@tapTsiType9039Code
railml/timetable/trainParts/trainPart/formationTT/passengerU sage/service/@tapTsiType7161Code

For details please see:
1) TRAC ticket #250
2) TRAC changeset #654

Best regards,

Philip Wobst
Previous Topic: Connections to external trains
Next Topic: Protocol developer meeting 22nd January 2016 at PSI
Goto Forum:
  


Current Time: Wed Aug 16 23:42:29 CEST 2017