Should ILink have a property indicating if its direction direction is omni or bi-directional?

[rolyhudson]

This is in relation to planning create and convert methods for graphs as per PR #1014.

It would be nice to have easy converts between collections of ILink objects and water-tight-no-duplicate object graphs...

ILink currently has StartNode and EndNode properties from which a direction can be inferred and used to inform relations in a graph.

Sometimes though an ILink is used to represent a bi-directional object for example PR #1000 for cable trays which are by (@tiagogrossi 's) verbal definition bi-directional and implement ILink.

In the specific case of cable trays we want to create a graph to do shortest path queries, the graph should represent bi-directional relations. Also there maybe situations where routing problems must observe a mixture of omni or bi-directional links for example modelling roads where both one-way and two-way road objects should be required.

Some possible alternative approaches:

1. Define the ToGraph method accept a bool IsBiDirectional
2. Where we need bi-directional ILink objects we create one in both directions
3. Force adding a fragment that explicitly defines the topological relations of each object used in the graph
4. Add a property to ILink to define the direction

It would be good to hear thoughts on this @tiagogrossi, @pawelbaran, @IsakNaslundBh , @michaelhoehn, @al-fisher , @adecler

[IsakNaslundBh]

Would personally opt for option 1 or 3 for this, or an alternative solution to 4.

For bars a direction boolean/enum would not make any sense. if a direction, tangent, would be needed, it would be based on the start and end order. This is actually used for local orientation of the profiles when the orientation angle is non zero, but being able to flip it would not really make sense I think.

Rather than as a defining property though we could put it as an extension method required for all ILinks, and potentially have a default true/false for ILinks that do not require more granular control. Then for classes that you want to be able to flip, you could add this property and simply have the extension method return the value of the property, while something like that bar simply could return the default.

Does that make sense?

[rolyhudson]

Yes good to have your view, thanks. I think it comes back to the need for clearly separating and not mixing the ILink and relational concepts in the graph.