| Re: "stop post" / "platform edge" reference from ocpTT [message #866 is a reply to message #862] |
Fri, 09 November 2012 12:48   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear all,
> I would tend to separate commercial aspects of a stop description from
> operational ones. The Czech timetables, e.g., publish only platforms but
> no tracks. It should be possible to express this in railML.
....
> That's why I would, with caution, pledge for being flexible here: allow
> for an ocptt to refer to a platform without referring to a track or stop
> post, as well as referring via the track.
Please note that currently there is no <platform> in RailML in the "Czech
sense". We do have <platformEdges> but even _one_ "Czech" platform would
have _two_ <platformEdges>. Theres is, as far as I see, currently no
possibility to "to refer to a platform".
> Now we /could/ say that for the sake of publication, the trackInfo
> attribute is what you have to use. But this being purely textual, we
> would loose reference to the infrastructure model.
I agree: A non-plaintext possibility would be much better. But that would
mean to further expand RailML in this direction in advance - before we
have practical need. Since we cannot do everything at the same time, I
think it's better to postpone this and wait.
Let's remember that the current discussion was only about "trackInfo" to
declare obsolete or not.
> There may be more than one stop post that refers to the same platform
> edge.
>
> I thought the train part should refer to its appropriate stop post if it
> exists otherwise to the platform edge.
It is not common to do so in timetables because the operational rules
clarify which stop post to take and would always have "higher priority"
over any timetable information of that kind.
However, I agree that this could be a "theoretic wish", pure
informational: To get a part of the operational rules (which stop post to
take) into RailML. If we deem it necessary, we should provide the
"stopPostRef". Again, it would be a kind of redundant.
> That would mean to keep the stop post ref and don't implement the
> platform edge ref.
>
>> So why not "forcing" to use <ocpTT>.trackRef to come from a train to
>> platformEdges and stopPosts?
>
> Sorry, I don't understand this suggestion.
In my opinion, a platform and the stop posts always belong to the same
station. The "belonging" (linkage) of platforms and stop posts to a
station is an infrastructure information.
So why repeating this infrastructure information at each train? Isn't it
simpler to express is only one time in the infrastructure?
--> providing references from a <platformEdge> to an <ocp>: <platformEdge>
gets an "ocpRef".
--> We then also have the references from the stop posts to its ocp's via
the platformEdges, but there may be stop posts without platforms
(freight-only tracks), so: providing references from a <stopPost> to an
<ocp>: <stopPost> gets an "ocpRef".
--> A <trainPart><ocpTT> already refers to an <ocp> and a <track>. With
this information one can find the <platformEdges> and <stopPosts> through
the infrastructure.
Conclusion:
Since Andreas does not plead against this redundancy, I also would accept
a "shortcut" from <trainPart> with a "stopPostRef" or "platformEdge" or
both.
I think it is necessary to introduce the two "ocpRefs" at <platformEdge>
and <stopPost> because we cannot expect that the programmes always refer
to the stop posts.
Best regards,
Dirk.
>> I don't think so. I would provide only one way and wait until somebody
>> claims and explains why there is a need for another one which is not
>> redundant.
>
> I would like to ask in advance because of the experiences in other
> cases: Changing an attribute into an element is not so easy done.
I was not aware that this is about <element> or attribute. I thought the
question is more or less attributes only. However, our experience shows us
that often we learn much more when implementing the schemes. So we should
not do too much in advance.
|
|
|
|
Members
Search
Help
Login
Home
