| Re: Station borders [message #2340 is a reply to message #2318] |
Mon, 24 February 2020 10:39  |
Thomas Langkamm
Messages: 25
Registered: April 2019
|
Junior Member |
|
|
christian.rahmig wrote on Fri, 24 January 2020 17:31
There are several candidates for implementation:
* a dedicated <border> element
* evaluate (linear or area) location of <operationalPoint>
* topology-based aggregation of <netElement>
I would suggest to implement option (3), topology-based aggregation. A "station" is at its core a topological element, and I would assume that it is a typical netElement in a macroscopic topology. As elements from more detailled topologies must be consistent with the top-level topology, that is, a microscopic netElement (representing a track, or part of it) must be either part of the station or not, but it's not allowed that only a part of that netElement is in the station and the remaining part is not. So we'll have to make sure that the netElement ends at the station boundary anyway.
For (1), I don't like borders. It has the potential of contradicting definitions, if you add a single track and forget to define the border then suddenly the whole track plan is the station (or at least a lot more than intended). Even worse things can happen if we mix up inside or outside. My favored solution (3) leaves no possiblity for a snafu, either a netElement is assigned to the station netElement or not.
(2) is just (1) in disguise, I think. In the end we define a border based on a positioning system.
An editor could of course still use a border element to visualize the boundaries of the station. But I'd prefer it to be a derived object, not a persistant one.
[Updated on: Mon, 24 February 2020 10:41] Report message to a moderator |
|
|
|
Members
Search
Help
Login
Home
