Home » railML newsgroups » railML.infrastructure » Not navigable netrelations and crossings
| Not navigable netrelations and crossings [message #3678] |
Wed, 30 July 2025 22:31  |
Mathias Vanden Auweele
Messages: 72
Registered: February 2025
Location: Brussels
|
Member |
|
|
Hell railML!
I'm in discussion with a software provider about the topic of modelling crossings in a way that connectivity is sufficiently defined to create for example a track layout.
First I would like to ask a fundamental topology question: what is the use of a netrelation with navigability='None'?
As far as I could find, there is no definition, wiki or other type of documentation that states that netrelations define connectivity between netelements. Only navigability. So if I have to add all netrelations with navigability='None' in my database (well.. my knowledge graph actually), I will need to add a very big all-to-all type of matrix. Because I could define a non-navigability between any linear netelement and any other linear netelement (and that 4 times, due to the number of ends on each netelement). I can however imagen that it has been used in this sense when people try to define connectivity in the topology layer (when they shouldn't).
But even when assuming that netrelation do define connectivity. It is still redundant to define none-navigable netrelations because their connectivity is defined by the functional infrastructure layer (and the associatedPositioning system, but that's another topic).
Crossings define the two straight branches. For each branch, a reference is made to the applicable navigable netrelation. So the crossing defines the two netrelations for which the common ends of the linear netelements physically intersect. A similar thing is applicable for other types of switches.
So basically, none-navigable netrelations are redundant and connectivity can be defined completely in the functional infrastructure elements. Sufficient data is available with only navigable netrelations, linear netelements and branch data for the crossings element, Right? :-)
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
| Re: Not navigable netrelations and crossings [message #3682 is a reply to message #3678] |
Mon, 04 August 2025 11:43  |
Rémi Collet
Messages: 12
Registered: November 2024
|
Junior Member |
|
|
Mathias Vanden Auweele wrote on Wed, 30 July 2025 22:31Hell railML!
You said it yourself !
---
Remember we had more or less this conversation when I started @Infrabel ?
Disclaimer : I do not claim to have the answer, I am trying to brainstorm to the best of my abilities and maybe we can find the truth together.
The NetRelations inform that two NetElements are physically touching each other, or are "connected".
The Navigability property informs whether that physical connection can translate to a train running between the two, without stopping and reversing. So, Navigability only has to be informed between two NetElements that are NetRelated (TradeMark)
Let us imagine this simple intersection :
There are multiple ways to model it according to railML onto 0.6. I think that all are equally valid.
As we can see, especially on the first two models, we cannot infer routes from all Navigabilities. We do need the Non-Navigability property between the two western NetElements.
The third model is a bit of a weird one, though technically permitted by railML 0.6 onto, this is not usual port modelling. There, we define Navigabilities only through NonLinearElements. Why ? Because we technically can.
Side note : route-making in a setting can only be inferred using only one type of Element (either Linear or NonLinear), one by one, and entering by one end and exiting by the other end.
In any case, the conjunction of NetRelations and Navigalibities informs us of the type of switch we have. Here, we know we have a simple switch, and we know its shape. If we have any other configuration or NetRelations and Navigabilities, we would have a different type of switch. The only thing we do not know is the orientation of the whole thing.
---
Now, I do agree that routes and Navigabilities do not belong in the Topology. If tracks are physically connected, and if the topology is just that, then mundane and menials concerns such as "blah blah a train cannot stop and reverse blah blah" have no place in our heavenly home of Topological abstractions. These types of rules are pure signaling and physical world constraints that the Topology has no dealings with.
---
Is it redundant to have Non-Navigability then ? Yes, I think so. I am scratching my head and finding no case where it is utterly necessary. As soon as we have NetRelations + PositiveNavigabilities (TradeMark), then NegativeNavigabilities (TradeMark) are superfluous because : the presence of a NetRelation and the absence of a PostiveNagivability between two elements can only indicate a PositiveNavigability.
Again, if we let the Divine Topology be bothered by earthly inconveniences and have OneWayNavigabilities, then the latter holds no more. However, since you did not touch on that, I guess that you do not have OneWayNavigabilities as use case, same as Infrabel.
---
To summarize, according to my opinion, and having the disclaimer in mind,
Mathias Vanden Auweele wrote on Wed, 30 July 2025 22:31So basically, none-navigable netrelations are redundant (1) and connectivity can be defined completely in the functional infrastructure elements (2). Sufficient data is available with only navigable netrelations, linear netelements and branch data for the crossings element (3), Right? :-) (4)
(1) Yes
(2) Sure, if you want
(3) Yes
(4) Left please.
---
Cheers !
Ontologist @Infrabel (Belgian Railway Infrastructure Manager)
remicollet(at)infrabelbe
[Updated on: Fri, 29 August 2025 09:14] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Not navigable netrelations and crossings [message #3693 is a reply to message #3678] |
Mon, 11 August 2025 13:56 |
Dominik Looser
Messages: 31
Registered: March 2020
|
Member |
|
|
Hi,
This has sparked some interesting discussions and I'd like to state our point of view from an importing tool:
Usually, having only the navigable netRelations is enough information to build the whole network graph just by using the <topology>-subelement. Only for crossings, netRelations with none-navigability are necessary to know which netElements are connected with each other, but not navigable.
The question if netRelations should define connectivity or navigability is fundamental, but all indications point towards connectivity:
- the fact that there is navigability="none"
- all the examples kindly mentioned by Torben above
If we don't have these netRelation with navigability="none" for crossings, we have to look up the branches in <functionalInfrastructure>/<crossings>/... This would be the only time that the connectivity is *only* defined in <functionalInfrastructure>. In all other cases, the <topology> contains all the information we need.
I would therefore suggest to stick with the current usage of navigability="none" (at least for crossings) as seen in various examples, also in railML3.4+.
After all, a crossing has much more common with a double switch crossing than with a grade-separated flyover (which is not relevant for topology).
Best regards,
Dominik Looser
trafIT solutions gmbh
|
|
|
|
| Re: Not navigable netrelations and crossings [message #3706 is a reply to message #3693] |
Thu, 28 August 2025 15:34 |
Mathias Vanden Auweele
Messages: 72
Registered: February 2025
Location: Brussels
|
Member |
|
|
@Torben:
Quote:- Most important, I read the documentation of netRelation [3] to require the usage of none-navigable netRelations. This as the navigability attribute is "obligatory" and it has the value "none". Why else have the value?
Could you clarify 'require the usage of none-navigable netRelations' in source [3]? I do not see it anywhere. That source requires that the attribute 'navigability' is filled in, but not that netRelations should exist for none-navigable relations.
I have also seen that most of the switch and crossing example are using none-navigable netrelations but my point is that the definitions and rules of RTM and railML don't require their use. So it's not mandatory and the discussion I would like to have here is that it's actually completely redundant except for when you want to define connectivity in the topology layer. But then that requirement should be defined in the netRelation wiki page so everyone knows and agrees.
But as I state above, that's not what I think that the topology was originally meant for and it's not needed either. In my opinion it's even way better to define connectivity in the functional infrastructure layer instead in the topology layer. But if the community disagrees with me then I'm fine with that as well, just please make that clear in the definition and the rules then and not just in the examples.
@Dominik
[/quote]The question if netRelations should define connectivity or navigability is fundamental, but all indications point towards connectivity:[/quote]
That doesn't make sense on a meso or macro scale.
Quote:
- the fact that there is navigability="none"
Instead of removing the netRelation when it's no longer possible to go through that route, the attribute can be changed to 'none'. So the fact of having the option, doesn't need to mean it's meant to define connectivity.
(to be complete, when I say connectivity is not defined in the topology, I'm only referring to netRelations, not to the associatedPositioning system properties of netElements in which connectivity can be defined using coordinates)
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
Goto Forum:
Current Time: Sat Nov 15 19:25:58 CET 2025
|
Members
Search
Help
Login
Home
