| Re: "stop post" / "platform edge" reference from ocpTT [message #862 is a reply to message #858] |
Fri, 09 November 2012 10:32   |
Andreas Tanner
Messages: 52
Registered: March 2012
|
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. 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.
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.
By the way, now that we are going to support delay infos, what about
changes in tracks and platforms? Well, maybe an issue for 3.0 and a
dedicated scheme for operation...
Best, Andreas
Am 08.11.2012 22:38, schrieb Susanne Wunsch:
> Dear Dirk, Joachim and others,
>
> Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>>> * A reference from the <ocpTT> to either a certain <stopPost> or a
>>> certain <platformEdge> is currently missing.
>>
>> But they would be a kind of redundant to "the way via the track" which
>> you described above.
>
> 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.
>
> You may cut the platform edge ref from the ocpTT if you refer to the
> stop post. There is a one-to-one reference from a stop post to a
> platform edge. But nevertheless there is no need to define platform
> edges at all. You may only define tracks and stop posts without platform
> edges.
>
>>> Both attributes are needed for different modeling levels. Some
>>> software tool handles platforms without stop posts another tool
>>> may only accept stop posts but no platforms.
>>
>> In other cases of that kind, RailML forces the user to use the one and
>> only way "in a wider sense".
>
> 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.
>
>>> * The current 'trackInfo' attribute in <ocpTT> would be marked
>>> deprecated.
>>
>> Generally: I understand and tend to agree. But: Do we possibly need
>> the "trackInfo" for additional (plain-text) info on the stop? Possibly
>> remarks for the passengers to be printed by a passenger information
>> system? Possibly for the difference between the railway-internal
>> (IM's) track number and a published platform number (think about
>> Czech platforms -
>> there is a platform name additionally to the track number).
>>
>> For the moment, I would leave the 'trackInfo' for individual
>> plain-text use like "remarks".
>
> I'm totally with you. There are enough examples from the practice for
> meaningful filling this attribute.
>
> But I feel a bit uncomfortable in changing the semantics without
> changing the attribute's name. The 'trackInfo' attribute is used for
> platform numbers up to now with no appropriate attribute name.
>
>>> Is there the need for more than one reference to either a 'platformEdge'
>>> or a 'stopPost'?
>>
>> 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.
>
> Kind regards...
> Susanne
>
|
|
|
|
Members
Search
Help
Login
Home
