Scenario: I wanted each node to have a size visualizing a value, so I added a feature to my Nodes with the Feature Inserter and set the Network Viewer to use it as a sizing factor.
Result: The sizing is used, but now the edges are all over the place. They're only pointing into their target's general direction. Additionally, their lengths are off.
Variations: Changing the layout, the edge style or the label positioning didn't help. Setting the type of the feature to "double" or "float" makes no difference, while "int" is not recognized at all. Label positioning works, though, recognising the sizes.
I haven't found a workaround yet, sadly.
thanks for reporting the bug. I will have a look at it. It would help me to find the error faster if you could provide some more information such as the workflow or an image of the network view or the network viewer settings and they type of network you want to visualize.
Integer values are recognized and used as is e.g. a node feature 10 would result in a node size of 10 pixel whereas double features are used for scaling the default node size e.g. with a default node size of 10 pixel and a node feature value of 1.5 the node size would be 15 pixel. This holds for all sizes/width (node/edge label size, node size, edge width, etc.)
thanks for the fast reply. Attached is a minimal workflow and the result as it is generated on my machine. I'm just adding size information in the range 0-1 to nodes with base size 100. But the same result appears in other situations, for example in the network examples.
I know the task of computing the best attachment points is not an easy one, especially with all the different shapes and edge types, so I wouldn't mind if it was off a little. But it gets really confusing in more complex networks. Even more so because the edges tend to jump when nodes move.
My guess? You probably compute a line connecting the center points, which you then clip at the shapes' bounding rects. But quite often there are rounding errors and the like, making the end points jump to some fallback values. If the fallback values are the rects' corners, it would already help to use closer bounding rects.
thanks for the info. As you said it seems to be a problem with the edge anchor point computation. The larger the node the worse it gets. Unfortunately I can not offer you workaround. But I will report a bug and have a look into it as soon as I find some spare time.
the bug will be fixed with KNIME 2.11 which will be release in December.
Thanks again for reporting the issue,