Even if you could be looking at streets/parks/golf courses in an area and then multi-select which incomplete street’s nodes to show, it would be helpful. I have a bunch at Locarno/Jericho which are off the beaten path and putting all of them on one view would help me plan a run. Otherwise, I can only save screen caps and bring them up as I run. There are lots of data views that could be tested.
1 Like
I thought I had a version of this that was ready to try, but in my first test I almost took the entire site down.
I guess I’m going to have to come up with some clever way to query a ~200million row table.
1 Like
I DID IT
It actually turned out to be much simpler than it seemed. My original code was accidentally converting data types for the 200+million records and also trying to do the search at the same time. 
So now the new Node Hunter feature is present on the LifeMap for any Monthly Contributor. I’ll be writing up a post for the #announcements category tonight.
Update: Announcement posted: New: Node Hunter
8 Likes
You did it! But … it’s option 2, correct? All the missing nodes, even on completed streets.
This isn’t very useful to me; I need the nodes that lead me to complete the last remaining streets only.
Also, clicking the Node Hunter symbol seems to only load part of the set of uncompleted nodes; there’s clearly more that are missing.
Yeah, currently it is showing Nodes whether or not they’re attached to completed Streets … however … I expect to be able to update this tonight so the Nodes on the map will only be for (Edit: uncompleted) Streets. I’ll update the #announcements post after that is released.
Yeah, there is a 1,000 Node limit on the page. So if you’re zoomed out quite a bit in a way that’ll show more than 1k unfinished Nodes then you won’t see them all. There should be a warning popup that tells you this, though.
1 Like
Yes!!!
Assuming you mean uncompleted streets.
The warning about 1000 nodes is a bit off, it seems. When I zoom into my city and click Node Hunter, it shows me ~20 nodes in a corner of the map, and displays the warning. What probably happens is that it fetches 1000 nodes that would be outside the map, and displays a small section into view.
In other words: properly asking for only nodes in the viewport would help fix this problem.
Thanks! I edited my comment. 
If you go through that process… Zoom in, click Node Hunter, then see ~20 Nodes in the corner … if you then zoom out, are you seeing Nodes elsewhere that would have been out of view at the previous zoom level?
Also, if you have the time/energy, would you be able to share a screen shot of the ~20 Node situation?
(what a coincidence that my upcoming mixtape also happens to be named ''The ~20 Node Situation" 
)
a this is a very nice feature. Sometimes i look at a street or field before i run/walk where the nodes are. One of the the problems is that that you can look aat streets but schools, churches, soccer fields etc are sometimes not findable or sometimes just not mentioned.
I am hoewever not sure how this feature works 100% correct. Is the restriction 100 or 1000 nodes?
It’s definitely a 1000 node limit 
Those non-street things shouldn’t really be in CityStrides. It’s possible that I’ve deleted them…
I also updated the code this evening to limit the Nodes displayed to those attached to unfinished Streets. 
1 Like
it looks hot, i mean cool 
1 Like
Thank you. I’ve used it successfully twice today.
1 Like
That’s AWESOME!
I’d love to hear your feedback on how useful it is / what could be better.
I used the new Node Hunter feature before my commutes to and from work, and it helped me to find the specific waypoints to include in my route.
I needed to be zoomed into a small area for the feature to work reliably, but that just meant using the Node Hunter on a few patches along my commute. Easy enough.
1 Like
Here’s an example. The nodes displayed are for the city of Hilversum, and are correct. The westernmost section of this map is in the city of Wijdemeren, and completely empty, although there’s enough unexplored streets, and there’s nowhere near 1000 nodes on the map.
I played around a bit and here’s what I think is happening: the cities are considered in alphabetical order. Hilversum is loaded, and somehow the cap applies, then displayed. Then, Wijdemeren is considered, but the cap is already maxed out so nothing happens there.
Zooming out does not reveal any other nodes, so the viewport is correctly considered.
If this is true, then the solution is something like “apply cap later in the process”, instead of:
- select nodes from Hilversum
- cap at 1000
- display nodes on unfinished streets
- consider Wijdemeren
do
- select nodes from Hilversum
- select nodes from Wijdemeren
- cap display nodes on unfinished streets at 1000
- display nodes
Hope this makes sense.
Thanks @rutgermooy this is really helpful!
Unfortunately, I’ll need to do some discovery work - these queries aren’t concerned with Cities at all.
The code is getting the “bounding box” of your browser (the coordinates for the top right corner and the bottom left corner of your window) & using those coordinates to query for Nodes within that space. It’s limiting that query to 1000 records. Then it’s looking through all of those results and discarding any Node that is completed or related to a completed Street.
My guess is that there’s something wrong with the original query (Nodes within that space):
Node.where("ST_Intersects(ST_MakeEnvelope(#{sw_lon},#{sw_lat},#{ne_lon},#{ne_lat}, 4326), geog)").order('id asc').limit(1000)
Time to 
firstly it is very usefull i think as it is now I already used it.
I tested a few points of view.
It works ok if there it is unchartered land but I think the problems lies in the interaction with already run area’s then left and middle area’s.
I stand by my original observation: the nodes that are displayed are shown on a per-city basis. This is probably due to the ‘order by ID’ clause, where the ID’s may be stored in a per-city order, and get shown this way, without you querying for anything city-related directly.
Also, I can confirm p.gomes’ observation: when there’s zero runs on the map, I get zero nodes in all cases.
In any case, the viewport (“bounding box” as you call it) seems fine.
You’re right about how the ID ordering affects the query. This order is how I imported all the data into CityStrides, which means that there’s some City involvement - if I imported CityA before CityB, then the nodes for CityA will appear before CityB in the query result.
The trouble is that there is only one query and there is one limit, so if the query isn’t hitting the 1000 node limit then the city order should not be playing any part in the query.
The written-out version of the query is not:
- select nodes from Hilversum
- cap at 1000
- display nodes on unfinished streets
- consider Wijdemeren
It is:
- select nodes that are within the ‘box’ that these coordinates produce: [southwest longitude, southwest latitude / northeast longitude, northeast latitude], and within that query have the results sorted by their ID, and stop the query when it reaches 1000 results
- remove the completed nodes as well as the nodes that are related to completed streets and format the data in a way that the map can read
AH HA!! THAT’S IT!!!
The original query is returning 1000 results. Most of those results happen to be Completed Nodes. So that second step - the “cleanup” of the data is why the Node Hunter isn’t showing tons of un-finished Nodes.
(I’ve just recently been able to reproduce the issue where zooming into an area with no visible LifeMap tracks displays zero Nodes - I’m looking into that separately, because there is an error occurring in a different part of the code.)
Bingo! Too much clean-up.
Solution: in the first query, only retrieve uncompleted nodes.