| Re: ocp's/stations and their properties [message #319 is a reply to message #298] |
Wed, 27 June 2012 22:34   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi Dirk and others interested,
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
> Currently, it is not possible that one station has different
> properties (RailML: <ocp>.<propService>, <propOperational>,
> <propEquipment> a. s. o.) at different tracks or lines.
>
> From our experience, there are often stations where two or more lines
> meet and which have different properties depending on the line.
>
> I think one can easily imagine a station where two lines meet and
> which has platforms at one line but has no platforms at the other
> line. So, the attribute "<propService>.passenger" should be 'true' at
> the tracks of the first line and 'false' at the tracks of the other
> line.
>
> Also, you'll find often the arrangement where a junction for one line
> is a head of a station for the other line. (A line branches off at the
> head of a station but does not pass through the station.) A typical
> German example is Unterlemnitz (coords 50.469913° 11.624211°,
> http://www.openstreetmap.org/index.html?mlat=50.469913&m lon=11.624211&zoom=16)
> which is a junction for line #6683 (the line to the north-east) and a
> station for line #6709 (the line to the west).
We (Christian and me) hope that the concept of <ocpGroups> help out for
these cases. I try to figure out this as an example code snippet:
<tracks>
<track id="t_1" .../>
<track id="t_2" .../>
</tracks>
<trackGroups>
<line id="l_1" code="6709">
<trackRef ref="t_1"/>
</line>
<line id="l_2" code="6683">
<trackRef ref="t_2"/>
</line>
</trackGroups>
<operationControlPoints>
<ocp id="o_1" code="UUTL" name="Unterlemnitz">
<propService passenger="true"/>
<propEquipment>
<trackRef ref="t_1"/>
</propEquipment>
</ocp>
<ocp id="o_2" code="UUTL" name="Unterlemnitz">
<propService passenger="false"/>
<propEquipment>
<trackRef ref="t_2"/>
</propEquipment>
</ocp>
</operationControlPoints>
<ocpGroups>
<ocpGroup id="og_1">
<ocpRef ref="o_1"/>
<ocpRef ref="o_2"/>
</ocpGroup>
</ocpGroups>
The ocpGroup could be defined in several ways. One is the above minimum
variant.
The other is a more comprehensive one. It would define some general
properties of an ocp (composed of "ocp parts"). The ocps itself override
these general properties as shown "o_2".
<ocpGroup id="og_1" code="UUTL" name="Unterlemnitz">
<propService passenger="true"/>
<ocpRef ref="o_1"/>
<ocpRef ref="o_2"/>
</ocpGroup>
Different 'codes' for a <line> are not taken into consideration here,
they should be discussed in another thread. [1]
Introducing <ocpGroups> may become a really powerful concept.
Any comments and questions are highly appreciated.
Kind regards...
Susanne
[1] https://trac.assembla.com/railML/ticket/152
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Members
Search
Help
Login
Home
