Home » railML newsgroups » railML.infrastructure » ocpRef at <platformEdges> and <stopPost>
ocpRef at <platformEdges> and <stopPost> [message #424] Fri, 09 November 2012 13:06 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Christian and all others,

with the new <platformEdges> and <stopPost> elements, I was only now aware
that they have no ocpRef attributes so far.

I herewith plead for these ocpRef attributes because we need them to link
the timetable information with the new infrastructure elements.

Background: Often the timetable programmes do only refer to an OCP (stop,
passing through) but not to a certain platform or stop post. The question
"which stop post to take" when stopping at a station is normally clarified
by the operational rules. Therefore, it is not common to clarify it again
with the timetable because it would be redundant to the operational rules.

So, a train in its <ocpTT> refers to an <ocp> and a <track> but not
necessarily to a <stopPost> or <platform>. To find the platforms or stop
posts for that stop anyway, there should be the ocpRefs.

--> 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".

---
In general:

- This applies theoretically not only to <platformEdges> and <stopPost>
but possibly to other track elements as signals and more. So possibly all
should get an optional ocpRef attribute, may be by inheritance. Currently
we do not have practical demand for that but theoretical it may come
quickly (drivers timetables normally also name the signals belonging to a
station...)

- There was a suggestion to provide all references as cross-references in
future. Therefore, an <ocp> should also name (enumerate) all its
<platformEdges> by refereces, possibly all its track elements. Again, I
see not specific demand now, it is a more general question.

Currently I only opt for the two now attributes; the general questions may
be discussed or postponed.

Best regards,
Dirk.
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Track: description vs. trackDescr
Next Topic: loading gauge
Goto Forum:
  


Current Time: Thu Apr 18 13:57:17 CEST 2024