I’m trying to wrap up a section of my city, but am having a hard time knowing exactly which dead ends I need to run. What I’ve been doing is opening my LifeMap in one tab with Node Hunter turned on, then my City view (with the boundaries) in another tab…and then I flip between the two to see the incomplete nodes in my LifeMap and whether it’s inside my city’s boundary in the other tab.
Is there an easier way to do this?? 
I agree this is a missing feature. We should be able to see the city boundary on the Life Map.
As an option, yes, but I wouldn’t want it there all the time, as in some cities there is quite a lot of that boundary line cluttering things up. I purposely use Lifemap, not City View, to avoid the boundary line most days.
The issue is there is currently no view that can show you a city boundary, your position, and incomplete nodes simultaneously.
Zelonewolf, I understand the request, and see why people node hunting would want it, but if I just pull that page up without being a node hunter, I don’t want the borders in my way, nor the re-polling as I move around. It would also save hits on the app server to not be forced into that mode, making James happy, I’m sure
Uh, what? Nodes are only shown when you explicitly push the purple button to load them. There is no re-polling whatsoever until the user presses the button.
Sorry, meant the city border lines, not the nodes I don’t worry about staying within the borders, as the ends of the road outside are either already in another town or may eventually be included so I was picturing the borders re-loading repeatedly, unless that was also tied to the button?
Okay, I see why my comment was not clear.
We need to enable the node hunter in the city view (CityStrides) page.
My point, and the original point, is that if you are explicitly looking at the page of a particular city, you should be able to hunt nodes on that page and not have to go back to the main Life Map, pan/zoom back to the city you were looking at, and then have to hit the node hunter without a border reference.
Though now that you mention it, a city border option in the Life Map would certainly solve the problem also.
I recently added the Node Hunter to both the City view pages as well as the Activity view pages.
Yes… this is very helpful.
In the city view, you might consider only showing/querying for the nodes that fall within the city boundary.
I agree, but sometimes I don’t have that boundary. 
How can you have a city view without a boundary?
I manually gathered some cities by hand-tracing their borders in https://extract.bbbike.org/ 
I think I also have some dumb character encoding bug that breaks the query for the border file for some cities.
Which reminds me that I don’t actually have the city border in the database, so including that in a query would be quite difficult.
It seems to me that you spend a lot of energy trying to overcome things that are missing from or not coded right in OSM.
Philosophically, you would be better served to say “sorry, I can’t do X until Y is fixed in OSM” and then you can direct folks to edit whatever’s wrong with OSM. It makes OSM better and it gets rid of all these hacks and workarounds you’re implementing.
Anyways, stepping off my soap box: I used this view last night, and I realized that the city view also needs the blue dot that shows where the user is!
You make a great point. Rather than fixing data, James should work on the import process automation, such that he can just point and click at OSM files. Then send out his army of runners to fix the cities themselves in OSM. Very good suggestion.
Definitely ideal!
Import automation is a massive piece of work.
I also don’t have any ability to do an “update” import, because of how OSM IDs are handled (as far as I’m aware, their IDs are not unique/static so I’d never know if the thing I was importing was new or changed).
It would have to be geography-based. I agree that a per-ID update is not feasible because of how OSM works. I.e., if I were to delete and re-create a street in OSM, it’d totally come in with a new ID. I think you have to let users mark a street as “needs update”, then, draw a rectangle around that street, delete what you have in the database, import new OSM data for that rectangle, and then re-process runs that intersect the geography. This method assumes you are using appropriate OSM tags to not import buildings, parks, railroads, etc.
Also, I think letting users mark streets “for deletion” is currently problematic. Streets that are partly runnable or just need updates are likely getting marked for deletion because that’s the only option users have available to them.