Home » railML newsgroups » railml.timetable » Stop posts for different train types (was: Haltetafel / stop post)
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
Joachim Rubröder railML is currently offline  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 ==----
 
Read Message
Read Message
Previous Topic: wiki: missing attribute description for additionalTrainNumber at <train>
Next Topic: Questions about "Category" and "Rosterings" of timetable
Goto Forum:
  


Current Time: Mon Apr 29 17:52:30 CEST 2024