| [railML 3.2] How to handle different granularity in node-edge-models at the level="micro"? [message #2859] |
Wed, 08 December 2021 16:50  |
Karl-Friedemann Jerosch
Messages: 11
Registered: May 2020
|
Junior Member |
|
|
Dear railML users,
as a node-edge-model can be described in railML by using the topology elements "netElements", "netRelations" and "networks",
it is possible on the one hand (option 1) to define in railML a topology whereas the nodes are only switches, buffer stops and other kind of project topology borders.
On the other hand (option 2) it is also possible to define in railML a topology whereas axle counters are considered as nodes additionally to switches, buffer stops and other kind of project topology borders.
How should data exchange between two (or more) tools be managed, if one (or more) is working with option 1 and the other one(s) is running with option 2?
[Updated on: Wed, 08 December 2021 16:51] Report message to a moderator |
|
|
|
| Re: [railML 3.2] How to handle different granularity in node-edge-models at the level="micro"? [message #2992 is a reply to message #2859] |
Mon, 04 April 2022 16:19  |
Milan Wölke
Messages: 139
Registered: April 2007
|
Senior Member |
|
|
Hi Karl-Friedemann,
from my point of view it should work in a way, that one first matches the funtional infrastructure elements, the ones that have an identity that exists across systems. It would be best to do this at least with the ones that have a spotLocation. Like this it should be possible to distinguish between elements that exist in the railML and in the importing system, the ones that do not exist in the railML anymore and the ones that are new in the railML. Next, one would search for the nearest elements known in both models of each element known in both models (I would define nearest based on the importing systems data). With this the mapping of the two graphs should be possible and based on this all other functional elements should be possible to be placed either on existing edges or on edges that are new in the incoming railML.
Another more obvious approach would be to follow the track-graph that exists on top of the netElement, netRelations graph. Of course this would only work if the necessary trackBegin and trackEnd information exists in the incoming data.
My 3 cents. Hope it helps some. I would really be interested in your experience with this algorithm? What was your approach so far?
Best regards, Milan
Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
