| Re: Station borders [message #2366 is a reply to message #2347] |
Wed, 04 March 2020 16:37   |
Thomas Nygreen
Messages: 68
Registered: March 2008
|
Member |
|
|
Dear Thomas,
Dear Christian,
Christian is correct that all three are already possible, although I
interpreted (3) as something else than the currently available topology
aggregation, and more like <propEquipment> in railML2. I fully agree
that we need to limit the number of ways to model the same infrastructure.
To me, topology and functional infrastructure are separate. An
<operationalPoint> of type "stoppingPoint" does not change the topology,
and therefore it is not natural to me that it should have its own
<netElement>. We could require it, but it would have to be through a
semantic constraint, and that constraint would have to be worded to cope
with differing station border definitions, including networks that do
not have them.
Trouble with 2 and 3: As Dirk has pointed out a couple of times, station
borders may be direction-dependent.[1][2]
What is the purpose of defining station borders in the railML
infrastructure? How will the information be used? Maybe the candidates
serve different, (mainly) disjunct purposes?
One possibility is to narrow down the use of each of the existing
possibilities, to try to make them fully disjunct, e.g.:
(1) Borders mark a point in the infrastructure that is relevant for
operations, and should be used where needed by operational rules but not
to model the station area.
Pros: Allows direction-dependent borders. Avoids graph traversal to
determine station area. A missing border does not affect station area.
(2) AreaLocation should be used to define the station area.
Pros: Builds upon topology but does not need to be 1:1. Defined directly
as a child of <operationalPoint> (as opposed to multiple borders).
<operationalPoint>s inside another <operationalPoint> clearly defined.
Question: Should SpotLocation also be accepted, when there is no need to
define an area? Should we rule out LinearLocation for <operationalPoint>?
(3) NetElements model the underlying topology and should not be used to
model station areas (or other areas).
Pros: Purpose separated from AreaLocation. Does not require multiple
meso aggregation levels for <operationalPoint>s inside another
<operationalPoint> or splitting <netElement>s at stopping points.
[1] https://www.railml.org/forum/index.php?t=msg&th=482& goto=1476#msg_1476
[2] https://www.railml.org/forum/index.php?t=msg&goto=1990#m sg_1990
Best regards,
Thomas Nygreen - Common schema coordinator, railML.org
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
