I have to admit, I'm not familiar with that¹. Do you have a link to a paper or something; I could ask our layout team.
But probably the answer will be that few customers asked so far and/or it might be fairly easy to accomplish with customizing one of the existing layout algorithms. We did something similar with our example BPMN implementation where a pre-processing step applied constraints for the hierarchic layout based on the node/edge types in the diagram. The vast majority of things customers ask of us are actually fairly easy to implement without necessarily having them in the library. So we have very few layout algorithms that are applicable to exactly one kind of diagram (family trees are an exception, but even that is just a wrapper around a more general-purpose algorithm).
The advantage is that there are very many knobs and configuration options to fiddle with to get the layout you want. The disadvantage is that there are very many knobs and configuration options to fiddle with, where having special layouts for certain types of graphs might be easier but not as flexible.
In the end, it's a library and the users (from our perspective) are developers and those shouldn't shy away from writing some code. It would be nice to also appeal to people who just want some data laid out nicely. To some extent that works already², but such wishes have to be balanced with what people are willing to pay for :-)
______
¹ Happens often with very domain-specific graphs; last thing mentioned I didn't know was some kind of diagram to describe pipes, valves, and water flows in buildings.
Your ¹ sounds like the Sankey diagram[1]. I only know about these because at one time matplotlib advertised support. And because of the classic diagram that Tufte promotes [2].
But probably the answer will be that few customers asked so far and/or it might be fairly easy to accomplish with customizing one of the existing layout algorithms. We did something similar with our example BPMN implementation where a pre-processing step applied constraints for the hierarchic layout based on the node/edge types in the diagram. The vast majority of things customers ask of us are actually fairly easy to implement without necessarily having them in the library. So we have very few layout algorithms that are applicable to exactly one kind of diagram (family trees are an exception, but even that is just a wrapper around a more general-purpose algorithm).
The advantage is that there are very many knobs and configuration options to fiddle with to get the layout you want. The disadvantage is that there are very many knobs and configuration options to fiddle with, where having special layouts for certain types of graphs might be easier but not as flexible.
In the end, it's a library and the users (from our perspective) are developers and those shouldn't shy away from writing some code. It would be nice to also appeal to people who just want some data laid out nicely. To some extent that works already², but such wishes have to be balanced with what people are willing to pay for :-)
______
¹ Happens often with very domain-specific graphs; last thing mentioned I didn't know was some kind of diagram to describe pipes, valves, and water flows in buildings.
² e.g. http://live.yworks.com/yfiles-for-html/2.0/databinding/graph... has only very minimal user code