| Re: Something about platforms, platformEdges, serviceSections and their relation to a track [message #457 is a reply to message #456] |
Wed, 21 November 2012 21:08   |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Dear Carsten,
> 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.
your comment made me smile, because in the forum discussion in [1] we
agreed on defining two separate types for describing platforms and
service sections. However, they are not that different anyway and the
<serviceSection> element contains the same attributes as a
<platformEdge> plus few boolean parameters for further specification of
the provided service. In case there is a PLATFORM where passengers can
board the coaches AND the vehicle can be loaded etc., you need to define
both elements: a <serviceSection> and a <platformEdge>.
> 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.)
Having a platform that is longer than one track remains a problem, which
cannot be solved at the level of the track-referenced platform-edges. As
you correctly mentioned, this requires an element at the same level like
tracks, and thus is independent from the single track. In my opinion,
this aspect is closely linked with your next point...
> 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.
I absolutely agree with you that the <platformEdge> is not sufficient to
model the complete functionality of the "operational platform" such as
interchanges between platform edges situated at the same platform.
Therefore, the introduction of a track-independent new element
<platform> is a good idea. Until now, I thought about this enhancement
as a topic for railML version 2.x with x>2 since I wanted to give it
some time in order to see how the introduced element <platformEdge> is
being used by the railML appliers before further extensions.
> 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).
How about the possibility of grouping platform edges similar to the
concept of the ocp grouping? Using the optional parameter
"parentPlatformEdgeRef" several platform edges (with lengths) can refer
to their common parent platform edge (without length). The ocpTT from
the timetable schema may then refer to the parent platform edge and
there is no need for further references.
[1] http://www.railml.org/forum/ro/?group=1&offset=0&thr ead=40&id=104
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Members
Search
Help
Login
Home
