| Re: speed profiles and braking percentages [message #405 is a reply to message #395] |
Wed, 24 October 2012 18:00   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Christian,
in many countries we have to "highlight" or distinguish between line-side
shown speed changes and such speed changes which are not shown (no signal
panel and no main signal). The "highlighting" can be of very different
kinds, for instance in Germany the non-presignalised speed changes have to
be shown inverse.
> In [1] the proposed attribute "signalised" for the <speedChange> has
> been discarded after the discussion with the other coordinators on
> September 10.
Well: How should we describe (in RailML 2.2 ff.) whether a speed change is
(pre-)signalised or not - so whether it has to be shown "highlighted" or
not?
Will that be possible from RailML 3.0 on only?
Also, I want to point out that this is not only a matter of "describing
infrastructure". It is also a matter of describing timetables, here
especially Driver's Timetables. So let's imagine I have to transfer a kind
of Driver's timetable from a planning software to an on-board system
(EBuLa or such). Normally, I do not write much infrastructure in such
RailML files - normally not all track elements and only the really needed
speeds.
Is it really the intention of RailML that, in such a case, I have to
create "panel" track elements for most of the speed changes only to tell
that they are not to be printed inversely?
Please take also into account: To know whether a speed change has to be
"highlighted" I only have to know _whether_ it is (pre-)signalised or not
- I do not need to know _where_ it is (pre-)signalised. To place a "panel"
track element in the RailML file, I would have to know _where_ the speed
change is (pre-)signalised. This is a special problem if the "highlight
status" depends on the pre-signalisation ("announcementPanel" rather than
the "executionPanel") - of course this is the more important panel since
the driver virtually can do nothing if he arrives at a "reduce speed
execution" panel without pre-signalisation...
Also, please take into account that between the "reduce speed
announcement" panel and the "reduce speed execution" panel there may be
points, especially trailing points (in contrary to facing points). So it
can become very difficult for a reading software... to scan all possible
routes leading to the speed change: If there is at least one route without
pre-signalisation (where there is no announcement panel in a proper
distance?) the speed change has to be shown inversely... I think this is
not a practicable solution.
Rather, in my opinion the "is (pre-)signalised" attribute is a _status_ of
a speed change - may be sometimes a somewhat indiscriminately assigned
status which cannot always be deducted from the real infrastructure.
With best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
