See the screen capture above for today’s CityStrides update for Burbank, California. This shows an unusual reversion back to a version of Open Street Map from about 2-3 weeks ago, not as it shows today. Why would that happen?
For example, CS deleted the correct McFarlane Avenue and added back the incorrect Mc Farlane Avenue (which is how OSM used to have it). But OSM today still has the correct McFarlane Avenue (I was the one who made the OSM correction, based on city records and an on-the-ground survey of the signage).
Lots of other streets were rolled back too. But none of them have been changed in OSM – everything is still in OSM as it should be, suggesting this was a CS rollback. @JamesChevalier, any thoughts on this and what needs to be done to correct it?
email notification from today shows an edit shortening a street name, but OSM history shows a maproulette editor actually updating the abbreviation as part of the project to spell these out. Only guess is that CS is pulling stuff from the tiger:name_base tag rather than the plain name tag?
Edit:
I remembered another instance like this from a short time ago. I don’t know why Bull Crossing would have been deleted, but when it was updated CS removed it.
James had mentioned elsewhere recently that one of the servers from which he gets data had outdated OSM information. If that issue resurfaced, then essentially what happens is:
CS gets data from an up to date server, everything looks fine in CS.
Some time later, CS gets data from an out of date server, thus overriding the newer changes with the old data.
Idk if it is this issue this time, but it would match what you are observing.
This seems like a very likely hypothesis! Thank you, @ward_muylaert.
@JamesChevalier, do you have any insight into fixing this? I thought that the problem might have gone away since Burbank seems to have recently fixed itself, but, today, I see that the city of Los Angeles just similarly reverted back a couple of months.
Running a query in the Overpass Turbo web interface has a
<meta osm_base="2024-01-11T16:34:05Z"/>
in the resulting XML. Do the servers you contact for OSM information return similar data, @JamesChevalier (and do they not lie about it) ? If so, that might be sufficient to filter out the bad data.
The core issue is that the Overpass service I query has some servers that are out of sync / serving stale data. This is causing some older versions to be returned, as well as new updates not appearing.
I don’t know how many servers this service has running behind the scenes, so I don’t know offhand what percentage of city updates this is currently affecting.
The timestamp_areas_base value is 2023-11-27T12:56:45Z in one of my test requests & 2023-12-30T01:46:35Z in another
( there are two dates provided, timestamp_areas_base & timestamp_osm_base … the ‘areas’ timestamp is more important, because I’m querying via internal area records)
The code currently ignores the special headers in the response, but it would be helpful for my system to early-exit the update process if the date is too old.
I’ve also contacted the service about their out-of-sync servers, so hopefully that helps get things resolved soon.
I’m going to mark this thread as “resolved” just so this message gets pinned to the top, hopefully making it easier for others to see that I’m aware of the issue & working on it however I can.
I’ve also merged another thread into this one, since it was the same underlying issue.
Update on 2024-01-12: I’ve updated the code to A) randomly choose from a few Overpass servers and B) early-exit if the returned data is more than 7 days old.
The main Overpass source is still having tons of issues (responding with errors and old data) & they haven’t responded yet. In the meantime, hopefully distributing the query load across the other available servers will help us get back to normal updates.
I’ve noticed that streets in some cities that are marked private in OSM are still showing as streets in citystrides even after several updates.
Example of Barrington NH. Kevin St. Laurent is running Barrington, New Hampshire - CityStrides (Kelly Lane, Hayes Road, Big Rock Lane are a few examples)
Many streets showing as grey but they still have nodes, they are marked appropriately as private in OSM. There was an update to the town on 12/28 when I first noticed this, assumed it would be fixed with next update but after 01/07 update the issue stil remains.
The map display is handled by Mapbox (I have little/no control over how streets are displayed), and the nodes etc are handled by me in the CityStrides database.
I update the data through a free Overpass service, and their servers can go sideways sometimes … Usually in the form of one/some of them becoming out of date.
A day or two lag behind the actual OSM values is pretty normal, but things can get worse than that at times.
I noticed Kelly Lane was not returned in a test query, so I queued up another sync for Barrington. I’ll keep an eye on this update as it runs, to see if it removes the street.
I think I am having a similar issue on St Thomas USVI. We have a lot of private drives labeled as street as well as other things like stairways, very inaccessible paths etc, all still labeled as nodes to be completed. I am new to OSM but have been trying to edit to show streets as private or driveways as gated etc. The attached shows an edit I made 10 days ago, City Streets updated on the 7th but the streets highlighted are still showing as Nodes to be completed. Not sure if I am doing something wrong or if I am being impatient or ???
Any help or education is appreciated.
there are two dates provided, timestamp_areas_base & timestamp_osm_base … the ‘areas’ timestamp is more important, because I’m querying via internal area records)
