Additional commercial attributes from TAP TSI for timetables [message #963] |
Wed, 14 May 2014 18:00 |
Stefan Jugelt
Messages: 3 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 #1300 is a reply to message #1299] |
Mon, 28 September 2015 12:54 |
Philip Wobst
Messages: 47 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 #1350 is a reply to message #1305] |
Fri, 04 March 2016 11:06 |
Philip Wobst
Messages: 47 Registered: November 2013 Location: Hanover, Germany
|
Member |
|
|
stefan.jugelt wrote on Wed, 14 October 2015 18:36Dear 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
|
|
|