You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the current data structure (a node has a list of nodes that it is connected to as well as three attributes connected_on_head/left/right that also reference nodes) it is difficult to represent a topology in which two nodes are connected to each other via two separate edges.
That topology happens quite often, e.g. when a line with a single track splits up to two platforms in a station:
So far, we couldn't support this at all. In simulate-digital-rail/orm-importer#49 we introduced inserting the same node twice in the list of connected nodes. That works so far, but as the left point only knows that it is connected to the right point twice and that connected_on_left and connected_on_right both lead to the right point, there is no way of identifying the corresponding edge from the node. As soon as there are signals, different speed restrictions etc. on those edges, this could be a problem. We should rethink the datastructure of the topology and maybe use something more like the PlanPro approach.
The text was updated successfully, but these errors were encountered:
With the current data structure (a node has a list of nodes that it is connected to as well as three attributes connected_on_head/left/right that also reference nodes) it is difficult to represent a topology in which two nodes are connected to each other via two separate edges.
That topology happens quite often, e.g. when a line with a single track splits up to two platforms in a station:
So far, we couldn't support this at all. In simulate-digital-rail/orm-importer#49 we introduced inserting the same node twice in the list of connected nodes. That works so far, but as the left point only knows that it is connected to the right point twice and that connected_on_left and connected_on_right both lead to the right point, there is no way of identifying the corresponding edge from the node. As soon as there are signals, different speed restrictions etc. on those edges, this could be a problem. We should rethink the datastructure of the topology and maybe use something more like the PlanPro approach.
The text was updated successfully, but these errors were encountered: