About the Node, Street, and City Data


This Wiki is all about nodes, streets and cities

  1. What they are and where the data comes from
  2. How they are counted, and
  3. Strategies to complete the hard-to-get ones

Definitions & Source of Data

Note: All of this data comes from OpenStreetMap (OSM). It’s accessed via queries to a self-hosted Overpass server.

  • Nodes: these are the “atoms” or building blocks of CityStrides. They are the individual points which make up a street.

  • Streets: streets are essentially collections of nodes, and are the element that Striding is all about! OpenStreetMap itself doesn’t have a concept of “street”. Instead, there are many smaller collections of Nodes that are called Ways. A “street” as we know it may exist in OSM as a single Way record or it may exist as several Way records. This Google Doc - CityStrides Street Query - contains a full list of road types and the full/explained query that CityStrides uses to import data.

  • Cities: this is the top of the data hierarchy in CityStrides, and is again defined by OSM. Your page will show a completion percentage for every city where you have completed at least one street.

For more information on OpenStreetMap, see About OpenStreetMap

Known issues or works in progress

  • Nodes are inaccessible: see section below

  • Nodes or street data are incorrect: If there’s something wrong about a Street or its Nodes in CityStrides, then the data should be corrected in OSM. As of April of 2020, I’m still working on a way to update the data in CityStrides with updates from OSM. Once that work is complete, the updates in OSM will make their way into CityStrides.

  • Street has nodes all over: Because of this lack of “street” record, the underlying CityStrides code needs to build its own understanding of a Street. This is (currently; April 2020) done by collecting all the Way records in one city with the same name & collecting all of those together as a Street. This doesn’t always work as expected :grimacing: which is why some cities have a Street with its Nodes scattered in separate areas around the city.

  • Cities are unambiguous: there are multiple overlapping city definitions

  • City is missing or otherwise incorrect: read or add to this tracker to help fix issues

Making them Count

  • Nodes: if you run (ie your GPS data has a point that is) within 25m of a node, it is counted as complete. You may capture nodes on streets you weren’t running on, or miss nodes on a street you did run based on this logic

  • Streets: if you complete 90% of the nodes on a street, the street will be considered complete. For streets with less than 10 nodes, you need to complete every node to complete the street (not enough for you? Check out the “hard mode” discussion for more!)

  • Cities: the percentage complete of a city is shown below. Discussions have previously arisen considering other completion metrics (like completed nodes/total nodes, or completed distance/total distance, however these are not currently active.

Percentage Complete = Count of Streets Completed in City / Total Count of Streets in City

Capturing Inaccessible Nodes

What about those nodes that are on private property, behind a fence, or in the middle of a building/body of water/other?

There are multiple strategies to deal with these nodes in CityStrides

  1. Correct the data: you can manually edit the underlaying data in OpenStreetMap. (Note that a regular connection between OSM and CityStrides is presently under development)

  2. Ignore the node: the stoic’s approach is to just ignore the fact it’s there and move on (okay, none of us do this, so what else?)

  3. Manually Mark Complete: this feature exists exactly for this reason. The street will be marked complete and you can carry on - you can do this by visiting the Street’s page and clicking the mark as manually complete button

  4. Fabricate the data: manually create a .gpx file with the two required data points, and load it to your Strava (ethically questionable, why not just use the “mark complete” option?)


(You can delete this comment, as I don’t like comments on Wikis) but are you certain it’s 25 m?? That seems … much further than my experience dictates. In most wide 4 lane roads, I will miss nodes in the corners, fairly consistently. I would have guessed 25 feet, not 82!

I have been tempted to make the same comment. There have been times I knew I was closer, but I then thought, “Maybe it’s the mystery of GPS drift? Or because I wear my Garmin on my left wrist?”

I think it’s 25m :thinking:

ST_DWITHIN(geog, path.geog, 25)

The ST_DWITHIN documentation says

For geography units are in meters and measurement is defaulted to use_spheroid =true, for faster check, use_spheroid =false to measure along sphere.

Maybe the query isn’t doing what I think it is since I’m not setting use_spheroid to false.

1 Like

Wow, that page is hard to make sense of. :confused:

Kudos to you James.

What SRID are you using James? the “distance” function is actually using SRID unit (treat SRID and EPSG as the same thing) and so technically you can’t assume the units are metre (but they probably are). Also, by setting the default of use_spheroid to true you are getting a more accurate calculation of distance. WGS84 is PROBABLY the spheroid you are using… the world is not flat and it is not a sphere (if it was either of these things all our lives would be much simpler). setting use_spheroid to FALSE would be faster, because the maths just assume a perfect sphere but it would be less accurate. So, the answer to whether your query is correctly calculating <25m distance will have more to do with what coordinate system and units of SRID you are using than setting use_spheroid to false. Just leave it TRUE - if you really want to be strict with 25m

Sorry, I’m not an expert - perhaps I know a dangerous amount - enough to think that I know what i’m talking about.

1 Like

If anyone is reading this, I’ve worked out you’re probably using GEOGRAPHY (ie Ellipsoidal spatial data types), therefore PostGIS defaults to metres (because angular units are a pain) - so after all that James, your query is correct and you can ignore what I said.

EXCEPT… setting use_spheroid to false will speed things up, and really over a few kilometres of a run the difference between a perfect sphere and the WSG84 spheroid are tiny, and so if you can live with a few centimetres inaccuracy, your code will run really quite a lot faster.

ST_DWITHIN(geog, path.geog, 25, false)

https://postgis.net/docs/using_postgis_dbmanagement.html#PostGIS_Geography_AdvancedFAQ - section

1 Like

I am trying to figure out how to manually enter a few streets that I completed but are not marked complete (one street ends and a building/business begins, but CS says I need to apparently run through the building to finish; another street ends and a driveway begins).

How do I manually override those streets?

Mapping changes need to be entered in OpenStreetMap (OSM). The changes you enter there will (eventually) make it here. If you want to mark a street complete, you can do that on this site.

I’ve edited the wiki to include instructions on how you can mark streets as manually complete - visit the street’s page in CityStrides & click the mark as manually complete button

1 Like


When we mark roads as manually complete (I had a few roads that I completed but they aren’t marked complete), do they fill in on the life map like the others? Or do they remain blank (not purple)?

Hi Molly - they do not fill in the map with a purple line if you marked them manually completed. The purple line is the GPS record of where you’ve been.

1 Like

I see from above that marking roads as manually complete does not mark them as purple. It also seems that it does not count toward the percentage of roads complete. Is that true? If so, how does one get to 100% complete if roads are not accessible and updates made to OSM are not taking effect or roads passing outside city borders are not reflected properly in our Life Map?

See also: Need advice regarding a private road and city border

James’s response in the above:

Two things happening here:

  1. most cities have an issue where streets extend past its borders, this has been fixed for newly imported cities and I’ll have a fix for existing cities eventually
  2. the street has some section of it that is not properly marked as private in OpenStreetMap & it needs to be edited there (then I need to update the data in CityStrides; a thing that I haven’t built yet)
1 Like

As far as i know, manually completion is deleting the nodes, but not colouring the street, since the purple is the gps tracks. It also makes 100% completion possible (and ocrrectly so imho, since one has run all runnable streets. Ans the flagged streets will dissapear sooner or later in CS anyway).


" Street has nodes all over : Because of this lack of “street” record, the underlying CityStrides code needs to build its own understanding of a Street. This is (currently; April 2020) done by collecting all the Way records in one city with the same name & collecting all of those together as a Street."

One issue that I think this causes which I just want to note, the query excludes trunk roads. However a major highway within my city boundaries (70mph traffic, no paths) has nodes on it, and my guess is that this is because it has a name ‘london road’ which is the same as a normal road within the city.

If you edit OpenStreetMaps so its Foot = No for the nodes that are inaccessible then next time Brighton is imported major London Road will disappear, but the minor London Road will remain.

1 Like

A post was split to a new topic: Tips on adding manually created GPX files to Strava?