Forum - RDF feed
https://www.railml.org/forum/index.php
Partial Route
https://www.railml.org/forum/index.php?t=rview&goto=1616&th=526#msg_1616
or more route release objects.
Partial routes are used for for transit souple in France and Teilfahrstraßenauflösung in Germany.
Partial Routes can be used, i.e. shared, by more than one route in terms of data modelling.
As such, Partial Routes can be regarded as immaterial assets.]]>Bob Janssen railML2017-06-23T14:24:54-00:00Re: Partial Route
https://www.railml.org/forum/index.php?t=rview&goto=2006&th=526#msg_2006
I would like to bring this topic up because I have some questions about the partial routes.
As far I understood, if the interlocking releases each individual tvd section after use, the release group of the knowsRoute can be omitted.
However, in this case, there would be no information about the tvd sections that compose the route.
On the other hand, one could avoid this by defining a partial route for each tvd Section (as done in the simpleExample), but in this way the information would be redundant.
I was wondering whether it makes sense to reference direclty the tvD sections that compose the route as an alternative to the partial routes.
What do you think about that?
Regards,
Fabiana]]>Fabiana Diotallevi2018-11-05T16:08:22-00:00Re: Partial Route
https://www.railml.org/forum/index.php?t=rview&goto=2007&th=526#msg_2007
the path of a route is defined by start and end plus the position of facing points. This equals the concept of
geographic interlocking. The TVD sections composing the route shall be derived from the topology.
There was also the idea of having an element ControlTable in interlocking to gather the information in tabular style.
However, this was deemed not really necessary and being a redundancy to the existing way to define routes. Thus it was
not yet further developed in the schema.
Best Jörg.
Interlocking coordinator
Fabiana Diotallevi wrote on 05.11.2018 17:08:
> Hi,
> I would like to bring this topic up because I have some
> questions about the partial routes.
> As far I understood, if the interlocking releases each
> individual tvd section after use, the release group of the
> knowsRoute can be omitted.
> However, in this case, there would be no information about
> the tvd sections that compose the route.
> On the other hand, one could avoid this by defining a
> partial route for each tvd Section (as done in the
> simpleExample), but in this way the information would be
> redundant.
>
> I was wondering whether it makes sense to reference direclty
> the tvD sections that compose the route as an alternative to
> the partial routes.
>
> What do you think about that?
>
> Regards,
>
> Fabiana
> ]]>Joerg von Lingen2018-11-07T04:17:57-00:00Re: Partial Route
https://www.railml.org/forum/index.php?t=rview&goto=2008&th=526#msg_2008
thanks for your reply, I understood your point.
It just seems to me that in some cases (when the interlocking releases each individual tvd section after use) the definition of partial routes coincides with the definition of tvd sections and gives no further information.
Anyway you are right, defining the start and the end elements plus the position of facing points is enough to define a route.
Best regards,
Fabiana]]>Fabiana Diotallevi2018-11-07T09:35:33-00:00Re: Partial Route
https://www.railml.org/forum/index.php?t=rview&goto=2013&th=526#msg_2013
in comparison to railML2.3nor the list of TVD sections in the route path seems
to be considered in addition to the path definition by point positions. They
intend to use a similar model with releaseGroups.
Thus the question arise whether to mandatorily have the partialRoutes as
realeaseGroups in each route although each single section is released on its own.
Best regards,
Joerg v. Lingen
Interlocking Coordinator
On 07.11.2018 05:17, Joerg von Lingen wrote:
> Dear Fabiana,
>
> the path of a route is defined by start and end plus the position of facing points. This equals the concept of
> geographic interlocking. The TVD sections composing the route shall be derived from the topology.
> There was also the idea of having an element ControlTable in interlocking to gather the information in tabular style.
> However, this was deemed not really necessary and being a redundancy to the existing way to define routes. Thus it was
> not yet further developed in the schema.
>
> Best Jörg.
> Interlocking coordinator
>
> Fabiana Diotallevi wrote on 05.11.2018 17:08:
>> Hi,
>> I would like to bring this topic up because I have some
>> questions about the partial routes.
>> As far I understood, if the interlocking releases each
>> individual tvd section after use, the release group of the
>> knowsRoute can be omitted.
>> However, in this case, there would be no information about
>> the tvd sections that compose the route.
>> On the other hand, one could avoid this by defining a
>> partial route for each tvd Section (as done in the
>> simpleExample), but in this way the information would be
>> redundant.
>>
>> I was wondering whether it makes sense to reference direclty
>> the tvD sections that compose the route as an alternative to
>> the partial routes.
>>
>> What do you think about that?
>>
>> Regards,
>>
>> Fabiana
>> ]]>Joerg von Lingen2018-11-17T05:23:33-00:00Re: Partial Route
https://www.railml.org/forum/index.php?t=rview&goto=2017&th=526#msg_2017
it is true that the TVD sections composing the route could be derived from the topology: however, this would involve a quite complicated process, because it would mean to locate the starting and the end signal in the interlocking schema (and the switches too), find their referenced signals (and switches) in the infrastructure schema, find the netelements they belong to, link them to the trainDetectionElements and finally to the trackCircuits.
Maybe it would be easier to add to <knowsRoute> a new mandatory tag <hasTvdSection> which lists all the TrackCircuits, and to leave the <hasReleaseGroup> tag optional (as it is today).
What do you think?
Regards,
Fabiana]]>Fabiana Diotallevi2018-11-20T10:41:39-00:00Re: Partial Route
https://www.railml.org/forum/index.php?t=rview&goto=2023&th=526#msg_2023
I have checked your proposal concerning <hasTvdSection> with the Norwegian model and the practise I knew from Thales.
Thus I have inserted this additional element into routes and overlap as optional, i.e. it is optional by the schema but
can be set mandatory by the use case. At least in IMED I have set it to mandatory.
The changes can be found in SVN trunk of railML3.
Regards,
Jörg v.Lingen - Interlocking coordinator
Fabiana Diotallevi wrote on 20.11.2018 11:41:
> Dear Joerg,
> it is true that the TVD sections composing the route could
> be derived from the topology: however, this would involve a
> quite complicated process, because it would mean to locate
> the starting and the end signal in the interlocking schema
> (and the switches too), find their referenced signals (and
> switches) in the infrastructure schema, find the netelements
> they belong to, link them to the trainDetectionElements and
> finally to the trackCircuits.
>
> Maybe it would be easier to add to <knowsRoute> a new
> mandatory tag <hasTvdSection> which lists all the
> TrackCircuits, and to leave the <hasReleaseGroup> tag
> optional (as it is today).
>
> What do you think?
>
> Regards,
>
> Fabiana
> ]]>Joerg von Lingen2018-11-26T05:14:10-00:00