I still like the idea of the efficiency score for completing a city, but that metric calls into question the total miles in a city that is reported.
I went in an measured the actual roads of Portage, OH using the CS Routing tool and measured them one-by-one and got only 3.84 miles instead of the reported 8.41
Then today I was looking for nearby small towns to finish when I am training and I came across this one:
It is listed on its city page as having 34.55 miles of roads. That number seemed a bit high to me so I measured it and got 9.4 miles.
I thought what was going wrong with the calculation was the city has two singular nodes on its N border where there are differently-named continuations of streets. If the calculation includes the length of those streets outside the city border, it only takes it to 26.4 miles.
So then I was thinking it might include the length of any streets that continue outside the city border, but that gets way to many miles.
I know it isn’t a big thing, and I don’t like to make more work for @JamesChevalier, but it sure seems like the algorithm to figure out street length could use some tweaks.
I get the total distance from Overpass (the service I query to pull data out of OpenStreetMap). This is the query used to get the distance for Berkey, Ohio: overpass turbo (you’ll have to click the top left Run button & click to ignore the error & then click the Data tab to see the results).
It tells me there are 51414.828 meters of streets in Berkey, which would be 31.947693 miles. This distance can change between city updates, so if any streets are created/updated/deleted I recalculate the distance for the city.
I am not an overpass guy, so my initial review of the code doesn’t scream that there is something wrong with the filtering you are doing to eliminate things like driveways and such.
We dealt with borders before when cities included all nodes on ways that crossed the boundary, but not just the part of it within the boundary, but I don’t have enough knowledge to know if that is part of what we are looking at here.
I’m decently certain that’s what’s happening here…
The query returns two sets of data in one list - both ways and nodes. It avoids returning the individual nodes that are outside the city border, but the way records themselves still know about those nodes. So the stats call isn’t summing up the returned node distances, it’s summing up the actual distance on the way record itself.
Since way records aren’t necessarily entire streets, there are some partials that extend out beyond the border which increases the total distance without exploding it.
I think I’ll have to find a way to sum up the distance on my stored data, but that hits upon the “same named streets” issue.
Ugh.
There is no easy way to manually measure it, but I think you are right - it is most likely counting the length of any segment of a way that has any part of it inside the border.
How to fix that? Your experience beats mine for sure, but that doesn’t make it easy.
I was able to cobble together some code that calculates distance off my stored data … It’ll err higher in the case of divided streets (counting each side as adding to the total distance) but it’ll err lower in the case of streets extending out beyond the city border.
I spot checked a few cities…
184.54 (overpass) vs 224.89 (mine)
106.28 (overpass) vs 100.5 (mine)
Berkey came out to 9.33
In addition (totally separate issue), I found some cases where a street passes through a city border & its name changes as it goes through … I saw some instances where the node placement wasn’t correct, which resulted in a single-node street.
