Stop posts for different train types (was: Haltetafel / stop post) [message #930] |
Mon, 11 March 2013 17:49 ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Susanne Wunsch railML
Messages: 0 Registered: January 2020
|
|
|
|
Dear railML users,
During our railML conference in Berlin a new proposal for train
types/kinds was articulated for the context of stop posts.
It is necessary to distinguish between "commercial passenger trains"
(with passengers) and "operational passenger trains" (without
passengers, only with staff). Former have to stop, latter may pass
without any stop. That is an important issue for simulation software.
Christian announced the last changes in this direction with the
following posting.
Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>> 3) Concerning the attribute "validForMovements" is should be possible
>> to enumerate more than one value.
>
> In the latest commit regarding trac ticket [1] I put the attribute
> "validForMovement" into a sequence. Now it is possible to define
> multiple movement validities for the same stop post.
>
> [1] https://trac.assembla.com/railML/ticket/167
I summarized the issue in Trac ticket #167 [2]
As stated at the railML conference in Berlin (2013-03-06) further
categories for stop posts are needed then currently defined in the
"kind" attribute.
Additionally to "passengerTrains" or "freightTrains" or "allTrains"
or "shunting" a flag for "not_valid_for_empty_run" is needed.
This is often used in combination with "passengerTrains".
The current implementation quite re-uses the "trainUsage" attribute of
the timetabling "category" element. This element also offers a "deadrun"
boolean-typed attribute, that would fulfill the new request.
How about referring to an "category" with "categoryRef" instead of the
current "kind" attribute?
That would mean to list all possible categories (ICE, ICE_empty, RE,
RE_empty...) each stop post or to
define some general categories (passenger, passenger_empty, freight,
mixed) therefore.
Any comments* appreciated.
Kind regards...
Susanne
[2] http://trac.assembla.com/railML/ticket/167#comment:22
* +1, -1, hints, questions...
Crosspost: railML.timetable
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
Re: Stop posts for different train types (was: Haltetafel / stop post) [message #960 is a reply to message #930] |
Mon, 02 December 2013 13:02 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) |
Joachim Rubröder railML
Messages: 0 Registered: November 2019
|
|
|
|
Hi,
we will make a Wiki documentation as clarification, about how to describe
a stop in relation with dead runs and flg stops.
https://trac.assembla.com/railML/ticket/237
Kind regards,
Joachim
-------------------------------------
Joachim Rubröder
Schema Coordinator: railML.timetable
Susanne Wunsch wrote:
>
> Dear railML users,
>
> During our railML conference in Berlin a new proposal for train
> types/kinds was articulated for the context of stop posts.
>
> It is necessary to distinguish between "commercial passenger trains"
> (with passengers) and "operational passenger trains" (without
> passengers, only with staff). Former have to stop, latter may pass
> without any stop. That is an important issue for simulation software.
>
> Christian announced the last changes in this direction with the
> following posting.
>
> Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>>> 3) Concerning the attribute "validForMovements" is should be possible
>>> to enumerate more than one value.
>>
>> In the latest commit regarding trac ticket [1] I put the attribute
>> "validForMovement" into a sequence. Now it is possible to define
>> multiple movement validities for the same stop post.
>>
>> [1] https://trac.assembla.com/railML/ticket/167
>
> I summarized the issue in Trac ticket #167 [2]
>
> As stated at the railML conference in Berlin (2013-03-06) further
> categories for stop posts are needed then currently defined in the
> "kind" attribute.
>
> Additionally to "passengerTrains" or "freightTrains" or "allTrains"
> or "shunting" a flag for "not_valid_for_empty_run" is needed.
>
> This is often used in combination with "passengerTrains".
>
> The current implementation quite re-uses the "trainUsage" attribute of
> the timetabling "category" element. This element also offers a "deadrun"
> boolean-typed attribute, that would fulfill the new request.
>
> How about referring to an "category" with "categoryRef" instead of the
> current "kind" attribute?
>
> That would mean to list all possible categories (ICE, ICE_empty, RE,
> RE_empty...) each stop post or to
> define some general categories (passenger, passenger_empty, freight,
> mixed) therefore.
>
> Any comments* appreciated.
>
> Kind regards...
> Susanne
>
> [2] http://trac.assembla.com/railML/ticket/167#comment:22
> * +1, -1, hints, questions...
> Crosspost: railML.timetable
--
----== posted via PHP Headliner ==----
|
|
|