Home » railML newsgroups » railml.timetable » reference from timetable's <stopDescription> to infrastructure's <stopPost>
reference from timetable's <stopDescription> to infrastructure's <stopPost> [message #896] Sat, 24 November 2012 11:06 Go to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear Joachim and railML users,

during the last railML.org meeting in Zurich I started wondering if we
really need a reference from the timetable's <stopDescription> to the
infrastructure's <platformEdge> or <serviceSection> (cp. [1], [2]).

For me, it seems to be sufficient to only have a reference to a
<stopPost> element and since the <stopPost> includes the boolean
parameter "virtual", it can be placed everywhere a train or locomotive
can stop (cp. [3]). Further, a stop post refers to its corresponding
platform edge via the parameter "platformEdgeRef", which might be
formulated in a more generic way to include the service sections as
well. Thus, a direct reference from the <stopDescription> to the
<platformEdge> or <serviceSection> would not be necessary anymore, would it?

Any comments appreciated...

[1] https://trac.assembla.com/railML/ticket/195
[2] https://trac.assembla.com/railML/ticket/208
[3] https://trac.assembla.com/railML/ticket/167

Regards

--
Christian Rahmig
railML.infrastructure coordinator
Re: reference from timetable's <stopDescription> to infrastructure's <stopPost> [message #898 is a reply to message #896] Mon, 26 November 2012 15:34 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Christian and all others,

I totally agree with your commit - it fits to the conversation from
08.11.2012 [Re: "stop post" / "platform edge" reference from ocpTT].

> For me, it seems to be sufficient to only have a reference to a
> <stopPost> element...

The only thing is:

>> The 'platformEdgeRef' alone would not be redundant for the very special
>> case if there are two platform edges at the same track and the train is
>> scheduled to open the doors at one of them only...

To understand how it came to all the references, please follow the
discussions with the above named topic from 08.-09.11.2012 (Susanne
Wunsch, Andreas Tanner, Dirk Bräuer).

The main reasons were
- a /platformEdgeRef/ is not enough because there may be several stop
posts at one <platformEdge>,
- a /stopPostRef/ is not enough because there may be two platforms at
each side of a track...

But anyway, I still agree that the current suggested solution with all the
/platformEdgeRef/, /serviceSectionRef/, /stopPostRef/ is not satisfying.

As we already discussed on <stopPosts> and their additional properties,
the "selection" of a certain stop post (out from all stop posts which may
come available at a track) is operational rule and currently out of
RailML. Additionally, we have learned that a train of course may (have to)
stop in-between two stop posts. So, to use <stopPosts> for trains is not a
general accepted practice. It would possibly lead to the creation of many
virtual stop posts, one for each train, which is clearly not intended here
so far.

So, I would strongly welcome to create a /platformEdgeRef/ but no
/stopPostRef/.

If you agree, to clarify this I would recommend for Wiki:

"Normally, there is a range or section of track where trains should stop
regularly. These ranges may typically lay alongside platforms, loading
ramps, or (other) service sections. But they may also lay in "pure" tracks
(operational stops, freight-only tracks). The exact place to stop in this
range may depend on the train length and other aspects. <stopPost>
elements with the attribute /virtual/='true' (virtual stop posts) are
intended to describe the extends where these ranges start, end, or
significant intermediate places. They are not intended to "disintegrate" a
continuous range into discrete, deterministic steps."

Best regards,
Dirk.
Re: reference from timetable's <stopDescription> to infrastructure's <stopPost> [message #899 is a reply to message #896] Mon, 26 November 2012 15:38 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Christian and all others,

I totally agree with your commit - it fits to the conversation from
08.11.2012 [Re: "stop post" / "platform edge" reference from ocpTT].

For me, it seems to be sufficient to only have a reference to a <stopPost>
element...

The only thing is:

The 'platformEdgeRef' alone would not be redundant for the very special
case if there are two platform edges at the same track and the train is
scheduled to open the doors at one of them only...

To understand how it came to all the references, please follow the
discussions with the above named topic from 08.-09.11.2012 (Susanne
Wunsch, Andreas Tanner, Dirk Bräuer).

The main reasons were
- a /platformEdgeRef/ is not enough because there may be several stop
posts at one <platformEdge>,
- a /stopPostRef/ is not enough because there may be two platforms at
each side of a track...

But anyway, I still agree that the current suggested solution with all the
/platformEdgeRef/, /serviceSectionRef/, /stopPostRef/ is not satisfying.

As we already discussed on <stopPosts> and their additional properties,
the "selection" of a certain stop post (out from all stop posts which may
come available at a track) is operational rule and currently out of
RailML. Additionally, we have learned that a train of course may (have to)
stop in-between two stop posts. So, to use <stopPosts> for trains is not a
general accepted practice. It would possibly lead to the creation of many
virtual stop posts, one for each train, which is clearly not intended here
so far.

So, I would strongly welcome to create a /platformEdgeRef/ but no
/stopPostRef/.

If you agree, to clarify this I would recommend for Wiki:

"Normally, there is a range or section of track where trains should stop
regularly. These ranges may typically lay alongside platforms, loading
ramps, or (other) service sections. But they may also lay in "pure" tracks
(operational stops, freight-only tracks). The exact place to stop in this
range may depend on the train length and other aspects. <stopPost>
elements with the attribute /virtual/='true' (virtual stop posts) are
intended to describe the extends where these ranges start, end, or
significant intermediate places. They are not intended to "disintegrate" a
continuous range into discrete, deterministic steps."

Best regards,
Dirk.
Re: reference from timetable's <stopDescription> to infrastructure's <stopPost> [message #900 is a reply to message #898] Tue, 27 November 2012 09:26 Go to previous message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Dear Dirk, Christian and others,

Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>
> The main reasons were
> - a /platformEdgeRef/ is not enough because there may be several stop
> posts at one <platformEdge>,
> - a /stopPostRef/ is not enough because there may be two platforms at
> each side of a track...
>
> But anyway, I still agree that the current suggested solution with all
> the /platformEdgeRef/, /serviceSectionRef/, /stopPostRef/ is not
> satisfying.

I mean that all of the above mentioned references work for different use
cases.

If a 'stopPostRef' is used, any 'platformEdgeRef' and
'serviceSectionRef' are redundant.
We may model this with a xs:choice:

"either stopPostRef or (platformEdgeRefs and/or serviceSectionRefs)"

* platformEdgeRef, if the software only handles some platform number
or handles different platform heights with regard to
formation characteristics,
but no stop posts for timetabling

* serviceSectionRef, if the software handles some service facilities and
the timetable is defined in such details that these
facilities are integrated into the train part run,
otherwise it would be defined as a 'mission' in
'blockPart' without any infrastructural reference

* stopPostRef, if the software handles stop posts, e.g. for simulating
drivers behavior

Multiple platformEdgeRefs and serviceSectionRefs were agreed as needed
for certain use cases at the meeting in Zurich, the single stopPostRef
was also shown and nobody argued against it.

> If you agree, to clarify this I would recommend for Wiki:
>
> "Normally, there is a range or section of track where trains should
> stop regularly. These ranges may typically lay alongside platforms,
> loading ramps, or (other) service sections. But they may also lay in
> "pure" tracks (operational stops, freight-only tracks). The exact
> place to stop in this range may depend on the train length and other
> aspects. <stopPost> elements with the attribute /virtual/='true'
> (virtual stop posts) are intended to describe the extends where these
> ranges start, end, or significant intermediate places.

+1

> They are not intended to "disintegrate" a continuous range into
> discrete, deterministic steps."

I'm sorry, I don't understand the intention of this sentence.

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Previous Topic: Ticket#77: vehicle services
Next Topic: Delay Causes Representation in RailML
Goto Forum:
  


Current Time: Fri Mar 29 08:08:21 CET 2024