search

52North / worldviz

Triturus WorldViz supports the development of thematic 3-d visualizations at world scale.
GNU General Public License v2.0
7 stars 4 forks source link

Migration from earthencounter to worldviz #5

Closed cDanowski closed 9 years ago

cDanowski commented 9 years ago

@BennoSchmidt I have migrated all source files from earthencounter to worldviz. I created a new branch named 'IntegrationEarthEncounter' (link: https://github.com/cDanowski/worldviz/tree/Integration_EarthEncounter ). It would be nice if you could review it.

kamakshidasan commented 9 years ago

@BennoSchmidt @cDanowski We should have a proper demarcation in VgRelation for Arcs and Edges.

BennoSchmidt commented 9 years ago

@cDanowski @wolfshadow18 I just pushed some useful stuff to the repository. Directed edges ("arcs" in Pajek) have been modelled by WvizArc objects now, as long as they do not consist of quantitative edge-weights; in this case, use WvizFlow objects. For undirected edges (called "edges" in Pajek), WvizConnection objects should be used inside Triturus WorldViz. The universal implementation to hold such relations is WvizUniversalFeatureNet. (For quantitative edges weights, WvizFlowNet should be prefered.) Hope that helps!

kamakshidasan commented 9 years ago

There are a few minor issues that have to be dealt with respect to parsing data by the Pajek Reader

1) There cannot be lines that randomly start with an asterisk. For example, " * Network Flows of trade ", cannot be written, since it " *Network" is not a keyword in Pajek. Such statements should be preceded by '%'

2) Currently, there cannot be any spaces in the label. If spaces are provided, the program crashes.

3) There has to 3 Coordinates while specifying a Node (Vertex) in Pajek

4) The keyword for specifying Arcs in Pajek in " Arcs" and not " arcs" (Please note the change in case)

5) While printing an Edge (Non-Directional and Weighted), by using the toString() method in WVizConnection, the arrow mark should be pointed towards both ways, than be unidirectional.

The way to deal 1 and 4, is to change the Pajek file. Changing our parsing technique for this issue, would not be ideal.

2 and 3, are minor bugs, and they will be dealt with, according to the comments.

5, is a suggestion. If we could implement this now, in future, debugging, would be a much more simpler task.

cDanowski commented 9 years ago

you made some good annotation. We just pushed our change according to your 5th idea.

cDanowski commented 9 years ago

this issue can be closed, I just merged both branches