Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to new (undocumented) Bing Streetside bubble metadata URL #10100

Closed
wants to merge 1 commit into from
Closed

Switch to new (undocumented) Bing Streetside bubble metadata URL #10100

wants to merge 1 commit into from

Conversation

dankarran
Copy link

Bing Streetside bubbles have often been missing recently, with the bubble metadata requests coming back with 401 errors. Occasionally, enabling the Streetside bubbles does work, but more often than not they don't show up.

This issue was first reported in the iD issue queue about two weeks ago (#10074) and also in the Rapid editor issue queue around the same time.

Per my comment in the issue, I noted that the Bing Maps website was now using a different URL, so I went poking around. I can't find either the old URL or the new URL documented anywhere, but switching to the new URL seems to work fine, and so far feels more reliable. The JSONP callback doesn't seem to be available with the new URL, so I dropped that and replaced it with a request method similar to the one in the Mapillary service.

Whether or not this is the right fix, I don't know. Probably needs discussing with someone at Microsoft?

bhousel added a commit to facebook/Rapid that referenced this pull request Feb 9, 2024
@tyrasd tyrasd added the streetlevel An issue with streetlevel photos label Feb 16, 2024
@tyrasd
Copy link
Member

tyrasd commented Feb 16, 2024

Hey, thanks for digging into this! 🙇 However, I'm not quite sure if switching from one undocumented broken API to a slightly different undocumented endpoint is really going to fix this in a stable way.

Did you hear from Microsoft that using the undocumented API at https://t.ssl.ak.tiles.virtualearth.net/tiles/cmd/StreetSideBubbleMetaData URL would be fine for OSM editors?

When I last talked to someone at Microsoft about this topic, it was recommended that we should not use these undocumented APIs and instead migrate to the official, documented Bing Maps streetside imagery API (cc @mbrzakovic). I just looked at my notes and it seemed that the only outstanding issue was whether we'd need a dedicated API key for that, as the one which we're using for the undocumented API does not work for the "proper" API.

As Bing's streetside imagery is currently now working in iD, I'm going to see if this can be done in a relatively quick way. Closing here for now.

@tyrasd tyrasd closed this Feb 16, 2024
tyrasd added a commit that referenced this pull request Feb 16, 2024
replaces the use of undocumented APIs for Microsoft's street level imagery service and gets rid of hardcoded values, e.g. for the `g` ("generation") parameter

see https://learn.microsoft.com/en-us/bingmaps/rest-services/imagery/get-imagery-metadata#get-streetside-metadata-centered-at-a-point for API docs

see also #10100
@dankarran
Copy link
Author

Thanks for that @tyrasd. I haven't heard back from Microsoft since their original acknowledgment last week. If there's an official API that works for this though, that sounds like a better solution anyway.

By the way, I've just tried the streetside bubbles in the live iD editor, and got 401 errors again, so it seems like it's not working reliably, at least for me. Maybe it depends which IP the requests come from, so works for some but not for others?

streetside-401s

@tyrasd
Copy link
Member

tyrasd commented Feb 16, 2024

oh, I had accidentally used a non-https URL for the API endpoint (copy-pasted it and didn't get the error locally as my local dev setup is not running on https). this should be fixed in 17d1c27

PS: by "live iD editor": do you mean the one on osm.org (your screenshot still has the old URL from before the fix…)? That instance does not have the fix yet (it requires to do a full release to updated that instance). But you should be able to test the development version on https://ideditor.netlify.app/.

@dankarran
Copy link
Author

PS: by "live iD editor": do you mean the one on osm.org (your screenshot still has the old URL from before the fix…)? That instance does not have the fix yet (it requires to do a full release to updated that instance). But you should be able to test the development version on https://ideditor.netlify.app/.

Ah, I misunderstood, sorry - I thought the old version was still working for you, even without your fix. Your new version looks good, and the bubbles work for me there 👍

@tsmock
Copy link

tsmock commented Feb 22, 2024

@tyrasd : What was the process like for getting a new API key (or is it one for OSM editors in general)? I was looking at fixing a similar problem in JOSM Microsoft Streetside plugin, but it appears that the old API key only works with the undocumented API.

@tyrasd
Copy link
Member

tyrasd commented Feb 24, 2024

@tsmock It was recommended to me to re-use the key we use to fetch the Bing aerial imagery metadata (https://dev.virtualearth.net/REST/v1/Imagery/Metadata/AerialOSM?…). I would assume that this should also work for the key you have in JOSM for that endpoint. @mbrzakovic maybe you can confirm this for us?

@dankarran dankarran deleted the 10074-streetside-url-change branch March 1, 2024 00:35
@mbrzakovic
Copy link
Collaborator

Apologies for late reply,

@tyrasd you can re-use the existing iD key for Bing streetside imagery as well.
Great job on transitioning to new api - it was the right and recommended move.

@tsmock there is no specific treatment to account/key that josm is using (if it works for Aerial imagery, it should work for Streetside as well). Please write us at osm@microsoft.com with some more technical specifics and we will try to resolve the issue you are experiencing.

@tsmock
Copy link

tsmock commented Mar 26, 2024

Sorry, I forgot to reply to this issue when I fixed Microsoft Streetside ~2 weeks ago.

As of r36228, the plugin is now using the official API (I have no clue what API it was using previously, probably an "internal" API or something), and the key for background imagery works with that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
streetlevel An issue with streetlevel photos
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants