I am having conceptual difficulties with edges and links in OrientDB.
I have a graph that represents link layer and internet layer in a network. link_layer EXTENDS V nodes correspond to MAC addresses, net_layer EXTENDS V nodes correspond to IP addresses.
A communication relationship between two addresses is represented by an edge class conx EXTENDS E. There will be two separate conx edges that represent the same connection: conx 1 connecting MAC A to MAC B, and conx 2 connecting IP a to IP b that represent the same connection. This will create a graph that is partitioned into two separate subgraphs which do not interact (no MAC to IP edges)
Now I need some way to associate the two graphs together. I would like to connect the edges with a link relationship. Each edge could have a LINKLIST property that identifies all the other edges that this edge is identical to in different layers (say I add the TCP/Application layers later, this would be an n-to-n relationship)
So far so good. How do those links affect the graph? OrientDB documentation says that "With the Graph API, Edges are represented with two links stored on both vertices to handle the bidirectional relationship." If then try to interact with this database from the graph API, can LINK or LINKLIST properties be interpreted as edges? Can you even make a link between an edge and an edge? Ideally, it would not affect graph traversal...I'd like to be able to run graph analysis the link layer usage of my network separately from the internet layer.
Sorry for the broad questions, but I am in general just confused about how and why to use referenced relationships and if using them to connect edges in two otherwise unconnected graphs is valid.
In general, a graph should be designed to best represent your scenario being described.
It is therefore essential to identify the entities that will be represented by the various classes.
Each class will have a relationship with another class, by edge or link.
Usually:
An edge Defines a relationship between two vertices. For example, you define two vertices, Person and Car. You then define an Edge Drives. This edge ties the two vertices together. "Jane" Drives "Ford".
While:
A Linklist is a list of classes associated with another class. A Car class might have a Linklist of parts from the Part class. A car Consists of multiple parts.
The edge / link should never be used to have a relationship with each other eg: edge to edge, and if you have this situation means that the graph has problems
conceptual design.
Related
I have a usecase diagram with an actor and a usecase and there is an association between the two. I want to get the source and target position of the association on the diagram. I tried considering the SX,SY,EX,EY points of the connector in the PDATA5 column of the t_connector table but it doesn't make sense for most of the connectors as they are 0 in most cases.
Is there any other way to get the positions of the connectors on the diagram?
Well, it's complicated. EA renders connectors internally. In your case you have a plain rendering. So what EA does is to find the centers of the two connected elements by looking at the element positions on the diagram (via t_diagramobjects). As you might know, EA considers all elements to be rectangular. Use cases and actors the same. This is why connectors do not attach to visible borders but swivel around an invisible frame. Now the geometric centers are calculated and the attachment to those frames (which is simple geometry).
You need to look into t_diagramlinks for the connector as well, but only if you shift attachment point or introduce bends. And of course if you have special renderings (like tree style which makes completely different things you can't re-compute (simply)). The geometry will tell how shifts are made. And the path reveals the bends. Again just simple geometry if you have standard Custom Lines being set. For every other line style: you better don't ask.
From DB side:
t_diagramlinks.geometry (SX,SY)(EX,EY)=(0,0)(0,0) - probably the line from the center of the object to the center. EDGE - where the connector starts (1 top, 2 right, 3 bottom,4 left) from the source object, t_diagramlinks.path - additional break points etc.
I'm new using Graph Databases and I'm a little confused about the concept of From / To or In/Out in OrientDB.
Which is the best approach to define which Vertex is From and which is To? Or Both for example when is a relation of contact in social network.
In my opinion, the most part of this confusion comes from Apache TinkerPop notation for edges. OrientDB historically adopted TinkerPop as its graph API (some things are changing here, so in v 3.0 there will be a native document/graph API that does not depend on Apache TinkerPop API, but we will still maintain the support with TinkerPop 3.x) so the notation is the same.
Apache TinkerPop uses OUT/IN to define both edges connected to vertices and vertices connected to edges:
given a vertex, you have outgoing edges referenced by OUT and incoming edges referenced by IN (so far so good)
given an edge, it has the starting point (the vertex it comes from) identified by OUT (ouch!) and the end point (the vertex it goes to) identified by IN
And here come the problems: for a beginner, it's very natural to consider an edge traversal as an out + out:
vertex -out-> edge -out-> anotherVertex
but unfortunately it's WRONG!
The right way to do a straight edge traversal is out + in:
vertex -out-> edge -in-> anotherVertex
You can also traverse the edge backwards with an in + out.
As I wrote before, IMHO it's extremely unintuitive, at the beginning I also had problems with this. IMHO the best notation for edge connection would have been FROM/TO, instead of OUT/IN, but it's a standard now, so we cannot do much.
The only thing I can tell you is that it becomes natural with a little practice.
A separate consideration is for social networks and in general for edges that are not intended to have a direction (in a social network the direction of edges is not important, the fact that I'm your friend also implied that you are my friend). Apache TinkerPop does not have a concept of undirected edges, so you just have to use directed edges and ignore the direction when traversing them (eg. using the both() operator or BOTH direction)
I've read the document but still confused of them, could any guy can give me a clearly explaining, e.g.any image comparison? Thanks.
The Wikipedia article on Pathfinding might help, as might the related topics on graphs and graph search algorithms linked from there. Beyond that, here's an attempt at a quick explainer.
Nodes are places that someone can be, and their connections to other nodes define someone can travel between places. Together, a collection of (connected) nodes form a graph.
GKGraphNode is the most general form of node — these nodes don't know anything about where they are in space, just about their connections to other nodes. (That's enough for basic pathfinding, though... if you have a graph where A is connected to B and B is connected to C, the path from A to C goes through B regardless of where those nodes are located, like below.)
GKGraph is a collection of nodes, and provides functions that work the graph as a whole, like the important one for finding paths.
GKGridGraphNode and GKGraphNode2D are specialized versions of GKGraphNode that add knowledge of the node's position in space — either integer grid space (like a chessboard) or open 2D space. Once you've added that kind of information, a GKGraph containing these kinds of nodes can take distance into account when pathfinding.
For example, look at this image:
If we're just using GKGraphNode, all we're talking about is which nodes are connected to which. So if we ask for the shortest path from A to D, we can get either ACD or ABD, because it's an qual number of connections either way. But if we use GKGridGraphNode or GKGraphNode2D, we're looking at the lengths of the lines between nodes, in which case ACD is the shortest path.
Once you start locating your nodes in (some sort of coordinate) space, it helps to be able to operate on the graph as a whole in that space. That's where GKGridGraph and GKObstacleGraph come in.
GKGridGraph works with GKGridGraphNodes and lets you do things like create a graph to fill a set of dimensions (say, a 10x10 grid, with diagonal movement allowed) instead of making you create and connect a bunch of nodes yourself.
GKObstacleGraph adds more to free-2D-space graphs by letting you mark areas as impassable obstacles and automatically managing the nodes and connections to route around obstacles.
Hopefully this helps a bit. For more, besides the reference docs and guide, Apple also has a WWDC video that shows how this stuff works.
I am going to design an Android application and I will be needing the distances of the pathways inside our university(pathways between buildings)
I read about OSM(OpenStreetMap) and tried it. It is a map which is editable which means anyone can contribute to that map(like a wikipedia map version).
It has many routing services that give routes and directions between two point(start and end).
There is a routing service named GraphHopper and it is very easy to use. I can just drag and drop the start and end pt and it gives the distance(km) between the two pts.
What I want to know is how did they come up with the distance?
Is the distance reliable and accurate?
Any help is greatly appreciated because I want to use the distances for my Android app and I need to know if these distances have basis.
The distance is 'accurate' in the sense that it correctly processes the existing information from OpenStreetMap and correctly adds road segments for the final route. You can just try for your local area and compare to your own knowledge.
There could be mapping errors, where a road is incorrectly mapped. And there could be also roads missing and so the router uses a detour making the path unnecessarily longer. Also there are different modes like for cars or bikes or fastest and shortest where you get a different distance between two coordinates.
Consider an existing Voronoi diagram V built over a set of sites S. This diagram effectively solves the problem of a "postal offices servicing regions that are nearest to them than to any other site".
Consider that the problem of postal offices evolves in terms of the need of decentralization without redefining the borders. That is, instead of (or in addition to) the former sites there need to be more smaller sites within the current site's area that would have the same original "external" borders (but obvoiusly some new "internal" ones).
In terms of more formal definition, does there exist a subdivision of an existing Voronoi diagram that in turn is a new Voronoi diagram such that it is a superset of original set of sites and set of resulting edges?
EDIT1: Maybe even more formal: if D is a set of edges, D={E}, being the Voronoi diagram for set of points S: D=DV(S), then does there exist a set of new points S1, such that S'=S+S1, for which a new Voronoi diagram D'=DV(S')={E'} is a "superset" of original one: U{E} < U{E'}?
You can solve your problem with the point-to-location algorithm:http://en.m.wikipedia.org/wiki/Point_location. Maybe you can look into TOPOJSON and merge adjacent cells:http://bl.ocks.org/mbostock/9927735.