使图形变得友好/可读(500 个节点,1600 个边)

发布于 2024-12-19 21:14:41 字数 1113 浏览 3 评论 0原文

我决定学习 DOT 语言,它看起来棒极了。我决定制作一个项目来为 RPM 构建制作图表。我扫描了所有构建 RPM 包的方法,并添加了有关所需补丁和导入的信息。目前我的图有不到 500 个节点和超过 1600 个边,并且大小应该稳定 +/- 50-100 个节点/边。

这是我现在所拥有的:

前两个比最后一个更具可读性。

详细信息:

  • 包装采用黑框盒子。
  • 补丁位于橙色边框框+橙色边缘中。
  • 进口是在红色边框框+红色边缘中。
  • 没有单个根包节点。我们可以说有几个顶级(根)包节点,4-10 个节点包(节点),它们导入大部分包。
  • 有独立的包(节点),没有依赖项,也没有依赖于它们。
  • 补丁只能(大部分)由单个包节点使用。
  • 并非所有包节点都有补丁。我想说一小部分包节点有它们。
  • 导入文件可以包含在包节点的很大一部分中(例如,所有包节点的1/3)。
  • 我有rankdir =“TB”(从上到下)
  • 我增加了边缘的重量(包 - >补丁)。这应该意味着补丁节点更接近其包节点。
  • 尽量减少覆盖节点的边数会很好。这使得图表变得不可读。

在这种情况下,对图形布局配置和算法使用有什么建议吗?

I have decided to learn DOT language, which looks fantastic. I decided to make a project for making a graph for RPM building. I scan all the recipes to build RPM packages and also add information about required patches and imports. Currently my graph has under 500 nodes and more than 1600 edges, and the size should be stable +/- 50-100 nodes/edges from time to time.

Here is what I have now:

The first two are a bit more readable then the last one.

Details:

  • Packages are in black bordered boxes.
  • Patches are in orange bordered boxes + orange edges.
  • Imports are in red bordered boxes + red edges.
  • There are no single root package node. We could say there are several top level (root) package nodes, 4-10 nodes packages (nodes), which import most of the packages.
  • There are standalone package (nodes), not dependencies and no on depends upon them.
  • Patches can be only (mostly) used by single package node.
  • Not all packages nodes has patches. I would say smaller part of packages nodes have them.
  • Import files can be included in a huge part of package nodes (e.g., 1/3 of all package nodes).
  • I have rankdir="TB" (Top-Bottom)
  • I have increased the weight on the edges (package -> patch). Which should mean that patch nodes are closer to their package node.
  • It would be nice to minimize number of edges overlaying nodes. This makes graph a lot unreadable.

Any suggestions on graph layout configuration and algorithm usage in this case?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

梅倚清风 2024-12-26 21:14:41

令人印象深刻的图表!
会发生什么

  • 我会尝试如果你给边缘一点透明度,
  • 实际上会让它们更长一点, 。我知道这会使图表更大,但它可以使其在视觉上更清晰一些,例如,如果您要打印它,最终得到的减小的字体大小可能会因更好的结构而被抵消。
  • 用其边框的轻型版本填充节点。
  • 使节点非常小并且只给它们索引号。然后创建一个与实际内容相匹配的颜色+索引号的图例。这可能违背了图表的目的,但仍然值得尝试。首先,只需省略标签并制作微小的彩色圆圈即可。不应该花太长时间,您最终可能会看到一些以前未见过的结构特性。如果您发现任何有用的信息,请尽可能少地获取节点上的信息,直到找到一个好的折衷方案。

哦,我也从来没有设法阻止 GraphViz 在节点上绘制边缘......

Impressive graph!
I would try what happens if you

  • give the edges a bit of transparency
  • actually make them a bit longer. I know this makes the graph even larger, but it could make it visually a bit clearer, and if you're going to print it for example, the reduced font size you end up with might be set off by the structure coming across better.
  • filling the nodes with a light version of their borders.
  • make nodes very small and only give them index numbers. Then create a legend matching color + index number to the actual content. That might defy the purpose of your graph, but still, it might be worth trying. For starters, just leave out the labels and make tiny, colored circles. Shouldn't take too long and you might end up seeing some previously unseen structural properties. If you find anything useful, work your way back up to as little on-node information as possible until you find a good tradeoff.

Oh, and I've never managed to keep GraphViz from plotting edges over nodes either...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文