| Re: new values for places and service [message #1838 is a reply to message #1834] |
Tue, 12 June 2018 19:51   |
Dirk Bräuer
Messages: 311
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.
|
|
|
|
Members
Search
Help
Login
Home
