Home » railML newsgroups » railML.infrastructure » Haltetafel / stop post
| Re: Haltetafel / stop post [message #469 is a reply to message #462] |
Mon, 26 November 2012 12:45   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Christian,
> thank you for your detailed explanation about the difference between
> infrastructure and operational rules, with which I totally agree.
+1
> So, we will come back to the definition of the parameter "bounding" with
> values "min", "max" or "interpolating", when there are stop posts that
> somehow physically include this information.
I am not very satisfied with this solution but - I have no better idea.
Obviously we are in the "gray zone" between operational rules and
infrastructure, combined with some "illogic" usage of H-posts in practice.
Your suggestion seams to be the best we can do for now. But there would be
still many questions left, e. g.:
- If a simulation software founds several H-posts at a track with
different properties (min/max train length, axle count, waggon count), the
relation between the properties were not clear.
- The terms "min" and "max" could be misunderstood as boundaries of
interpolation (outermost H-posts in Switzerland) and as "for all trains up
to a length of..." (H-posts in Germany). We intend to mean the latter, but
this cannot necessarily be deduced from the terms. So we possibly regulate
nothing with the new attribute. The enumeration values of the attribute
you suggest would (theoretically) have to be named "for all trains up to"
(=max), "for all trains with more than" (=min), "only for trains with
exactly" (=interpolating).
Since these problems become clear, I could also imagine that we leave it
with the absolute minimum of information which is obviously
infrastructure: The additional values or strings which are written at
H-posts but nothing more. Since "interpolating", "min", and "max" are
(currently) not written at the H-posts, this attribute would be off.
This would possibly mean to provide an optional string attribute for
H-posts only. And leave the interpretation of that string either to the
reading software (for the moment) or to an <operationalRules> scheme (for
the future).
Of course I would also accept the attribute you suggested in spite of the
problems which come with it. If you want to introduce it, please consider
a self-explaining naming of the enumeration values.
Best regards,
Dirk.
|
|
|
|
Current Time: Wed May 08 18:43:28 CEST 2024
|
Members
Search
Help
Login
Home
