That’s really interesting, at 21:30 UTC JOSM has just successfully loaded the Bing attribution data for me as well. 
However, May 1 is a public holiday in many countries, especially in Europe. Maybe that’s why the number of users is lower today (“bridge day”)? We’ll see what Monday brings.
Maybe it’s all these liberation days in Europe causing more bridging days as when starting up JOSM and loading the imagery set incl. Bing at 17:17 CEST (15:17 UTC), no pains here.
Loading has just failed again (12:35 UTC).
HTTP status code 403
DeniedCredentials
So the problem still exists.
Here was hoping, even late last night started Josm with bing without a hitch. The clock is ticking…
As nobody seems to have thought of this up to now: one way of working around the issue would be to find out who, outside of JOSM users using JOSM, is using the key and causing so high usage and asking them to stop.
And how exactly do you imagine that we discover who is/are causing the high usage?
Anyway they’re most likely a malicious actor who has zero interest in stopping even if we ask nicely.
For example by checking any web apps that you use?
1 Like
Friday was good again. It may be we’re too focused on the western world weekend thinking. In other parts it’s Friday-Saturday. So Bill may have helped to expand the world view at MS.
Problem still exists for me, on and off. Fixed it by restoring bing.attribution.xml from last week, but have the impression that resolution is reduced (lowest level seems to be missing; I’m not entirely sure).
Edit: compared with ID and yes, resolution is reduced.
1 Like
Can you please give an example of this (specific location)?
I can’t at the moment, as Bing is working in JOSM again … for now.
If Bing doesn’t work, then there is no reduced resolution either — it simply doesn’t work at all.
This just started for me when updating to the latest version of OpenWebStart.
BTW: Since this seems to be the necessary workaround for now, recentlyish I wrote a PowerShell script to make backing up a working bing.attribution.xml and later restoring it when JOSM is giving the error again easier. Usage is .\attribution-backup.ps1 backup and .\attribution-backup.ps1 restore, and you can add the parameter -DryRun to get the output describing what would be done without actually touching any files. I also have instructions in a bit more detail in a comment on the Gist:
At a time when the Bing imagery is working, run
.\attribution-backup.ps1 backup. Then, at a later time when you get tiles stuck on “Error: Attribution is not loaded yet”:
- Close JOSM.
- Run
.\attribution-backup.ps1 restore.- Reopen JOSM.
- Before loading the Bing imagery layer, disable cache updates by opening [File] > [Work Offline…] and choosing [Cache updates]. This prevents JOSM from trying to overwrite your working Bing attribution file with a non-working one again.
I assume your script is just copying the cached copy of bing.attribution.xml over the version in JOSM. If so, then I’ve been doing this successfully with the following workflow (which avoids having to close JOSM or disable cache updates).
1/ Open JOSM and load the Bing image layer.
2/ If the “Attribution not loaded” errors appear, then delete the image layer.
3/ Copy the good bing.attribution.xml file over the top of the JOSM one.
4/ Reload the Bing image layer, and it works.
But I have to repeat this each time I restart JOSM and the imagery fails to load. Perhaps your method works indefinitely if the cache is disabled?
1 Like
That’s how I do it too, difference is, Monday-Friday till about noon and western weekends starting/restarting JOSM, then my layer set including Bing loads fine. It’s only on the Mo-Fr afternoons-evenings having to go through the rigmarole.
Notably a JOSM ticket got the added comment from a regular JOSM programmer that the assumption is now made, either by this person or their group that Bing will be gone for JOSM after 06.30.2025 and my reading is of the linked letter above that over at the MS cohorts it’s taking the posture of either you license with pecunia forked over or you go dark.
Honestly, my script might work if used like that, I haven’t tested it that way. All restore does is move the current file temporarily, copy the backup file to bing.attribution.xml, and then delete the moved file once that’s done. The recommendation to close and restart is based on instructions others have given as well as just the basic assumption that if you’re going to be messing with a program’s files, closing the program before you do so is Probably A Smart Thing To Do.
If you do as @Robert_Whittaker says, simply add this line to the instructions:
3a/ Change the Attributes of bing.attribution.xml to Read Only (make sure it’s a good file and not a failed one first).
Do this by right clicking on the bing.attribution.xml file > properties then check the Read Only box, then OK
You don’t then have to replace it each time the loading of tiles fails
The bing.attribution.xml is usually located at C:\Users$env:username\AppData\Local\JOSM\cache
The above has worked fine for me for many months now
2 Likes
Hello,
the potential loss of bing imagery as JOSM layer at the end of the month has quite some serious implications for mapping in most countries, where no other high resolution imagery is available. Most JOSM mapping (at least in Australia) would probably come to a halt, I’m unsure about the implications for ID editor. There’s no guarantee our workarounds will continue to work. I would like to restart the discussion/conversation about how to proceed, if there’s any progress/solutions etc. I think this thread is more suitable for that: Discontinued Services Bing Maps Rest Services - #44 by Jorieke_V
While I very much appreciate all the effort everyone puts in behind the scenes to sort out the issues (thanks), information trickles very slowly in this forum.
2 Likes
Bing tiles are finally working. About time to create a cache backup.
Aaaaaand I was too late with this. Huh, that was a very short lifespan.