Home » railML newsgroups » railml.timetable » reference from timetable's <stopDescription> to infrastructure's <stopPost>
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 messageGo 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
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: Ticket#77: vehicle services
Next Topic: Delay Causes Representation in RailML
Goto Forum:
  


Current Time: Thu May 16 15:36:45 CEST 2024