Thanks Hans. No matter how much I zoomed/squinted didn’t see a name on the original screenshot (so assumed (bad me!) it was unchanged). That makes it make more sense 
Out of interest I looked at one of these “single node” streets which disappeared - Recreation Road and also Cherry Tree Road here has a similar issue.
On the right is the “official” representation of the border between East Hampshire (on left side with the single node) and Waverley where the road is really in.
It is a bit of moot point as to whether any of Recreation Road is really in East Hampshire as clearly all the houses in it are in Waverley and the boundary “really” seems to stop at the notional “white line” junction with School Road. Of course OSM is more “schematic” and the node for the intersection is in both streets. The boundary as depicted in OSM seems to give the impression that a tiny bit of Recreation Road “really” is in East Hampshire. Ditto for Cherry Tree Road which ends where the aptly named Boundary Road starts.
I suppose if any part of Recreation Road and/or Cherry Tree Road is in East Hampshire would need to add another node to make a tiny way consisting of 2 nodes.
Further if I ask Google which county this two streets are in and tells me just Surrey (of which Waverley is a part of).
It would thus appear that by accident or design this change has “correctly” removed both streets from really being at all in East Hampshire.
Not quite sure how in OSM you can draw a road and a boundary so that the boundary is on the far side of the road but does not extend into any adjoining roads? In other OSM is seemingly giving a slightly false impression.
I don’t think overlaying the boundary with the road exactly in OSM is prudent either as such things get very messy. I might check some of the other 12 “lost” streets of East Hampshire to see if they basically show a similar situation.
I’ve been thinking about the issue where a street physically extends into a city but only registers a single node within the border, causing it to be excluded under the current “no single-node streets” rule.
What if the system treated the start node and end node of each linestring as valid nodes when evaluating whether a street segment belongs in a city? In other words:
• If a linestring crosses into a city, count both the entry point and exit point (or the first and last nodes inside the border) as part of that street’s node set.
• This would allow legitimate fragments of streets that do exist inside a city—just with minimal geometry—to be recognized as streets to complete.
• Streets that only touch the border from the outside would still be excluded, because they would truly only have one node in the city.
This could resolve the issue of valid border-crossing streets being lost, while still preventing the “single random node” artifacts the new data source created.
Here is a tricky one
Way: Prunella Place (389904040) | OpenStreetMap
This Prunella Place is a very short street so just has 2 nodes. However one is in Winchester and the other in Havant.
I just synched Havant and it got deleted.
Assume when I synch Winchester it will get removed there as well and so it is a street you effectively can’t “do” in CS any more!
If I add a “middle” node on the way for the street that also intersects with the boundary line in OSM, will that do the trick here? It is a bit fiddly in OSM to do that but may as well give it a go.
I have tried elsewhere adding a point both sides of the boundary line to see what effect it has but waiting for the city synch queue to settle down!
I’ve alternative 2, one node on each side of the boundary a couple of times, seems to work fine
@JamesChevalier, your map at the bottom of this post is the way that it’s been for years and the way that it should be. In order to complete Northampton Street, one would need to do the main trunk and the single node dot out near Mount Tom.
That situation follows the exact same logic as when we deal with cities that have two completely different streets in different neighborhoods but with the same names. And that happens a lot already. See this example in the city of Los Angeles:
We have two West 3rd Streets (not to mention lots of other duplicate numbered and even non-numbered streets). If somebody finishes the long one that extends west out of Downtown L.A., they still need to head 25 miles south to the neighborhood of San Pedro (but still in the city of Los Angeles) to finish the other same-named streets in order for it count as done.
Thus, we’re used to this already. But when you omit the single-node streets, you not only run into numerous problems that are described by other users above, but you just don’t get accurate street counts anymore and that defeats one of the very goals of this website.
This all came to my attention since the newest Los Angeles update went through today. This single-node issue deleted 150 streets!! I lost 10 completed streets from my personal total.
After that update, I spent 20 minutes digging around Open Street Map to figure out what was going on since none of those streets should have vanished. Lots of prominent streets are now gone simply because they have one node instead of two across a border with Burbank, Culver City, and other cities. Once I figured out the pattern, I came to the forums and found this topic.
It’s not right. If a street crosses a city border into a new city, it should count.
Scott Trimble
Calabasas, CA
==============================================
NORTHAMPTON STREET EXAMPLE BELOW:
By the way, to those of you who are suggesting the mind-numbingly tedious task of finding these now-omitted streets (150 in the city of Los Angeles alone) and trying to get them added back to CityStrides, be aware….
Sure, you can add one more node and the street would get added back in, but, later, all that another completely unaware user would need to do is to hit S to straighten that same line (assuming the road is generally straight anyway) and your previously redundant node would vanish, so the street would disappear a second time in the next update.
That’s why this whole issue is so frustrating. Having real-life streets disappear because of a completely arbitrary and truly non-existent-in-the-real-world node is insane.
But having to complete different segments of same-named streets in different parts of town is a real-life geography problem, so we can accept that.
Scott
Ah, no, you’re conflating the “same name streets count as one street” issue and this issue where a street reaches and does not cross the city border. The Northampton Street that is out near Mount Tom is not in Easthampton. That street only exists in Holyoke. At the border, its name changes to North Street for the section that’s within Easthampton & then its name changes again at the border of Northampton, to Mt Tom Road. 
I’m saying this to clarify the situation, not to take a stance on the current state of things. I think this post sums up the situation well enough.
Yeah, LA is huge. It’s very much an outlier around the globe. Most cities don’t come close to being this affected by the issue.
It’s not conflating. In Open Street Maps, most streets do not start or end on a precisely defined border since the border might actually be alongside the road or following a natural feature that parallels the road, as even your Northampton Street proves….
Northampton Street DOES CROSS THE BORDER into Easthampton from Northampton, so, yes, somebody should indeed run/walk this spot too to count it as done.
It’s visible right there in the image and you were the last one to edit it. I don’t know the particulars of this road, but, elsewhere, this can happen because the street sign that changes the road name might not have been placed on the actual border but perhaps some distance away, or maybe the road got shifted due to a landslide, or a river changed course. But the city border stayed the same.
Again, you are removing the reality of real-life geography for the arbitrariness of where a made-up node happens to exist. You are also forcing people to do unethical things like fudging maps with fake nodes in order to keep the geographical reality going here at CityStrides.
These two examples alone already proved my point of view. It could be argued, so what, Northampton Street only extends a few feet into the other city. The street above goes a significant distance into the other city (but still with one node). And Prunella Place can’t even exist at all in City Strides with the one-node rule in place. This is insane.
And please don’t dismiss Los Angeles in the same way as the other detective in the movie Chinatown (“Forget it, Jake, it’s Chinatown”). Sure, Los Angeles is big, but its rules along the city borders are no different than other places around the world that I’ve seen in OSM.
Please think harder on this issue and revert it back to the way it’s been all this time. You’re trying to fix something that was never broken and you’re taking away part of the joy of CityStrides wherein we learn about these fascinating geographical quirks as we run/walk.
Scott
Here is another way to think about it. Imagine a survey:
Hey, CityStrides users, would you rather lose anywhere from 5 to 25 streets from your completion count due to quirks of how OSM was designed and CS was programmed?
Or… in order to officially complete a particular street, would you rather pick up one final node elsewhere across town, a town that you are trying to complete regardless and you would’ve hit that spot eventually anyway?
This change is also unintentionally removing short single-node streets that have nothing to do with border issues and are located entirely within a city/town.
We’re now focusing on two separate pieces of data. I don’t seem to be doing a good job of articulating the nuance of this issue.
Your screenshot is focused on the section with purple nodes in the image below. That’s the known good street that is and should be included in Easthampton. Everything is working as we would both expect it to there.
Over on the eastern side, under the text “Mount Tom”, there’s a red node that is used in two Way records in OpenStreetMap - North Street in Easthampton (great! bring it in!) and Northampton Street in Holyoke (No! Wrong city!).
There is nothing made up here in this very specific but important example. The Northampton Street with the red node in this image does not exist in Easthampton and should not be included. Looking at specifically and only this street in these two cities, we are likely in agreement.
In cases like Prunella Place, it’s different.
Let’s assume the city border is correct, and Prunella Place actually straddles both Havant & Winchester (tough for me to determine, because general searches place it in Waterlooville, Hampshire… but I’m not using either of those admin levels & the OSM boundary for Waterlooville doesn’t agree 
whatever, I can only deal with one catastrophe at a time). The result should be that you’ve got a piece of Prunella Place in Havant, and a piece in Winchester. We’re both agreeing on this.
Oh, you’ve also missed Updates on October 31, 2025 (Release 1314) which is the root cause of this issue.
The background is that the previous data source was incredibly unreliable, adding to the slowness of city syncing. It got to the point where the system had to retry collecting city data multiple times before it would return data successfully. I had to do something about this, it was not sustainable long term.
That previous system had what I think was a kind of dual query that would gather a collection of Way records that passed through the city border, as well as another set of data for all the nodes within the city border. As far as I could tell, this was excluding nodes on the border. This is what allowed it to properly exclude that node from Northampton Street in Holyoke while also including the relevant node from Prunella Place. I didn’t need a “no single node streets” rule.
I haven’t figured out the PostGIS query that’s comparable to that old Overpass query yet. It’s currently operating on a kind of “pass into or touch“ definition, which is incorrectly including streets like Holyoke’s Northampton Street within Easthampton because it touches. The best way I could temporarily handle this was to exclude single node streets. Unfortunately, it matches both streets where the way record only touches the border as well as streets where the way record only has one node validly within the border.
Going back to my earlier reply, this is a no-win temporary choice … I either upset/confuse people because extra streets are incorrectly added, or I upset/confuse people because some straddling streets are removed. In my quick research, this issue looked skewed in the chosen direction - fewer streets would be removed than would have been incorrectly added.
This is interesting! I’m not aware of any such Way record. Do you happen to have a link for me to check out?
It’s amazing that after all this back and forth you still think I don’t understand the Northampton Road issue. I do. For the record….
… Northampton Road does cross over that city boundary, so, yes, it should be included in CS. But, to the overall point, I just feel, whether a road extends a quarter mile into a city, a few feet into the city, or ends right on the border, it should be included as being in that city.
I either upset/confuse people because extra streets are incorrectly added, or I upset/confuse people because some straddling streets are removed.
As a business owner, wouldn’t you rather your customers get a handful of points for completed streets that you (though perhaps not they) feel as if they shouldn’t actually have… than to take away a lot more points from other customers who legitimately earned them? It’s better to give away a few extra chocolate chip cookies than to take away entire birthday cakes elsewhere.
Anyway, I’m grateful for your responses and the overall work that you do here, so I won’t push the issue any further, particularly since there are technical conundrums going on that are way over my pay grade! I wish you well as you sort it all out. Thank you!
Scott
oh, maybe you have the cities mixed up - this very zoomed in screenshot is indicating that Northampton Street is overflowing into Northampton… The area above that blue line is Northampton & the area below that blue line is Easthampton. Maybe you’ve been indicating that upper node is what should be included in that upper city (Northampton), and I’ve been focusing on your phrasing of “Northampton Street DOES CROSS THE BORDER into Easthampton from Northampton” (with the directionality of that statement being wrong - in your newest screenshot I can see that it’s crossing the border into Northampton from Easthampton).
I’d disagree with that, as well - it’s Easthampton Road on the Northampton side of the border. This warrants an update to the way records to split at the city boundaries, fixing the name on each side - as pedantic as that may be.
But, also, this is still the very specific aspect of the overall issue that should be fixed in this way. There’s still plenty of data like Prunella Place that we’re both in agreement should be present in both cities. I just need to figure that out.
I strive for correctness over points. There are things I’ve run into where “nothing” is correct, at which point a “least worst” decision needs to be made. Sometimes I get to make a temporary decision so that I can wrap up one piece of work (the core city sync code) … fix/improve something elsewhere (the post-sync processing performance) … so that I can return to fix/improve the interim decision (allowing single node streets within but not on the city border).
I’m trying 
BTW I do go “node adding” in East Hampshire and “regained” about 10 streets and “fixed” Prunella Place. I must say that some of them were very dubious as whether they “really” had a tiny bit in one city. OSM is of course “schematic” and often I find side streets extend essentially falsely past their junction as the connection on OSM is of course typically more “in the middle” of the road it connects with. Also I observed some boundary lines that looked “unlikely” to be the exact course and essentially not straight but “waving about a bit”. Still best not to try and “fix” boundary lines when have no basis to do so.
W 239th St is an example of a street in Los Angeles that completely disappeared because only one node is in the city limits. Even though the entire length of this street segment is in Los Angeles.
2 Likes
That’s a useful example to add to the mix. I’ll keep this one in mind as I continue to work on this issue.
This is much more on the “Full On OpenStreetMap Nerd” side of things - I’m not really considering the implications within CityStrides here, I’m just wondering how to best handle this & situations like it in OSM. Keep in mind, if you continue reading, that the OSM editing community is incredibly detail oriented.
My quick searching suggests that Fulmar Avenue is not in LA, but rather Torrance. So the blue line (the border of LA) in the screenshot above would seem more or less correct.
The shared node between Fulmar Ave & West 239th St is also correct. It’s a bit of an assumption, but it feels like a safe one to make - if they didn’t share that node, then direction services wouldn’t be able to route you to that third house on the street. LA ain’t Maine, so…
So if Fulmar isn’t in LA and W239th isn’t in Torrance, I’m not sure what the best/most-correct way to draw all three lines is.
- I don’t know if it makes sense to attach the blue line to the shared node, ensuring the rest of the blue line stays east of Fulmar.
- I don’t know if it makes sense to align Fulmar and the blue line, causing Fulmar to be the border of LA/Torrance.
- I don’t know, technically speaking (full on OSM pedantic mode), how this defines the space between the shared node on Fulmar and the LA city border… e.g. it’s not W239th because that’s not in Torrance
First, Robb Briggs / @facebook, great find. There are so many of these (like I said, 150 of them in Los Angeles), but they’re small and hard to dig up.
Second, James, my input on your OSM query…. Nothing changes. The blue border is the border. Borders are sometimes in the middle of the street, sometimes on the side of the street, and sometimes right through houses. (Remember that classic story of the house and church that have the U.S.-Canadian border go right them?). They’re quirks of history. Sometimes roads get realigned, rivers change courses, earthquakes happen and we rebuild slightly differently….
Borders are real-life, defined by city surveyors. They can’t move. I just cleaned up the street nodes a little bit in the neighborhood around W. 239th Street. (And, side note, I added a couple of kinks in that cul-de-sac so it comes back to CS… which was legit because that segment isn’t TRULY straight, as you can see in the aerial imagery).
Anyway, Fulmar Avenue and the houses on the west are in Torrance. The houses on the east have Torrance addresses (for GPS and USPS purposes), but they are in Los Angeles. And W. 239th Street starts in Torrance at the middle of the intersection and is 95% in Los Angeles.
Torrance has other portions of W. 239th Street further west. So, yes, to my point earlier, walkers & runners who complete the western segments will still have to come to Fulmar Avenue to pick up that final node in the middle of the intersection. There’s nothing wrong with that and it’s just part of the fun of the CityStrides collecting game.
Scott
2 Likes