I want to find the shortest path using Orient SQL between two nodes where edge type is type_A or type_B but not type_C.
From the documentation (http://orientdb.com/docs/master/SQL-Functions.html#shortestpath) it looks like only one edge type is supported. Is it possible to mention a list of edge types? Or is there any other way to find it?
Related
I have a query which returns a number of ways. I want to find nodes matching certain criteria which appear within those ways. Note that the nodes I'm interested in do not form part of the way itself, but do appear within the bounds of the way. Also, the ways do not all have corresponding areas, so using the area search doesn't work in all cases.
I've got a minimal example which finds way 95677318, and I want to be able to find node 1552949334:
(
way({{bbox}})["man_made"="lighthouse"];
)->.searchArea;
/*doesn't work:*/
/*node(area.searchArea)["seamark:name"];*/
/*recur down and find node directly, just for the purpose of this question*/
(
.searchArea;>;
node({{bbox}})["seamark:name"];
);
out;
(Try it on https://overpass-turbo.eu/s/EpV)
This feature is not yet available as of release 0.7.55. In case there's no corresponding area available on the Overpass server, this kind of query is simply not feasible.
See https://github.com/drolbr/Overpass-API/issues/77 for details.
I am trying to use traverse to explore multiple orders of edges away from a specific starting node. For example, using the Grateful Dead graph, I call this command:
traverse bothE('followed_by') from #15:8 while $depth<3
I expect this to get two orders of edges. However, all the edges are ones that include the starting node. If instead I use both('followed_by') it appears to visit all the desired vertices, but it doesn't report the edges. What should I do?
The in edge on #15:8 record is called followed_by, and the out are sung_by, written_by, followed_by, so you can't use followed_by name and get also out edges, even if you use both in your query:
This one should do it:
traverse bothE() from #15:8 while $depth<3
I am working with OrientDB graph API using java API and Gremlin Pipeline. I wanted to know is there a way to specify storing order for edges based on an attribute? I know we can create a custom edge type and define index on the attribute based upon which we want to retrieve.
I also had a look at the tutorial on the OrientDB website:
http://orientdb.com/docs/last/Graph-Database-Tinkerpop.html#ordered-edges
There they do mention that edges can be retrieved in an ordered way but they dont mention how is the order determined.So I would like to know:
What is the default storage order?And will fetching from this order give me edges in an LIFO format?
How can we store based on custom order i.e. store in the order in which we want it to be fetched?
The underlying type used is a List, so the order is the inserting order. To change it, get the edge list, work on it and then call vertex.save() where vertex is casted to OrientVertex.
I am trying to create a graph in OrientDB where the weight of edges has to be calculated on demand using data from another database. I would like to know if there is a way to do this, since all example I´ve seen use static weight properties, none of which is dynamic by nature.
If I could use a stored function as a property and have it evaluate each time I call shortestPath then it would solve my problem, but I haven´t found any documentation on this topic.
Help would be greatly appreciated!
This isn't supported by OrientDB out of the box, even if it would be something nice to have. Could you open a new issue?
About the solution I suggest to clone the OSQLFunctionDijkstra class, do your changes and plug into OrientDB engine with a different name.
I want to query the Overpass Api to find out the distance of special relations (railways). The request is fine, and returns me all relation, way and node objects I'm interested in. Example for Hamburg:
[out:json];(rel(53.55224324163863, 10.006766589408304, 53.55314275836137, 10.008081410591696)["route"="train"];>;);out body;
In Overpass, each relation object has members defining this relation. For way objects you can resolve the lat/lon of its node attributes and calculate the distance for that way. If you sum up all the way distances it seems to be reasonable.
However, there are members from that relation of the type node (most of the time, they have a role of "stop") which seem to represent the right order of stops from that relation. But instead being in between the members, they are roughly at the end.
If I try to look the stops up inside the ways, they are not all present. How am I supposed to calculate the distance between two particular stops?
There seems to be a misconception about relations. Relation members don't necessarily have to be sorted. Consequently you might have to sort the members yourself, if necessary at all.
You can take a look at JOSM which has a neat sorting algorithm for various types of relations. But I don't think it is able to place members with the role stop at the correct position. This isn't always possible because a way doesn't necessarily have to be split at each node with the stop role. This also means a single way can contain more than one node with a stop role, making it impossible to sort the relation members correctly. Unless you do some pre-processing for splitting each way accordingly.
For calculating the distance between each stop it seems unnecessary to sort the elements. Just follow the way by iterating over all each nodes and check for each node if it has a stop role in the corresponding relation. When reaching the end of the way continue with the one which shares the same node at its start or end and which is also member of the relation.