| Something about platforms, platformEdges, serviceSections and their relation to a track [message #456] |
Tue, 20 November 2012 11:03  |
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
|
|
|
|
| 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
|
|
|
|
|
|
| Re: Something about platforms, platformEdges, serviceSections and their relation to a track [message #459 is a reply to message #457] |
Wed, 21 November 2012 23:30 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Christian, Carsten and others,
Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>> 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.
I'm sorry I don't really understand the difference between this aspect
(Trac ticket #122, comment #8, [1]) and the one written in Trac ticket
#209 [2].
The grouping of platform edges offers the possibility to refer only one
platform from the ocpTT (from the train part). That's is already an
important step into the direction of modelling "real" platforms.
The "parentPlatformEdgeRef" should only refer to platform edges that are
"in sequence" not "parallel", shouldn't it? If you may group "parallel
platform edges" that would mean to model a "platform" and should not be
defined with the same "parentPlatformEdgeRef".
If the "parent platform edge" should not have any length and/or height
parameters (what I would prefer because of reduced redundancy) their
should be another element definition for it. It is not similar to the
'ocp concept' because you may not "overwrite" some features at the
children level and inherit some features from the parent level. It is
more or less a grouping concept like the "trackGroup/line" concept.
This would possibly need to define two distinct levels, one for single
platform edges with defined length and height and side values and one
for grouping them with the ocpRef reference. The grouping element should
be referred from the ocpTT. That would enable to define a "platform
number" without any knowledge of length and height.
Any comments appreciated.
[1] http://trac.assembla.com/railML/ticket/122#comment:8
[2] http://trac.assembla.com/railML/ticket/209
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: Something about platforms, platformEdges, serviceSections and their relation to a track [message #460 is a reply to message #459] |
Thu, 22 November 2012 09:46 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Good morning Susanne,
> I'm sorry I don't really understand the difference between this aspect
> (Trac ticket #122, comment #8, [1]) and the one written in Trac ticket
> #209 [2].
The Trac ticket #209 was created, because I closed the ticket #122,
which belongs to railML 2.2 while the topic of a track-independent
<platform> element belongs to railML 2.x or higher.
> The grouping of platform edges offers the possibility to refer only one
> platform from the ocpTT (from the train part). That's is already an
> important step into the direction of modelling "real" platforms.
>
> The "parentPlatformEdgeRef" should only refer to platform edges that are
> "in sequence" not "parallel", shouldn't it? If you may group "parallel
> platform edges" that would mean to model a "platform" and should not be
> defined with the same "parentPlatformEdgeRef".
The parameter "parentPlatformEdge" is only used for grouping platform
edges "in sequence" e.g. platform edges with different heights that
still form one physical PLATFORM EDGE. As you correctly mentioned, the
grouping of platform edges at one PLATFORM will be only possible with
the <platform> element suggested in Trac ticket #209.
> [1] http://trac.assembla.com/railML/ticket/122#comment:8
> [2] http://trac.assembla.com/railML/ticket/209
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Members
Search
Help
Login
Home
