I'm looking for all of the nodes at the end of residential roads that aren't turning circles to see if there are any missing turning circles.
I have this so far:
node({{bbox}});
way(bn)[highway="residential"];
node(w:1,-1)[highway!="turning_circle"]({{bbox}});
out;
It works well except it also finds nodes at the end that join another road, I only need the nodes that are part of a singular way.
Related
There is a script Here that can process the data from OSM to detect intersections in a given bounding box. It works by getting all the ways in a given bounding box and then finding other ways that share common nodes with these roads. Here is the query that does that,
way
["highway"]
["highway"!~"footway|cycleway|path|service|track|proposed"]
(, , , )
->.relevant_ways;
foreach.relevant_ways->.this_way{
node(w.this_way)->.this_ways_nodes;
way(bn.this_ways_nodes)->.linked_ways;
way.linked_ways
["highway"]
["highway"!~"footway|cycleway|path|service|track|proposed"]
->.linked_ways;
(
.linked_ways->.linked_ways;
-
.this_way->.this_way;
)->.linked_ways_only;
node(w.linked_ways_only)->.linked_ways_only_nodes;
node.linked_ways_only_nodes.this_ways_nodes;
out;
}
This query returns all kinds of intersections (4-way intersections, T-junctions, ... ).
Question:
Is there a way to further filter out the intersection to 4-way intersections and T-junctions?
One idea I have is to check if the common node is an endpoint of one the ways, which makes the intersection and if the common node is in the middle of the road it will be a 4-way intersection. But I am not sure how to write a query that does this.
Any help will be appreciated, Thanks.
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 would like to find all highway way member nodes in a certain radius. I cannot see how to do this without using intersection, however, that is not in the API. For example I have this:
[out:json];
way(around:25, 50.61193,-4.68711)["highway"];>->.a;
(node(around:25, 50.61193,-4.68711) - .a);
out;
Result set .a contains the nodes I want but also nodes outside the radius - potentially a large number if the ways are long. I can find all the nodes inside the radius I don't need, as returned by the complete query above. Now I can always perform a second around query and do the intersection of the two result sets outside of Overpass. Or I can do another difference:
[out:json];
way(around:25, 50.61193,-4.68711)["highway"];>->.a;
(node(around:25, 50.61193,-4.68711) - .a)->.b;
(node(around:25, 50.61193,-4.68711) - .b);
out;
This gives the result I want but can it be simplified? I'm certain I'm missing something here.
Indeed, your query can be simplified to an extent that we don't need any difference operator at all. I would recommend the following approach:
We first query for all nodes around a certain lat/lon position and a given radius.
Based on this set of nodes we determine all ways, which contain some of the previously found nodes (-> Hint: that's why we don't need any kind of intersection or difference!).
Using our set of highway ways we now look again for all nodes of those ways within a certain radius of our lat/lon position.
In Overpass QL this reads like:
[out:json];
node(around:25, 50.61193,-4.68711);
way(bn)[highway];
node(w)(around:25, 50.61193,-4.68711);
out;
Try it on Overpass Turbo
I would like to add additional forces to networkx spring_layout.
I have a directected graph and I would like nodes to move to different sides according to the edges that they have. Nodes that have more outgoing edges should drift to nodes that have more ingoing edges should drift right. Another alternative would be. That these groups of nodes would drift towards each other, nodes with outgoing edges would get closer while nodes with ingoing edges would also get closer to each other.
I managed to look into to the source code of spring_layout of networkx http://networkx.lanl.gov/archive/networkx-0.37/networkx.drawing.layout-pysrc.html#spring_layout
but everything there is just beyond my comprehension
G.DiGraph()
G.add_edges_from([(1,5),(2,5),(3,5),(5,6),(5,7)])
The layout should show edges 1,2,3 closer to each other, the same regarding 6 and 7.
I imagine, that I could solve this by adding invisible edges via using MultiDiGraph. I could count ingoing and outgoing edges of each node and add invisible edges that connect the two groups. However, I am very sure that there are better ways of solving the problem.
Adding weights into the mix would be a good way to group things (with those invisible nodes). But the layouts have no way of knowing left from right. To get the exact layout you want you could specify each point's x,y coordinates.
import networkx as nx
G=nx.Graph()
G.add_node(1,pos=(1,1))
G.add_node(2,pos=(2,3))
G.add_node(3,pos=(3,4))
G.add_node(4,pos=(4,5))
G.add_node(5,pos=(5,6))
G.add_node(6,pos=(6,7))
G.add_node(7,pos=(7,9))
G.add_edges_from([(1,5),(2,5),(3,5),(5,6),(5,7)])
pos=nx.get_node_attributes(G,'pos')
nx.draw(G,pos)
I am using NetworkX to generate graphs of some noisy data. I'd like to "clean up" the graph by removing branches that are spurious, and hope to avoid re-inventing the wheel.
For example, the linked picture shows a sample set of graphs, as colored nodes connected by gray lines. I'd like to prune the nodes/edges indicated by the white boxes: http://www.broadinstitute.org/~mbray/example_tree.png
Essentially, the nodes/edges to be removed are branches typically only a few nodes (< 3) in length. By removing them, I hope to have a tree with a minimum of branching but the branches that do remain are "suitably" long.
Before I start crafting code to examine subtrees for removal, are there NetworkX functions that can be used for this purpose?
You can use the betweenness_centrality score of the nodes. If the node with a low centrality score is connected to a node of remarkably higher centrality score, and has 3 edges, then you can remove the low centrality node. (the rest of the <3 connected nodes aren't connected to the main graph anymore.).
You'll need to experiment with the phrase "remarkably higher".