Home » railML newsgroups » railml.rollingstock » new values for places and service (new values for places and service)
new values for places and service [message #1750] Thu, 05 April 2018 16:33 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 55
Registered: March 2016
Member
We need to define the following undefined values in the railML rolling stock schema for the use case capacity planning.

The norwegian sector will use the already defined values in railML 2.3 in the wiki under <places> and <service>. We will also define the following "other:" values:

Suggestion towards definition of <places> and <service> We define places as capacity of the vehicle. So a 1. class seat or a bed is a place, but a toilet, a seat in the restaurant car is a service as this is used in addition to a place.

<places>@category=

As the Forum does not support tables I had to restructure the list accordingly:
railML value
English short definition
Norwegian name
Comment


class1
Seating capacity of the vehicle, class1/comfort class
Sitteplasser komfort/1.klasse

class2
Seating capacity of the vehicle, class2/standard
Sitteplasser standard/2.klasse

standing
Number of people capacity of the vehicle, standing
Ståplasser, antall. Klappseter i bruk

other:standingArea
capacity of the vehicle, standing room in square meters. Flip-up seats not in use.
Ståplassareal, klappseter ikke i bruk
Use <place> for now. Should be moved to an element describing technical characteristics of the <wagon/passanger> later.

other:folding
Flip-up seats (folding and resting). Folding seats are seats with dedicated area for the seat when it is folded down. Resting seats are in dedicated standing area (like entry/exit area)
Klappseter (folde og klapp)
We do not differentiate between folding and resting seats here.

wheelchair
Dedicated place(s) for wheelchair(s)
Rullestolplasser

bicycle
Dedicated place(s) for bicyle(s)
Sykkelplasser
Use <place> for now, as already defined there. Should be moved to <service> to be conform to definition?

bed
Number of bed (s). Not differentiated in class.
Soveplasser

other:sleepingCompartment
Number of sleeping compartments. Not differentiated in class.
Sovekupeer
TAF/TAP differentiates in class of compartment and number of beds in the compartment. Should be grouped somehow later.

other:family
capacity of seats in the vehicle in family compartment with family services like playroom and baby wagon storage area/places. Services not defined.
Famileavdeling, antall sitteplasser

other:restaurant
Seating capacity in the restaurant/dining car
Resturant (antall sitte plasser)
Use <place> for now. Should be moved to <service> to be conform to definition?


<service>@name=

other:wheelchairLift
Onboard Wheelchair lift
Rullestolheis
Separate code list for PRM in TAF/TAP. But this does not contain onboard wheel chair lift.

other:toiletClosed
toilet with closed sewer system
Toalett (lukket system)
Should be grouped later. Did not find any code list for toilets in TAF/TAP?

other:toiletOpen
toilet with open sewer system
Toalett (lukket system)

other:toiletHc
toilet for impaired passengers
Toalett (lukket system)

other:Snack
Kiosk (no seating)
Betjent kiosk

other:SelfService
Food/drink vending machines
Automat

other:PIS
Passenger information system
Informasjonssystem
Count:"1"=yes, Count:"0"=no or no value. Should be moved to an element describing technical characteristics of the <wagon/passanger> with bolean value later.

other:WLAN
WLAN/WiFi
WiFi
Count:"1"=yes, Count:"0"=no or no value. Should be moved to an element describing technical characteristics of the <wagon/passanger> with bolean value later.

other:HVAC
Heating, Ventilation and Air Conditioning
HVAC for passasjerer
Count:"1"=yes, Count:"0"=no or no value. Should be moved to an element describing technical characteristics of the <wagon/passanger> with bolean value later.

other:APC
Automatic passenger counting system
APC
Count:"1"=yes, Count:"0"=no or no value. Should be moved to an element describing technical characteristics of the <wagon/passanger> with bolean value later.

other:SecurityCamera
Security camera
Trygghetskamera
Count:"1"=yes, Count:"0"=no or no value. Should be moved to an element describing technical characteristics of the <wagon/passanger> with bolean value later.

As <places> leans towards TSI TAF/TAP code list 9039 and service towards code list 7161 we have tried to use the existing name where they exist and seem logical. But we reccomnd a later through meeting to go through a logical structure of places and service as the definitions in railML and the TAF/TAP seems somewhat incoherrent.
Re: new values for places and service [message #1757 is a reply to message #1750] Mon, 09 April 2018 16:23 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 77
Registered: May 2011
Member
Thanks for your input. The additional attributes will be probably interesting
for other users as well. I will look for a good way to incorporate them into the
existing elements.

Best regards,
Joerg v. Lingen

Rollingstock Coordinator

On 05.04.2018 16:33, Torben Brand wrote:
> We need to define the following undefined values in the
> railML rolling stock schema for the use case capacity
> planning.
>
> The norwegian sector will use the already defined values in
> railML 2.3 in the wiki under <places> and <service>.  We
> will also define the following "other:" values:
>
> Suggestion towards definition of <places> and <service> We
> define places as capacity of the vehicle. So a 1. class seat
> or a bed is a place, but a toilet, a seat in the restaurant
> car is a service as this is used in addition to a place.
> <places>@category=
>
> As the Forum does not support tables I had to restructure
> the list accordingly:
> railML value
> English short definition
> Norwegian name
> Comment
>
> class1
> Seating capacity of the vehicle, class1/comfort class
> Sitteplasser komfort/1.klasse
>     
> class2
> Seating capacity of the vehicle, class2/standard
> Sitteplasser standard/2.klasse
>     
> standing
> Number of people capacity of the vehicle, standing
> Ståplasser, antall. Klappseter i bruk
>     
> other:standingArea
> capacity of the vehicle, standing room in square meters.
> Flip-up seats not in use.
> Ståplassareal, klappseter ikke i bruk   
> Use <place> for now. Should be moved to an element
> describing technical characteristics of the
> <wagon/passanger> later.
>
> other:folding
> Flip-up seats (folding and resting). Folding seats are seats
> with dedicated area for the seat when it is folded down.
> Resting seats are in dedicated standing area (like
> entry/exit area)   
> Klappseter (folde og klapp)   
> We do not differentiate between folding and resting seats
> here.
>
> wheelchair
> Dedicated place(s) for wheelchair(s)    
> Rullestolplasser   
>
> bicycle
> Dedicated place(s) for bicyle(s)   
> Sykkelplasser    
> Use <place> for now, as already defined there. Should be
> moved to <service> to be conform to definition?
>
> bed
> Number of bed (s). Not differentiated in class.   
> Soveplasser
>     
> other:sleepingCompartment
> Number of sleeping compartments. Not differentiated in
> class.   
> Sovekupeer
> TAF/TAP differentiates in class of compartment and number of
> beds in the compartment. Should be grouped somehow later.
>
> other:family
> capacity of seats in the vehicle in family compartment with
> family services like playroom and baby wagon storage
> area/places. Services not defined.   
> Famileavdeling, antall sitteplasser   
>     
> other:restaurant
> Seating capacity in the restaurant/dining car   
> Resturant (antall sitte plasser)   
> Use <place> for now. Should be moved to <service> to be
> conform to definition?
>
>
> <service>@name=
>
> other:wheelchairLift   
> Onboard Wheelchair lift   
> Rullestolheis   
> Separate code list for PRM in TAF/TAP. But this does not
> contain onboard wheel chair lift.
>
> other:toiletClosed
> toilet with closed sewer system   
> Toalett (lukket system)   
> Should be grouped later. Did not find any code list for
> toilets in TAF/TAP?
>
> other:toiletOpen   
> toilet with open sewer system   
> Toalett (lukket system)   
>
> other:toiletHc   
> toilet for impaired passengers   
> Toalett (lukket system)   
>
> other:Snack   
> Kiosk (no seating)   
> Betjent kiosk   
>
> other:SelfService   
> Food/drink vending machines   
> Automat   
>
> other:PIS   
> Passenger information system   
> Informasjonssystem   
> Count:"1"=yes, Count:"0"=no or no value. Should be moved to
> an element describing technical characteristics of the
> <wagon/passanger> with bolean value later.
>        
> other:WLAN   
> WLAN/WiFi   
> WiFi   
> Count:"1"=yes, Count:"0"=no or no value. Should be moved to
> an element describing technical characteristics of the
> <wagon/passanger> with bolean value later.
>        
> other:HVAC    
> Heating, Ventilation and Air Conditioning   
> HVAC for passasjerer   
> Count:"1"=yes, Count:"0"=no or no value. Should be moved to
> an element describing technical characteristics of the
> <wagon/passanger> with bolean value later.
>
> other:APC   
> Automatic passenger counting system   
> APC   
> Count:"1"=yes, Count:"0"=no or no value. Should be moved to
> an element describing technical characteristics of the
> <wagon/passanger> with bolean value later.
>
> other:SecurityCamera   
> Security camera    
> Trygghetskamera   
> Count:"1"=yes, Count:"0"=no or no value. Should be moved to
> an element describing technical characteristics of the
> <wagon/passanger> with bolean value later.
>
> As <places> leans towards TSI TAF/TAP code list 9039 and
> service towards code list 7161 we have tried to use the
> existing name where they exist and seem logical. But we
> reccomnd a later through meeting to go through a logical
> structure of places and service as the definitions in railML
> and the TAF/TAP seems somewhat incoherrent.
>
Re: new values for places and service [message #1785 is a reply to message #1757] Thu, 03 May 2018 09:03 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 77
Registered: May 2011
Member
Some of the suggested values were already available in tPlaceCategory or tServiceType. I have extended the enumerations
by some additional values as suggested. Please note that values "impairedToilet" and "toilet" are still in
tPlaceCategory but are not sensible as "Places". Thus the related values at tServiceType shall be used.

<xs:simpleType name="tPlaceCategory">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="class1" />
<xs:enumeration value="class2" />
<xs:enumeration value="class3" />
<xs:enumeration value="standing" />
<xs:enumeration value="standingArea" />
<xs:enumeration value="wheelchair" />
<xs:enumeration value="bicycle" />
<xs:enumeration value="couchette" />
<xs:enumeration value="bed" />
<xs:enumeration value="chair" />
<xs:enumeration value="bistro" />
<xs:enumeration value="restaurant" />
<xs:enumeration value="foldingSeat" />
<xs:enumeration value="impairedToilet" />
<xs:enumeration value="toilet" />
<xs:enumeration value="business" />
<xs:enumeration value="businessCompartment" />
<xs:enumeration value="family" />
<xs:enumeration value="familyCompartment" />
<xs:enumeration value="toddler" />
<xs:enumeration value="toddlerCompartment" />
<xs:enumeration value="sleepingCompartment" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="rail:tOtherEnumerationValue" />
</xs:simpleType>
</xs:union>
</xs:simpleType>

<xs:simpleType name="tServiceType">
<xs:annotation>
<xs:documentation>list of common service types</xs:documentation>
</xs:annotation>
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="mobileCatering" />
<xs:enumeration value="WLAN" />
<xs:enumeration value="wheelchairLift" />
<xs:enumeration value="toiletClosed" />
<xs:enumeration value="toiletOpen" />
<xs:enumeration value="toiletHc" />
<xs:enumeration value="Snack" />
<xs:enumeration value="SelfService" />
<xs:enumeration value="PIS" />
<xs:enumeration value="HVAC" />
<xs:enumeration value="APC" />
<xs:enumeration value="SecurityCamera" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="rail:tOtherEnumerationValue" />
</xs:simpleType>
</xs:union>
</xs:simpleType>


Joerg von Lingen wrote on 09.04.2018 16:23:
> Thanks for your input. The additional attributes will be probably interesting
> for other users as well. I will look for a good way to incorporate them into the
> existing elements.
>
> Best regards,
> Joerg v. Lingen
>
> Rollingstock Coordinator
>
> On 05.04.2018 16:33, Torben Brand wrote:
>> We need to define the following undefined values in the
>> railML rolling stock schema for the use case capacity
>> planning.
>>
>> The norwegian sector will use the already defined values in
>> railML 2.3 in the wiki under <places> and <service>.  We
>> will also define the following "other:" values:
>>
>> Suggestion towards definition of <places> and <service> We
>> define places as capacity of the vehicle. So a 1. class seat
>> or a bed is a place, but a toilet, a seat in the restaurant
>> car is a service as this is used in addition to a place.
>> <places>@category=
>>
>> As the Forum does not support tables I had to restructure
>> the list accordingly:
>> railML value
>> English short definition
>> Norwegian name
>> Comment
>>
>> class1
>> Seating capacity of the vehicle, class1/comfort class
>> Sitteplasser komfort/1.klasse
>>     
>> class2
>> Seating capacity of the vehicle, class2/standard
>> Sitteplasser standard/2.klasse
>>     
>> standing
>> Number of people capacity of the vehicle, standing
>> Ståplasser, antall. Klappseter i bruk
>>     
>> other:standingArea
>> capacity of the vehicle, standing room in square meters.
>> Flip-up seats not in use.
>> Ståplassareal, klappseter ikke i bruk   
>> Use <place> for now. Should be moved to an element
>> describing technical characteristics of the
>> <wagon/passanger> later.
>>
>> other:folding
>> Flip-up seats (folding and resting). Folding seats are seats
>> with dedicated area for the seat when it is folded down.
>> Resting seats are in dedicated standing area (like
>> entry/exit area)   
>> Klappseter (folde og klapp)   
>> We do not differentiate between folding and resting seats
>> here.
>>
>> wheelchair
>> Dedicated place(s) for wheelchair(s)    
>> Rullestolplasser   
>>
>> bicycle
>> Dedicated place(s) for bicyle(s)   
>> Sykkelplasser    
>> Use <place> for now, as already defined there. Should be
>> moved to <service> to be conform to definition?
>>
>> bed
>> Number of bed (s). Not differentiated in class.   
>> Soveplasser
>>     
>> other:sleepingCompartment
>> Number of sleeping compartments. Not differentiated in
>> class.   
>> Sovekupeer
>> TAF/TAP differentiates in class of compartment and number of
>> beds in the compartment. Should be grouped somehow later.
>>
>> other:family
>> capacity of seats in the vehicle in family compartment with
>> family services like playroom and baby wagon storage
>> area/places. Services not defined.   
>> Famileavdeling, antall sitteplasser   
>>     
>> other:restaurant
>> Seating capacity in the restaurant/dining car   
>> Resturant (antall sitte plasser)   
>> Use <place> for now. Should be moved to <service> to be
>> conform to definition?
>>
>>
>> <service>@name=
>>
>> other:wheelchairLift   
>> Onboard Wheelchair lift   
>> Rullestolheis   
>> Separate code list for PRM in TAF/TAP. But this does not
>> contain onboard wheel chair lift.
>>
>> other:toiletClosed
>> toilet with closed sewer system   
>> Toalett (lukket system)   
>> Should be grouped later. Did not find any code list for
>> toilets in TAF/TAP?
>>
>> other:toiletOpen   
>> toilet with open sewer system   
>> Toalett (lukket system)   
>>
>> other:toiletHc   
>> toilet for impaired passengers   
>> Toalett (lukket system)   
>>
>> other:Snack   
>> Kiosk (no seating)   
>> Betjent kiosk   
>>
>> other:SelfService   
>> Food/drink vending machines   
>> Automat   
>>
>> other:PIS   
>> Passenger information system   
>> Informasjonssystem   
>> Count:"1"=yes, Count:"0"=no or no value. Should be moved to
>> an element describing technical characteristics of the
>> <wagon/passanger> with bolean value later.
>>        
>> other:WLAN   
>> WLAN/WiFi   
>> WiFi   
>> Count:"1"=yes, Count:"0"=no or no value. Should be moved to
>> an element describing technical characteristics of the
>> <wagon/passanger> with bolean value later.
>>        
>> other:HVAC    
>> Heating, Ventilation and Air Conditioning   
>> HVAC for passasjerer   
>> Count:"1"=yes, Count:"0"=no or no value. Should be moved to
>> an element describing technical characteristics of the
>> <wagon/passanger> with bolean value later.
>>
>> other:APC   
>> Automatic passenger counting system   
>> APC   
>> Count:"1"=yes, Count:"0"=no or no value. Should be moved to
>> an element describing technical characteristics of the
>> <wagon/passanger> with bolean value later.
>>
>> other:SecurityCamera   
>> Security camera    
>> Trygghetskamera   
>> Count:"1"=yes, Count:"0"=no or no value. Should be moved to
>> an element describing technical characteristics of the
>> <wagon/passanger> with bolean value later.
>>
>> As <places> leans towards TSI TAF/TAP code list 9039 and
>> service towards code list 7161 we have tried to use the
>> existing name where they exist and seem logical. But we
>> reccomnd a later through meeting to go through a logical
>> structure of places and service as the definitions in railML
>> and the TAF/TAP seems somewhat incoherrent.
>>
Re: new values for places and service [message #1834 is a reply to message #1785] Mon, 11 June 2018 15:03 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 55
Registered: March 2016
Member
Jernbanedirektoratet would like to thank the RS coordinator for his quick feedback and implementation of the suggested values. However this has spurred us to think further about refining the service/places. We would thus like to ask for the following.

Clearer definition of what is a place and what is a service.
We see this issue especially in the toilets (which now are mapped under both elements). As this is on one side a place you can occupy and also it is an extra service to the customers. But for univocity we should choose only one. As both elements have a count attribute both elements can count physical places. Leaving out the count just the type of service is indicated.
We suggest to refine further the definitions in the wiki by adding the following words highlighted in blue:
Places: The element <places> contains the data related to particular passenger planned regular transportation capacity with respect to the various categories of providing space for them.
Service: The element <service> can be used for a list of description of any additional service to the planned regular transportation capacity provided per vehicle. This can be catering, baggage, toilets, low floor portion, conference compartment, internet access etc. The element can also be used to specify particular provisions of a goods compartment.
This would then be in line with what the RS coordinator writes in the forum:
"Please note that values "impairedToilet" and "toilet" are still in tPlaceCategory but are not sensible as "Places". Thus the related values at tServiceType shall be used." I assume this means that they are deprecated. If this is correct please mark them as DEPRECATED in the wiki. Or do you not deprecate enumeration values?
To be consistent with the definition the following <places> @category attribute enumeration values should be moved to <service> @type enumeration value:
"bicycle" - the passenger does not sit on his bicycle while riding the train. He uses either the category attribute enumeration value "standing" or one of the seating classes.
"bistro" and "restaurant" - The passenger has a seat in one of the classes and uses the bistro or restaurant seat additionally to his regular seat while eating. So the seat is an additional service.
It can be discussed for backwards compatibility reasons to keep the attributes in <places>.

Further details on folding seats
There is now a value "foldingSeat". But we would also like to use it in combination with the classes.
As we can not use two enumeration values for the same @category in one <places> element, we need to create a new optional boolean attribute @isFixedSeat. Default value is "true". The value "true" means the seat is a fixed seat. The value "false" means the seat is a folding seat with the same definition as enumeration value "foldingSeat".
Example:
<passenger>
<places category='class3' count='15' isFixedSeat='true'/>
<places category='class3' count='5' isFixedSeat='false'/>
Resulting in 20 seats of category class3.

Further details on standing places
Jernbanedirektoratet needs, for a better detail of capacity planning, to differentiate in the quality levels of standing places (attribute @standing).
We therefore will use the following other: extensions and suggest to adopt it to the enumeration list if other users will use it.
"other:standingCategoryA" - Standing places with possibility to hold on to designated grips. Calculated with 2 passengers per square meter of available passenger standing area ("standingArea") with all seats in use ("class1", "class2" and "class3").
"other:standingCategoryB" - Standing places with calculated with 4 passengers per square meter of available passenger standing area ("standingArea") with seats of "class1" and "class2" in use.
"other:standingCategoryC" - Maximum number of standing places up to the technical or safety level of the vehicle with seats of "class1" and "class2" in use.

Alternative to the two last suggested extensions
Alternatively we could add a new:
<places>@category enumeration value "seat"
<places@class optional attribute with enumeration values "1","2" and "3" or as integer. Alternative the more ambigious @qualityLevel as string.
Mark <places>@category enumeration values "class1", "class2" and "class3" as deprecated.
Then you could freely combine and define the classes/quality level of seats, folding seats and standing places.

Further new enumeration value to places/services
Jernbanedirektoratet will use the following other: extensions and suggest to adopt it to the enumeration list if other users will use it.
"other:stroller" - Number of baby or small child transport vehicles possible to place in the <vehicle>. A stroller must have 80cmx120cm designated area and access from the public entry area and not hinder the through-fare. (Other names: pram, pushchair, buggy. See upcoming glossary)

Depending of how you see the discussion on the placement of @bicycles the attribute will be placed under <places> or <service>.
Re: new values for places and service [message #1838 is a reply to message #1834] Tue, 12 June 2018 19:51 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 239
Registered: August 2008
Senior Member
Dear Torben and Joerg,

I welcome the improvement of places and services in railML and the possible clarification of interferences.

Sometimes we have the same kinds of problems in our data exchanges. In general, we do not distinguish between places and services because of the problems Torben mentioned (does a restaurant or bar car has places to count or is it rather a service?). Rather, we have "countable" and "non-countable" places+services. For instance, WIFI and Mini-Bar are non-countable (boolean): Either existing or not. Places and such are countable.

If countable, they have a unit. Places are counted in "number of", but "multi purpose area" is counted in square metres (m²).

It seems that railML:places correspond to "countable" and railML:services correspond to "non-countable". May be this helps clarifying "what is a place and what is a service".

Therefore I have an idea (or suggestion):
Toilets as places are to be used if you want to count them.
Toilets as service are to be used if you do not want to count them, just saying "there is at least one", or you don't know the number of.

And in the same sense:
Restaurant as a service is to be used if you do not want to count the places but you want to say "there is a restaurant in the train".
Restaurant with countable places is to be used if you want to count the places raising the capacity of the train.

If you agree, you can copy this to Wiki.

> "bicycle" - the passenger does not sit on his bicycle while
> riding the train.

Countable bicycle places are of course no places for passengers but places for bicycles. I regard this as reasonable.

> Further details on folding seats
> There is now a value "foldingSeat". But we would also like
> to use it in combination with the classes.

A first class folding seat? Please send me a picture ;-)
Seriously: No objection against it.

> As we can not use two enumeration values for the same
> @category in one <places> element, we need to create a new
> optional boolean attribute @isFixedSeat.

I would not recommend this in regard of backward compatibility.
Rather, I would like see the idea of <places> enumeration from railML 3.x.

> Further details on standing places

Please do always consider that the railML elements and attributes should be general.
So, if you calculate different categories of standing places with different passengers per square metre, this seems to me not very generally agreed. You should really use "other:..." for that. Alternatively, the passengers-per-square-metre value should become an attribute of railML. But currently I could imagine that there is too less demand really to exchange data with that.

> <places@class optional attribute with enumeration values
> "1","2" and "3" or as integer.
....
> Then you could freely combine and define the classes/quality
> level of seats, folding seats and standing places.

I would welcome this suggestion at least for railML 3.x.

> "other:stroller" - Number of baby or small child transport
> vehicles possible to place in the <vehicle>. A stroller must
> have 80cmx120cm designated area and access from the public
> entry area and not hinder the through-fare.

I presume the babies get places for their buggies but not their own vehicles... ;-)

Please consider that there are limits and railML can possibly not clarify everything:
- The dimensions for such designated areas are probably not generally excepted.
- The stroller area is possibly overlapping with that for wheelchairs. If a <vehicle> has @strollers=5 and @wheelchairs=5, can it occupy 5 strollers _and_ 5 wheelchairs at the same time or either of them?

Therefore, we rather use the "countable" /multi purpose area/ and count it in square metres. So, everybody can calculate how many strollers or wheelchairs he/she can put there depending on the "national stroller size". ;-)

Best regards,
Dirk.
Re: new values for places and service [message #1842 is a reply to message #1838] Thu, 14 June 2018 16:47 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 55
Registered: March 2016
Member
Thank you, Dirk, for valuable input and good questions.
 
I agree to the definition suggestion that <places> being countable places/services for the passenger and <service> being not countable places/services for the passengers.
As this would require some refactoring I suggest leaving as is for now in railML2 and just remove duplicates. When using the count it's a place and when not it's a designated service independent if the object is under <places> or <service>.
 
We appreciate the agreement for a new "seat" value for @category and new @class attribute. However we in Norway cannot wait for railML3. So if not in railML2.4 we will make our own extensions "other:seat" and an optional attribute "@nor:class.". As mentioned @nor:class would be a generic service/quality level attached to the place. So, the values "business", "family", "toddler" and "impaired" (from "impairedToilet") should also be moved there. Additionally a new "quiet" class should be added. We suggest to use an enumeration list with other:. It sould be considered to change the terms "class1", "class2" and "class3" to the more generic terms "premium", "standard" and "reserve".

The different "compartment" values should be replaced with a new attribute @compartments that counts the number of compartments. As this is a more generic structure and gives the possibility to define compartments for all specific categories and classes it will be an improvement.
 
This structure will give us in Norway the possibility to map in railML our distinction needs between the seats in Norway. The 2.class seat is a regular/standard seat that can be fixed or folding (yes we have regular folding seats). 1 class is a comfort seat which you pay a premium for. 3 class is reserve seats that are not used in planned regular occupation service. Just when the train is full to seating capacity the reserve/class3 seats are used. Class3/reserve seats are almost always folding/resting seats. If the train is even fuller (in rush hour) the foldable reserve seats are no longer used as the space is more effective used for standing passengers. This flexibility in the suggested model will be greatly appreciated in Norway. This as the development of places in Norway will be up to the suppliers that tender for in our new transport packages. And who knows: maybe one will run with a 1. class folding seat in the future... ;-)
 
Could you please link to the resource you mention for places in railML 3, as this is a very useful information.
 
We still suggest adding a new "stroller" value for counting purpose (standard for counting not defined in railML, but one could use the description). If not available in railML2.4RS we in Norway suggest to use value other:stroller.
 
The suggestion for "multipurpose area" seems to vague. Sometimes in Norway we have dedicated areas for specific places and sometimes the multiple specific places categories share a dedicated area. I suggest for these shared/multipurpose areas to use the dominant category value and specify the common/shared area in @area and specify the other categories that can also use the area in @description.
For a later development I suggest adding a new @id attribute to <places>, a new @category value "multiPurposeArea" and a new sub element <placesRef> under <places>. This would also have the very important benefit that you would not have to map the places redundant in RS and TT under trainPart/formationTT/passengerUsage.

The wiki should then read:

Attributes of places / Attribute von places / Attributs de places[edit]
• category: The type of places specified within this element. 
Possible values are:
- seat This is used for identifying the number of seats within the vehicle.
- standing This is used for identifying the number of standing places within the vehicle.
- wheelchair This is used for identifying the number of places available for wheelchairs within the vehicle.
- bicycle This is used for identifying the number of places available for bicycles within the vehicle.
- couchette This is used for identifying the number of accommodation berths within the vehicle (couchette car).
- bed This is used for identifying the number of bed places within the vehicle (sleeping car).
- chair This is used for identifying the number of sleeping chairs within the vehicle.
- bistro This is used for identifying the number of seating capacity in the self-service bistro area.
- restaurant This is used for identifying the number of seating capacity in the restaurant/dining car with waitor service.
- foldingSeat This is used for identifying the number of Flip-up seats (folding and resting). Folding seats are seats with dedicated area for the seat when it is folded down. Resting seats are in dedicated standing area (like entry/exit area).
- toilet This is used for identifying the number of normal toilets.
- stroller This is used for identifying the number of dedicated stroller places.
- other:anything Any value that does not fit any value from the previous enumeration list, fulfilling the constraint: at minimum two characters, whitespace is not allowed. 
This is used for identifying the number of any other type of places within the vehicle.
class: The type of service or quality level attaced to a places. Possible values are:
- class1 places with a premium to/more comfort than the standard class
- class2 places of standard class within the vehicle.
- class3 Reserve or sub-standard places within the vehicle.
- business places catering for special buisiness needs like extra working space or office applications
- family places of standard class catering for special childeren needs like proximity to playroom and stroller/baby wagon storage area/places (see seperate category). If there is no distinction between "family" and "toddler" use "family".
- toddler places of standard class catering for special baby and toddler needs like proximity to changingtables and stroller/baby wagon storage area/places (see seperate category).
- impaired places of standard class catering for the needs of the impaired/HC.
- quiet places of standard class catering for quietness/silence.
- other:asnything Any value that does not fit any value from the previous enumeration list, fulfilling the constraint: at minimum two characters, whitespace is not allowed. 
area: This is used for identifying the capacity of the vehicle, room in square meters. Flip-up seats not in use. Possible to use in combination with category and class.
compartments: This is used for identifying the number of compartments. Possible to use in combination with category and class.
• tapTsiType9039Code: Code list for the facility type description based on the directory of passenger code lists for the ERA technical documents used in TAP TSI (B.4.9039)
• count: The number of places within the vehicle of the type given in the category attribute of the same element.
• description: This allows an additional description or comment for the provided places.
• xs:anyAttribute: 

I have made an example for the norwegian FLIRT type 74 (https://www.norsketog.no/tog/type74): Additional described values, for completnes, in kursive.
<vehicle id='veh_1' name='type 74 track-Gauge='1.435' length='105.500' speed='200' bruttoWeight='237.270' net-toWeight='218.070'>
<wagon>
<passenger>
<places category='seat' class='class1' count='44'/>
<places category='seat' class='class2' count='148'/>
<places category='foldingSeat' class='class3' count='48'/>
<places category='standing' class='class1' count='128'/>
<places category='standing' class='class2' area='64,4'/>
<places category='wheelchair' count='4' area='8' description='area also usable for strollers'/>
<places category='bicycle' count='3' area='8' description='area also usable for strollers'/>
<places category='strollers' count='2'/>
<places category='toilet' count='3'/>
<places category='toilet' class='impaired' count='1'/>
<service type='toiletClosed'>
<service type='wheelchairLift' count='2'>
<service type='SelfService' count='4'>
<service type='PIS'>
<service type='WLAN'>
<service type='HVAC'>
<service type='APC'>
<service type='securityCamera' count='33'>
</passenger>
</wagon>
</vehicle>

And partial example for the norwegian type 73-B (https://www.norsketog.no/tog/type73b/bfm73b)
<wagon>
<passenger>
<places category='seat' class='quiet' count='32' compartments='1'/>
<places category='seat' class='family' count='8' compartments='1'/>
<places category='seat' class='impaired' count='4'/>
<places category='seat' class='class3' count='3'/>
<places category='standing' class='class1' count='19'/>
<places category='standing' class='class2' area='9,5'/>
<places category='wheelchair' count='1'/>
<places category='bicycle'/>
<places category='strollers' count='2'/>
<places category='toilet' count='1'/>
<service type='toiletClosed'>
<service type='SelfService' count='1'>
<service type='PIS'>
<service type='WLAN'>
<service type='HVAC'>
<service type='APC'>
</passenger>
</wagon>
</vehicle>

[Updated on: Sat, 23 June 2018 14:31]

Report message to a moderator

Re: new values for places and service [message #1893 is a reply to message #1842] Tue, 07 August 2018 08:30 Go to previous message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 77
Registered: May 2011
Member
Thank you both, Torben and Dirk, for discussing the point.

At the moment you can have "seats" when using "class1/2/3" with a count. This was described in wiki
(https://wiki.railml.org/index.php?title=RS:places).
Concerning "toddler" vs. "stroller" it was unclear description in wiki as trains would not have particular baby seats
but places to store the accompaining prams/stroller.

The suggestions from Torben are sensible but would require restructuring of <places> and <services> which cannot be done
in 2.4 due to compatibility reasons. In addition both elements are used also in TT and it has to be coordinated with them.

BTW there was already a forum post ( https://www.railml.org/forum/index.php?t=msg&th=562& start=0) on similar issue with
resulting changeset [795].

Regards,
Dr.-Ing. Jörg von Lingen - Rollingstock scheme coordinator
Previous Topic: speedProfile and rolling stock
Goto Forum:
  


Current Time: Thu Aug 16 08:01:25 CEST 2018