Mismatch nested and parent city

Support City/Street/Node Issues
1

I have a strange situation here in Stockholm. Yesterday morning I discovered someone had edited a couple of streets in the ferry port area, and changed access from customers to permissive. Since this is behind gates I think permissive is not correct, so I changed it back. Now Stockholm and its nested cities was update today, this morning, but the strange thing is that for the nested city Hans Westerback is running Östermalms stadsdelsområde, Stockholms län - CityStrides everything looks OK, these streets do not show, but for the parent Hans Westerback is running Stockholms kommun, Stockholms län - CityStrides these street appear as incomplete. And actually, looking at the mail time stamps Östermalm was updated an hour before Stockholm, so I can’t see how my change for Östermalm is visible, but not for Stockholm. One example of a street which is customers access in OSM but incomplete in CS Norra Bassängkajen - CityStrides

2

Ok, this is sorted now after a new update. I thought that if a city is updated in OSM, and the next day in CS, this would bring the new change into CS, but it seems that is not always the case. There can be a time gap, so the change might not be included this time, but next update instead

3

Yeah, this is how you can tell how far back the data it’s serving currently is:

  • Visit https://overpass-turbo.eu
  • Replace the query with [timeout:900][out:json];area(1);out ids;
  • Click the “Settings” button
  • Select https://overpass.kumi.systems/api/ from the Server dropdown menu
  • Click the “Save” button
  • Click the top right “Data” tab
  • Click the top left “Run” button
  • View the timestamp_areas_base output value

As of right now, it’s 2023-09-09T14:26:51Z which is basically fully up to date.
:thinking: Interesting … my queries identify myself, and those are returning 2023-09-02T20:19:00Z so I must be throttled due to the amount of queries I’m sending over :sweat_smile:

4

Hmm, following your steps I get:
“timestamp_osm_base”: “2023-09-02T20:19:00Z”,
“timestamp_areas_base”: “2023-09-02T20:19:00Z”,

5

OK, so they probably have multiple Overpass servers behind a load balancer & each is in a different state. I’ve been doing some testing today and I’ve seen 09-02 and 09-11 across multiple queries.

6

Maybe that explains why the nested city, update an hour earlier, was OK, but not the parent. Different servers used

7

I tried again now, and still I got this old date:

“generator”: “Overpass API 0.7.60 f4c14d41”,
“osm3s”: {
“timestamp_osm_base”: “2023-09-02T20:19:00Z”,
“timestamp_areas_base”: “2023-09-02T20:19:00Z”,

Restarted my browser and tried again, this time looks better
“generator”: “Overpass API 0.7.59 e21c39fe”,
“osm3s”: {
“timestamp_osm_base”: “2023-09-13T08:31:58Z”,
“timestamp_areas_base”: “2023-09-13T01:55:08Z”,

Could it be that one of the overpass servers has some kind of freeze, and never updates? Maybe you could ask in the Slack channel for #overpass?

8

It’s not Overpass, directly. It’s Kumi Systems … I tried sending them a note on their contact page, but it failed. I was able to send it over in their main site’s contact page, though.

It seems isolated to "generator": "Overpass API 0.7.60 f4c14d41" with both timestamp_osm_base and timestamp_areas_base stuck at “2023-09-02T20:19:00Z” … If the issue persists much longer, I might have to ignore responses from f4c14d41 :slightly_frowning_face:

1 Like