I’m finding that I can pull data into JOSM and iD that I know exists (due to recently pushed edits), but a query on the map doesn’t list them (not to mention that they also aren’t being rendered; however, when something’s awaiting rendering, I always, at least by my experience, can still query it).
For example, this query should list building=toilets, but it doesn’t. If I edit that location in iD I can see the aforementioned feature, and I can also pull it into JOSM, but it isn’t being rendered, and the data isn’t present in the map via a query.
Update: I appear to be able to see the edits in the history, but I’m still not able to query them, or see them render.
No just updates to third party sites and internal stuff (rendering, nominatim and the internal overpass instance) are not working (if it is just replication that is broken).
Yes, and a qualified no, you should be able to access them via the editing API which as the name says, is used by editors.
PS: we’re likely 2-3 hours before operations can do anything.
Hmm, it’s seeming like this is no longer the case. I pushed a change, and I can’t see it in iD: is_in is present in this query, and it’s visible in iD. It should not be, by the aformentioned changeset.
Well, the changeset seems to be fine, so maybe changeset ingestion is broken? if so, it might mean that the edits will be lost, if they’re all based on stale data. I have no idea if changesets includes the old state (I guess somehow they do, since conflicts are detected?). Maybe they can replay some changesets, but once you start having conflicts, not sure which options there are…
Speculation here: if the replication (nothing to do with the replication via diff files) between the database instances is broken the read-only database(s) will be out of sync*. IIRC this can be a problem for iD as it doesn’t update the loaded data in place after an upload, but discards the current data and reloads it, potentially retrieving said out of sync data from the read-only DB.
* however Grafana would seem to indicate that that is just fine.
The updating of Carto Standard, the OSM site reference, seems to be indeed sloooow. Fortunately with the Better-OSM-Org browser addon you get a visualization of what was uploaded, so you know you know.
This one about 7 minutes ago after another Ctrl+F5 in the windows browser.
But way/959011955 was not changed by your changeset. If you download osmChange XML, it will not contain such an element.
Judging by the fact that you have exactly 1000 objects in the changeset, did you happen to use uploading changes in parts? Maybe the upload was interrupted?
Confirmation of the issue: OpenStreetMap planet diffs are not currently updating.
The Ops team are trying to get this resolved. The issue is due to an unexpected issue with PostgreSQL and how osmdbt pulls the changes from the database.
The PostgreSQL database is operating normally and all map changes are being saved in the database. Our PostgreSQL site-to-site replication remains working as expected.
It is expected OpenStreetMap.org will be offline briefly for maintenance later. We have to stop some systems briefly to get the OpenStreetMap planet diffs (minutely / hourly / daily) back into sync with the database.
Progress on restoring the publish of planet diffs is being made, but care is being taken to ensure that only the expected data is published and we don’t miss anything.
Background: planet diffs (minutely, hourly, daily) are used by many downstream services. eg: rendered map on OSM.org (tile.osm.org), nominatim, overpass (query tool) and most other services use the OSM planet diffs to receive a live feed of changes from the main OSM database.
OpenStreetMap.org will be offline for the next hour due to maintenance while we fix an issue with OSM planet replication diff publishing. Sorry for the short notice. We will return services as soon as possible. maintenanceosmopenstreetmap
