search

ogdf / ogdf

OGDF, the Open Graph Drawing Framework/Open Graph algorithms and Data structure Framework.
http://www.ogdf.net/
Other
311 stars 107 forks source link

Process z coordinates #160

Open milsen opened 7 years ago

milsen commented 7 years ago

In GitLab by @KarstenKlein on Mar 25, 2017, 16:25

Some layout methods (StressMinimization,...) and also the GraphAttributes allow z-coordinates, but they are ignored for example in file import and export. If a GraphAttributes has a threeD attribute set, the third coordinate should be written in formats that support it (graphML,...).

milsen commented 7 years ago

In GitLab by @wirkom on Mar 27, 2017, 16:33

MR !349 looks at reading and writing GraphAttributes and the issue will be solved by it, i.e. DOT and GML will get that feature, but GraphML (and TLP, GDF and GEXF for that matter) should already be capable of handling z.
@KarstenKlein Was GraphML just an example for a format capable of handling GraphAttributes or did the problem occur with GraphML for you?

milsen commented 7 years ago

In GitLab by @KarstenKlein on Apr 4, 2017, 14:59

Great. There are two aspects here: That all coordinate dimensions are read/written by parser/writer, that this is consistent for the flexible formats (GraphML, as it is the expressed intention that e.g. x does not need to stand for the x coordinate) for at least a few major tools, and second that the behavior is intuitive, i.e. when a 3D layout is computed, it is really written without manual tweaks etc. (I think StressMinimization reads the GA threeD attribute now, but PivotMDS has an internal static const dimension_count that is blocking 3D calculation if not manually set to k>2).

For the consistency, I created a 3D layout and exported it in GraphML, and MIru (can do 3D) and yEd (can't but should read x and y) both don't show any layout.... yEd complains that it doesn't know what to do with x and y floats..., miru says something about yEd style layout...

As there are more and more competitors for at least ok-ish large graph 3D layout, and they gain popularity (graphs in VR), it might be good to use what we actually already support, but nobody can use right now.

milsen commented 7 years ago

In GitLab by @wirkom on Apr 4, 2017, 19:43

Aspect two:
This is an issue that doesn't really have something to do with GraphAttributes, I suppose, but with how the implementation of the methods is done. So this is not something !349 will solve.
Aspect one: You're right, yEd can't read graphML's written by the OGDF. The complaint with float is not really an issue, as yEd (correctly) translates the coordinates to double and it will be "fixed" by changing the type of the coordinates to "double" in general for GraphML. The bigger problem is, that AFAIK there is no standard for GraphML for handling coordinates. Our approach is to define an attribute, while yEd introduces its own "nodegraphics" and handles coordinates, height, FillColor and other stuff in there. I suppose, it is debatable whether the OGDF should be changed to write GraphML in the style of yEd for more compatibility with yEd (and Miru), but this can be archived by just writing to gml in the OGDF, or leaving it like it is to ensure compatibility with older versions of the OGDF.
With Miru I can't check why the OGDF GraphML can't be read, I'm afraid, but gml works fine (even in threeD).

milsen commented 4 years ago

PivotMDS has an internal static const dimension_count that is blocking 3D calculation if not manually set to k>2

503dfe2b6852c34e560c60a1c40273919c16a864 fixes this. PivotMDS now also sets the dimension count to 3 automatically if GraphAttributes::threeD is set.