I am getting a number of completed streets because I have run the crossing streets, because there are no nodes mid-block. Because of this, I can complete the street, while actually only running crossing streets. See the N/S streets in the image below. Given that I want to run all streets, not all intersections, is there a fix for this?
3 Likes
No fix. your personal CS map is what you make count. Each individual will decide for him-/herself what is a completed city/street. In these situations above, my lifemap dictates for me personally that there should be a run-gpx line on each street. So maybe you also want to go and fetch those missed (but completed all nodes) streets and reminisce afterwards how cool your lifemap looks at the end
5 Likes
This might be a tough one to resolveā¦
It seems like Iād have to switch things from a 1:1 GPS coordinate comparison (the GPS coordinates from your activities compared to the GPS coordinates of the streets) to something of a ādo you have any GPS coordinates between each coordinateā check.
I can think of some scenarios where you would legitimately not have coordinates between two nodes (curved roads).
I have no idea whether or not it would be acceptable to add nodes to streets between intersections - assuming anyone would even want to do that.
Could you update the streets in OSM to have nodes up and down the streets and then the next update should push them through as incomplete again? Or once theyāre marked as complete would they stay this way?
Iāve adopted @petjeās philosophy. You can hit 100% and legitimately say, āI have run on every street.ā Or, you can use the LifeMap as a guide, and run the length of every street.
I have two streets left to complete my city at this level.
But, there is also the concept of every node.
I am also hoping to turn every node in Keller green.
PS. Next update I should be 100%. 
1 Like
We donāt control OSM. Youād need to manually go into OSM and manually add nodes to every street.
CS uses the data in OSM, which predates CS by a lot. OSM is also used by a bunch of other web services, so be very careful thinking about making changes to OSM to make your CS experience better.
2 Likes
Iāve also noticed the same problem, and Iām using the map as a guide. You can also get credit for street parallel to the one you are in if the nodes are under the 20m threshold!
Regarding not having nodes in the middle of the streetā¦ what about having CS add nodes automatically between every two imported nodes?
Yeah - another reason I donāt really love the current calculation processā¦
I canāt be certain thatās the right thing to do 
every time
1 Like
Adding intermediary nodes to OSM itself would not improve the map. So I concur, we should not consider that approach. Plus, it would be very manual.
It seems to me, although Iām certainly no expert, that if the nodes represent linear segments of a street, then placing interpolated points along them ought to not cause things to break, including along curves as curves are represented by line segments approximating the curve, so the nodes are closer together along curves. Curves therefore probably do not need extra nodes, but I donāt know if adding them would be harmful.
3 Likes
to petjeās point about not fixing this:
I disagree. One of the major points of this site is identifying gaps in the completeness of a city. If people still have to stare at their lifemap, either on here, Strava, or wherever, then youāre still doing the effort that CityStrides should save you from.
I agree with troyml that adding points between line points should get us āevery single blockā.
Iām relatively new to OSM and CS but not new to spatial computing. I see that a way (the ones we care about are roads), āis specified by a collection of [ordered] nodes. The way is made up by the way segments connecting these nodes. Each segment is assumed to be the shortest line [ā¦] connecting its two endsā (Way - OpenStreetMap Wiki) The way segments are straight lines (ignoring geodesic complications), segmented by curves of the way, intersections with another way, or other things.
Since each way segment is a straight line, we can take the midpoint of any way segment and be assured that itās on the line. In a grid of straight streets, the segments are blocks. So the way segment midpoints are the centers of each block.
A simple, but perhaps not computationally efficient, way of getting these midpoints is to iterate through the lines (ways) in an area (relation in OSM speak) and then walk through the points (nodes), starting with the second, and calculate the midpoint between the two points.
in psuedocode:
Assume lines is something like an array of lines (ways) in the area
Assume each line is something like an ordered array of points (nodes)
for line_index in 1 to max number of lines:
for point_index in 2 to max number of points:
current_point = lines[line_index][point_index]
previous_point = lines[line_index][point_index -1]
segment = make_a_line(previous_point, current_point)
midpoint = calculate_centroid(segment)
add midpoint to a list of midpoints
Something special would have to be done for āclosed waysā which present as polygons depending on how you fetch data from OSM. Probably the simplest way of dealing with these circular streets is to break the polygon into a line.
Iād go further and suggest that the way segment midpoints are more interesting to CityStrides than the vertices. And by vertices, I mean points that are on more than one way segment. More generically, I mean the nodes at intersections.
To illustrate, Iām 100% complete in hard mode in my tiny town of Coupeville, WA, USA. But looking at this part of town that has a grid, you can see I got the east/west blocks but not the north/south blocks:
Calculating the midpoints from the osm data I get this:
blue dots - way segment midpoints
red dots - all way nodes
red dot with smaller green dot superimposed - vertices.
I didnāt implement the full logic that CS has for excluding ways, so there are parking lots and non-roads in my model. But you can see the midpoint (blue) dots get all of the blocks and the full red dots get the street ends. The verticies (green with red outline) can be left as they make sure people donāt turn around mid-block I guess. But I donāt have a strong opinion on leaving or removing vertices.
I wouldnāt suggest changing the algorithm for calculating nodes for the two current modes, normal mode and hard mode. That would be unkind to folks who are complete on cities. I would suggest a new mode, I might call it āevery single blockā, or ESB for short. (plus, Iām partial to an Extra Special Bitter beer). I also think the mode argument should be per user per city. I could see doing one city in hard mode and another in normal mode. But thatās a different discussion 
Since this thread has been dormant for 4 1/2 years, Iām guessing there isnāt a huge amount of interest in changing / adding nodes in CS. But Iām happy to talk more about this or contribute code. CityStrides is a great tool and it would be cool to see it grow and evolve.
cheers,
steve
2 Likes
Itās possible Iām misunderstanding some things. I appreciate any corrections you can make.
I definitely agree that thereās an issue that needs to be resolved, but Iām not (as of exactly right now) sure that adding data at this scale is the answer.
(edit: though the more I mess around with different PostGIS queries that I hope to accomplish this, the more it seems like adding data could be the only way)
In my experience not all way segments (defined as any section between any two consecutive nodes in a way) are of equal importance - if I added a node between each two nodes in Way: āŖLeary Driveā¬ (āŖ8766754ā¬) | OpenStreetMap Iād have a lot of extra useless data.
Yeah, that midpoint calculation seems reasonable enough. My problems start to come up within the city update process, where nodes can be added/removed/moved & some amount of all this midpoint calculation needs to happen again.
Thatās assuming Iām storing these midpoints, since it would be expensive to recalculate them on every progress calculation (new activity saved, street with node added/removed/moved, activity deleted, then multiply it all by the number of challenges which I handle separately).
I would 
If thereās a way to either generate the data to add this midpoint, or a way to adjust the queries that determine if a street is completed based on the space between nodes ā¦ Iād definitely have no problem adjusting that site-wide. Itās ārun every streetā not āpass by all the intersectionsā - the fact that we get credit for other streets in grid situations like this is a shortcoming of CityStrides.
I also like ESB 
Itās less a lack of interest and more the fact that itās a whole lot of work to revamp things in a way that works for all the different background goings-on in CityStrides.
1 Like
I like the idea, and regarding your example Leary Drive, one solution would be that during these iterations look at the distance between two nodes, if distance is greater than x meters, then insert an intermediary node. Maybe x could be 20 meters.
1 Like
Yeah, operationalizing this is a lot harder than the concept. Is there something that documents the flow of OSM data into and āinā CS? I had assumed there was local storage of osm data that was already being augmented or reduced with the app code, but maybe not.
For sure, including both all of the line nodes and midpoints in CS would nearly double the points. This is why I would suggest dropping the points that are on more than one line segment (verticies). Exchanging midpoints for vertices would slightly lower the number of points. Basically, drop the intersections, add the mid-blocks, and keep the terminal street ends. For example, your referenced Leary Drive has 64 nodes, and thus 63 midpoints. All 64 of the original nodes would get dropped since both ends of the street share a point with Cherry St. So, thatās a net decrease of one point. Of course, at the cost of computation.
Since computing the vertices (points on more than one line segment) needs to be done by looking at the network of lines that has to happen separately from traversing the lines and points. But most libraries have pretty efficient functions for this. But again, thatās in the weeds on implementation.