| [railML 3.2] Modelling of Routes [message #3392] |
Tue, 19 November 2024 07:49  |
David Lichti
Messages: 47
Registered: December 2020
|
Member |
|
|
Dear Community,
In the context of a new railML 3.2 infrastructure export, we need to add some information about the construction aspects of blocks. railML already has the route element. But this element does not seem to have suitable attributes for the following properties:
- Approach Signal Distance: The (nominal) distance of the approach signal from the route's destination signal.
- Line of Sight: The maximum distance from which the route's exit signal can be recognized. This may be different for each route ending at a particular main signal. So the sightDistance property of interlocking signals is not suitable.
- Linear Location: Exact limits of a route in the microscopic infrastructure. This may differ from the area enclosed by the entry and exit signals, if those are not located exactly on the block boundaries.
Is there any suitable alternative for modelling this data in railML 3.2? Or should we design an extension? It seems to me that this would best be solved by a routeIS element in the infrastructure sub-schema. This would be similar to the modelling of signals and switches.
Best regards
David
|
|
|
|
| Re: [railML 3.2] Modelling of Routes [message #3430 is a reply to message #3392] |
Mon, 13 January 2025 16:59  |
Jörg von Lingen
Messages: 96
Registered: March 2016
|
Member |
|
|
Dear David,
there are some clarifications for better understanding necessary.
Approach Signal Distance: Do you mean the distance between the main signal and
its related distant signal (Vorsignalabstand)? If yes, this could be calculated
from the positions of these signals. The nominal value of a railway line can be
specified in Line/linePerformance@signalledBrakingDistance.
Line of Sight: It is not clear, why SignalIL/@sightDistance does not suit and
why it might be different depending on route? There rules on the minimum
distance of sight. In case this cannot be achieved, repeaters of the distant
signal are used.
Exact Linear Location: All signals and train detection elements have a position
information. A route ends at the destination signal, whereas the TVD section of
destination track shall include the exit signal position, i.e. the related train
detection element is at the signal position or some meters in advance of the
signal. Thus a train approaching the signal will never leave the running path of
the route.
Best regards,
Joerg v. Lingen - Interlocking Coordinator
Am 19.11.2024 um 07:49 schrieb David Lichti:
> Dear Community,
>
> In the context of a new railML 3.2 infrastructure export, we
> need to add some information about the construction aspects
> of blocks. railML already has the
> https://wiki3.railml.org/wiki/IL:route. But this element
> does not seem to have suitable attributes for the following
> properties:
>
> Approach Signal Distance: The (nominal) distance of the
> approach signal from the route's destination signal.
> Line of Sight: The maximum distance from which the
> route's exit signal can be recognized. This may be
> different for each route ending at a particular main signal.
> So the sightDistance property of
> https://wiki3.railml.org/wiki/IL:signalIL is not suitable.
> Linear Location: Exact limits of a route in the microscopic
> infrastructure. This may differ from the area enclosed by
> the entry and exit signals, if those are not located exactly
> on the block boundaries.
>
> Is there any suitable alternative for modelling this data in
> railML 3.2? Or should we design an extension? It seems to me
> that this would best be solved by a routeIS element in the
> infrastructure sub-schema. This would be similar to the
> modelling of signals and switches.
>
> Best regards
>
> David
|
|
|
|
| Re: [railML 3.2] Modelling of Routes [message #3432 is a reply to message #3430] |
Tue, 14 January 2025 14:43 |
David Lichti
Messages: 47
Registered: December 2020
|
Member |
|
|
Hi Jörg,
I will try to clarify our requirements:
Quote:
Do you mean the distance between the main signal and
its related distant signal (Vorsignalabstand)? If yes, this could be calculated
from the positions of these signals.
Yes, this is the distance from the distant signal to the main signal. However, these approach signals are usually not modelled as individual objects in our infrastructure. So, we would have to invent a signal that does not exist in the original infrastructure model.
<signalIS id="as-1">
<isAnnouncementSignal/>
</signalIS>
Still this seems like a very complicated way to transmit a simple number...
Quote:
It is not clear, why SignalIL/@sightDistance does not suit and
why it might be different depending on route?
This is just the way the infrastructure is modelled in TPS: The sight distance is a property of the route, not of the signal. It is not the minimal sight distance required by some abstract regulations, but the effective line of sight in the specific situation. This may be much longer than the minimal required distance. The exact value is important to make realistic estimates of the driver's reaction to signal aspect changes.
You may imagine a bent railway line with multiple, parallel tracks. In case of a main signal behind a track change, there may be two parallel routes with the same destination signal. When a train approaches this signal on the outer track, it is very likely that the driver can see it much earlier, than on the inner track.
Quote:
All signals and train detection elements have a position
information. A route ends at the destination signal
TPS does not require routes to start on a signal. Exporting such a route with the current model of railML 3.2 would lose all location information up to the first switch. Is there any dummy track element that we could then place at the start of such a route?
Best regards
David
|
|
|
|
|
|
| Re: [railML 3.2] Modelling of Routes [message #3497 is a reply to message #3447] |
Tue, 04 March 2025 12:08 |
David Lichti
Messages: 47
Registered: December 2020
|
Member |
|
|
Quote:The relations of signals with their aspects within a route are defined in
signalBox/implementsSignalplan/aspectRelation. Unfortunately, we do not have any detailed interlocking information. In particular, there is no signal box, no signal plan, and no aspect information.
Quote:In the majority of cases the signal is in rear of a track change. Exceptions are
conceivable in the approach area of large stations. Our infrastructure export should cover all cases that can be modelled in our infrastructure model, not just the majority of cases. Using only the signalIL@sightDistance attribute may cause data loss.
Best regards
David
|
|
|
|
Members
Search
Help
Login
Home
