Welcome to yEd Q&A!
Here you can ask questions and receive answers from other members of the community and yEd developers. And you can tell us your most wanted feature requests.

Most popular tags

import node export labels edge nodes bug-report layout excel groups graphml yed edges properties-mapper palette svg automatic-layout swimlane custom-properties text properties error-report pdf group linux hierarchical-layout bug label macosx html bpmn kb print installation uml settings family-tree resize ui color label-placement grouping url yed-live graphmlviewer windows import-excel printing java line entity-relationship gedcom background save arrow flowchart link image error license positioning structure-view select font open icon data search default arrows tree lines copy size graph 64-bit diagram neighborhood-view fit-node-to-label description paste feature font-size icons xml symbols tooltip custom shape move selection editing edit - file-format ubuntu word visio alignment user-defined-symbols

Categories

Graph edge "type" ignored when importing a graph

0 votes
Current behaviour:

When importing a (graphml) graph, the default edge type is (kind of) ignored. Instead it relies on whatever the default edge type has been set to via the GUI.

Consequently, if yEd has its undirected edge pre-selected and the user loads a directed graph, after layout, it appears undirected.

Desired behaviour:

When importing a graph, the edge type should be set to whatever it is supposed to be in the file.

Steps to reproduce the error:

I was trying to layout a digraph constructed via networkx and saved in graphml.

1. From the "Palette/Edge Types" window, select the undirected edge

2. From "File/Open", load a graphml file for a **directed** network.

3. The edges of the graph should be depicted as undirected.

4. Repeat the above, but now replace "undirected" with "directed" at step 1.

5. The edges of the graph should now be depicted as directed.

Versions:

Ubuntu 18.04

OpenJDK 11.0.5

Python 3.6.9

Networkx 2.4

yEd 3.19.1.1

 

Hope this helps
in Help by (160 points)
recategorized by

1 Answer

0 votes

There seems to be a misunderstanding here: Edges in yEd are always directed. The arrow heads that may be displayed at the ends of an edge do not determine the edge's direction1 but are only a visual decoration:

Even though the edge in the above illustration does not have any arrow heads, it still has a source end and a target end.

If you select an edge (or node) template in yEd's palette, the template is set as default style for new elements. If you open a graph from GraphML, the default style is used if and only if the GraphML file has no (yEd-compatible) style information.

You can check this using a fairly simple test:

  1. Double-click the "Polyline" edge template without arrows in the "Edge Types" palette section to set "Polyline" as default style.
  2. Create a simple graph consisting of two nodes connected by one edge that uses the default "Polyline" style.
  3. Save the graph as GraphML file.
  4. Close the editor with your sample graph.
  5. Double-click the "Polyline with Target Arrow" edge template in the "Edge Types" palette section to set "Polyline with Target Arrow" as default style.
  6. Open the recently create GraphML.

You will notice that the edge in your sample file still does not have any arrow heads, even though you changed the default style to a style with target arrow heads.

1 The notable exception to this rule is yEd's Hierarchic layout algorithm. This algorithm offers an option "Arrows define Edge Direction". If that option is enabled (which it is by default), the arrow heads of edges effectively overwrite the edges' inherent direction for the calculations performed by this algorithm (and this algorithm alone).

by [yWorks] (160k points)
Hi, thanks for such a quick response.

I understand the response from the point of view of "yEd is only a drawing program".

But since the hierarchical algorithm "respects" directed edges, then it seems that at least part of yEd also respects what it means for an edge to be "directed".

Granted, a random graphml file might not contain (yEd-Compatible) information for yEd to pick up the drawing style of an edge but that can definitely be inferred by the `edgedefault` attribute (See for example: http://graphml.graphdrawing.org/primer/graphml-primer.html#BCfile).

The editor is by default supporting directed graphs which is clear (there was no "misunderstanding" about this by the way).

If the underlying edge style is undirected, no arrows are placed but if it is directed, the direction can be respected.

The issue of the direction of the edge and the placement of the arrow being two different things is very easily resolved. I cannot think of a use case where it is impossible to align the placement of the arrow and the direction of the edge beforehand, EXCEPT UML associations (e.g. composition/aggregation) where the direction and the placement of the symbol would have to be opposite. But such an edge has specific semantics and it would not originate from a "random" graphml file.

In that case, if the graph had to be saved in graphml I would expect that it contained enough information for its visual style to be set via (for example) the properties mapper.

But in the opposite case, where it is possible to infer the direction of the edge and the edge itself does not have any other data by which to decide the direction of the arrow why not use the directed style from the beginning?
by (160 points)

Re

But since the hierarchical algorithm "respects" directed edges, then it seems that at least part of yEd also respects what it means for an edge to be "directed".

All of yEd "respects what it means for an edge to be directed". However, it is not the arrow heads that determine direction. (This is the point I was trying to make in the illustration in my answer above.)

Re

I cannot think of a use case where it is impossible to align the placement of the arrow and the direction of the edge beforehand, EXCEPT UML associations (e.g. composition/aggregation) where the direction and the placement of the symbol would have to be opposite. But such an edge has specific semantics and it would not originate from a "random" graphml file.

Well, yEd does not make these kind of assumptions about direction correlating to visualization (or vice versa). Not making these assumptions is actually a key point of yEd and the underlying yFiles library.
Additionally, I do not think it is possible to determine if a GraphML file is a "random" GraphML file or not.

Re

If the underlying edge style is undirected, no arrows are placed but if it is directed, the direction can be respected.

...

But in the opposite case, where it is possible to infer the direction of the edge and the edge itself does not have any other data by which to decide the direction of the arrow why not use the directed style from the beginning?

I would like to stress once more that direction is an inherent property of edges in yEd. It is not the style that defines the direction of an edge. (Even in the case mentioned in the footnote of my answer above, the direction of the edge is not changed - only the algorithm treats the edge differently.)

If you know that the GraphML file you are about to open does not have any style information, simply set the default style to the one you like. In my opinion, giving you, the user, the option to choose the desired default style is way more flexible than having the GraphML import routine force a decision on you.

by [yWorks] (160k points)
The only thing I have to add and that is for clarity is that a "random" graphml file does not mean a random graph but a graphml file for which nothing is known beforehand, i.e. "Any given graphml file".

In the graphml specification (linked above), the "style" of an edge does not correspond to its visual style. It corresponds to exactly the same inherent property of an edge. It is the default direction unless specified otherwise on a given edge. (http://graphml.graphdrawing.org/specification/xsd.html#element-graph)

The difference here is between loading a large(ish) file, laying it out and then discovering that you have to do it all from the beginning because you were not careful enough to set the default edge style and the case where the software takes a hint from the file as to how to depict the graph by default.

It has nothing to do with whether the internal model that yEd is using has a bug or not.

I appreciate the detail in the discussion.
by (160 points)

Let me put it differently: yEd does not support undirected edges at all. As a result, it completely ignores GraphML's graph.edgedefault and edge.directed attributes. Strictly speaking, yEd's GraphML parser is not 100% GraphML compliant.

However, I do not think this is much of a problem in day-to-day usage. Even in your case of "loading a large(ish) file, laying it out and then discovering" that the style is not the one you want, you do not "have to do it all from the beginning"! You can select your edges1 and change the style of all selected edges. If it is only the wrong arrow head, simply set the desired arrow head in the properties view. If you rather have another style altogether, right-click the desired style template in the palette to open the template's context menu and choose "Apply Type". (The "Polyline" template and the "Polyline with Target Arrow" template in the "Edge Types" palette section are the same type of style - these two templates differ only in their target arrow head.)

1 There are several ways to select all/multiple edges:

  • Use "Tools" -> "Select Elements".
  • Click on one edge to select it with the mouse, then use CTRL+A to select all edges.
  • Open the "Current Elements" palette section. Right-click the template representing the style of the edges you want to select. Choose "Select Matching Elements" from the template's context menu.
by [yWorks] (160k points)
edited by
Thank you for the tip, I had never before have to change the direction of edges en masse and it is good to know of this shortcut. And with this, I guess we can consider the question answered (or snag resolved if you like).

I feel that this is one of those things that both of us might see as too small to tip agreement to one or the other way, at least at this point in time. From the description provided, I am guessing that things like traversal (where the direction of the edge matters for very simple things like reachability) are not (yet) a requirement. When they become, there will have to be a way of deciding if the graph is directed or not because this affects the way traversal would treat it.
by (160 points)
Powered by Question2Answer
Legal Disclosure | Privacy Policy
...