Home » railML newsgroups » railML.infrastructure » Something about platforms, platformEdges, serviceSections and their relation to a track
Something about platforms, platformEdges, serviceSections and their relation to a track [message #456] Tue, 20 November 2012 11:03 Go to previous message
Carsten Weber is currently offline  Carsten Weber
Messages: 27
Registered: November 2011
Junior Member
Dear infrastructure users,

regarding to the current developer version and the discussions at the
meeting in Zürich I would like to give some hints:

1. At the moment I can not see any real difference between the
<platformEdge> and the <serviceSection>. The <platformEdge> is predefined
for passenger exchange and <serviceSection> describes the same things for
all other things which can be exchanged between vehicles and the current
station. So for me it is usefull to combine both elements by adding the
boolean attribute /passengerExchange/ to the <serviceSection>. Please make
sure that such combined "platforms" exist. For example at Wien Westbahnhof
you can load or unload your car at the same platform where you board or
disembarque the coaches. It think it is not a use case to describe this
platform as a <platformEdge> and a <serviceSection> too.

2. Both elements (<serviceSection> and <platformEdge>) are at the moment a
child of ONE track. This will bring trouble in a case where you will find a
point at the platform section if you use the microscopic infrastructure
model. So you have to change the track at the platform. In the current
version you will find the first section at track A and the second section at
track B but both sections are one and the same platform. At the end it means
you have to put the elements at the same level like tracks. So every element
has to have the option to define one or more relations to a track. This
relation includes the ref to a track, the position at the track, the
direction, the side and so one. For further use it would be usefull to group
these coordinates in an attribute group to recall them several times and for
use in other elements which might be described in the (near?) future. (This
topic is the same for tunnels, bridges, levelCrossings and so on.)

3. It would be usefull to implement an element like <platform> which has
several childs like <serviceSection> or <platformEdge> (or maybe both). So
you can find out whether a connection will be done at the same platform or
not. This is helpful if you do some routing for passenger information. This
mother element can also include the link to an ocp so it can be taken away
from the <platformEdge>. So you are also able to link a <platform> or a
<platformEdge> depending on the information you want to give to the
following systems.

4. As discussed in Zürich it is necessary to link two <platform> or
<platformEdges> from an ocpTT. (This is more topic for timetable scheme).

Best regards.

Carsten
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Tools zum Erstellen der Topologie / Tools for creating the topology
Next Topic: <crossSection>.ocpTrackID
Goto Forum:
  


Current Time: Fri May 03 15:26:34 CEST 2024