Seems an update to East Hampshire has knocked out some streets which span two cities but may just have one node in one of them.
e.g. Recreation Road - CityStrides was in both Waverley & East Hampshire but got deleted from the latter.
There were about 13 other such deletions.
Has there been a change to disregard streets with only one node ?
In list below Spire Hospital Portsmouth would have been another one node street.
My profile link :
Long discussion last week in Updates on October 31, 2025 (Release 1314) - #24 by tertullian.disconcer
Wow, Quite some updates over there. Just pulling on strings here, if this is connected.
There were some updates to the map of Burlövs Kommun in SkĂ„ne Region, Sweden. Some two âstubborn streetsâ, each with one node, and 0 distance popped up on the map, and unfortunately not completed in my case. These ghost nodes do not show on the map, even when I
I have seen these 1 node streets before, and they usually are at a border of cities. I couls find the streets in the neigboring city (Malmö), connected to the current city, but it is clear that I should have covered them.
I just cannot find them. Any tips, to have them cornered?
I recognize this problem, both of them are streets in Malmö that extend into neighboring Burlöv. But as they are completely straight from the border to the end in Burlöv thereâs only one node (the end node) on the Burlöv side. And it seems CS have problems handling that. I have previously solved such cases by inserting two new nodes, one on each side of that border. Then you get two nodes in Burlöv, in this case, and also an âend nodeâ for Malmö. Iâm not sure what the OSM etiquette is for doing this thoughâŠ
Burlövs kommun, SkÄne lÀn - CityStrides has CityStrides and CityStrides
In both cases, the streets donât actually have any nodes. Iâd expect the sync process to remove those, so Iâm re-syncing it now. While thatâs running, Iâll look into whether the code is working as expected.
Update: Iâve got some lingering bad data from the old sync code. Iâve updated the new sync code to automatically clean that up. The sync that just finished for https://citystrides.com/cities/105897 has removed those streets, as well.
@JamesChevalier Iâm curious why the part of Strömgatan extending into Burlöv should not be in CS, as far as I can see it has one node at the end?
Ah, itâs because the new city sync code doesnât allow single-node streets & thatâs all thatâs present in Burlöv.
Oh, I see, you solved it that way!
Hi James. Why will streets with only one node no longer count? There are a huge number of streets that run between towns, but only have one node in one or the other town, even when the street does not change names. This change will cause total street completion numbers to drop significantly. Otherwise we will have to add nodes to every street in this situation on OSM, which will be incredibly laborious. Please reconsider if you can. Thanks.
With overpass, the data it returned was entirely node based. The way records it returned would have an array of node IDs, and that was the connection between way/node.
With the new data setup, itâs proper line strings that are stored. I query that collection of line strings with the city border acting as a kind of cookie cutter.
It seems like that âcookie cutterâ result and the overpass result have different logic for what is defined as âinsideâ ⊠overpass wasnât returning nodes on the border, whereas my query is.
That resulted in a lot of extra/wrong single-node streets being brought in. My fix for those problematic streets was to disallow single node streets.
This seems to be resulting in cases where a street actually extends into a city, but with only a single node on the other side of the border. I donât yet have a fix for this.
From a user perspective though, it still feels like somethingâs getting lost with the new logic. If a street physically extends into a city but only registers a single node inside the border, the âdisallow single-node streetsâ rule ends up removing a segment that actually is part of the town. Thatâs where the confusion and gaps come in when trying to complete all the streets.
Is there any potential workaround or future fix youâre considering so those legitimate border-crossing segments still count? Even if they only clip the city limits by a node, theyâre still real, runnable pieces of the townâs road network â and losing those breaks some of the continuity for folks trying to complete cities or multiple adjacent towns.
Happy to help test anything if thatâs useful.
Short term fix would be to add a node in OSM at the administrative border on those one-node streetsâŠbut thatâs laborious and annoying (I certainly wonât be doing that, at least not intentionally).
Iâve done that when needed, itâs not a very common problem, maybe 20 times during my completion of Stockholm.
I donât yet have a fix for this. I am trying to figure it out.
To be clear - this is a âsomeone is going to dislike this regardless of what I doâ situation, based on what I know and can accomplish right now
Itâs more important for me to make a decision on this so that the overall city sync job can be finished, rather than pausing the entire city sync effort while I work on resolving this bit. This will let me finish the overall project and return back to clean this smaller problem up (and also address the grid city troubles where nodes only exist on intersections).
Thereâs probably a way to query PostGIS for âcollect the coordinates within/on a city border from line strings that pass through the border, ignoring the lien strings that just touch the border with one of their coordinatesâ. I do not yet know how to do this.
Is it possible for a street to really only have one node? If itâs not a cross-border case? Wouldnât a street need a start and an end, thus at least two nodes?
Nope. A single coordinate line string is invalid data.
The trouble is that weâre attaching the concept of city borders to OSMâs collection of way records.
So the OSM data is good/valid, but taking a âcookie cutterâ chunk out of it (the border of the city) causes all sorts of different/potentially-bad data to appear. Anything from the simple change of e.g. a four node way record being chopped in a way that leaves a single node ⊠to a collection of way records all being chopped in various ways e.g. a street that goes in and out of a city multiple times.
Then, internally to CityStrides, the data is still being stored as individual nodes. So itâs possible and technically ok to reach a situation where streets have single nodes.
Why would someone be upset about this? Ignoring reasons for the street not being included for other reasons [trunk road, private, etc], wouldnât this just be another street we should be running? Sorry⊠feel like Iâm missing something that you feel is obvious. 
Basically because itâs wrong. No fault on you, though, itâs a surprising situation that isnât obvious. Hereâs an example of how things fall apart when single node way records are included.
In Easthampton there is a Northampton Street (from this way record as well as some others):
In Holyoke there is a Northampton Street (from this way record as well as some others ⊠which includes this node record, the main point of our troubles):
That node is on the border of the two towns. The query that I have is asking the database for âall the way records that pass through this city borderâ where [pass through] means âis fully inside, or has any piece inside, or touchesâ ⊠further, the query takes the resulting way records and chops their linestring data in a kind of cookie cutter way where the cookie cutter is in the shape of the city border - this chop also uses the same meaning as [pass through].
When that node is included as a result of the query in Holyoke, it comes along with 117 other nodes on the same way record. Great - we have the complete way record all the way up to the border.
When that node is included as a result of the query in Easthampton, it comes along with 0 other nodes. If that single node is included, then thereâs now an invalid Northampton Street that includes a node across town.
Thanks James. Makes sense, other than why there arenât more nodes on that small stretch of the street east of the trunk road, particularly on the north border of the town, to match the singleton you pointed out? Should I just go for a hike and leave the problem solving to the Node Nerds? 
