Attached two example images of StreetViewCoverageLayer. 

"Then" is an example of the StreetViewCoverageLayer from 25 November 2014.
"Now" is 14 December 2014.

	CoverageLayerThen.jpg 216 KB   View   Download

	CoverageLayerNow.jpg 328 KB   View   Download

If you're wondering where this layer is documented?

See  https://developers.google.com/maps/documentation/javascript/reference#StreetViewCoverageLayer

update...

maps.google.com also now has NO Photosphere or Maps for Business dots.

www.google.com.au/maps/ STILL has the dots!

	MapsAUWithDots.jpg 317 KB   View   Download

	MapsComNoDots.jpg 342 KB   View   Download

This should be fixed. Please reopen if this is still occurring.

The photosphere blue dots have disappeared again! Monday Aug 24 2015.

Confirmed. Looking into this.

I there any deadline on this? There are lots of api implementations out there that depend on this feature. So far the photosphere program that has been moved to google maps is a complete disaster. 

+1 to fix this problem.  Really serious disability after Google Views was merged to Google Streetview.  This is related.  No doubt.

Please do fix 

pls fix this problem

yes, please fix this.

The blue dots for photo spheres disappeared with the demise of Google Views. Also, it is now no longer possible to obtain embed links or pano IDs for photo spheres. The "get panorama by location" feature in javascript continues to function for Street View panos, but not for photo spheres. Unless you already know the pano ID, you can no longer access a photo sphere using javascript. Recently uploaded photo spheres are completely inaccessible for javascript applications. Google's previously unified javascript API is now broken.

Please restore embed codes and pano IDs, as originally envisioned here -- https://developers.google.com/photo-sphere/web/

Awaiting a fix.

Hi, there is no need to post "please fix" comments they don't help. This is not a discussion forum! Simply click the yellow star at the top of this page to raise the profile of the issue. 
If you have additional Maps API issue's (this Issue is just about Street View Coverage Layer) please find or create a separate Issue by clicking "New Issue". Thanks.

With our apologies for this being broken. This should be fixed as of roughly 3 hours ago.

Well done Maps team.  Its working fine now.  Please don't skimp on your test suite going forward :)

There is a baffling new behavior on the maps.  I understand this is not a Maps API problem but a Maps product problem.  But I am guessing you guys still talk to each other?  And adding here since we just worked on it.  So, not sure whether there is a relation.  After loading a sphere in Streetview, after 1 second, the browser URL changes to show a wrong co-ordinate.  It changes, negative Latitude number to positive

eg.
https://www.google.com/maps/place/Thurston+Garden/@-18.1486111,178.4249717,3a,75y,71.01h,74.97t/data=!3m8!1e1!3m6!1s-UPeNdFHU-GU%2FUvYSxld7mGI%2FAAAAAAAAH8A%2F9aZblWcwqJ0!2e4!3e11!6s%2F%2Flh3.googleusercontent.com%2F-UPeNdFHU-GU%2FUvYSxld7mGI%2FAAAAAAAAH8A%2F9aZblWcwqJ0%2Fs203-k-no%2F!7i8000!8i4000!4m2!3m1!1s0x0000000000000000:0x939f5ff3dd89d83e!6m1!1e1?hl=en

@-18.1486111,178.4249717 : Is the correct LatLng for this sphere.  but once sphere is loaded, the URL changes to @18.1486111,178.4249717

So this issue is marked fixed by a project member?
StreetViewCoverageLayer still does not show any photspheres uploaded after 3rd of August. Are you aware of this? 

I have not done a thorough inventory but the majority of the photo spheres are now showing as blue dots.  I have found a few that are not showing up, but when I mouse over the area, the preview shows. As for the 3rd of August date, I can confirm that I have uploaded a good dozen or so since 3 August and they are all showing.  

Yes unfortunately the Google Views merger has caused some infrastructure changes, which means new photospheres currently do not show up in the maps api. This is a separate issue from the previous issue, but this only applies to newly uploaded photos. Old photo should stay working uninterrupted, and if they fall off that is a bug.
We're working to iron out the issue for new photos as well, but that will not happen in the next couple of days.

Thanks for flagging!

Glad to hear that you are working on a solution for post merge photospheres also to be made available through Maps API.  And you are right older Spheres are accessible through the StreetviewOverlayLayer like always did.

I would like to put this in bug the real world context.  It might not be so obvious to the Maps API team; there were 100s of businesses around the world dependent on the ability to publish to Maps and those imagery being available through the Maps API.  This change in behavior has created a serious problems to people who made business commitments already.  It is unfortunate that there was no clear communication on the impact on the Maps API front.

Hoping to see a resolution soon.

Unfortunately not fixed until ongoing added tours are also accessible via panoID; it's a really important feature I believe. Thanks in anticipation. 

Thanks Google for reply if that means that remove new photospheres from map API was not a goal.
Using photosphere in map you have done good job, keep going and make thousands photographers happy.

In the moment this does not look like a merger to me but rather a senseless attempt to separate photspheres from street view. The people coming here are to find information and solutions are not hobbyists but programmers trying to make a living. "That will not happen in the next couple of days". Really? What kind of statement is this from a pro? I would lose my business very quickly telling this to a customer.

please fix it

Post merging of photospheres via Maps API is widely used by many businesses.

Please raise the prio of this issue. 

Great if an expected delivery date is published here! 

Generally, there are now some opportunity to determine pano-ID... at this time?

Older examples  - it works http://astanacapital.com/index.php?fullarticle=49

As with many of the above posters, part of our business involves taking and embedding of photospheres.

We are currently unable to obtain the Pano ID of NEW photospheres and are therefore loosing business.

If there is a workaround for this would somebody please post it.

Some TEST DATA for the Dev Team (What more you want us to do?)

Attachment 1 shows same area with StreetviewCoverageLAyer ON
Attachement 2 shows same area on Google Maps, with IT's StreetviewCoverage layer on.

What is missing is at least two blue dots (Photospheres).

One of the missing Photospheres is at this URL.

https://www.google.com/maps/place/Meridian+at+Harrison+Pointe+Apartments/@35.8068522,-78.7805955,3a,75y,46.1h,90t/data=!3m8!1e1!3m6!1s--JUC4fEFGcM%2FVVThyYUcFMI%2FAAAAAAACzSQ%2Fse1GzqTOxJw!2e4!3e11!6s%2F%2Flh6.googleusercontent.com%2F--JUC4fEFGcM%2FVVThyYUcFMI%2FAAAAAAACzSQ%2Fse1GzqTOxJw%2Fs203-k-no%2F!7i2508!8i1254!4m2!3m1!1s0x89acf3c6174e42d3:0x6898ce7e11ffe6ac!6m1!1e1

	Screenshot 2015-09-13 at 7.32.49 AM.png 87.7 KB   View   Download

	Screenshot 2015-09-13 at 7.35.04 AM.png 40.9 KB   View   Download

Looks like the missing photo sphere are now showing.  Thanks to the Project team for fixing it.  Hint: if you do not see some blue dots, you may need to zoom in further.  I found that some of mine were visible and assumed the invisible ones were not there until I zoomed in a bit more to see them show up. 

Hello Nick: Yes, there are positive movements on Maps front.  Hopefully the StreetviewCoverageLAyer will also start showing signs of TLC by the Dev team.  As far as your usage goes, to embed anything to a webpage or to use it in http://walkinto.in , we will need these to be available on StreetviewCoverageLayer.

Status: 	Fixed
Owner: 	[email protected]
Closed: 	Sep 1
ApiType-Javascript3

Please RE-OPEN this issue.

This month Google updated all the support about Street view: how publish, how create a constellation, and more.....
https://support.google.com/maps/answer/6281981?vid=1-635777319825221246-3529927389#thumbnail

I am glad there is some corrections being made. I still do not understand why some of my panos that I created and put on Views are still able to be used on Walkinto.in  or PanoWalks and some are not able to be used. All of my panospheres were uploaded and approved for Maps prior to the transition. I would greatly appreciate some help with this issue. I was using the images and tours for a websites for local directories.
Thanks

As with #37 above we also use our Photosheres on our directory by simply storing the Pano ID in a database with the other properties of of the members business:

https://www.visithorsham.co.uk/product/photosphere

Since the changes we have been unable to obtain the Pano ID of new photospheres so are unable to add them.

Most of these photosphere were taking using the Android App but we do always inform our customers that the professional 'see inside' option is available - so preventing these 'amateur' (albeit Maps-Approved) photospheres is also blocking the 'on-ramp' to more professional Google services.

It seems crazy to me that Google was actively do this to people that are effectively promoting Google services

Hi folks,

We appreciate the level of concern around this one. The team is working on a fix as a matter of priority, which we hope to have live within the next few weeks.

Note that the fix involves switching over to a module that is not yet ready for a general launch. This means that developers who need to be able to display recently-uploaded photospheres will need to make a small code modification (set a variable) in order to do so.

Thanks for your patience, we know this sucks. We'll keep the issue updated.

(No comment was entered for this change.)

I am not sure if this has been covered, but I uploaded a photosphere to a public park in my city via Google Maps using the "upload photos" option. The photoshpere uploaded however when I click to open it, the image started out sideways or pointing straight up. Any advice or suggestions to fix this issue will be greatly appreciated. Oh I am not sure if this is a global problem, but I know another photographer has the same problem as well.
 Here is the link to the photosphere:  https://goo.gl/maps/J0xUg
Thanks

I submitted photospheres of this park and they are appearing sideways instead of the correct way.

Other people I know have had the same issue
https://www.google.com/maps/place/Jervey+Gantt+Park/@29.1661361,-82.0904159,17z/data=!3m1!4b1!4m2!3m1!1s0x88e7d320d5d9aaf9:0x17114c6cba7cb5fa

Dear project members folks
It has been almost 2 months now since the api is broken. You promised us to keep us updated and come up with a fix. What is the status? As mentioned before some of us are loosing considerable income during this time.

We are indeed actively working on a fix, and will be back on this thread as soon as it becomes available. We know this is a longer wait than many of you would have wanted, but there are complex backend infrastructure issues that make it far from trivial.

Thanks again for your patience.

Please fix this, I'm also getting complaints from customers

Actively working on a fix for 9 weeks?

A month back this is what you guys (google dev) said

"Note that the fix involves switching over to a module that is not yet ready for a general launch. This means that developers who need to be able to display recently-uploaded photospheres will need to make a small code modification (set a variable) in order to do so.
"

then, in two weeks

" but there are complex backend infrastructure issues that make it far from trivial"

In the mean time we all see some active changes happening on the Streetview module involving photosphere.  Why this fix did not make the cut? 80 people waiting on it should give you an idea that your customers are suffering.

Well, after almost 3 months I am pretty sure now that nobody is actually working on this, because no serious programmer can be that ignorant and clueless.  

Folks, we understand your frustration here. Rest assured that we *are* actively working on a solution and we *will* update this bug as soon as it is available for use.

As I noted earlier, the initial breakage resulted from backend infrastructure changes and unfortunately this means that the solution is not a simple bug-fix but rather a relatively large change.

@Google project member: Thanks for the update.

Lack of progress updates and very limited info about future solutions is hard to swallow for businesses developping products and services on top of Google platforms. 

Sometimes Google is a very very very large black box and a difficult partner. And sometimes it's a absolute pleasure. Anyway, we all are responsible for families, paychecks and customers.

So any information is appreciated...not daily but periodically.

Hi all,

We've just released a new renderer option for version 3.22 of the API that will address some of the issues brought up in this thread. Specifically, this release will reinstate the ability for users to view newly-uploaded photospheres via the API. Please note that the renderer is not fully mature and is being made available ahead of schedule as a solution for those applications greatly impacted by the issues discussed earlier.

Some further points to note when using the new renderer:

- Navigation chevrons aren’t available. This should not affect most photospheres, since they're not connected. We’re working to restore navigation chevrons in the new renderer.
- Custom user-hosted panoramas aren’t available.
- This new renderer has not been as thoroughly tested as a full release, so you shouldn’t expect it to be as reliable.

Again, please note that you should only use this solution if you are affected by the inability of the standard renderer to display recently-uploaded photospheres.

To make use of the new renderer, you need to specify the following setting in your JavaScript code, prior to Street View instantiation:

google.maps.streetViewViewer = 'photosphere';

Thanks for your patience, we apologize for the disruption caused by this issue, and we'll provide further updates here once a complete solution is released.

Sorry Stephen, appreciate you speeding this up.  Unfortunately the whole fix seems totally off target.  I am a bit caught up to give test case today.  Quick test this is what I could see:
1. Pano ID is not stable anymore : especially for older panos.  Are you guys changing panoid format?  It'd going to be scary.
["F:-Vq5cvzbGAIE/VMTIFmD02LI/AAAAAAAAJww/5PYURFhjajE"] this is the panoid of a sphere I could load.  Clearly far far away from the usual 22 char format.  What's up with those /s?
2. Some spheres are showing up on Streetview layer without PanoID
3. imageryviewer.js is spewing max_callstack_exceeded every once in a while - crashing system.  Minimized so can't see much into it.
4.  How is this thing loading spheres some times without panoid?
5. It seems : google.maps.StreetViewService.getPanorama is returning false positive.  I am pretty sure of this.

Very unstable.  Could you please do me a favor, Is mode:webgl on the 3.21 version?  I know earlier you had told that it'll stay on the .exp verision, and considering the instability on current exp I'd really want to stay on 3.21 - BUT nees the mode:webgl.

	imageryviewer.jpeg 33.5 KB   View   Download

Thank you for giving this a go. I have a few questions:

1. In what way does the format of a pano id matter to you? It is meant to be an opaque string. What do you mean by pano ids not being stable?
2/4. Can you please describe how you got to a photosphere that doesn't have a pano id?
3. Is the error consistently reproducible under certain circumstances? Can you describe the steps needed to get to this error please?
5. Can you provide a code sample that illustrates what you mean by getPanorama returning a false positive?

I want to give you a better bug report.  Will do that too.  Terribly busy with something right now - funnily it is because of this bug though!  We ended up building a self hosting solution, with chevrons and a hosting platform because people really really wanted it.  People loved views!  Anyways, enough ranting.  Will give you proper bug report with test case - unless Rene here beats me to it :)

panoid is opaque string.  But panoid did not mutate.  As long as the same panoid from before still identifies the same pano (older ones) and the newer format is just for the newer ones - and this statusquo is maintained going forward we are all good.    So confirm me this please 

(1) 3.21 has mode:webgl - seems like it has
(2) Old panoids for older spheres (22 char format) is going to stay.
(3) The new panoid format is going to stay for all newer spheres.

1. The new renderer uses WebGL where it can automatically. However, if using the current standard renderer, webgl mode continues to be available.
2. If you have a 22 character pano id for an older photosphere, it will continue to load. However, a new format id may be returned for an older photosphere when looking it up via the service or when dropping pegman onto the layer.
3. The pano id is meant to be treated as an opaque string and no guarantees are made about its format.

In what way does the format impact your application?

How do you handle click events on your new canvas layer?
Is there an event listener that can be used?

Will it take you another 3 months to bring the chevrons back? This makes your fix useless using photospheres and streetview in the same application. 

Re #56: The StreetViewPanorama class (https://developers.google.com/maps/documentation/javascript/3.exp/reference#StreetViewPanorama) does not have a click event (either for the new or the old renderer).

Re #57: For Google Street View panoramas: on desktop, users can navigate my moving the mouse over the pano and an arrow will show up on the ground; on mobile, users can move by double tapping on where they want to go.

Re #58: Using the api without "google.maps.streetViewViewer = 'photosphere';" I can assign a onclick function to the panorama container, this does not work using your streetViewWiewer.

Using your api version 3.22 and "google.maps.streetViewViewer = 'photosphere';" I cannot see any chevrons when pulling up a streetview panorama.

Re onclick function: I see. Let us investigate that.

Re chevrons: Let me clarify your use case. Are you programmatically adding links from Google Street View panoramas to your custom panoramas and that's why the lack of chevrons is causing a problem?

The lack of chevrons is not causing a problem? Just makes your fix not very usable.
Here is a demo using your fix, you can load new spheres using the search button top right:

https://www.panowalks.com/pano.php?&id=C2ZIIucZKAwAAAQpmJ3HQA&h=338.85&p=-6.00&z=0.75

1: no chevrons for streetview panoramas
2: $("#pano").on('click', function().... not working

also frequently crashing in chrome

When you say the lack of chevrons is not making it very usable, can you describe how you use chevrons in your application? What does the lack of them make harder?

With the crashing, are you able to make it crash consistently under certain circumstances? Or are the crashes random?

Most of us are providers for third party overlays for google streetview. Customers also want to integrate photospheres. However it does not make much sense to have google street view without navigation chevrons for the sake of including photospheres into the application.

Crashing in chrome is random. Did not happen again the last 20 minutes. No problems in other browsers.

We took a look at your application: is it the case that you've turned off clickToGo (https://developers.google.com/maps/documentation/javascript/3.exp/reference#StreetViewPanoramaOptions)? That would explain why you don't see the navigation narrows on mouseover so that you can go from pano to pano in Street View.

Setting clickToGo to 'true' does indeed make the chevrons appear. However clicking on a chevron will not work while the pano is in motion. This would require stopping the motion on mousedown, which brings me back to the previous problem that the pano container cannot be addressed via mouse events.
I appreciate you looking into this.

I see, indeed clicking on them doesn't work while the rotation is happening.

It is pretty cool though that you enabled the smooth transition from google maps in the new api.

Is there a chance to make the streetViewViewer canvas accessible, maybe assign an ID. Or any suggestion why the canvas cannot be pulled into the DOM.
Or is this a dead end again?

> Is there a chance to make the streetViewViewer canvas accessible, maybe assign an ID
Could you indicate what you mean with "access" and the use case for the need to a canvas? We have different rendering strategies for rendering Street View, not all of them use a canvas. Also Webgl and Canvas have different types of canvases (which makes "access" different, perhaps?). It would probably help to understand why you would like get the canvas.

> Or any suggestion why the canvas cannot be pulled into the DOM.
Not sure what you mean. When we render a Street View with a canvas, the canvas already is in the DOM, right?

Please read #56 / #57 / #58 / #59/ #60 / #61 / #66 /#67
It would be cool id there is on project member dealing with this issue so we don't start from the beginning every time.

Ok this is about the click issue. I am aware of #56-#67. And like indicated we are thinking what we can do about it.

#69 didn't give away it's about the same issue. Really, "access" for a canvas can mean different things. Some people want access to the pixels and do other things.
I'm also still not sure how you assert the "canvas cannot be pulled in the dom". Could you explain? How is the canvas not already in the dom?

The issue is (like I indicated in #70) there isn't always a Canvas. We have rendering strategies without them. Getting the canvas itself is not a solution that would work for all the cases of the API. As such we are thinking how we can solve this for all use cases.
Please bear with us, while we would like to make something that would work generally.

May I also ask for #62. This worries us and we would like to fix this, could you tell us under what circumstances this happens?

I believe anything that is painted on the canvas is not in the DOM. I am looking forward to your solution because the current fix does not work for me. Although it's very close.

What I have seen so far is that Chrome is crashing when more than one window is using the streetViewViewer. The message after crashing says: Something went wrong while displaying this webpage. "Closing the apps and tabs that you don't need may help by making more memory available" Restarting the browser does not help. Clearing temp files brings it back to life.

Pls fix this problem

Re #74: See comment #51. Does it solve what problems you have? If not, please describe how.

enoch!
How many descriptions of the problems do you need? You have offered a fix which is faulty and it seems your work is done for this year. You promised to keep us updated on the progress of your work yet not once in almost 4 months there has been anything usable coming from your side.

This is in response to #51 by Stephen, adding
 google.maps.streetViewViewer = 'photosphere';
before instantiation.

I have been experimenting with this. I am glad to see correct spherical rendering on all browsers. I am extremely pleased with the smooth rotation of spheres (no chop), and with the transitions from sphere to sphere in classic Street View fashion, rather than having spheres come up in tile-by-tile chunks, as previously. Terrific work! Thank you, thank you!

Here are a few things I suggest you add that would be icing on the cake:
First, capabilities in 3.23 that I use, and request that you add to the version under development:
 - Capability to add custom link descriptions
 - Capability to push links onto panos (i.e., to link panos not currently joined in a constellation)

Second, a capability not in 3.23 that I would like to see added:
 - Auto-rotation on/off toggle

Here is a pair of links showing results of simply adding the StreetViewViewer call:
 http://suddenlink.net/popenoe/panoramas/coastwalk.htm
 http://suddenlink.net/popenoe/panoramas/coastwalk-new.htm

Hopefully comparing the above helps explain my interest in the requests.
Again, thanks!

Lest I seemed overly enthusiastic in #78, here are a couple more bugs to fix:

1. Both the new Google Maps and the new renderer fail to find photo spheres that were "lost" when Views was discontinued. All of my "lost" photo spheres are still viewable from the javascript API when I do not specify the new renderer, so I know they still exist. Is this not an oversight? Could you have Maps and the renderer programatically look at both the new and old data? Or at least make another pass at converting old to new data? Although what about our legacy 22-character panoIDs?

2. Clicking on "Google" in the lower left corner fails to bring up a photo sphere in Google Maps. This may be a minor bug, but it is right on top of a Google logo!

popenoe:

Responding to #79 (#78 is something we're aware of and we're still working on it) but for #79, could you please give a reproduciabe case?

I did this:

 <script>
var panorama;
function initialize() {
  google.maps.streetViewViewer = 'photosphere';
  panorama = new google.maps.StreetViewPanorama(
      document.getElementById('street-view'), {
        pano: "oOv4lqJJjswAAAAGOu1D7w",
        pov: {heading: 165, pitch: 0},
        zoom: 1
      });
}
</script>
 <script async defer
         src="https://maps.googleapis.com/maps/api/js?callback=initialize">
 </script>

Which loads successfully a pre-views-shutdown photosphere (Jan 2014 with a legacy ID). Loading it with the new id

deleting pano: "oOv4lqJJjswAAAAGOu1D7w",
and replacing it with the new id:
        pano: "F:-GlSyu6tw7B0/UtNeu1v4mAI/AAAAAAAAvYU/7WDtkuOvXOI",
Also works.

(Clicking the logo indeed is broken in the second case, and I'll file an internal bug for that, thanks for brining that to our attention, however clicking on the logo with old ID works, and so does loading/displaying it both with the old and new id.)

So could you explain #1? How are you old photospheres not reachable (they certainly should). If you can give a code example we can look into it as we can get a better understanding of what goes on.

Thanks for your report!

zwa... Thank you!

Yes sir, I believe I can show you examples of "lost" photo spheres. By "lost", I mean they are not reachable from the present Google Maps (no blue dot and absent from the image carousel), but they nevertheless retain the old 22-character panoID. Therefore, they are accessible if you already know that panoID or if you look for them in javascript via a location look-up.

Here are two URLs to play with:

http://suddenlink.net/popenoe/tools/Old-Inspector.htm
http://suddenlink.net/popenoe/tools/New-Inspector.htm

The first finds spheres with the old pano-IDs. The other finds spheres with the new pano-IDs. During this transition period, most of my photo spheres currently have both, but not all. Move the orange peg man over the coastline with each and look for blue dots. There are 8 photo spheres that produce blue dots from the old 22-character pano-IDs using the Old Inspector, none of which produce blue dots and have the new pano-IDs using the New Inspector.

This is a beautiful part of the Pacific coast lacking Street View coverage, and I would be very happy indeed to have these photo spheres back on Google Maps again. I believe from the buzz on the communities that this is far from a unique issue of mine.

With
 google.maps.streetViewViewer = 'photosphere';
 linksControl: false
does not work. The links in constellations show and work regardless.

FYI regarding #81, the missing are in a constellation of 8 spheres.

// pano IDs

var houda1 = 'lB7SyjbbvVoAAAQY9Zugsw';
var houda2 = 'VperGFdzL8AAAAQY9ZugrQ';
var houda3 = '5Tm6fvZDeuMAAAQY9Zugrg';
var houda4 = 'L-Bkee3X2ZgAAAQY9ZugtA';
var houda5 = 'teCAsxZ8Q8IAAAQY9Zugrw';
var hFalls = '289bu0ZcLsYAAAQY9Zugsg';
var little = 'JEjdeQQ5X_0AAAQY9ZugsA';
var moonst = 'PNwQR-SLJRgAAAQZCagiww';

My only other personally "missing" photo sphere is

var panoID = "e5N6fTWaFbUAAAQY-8rTSw";
var coords = new google.maps.LatLng(41.159763, -123.893951);

in another special, but obscure location.

 popenoe: Good question... Give me some time to investigate what is going on with these particular photospheres, and let me investigate whether this is an isolated case or whether this happened more wide spread. This is certainly not intentional from what I can see now.

Hey Jim

Here are your spheres. Click the google icon at the bottom left to go to Google Maps.

https://www.panowalks.com/pano.php?id=lB7SyjbbvVoAAAQY9Zugsw
https://www.panowalks.com/pano.php?id=VperGFdzL8AAAAQY9ZugrQ
https://www.panowalks.com/pano.php?id=5Tm6fvZDeuMAAAQY9Zugrg
https://www.panowalks.com/pano.php?id=L-Bkee3X2ZgAAAQY9ZugtA
https://www.panowalks.com/pano.php?id=teCAsxZ8Q8IAAAQY9Zugrw
https://www.panowalks.com/pano.php?id=289bu0ZcLsYAAAQY9Zugsg
https://www.panowalks.com/pano.php?id=JEjdeQQ5X_0AAAQY9ZugsA
https://www.panowalks.com/pano.php?id=PNwQR-SLJRgAAAQZCagiww
https://www.panowalks.com/pano.php?id=e5N6fTWaFbUAAAQY-8rTSw

Unfortunately the API is still not working right, but the project team is on holidays since 4 months.

popenoe: I've tried to trace what happened with these particular photospheres. Internal tools claim these have a "USER_DELETE" tag on them, with a date attached to it of 2014/12/24 (for '289bu0ZcLsYAAAQY9Zugsg')

For some reason this has not been picked up in the old catalogue (this certainly must be a bug), but was sanctioned in the new catalogue.

This could have happened because of the panoramas being marked as 'private' because of some 'delete' action, or of course a bug in the ingesting pipeline at the time.

Could you check for me when you
1) go to https://photos.google.com/
2) Click in the left menu bar on 'Collections'
3) If you have photospheres a collection 'geo panoramas' should show up, please click on that
Can you verify whether your missing photospheres are there?
Or perhaps the photospheres were moved out of that collection, or that collection folder itself is no longer shared? (Before you click on it at step 3, it should say "Geo Panoarams $n items - shared" as a title)

You can see this problem is not API specific, as these particular photospheres also don't show up when you drag pegman on maps.google.com itself. So this particular problem lies deeper than just the API.

Since either the user or a bug a year ago has removed them, I would suggest the best course of action is to re-upload these particular photospheres. Would that be a workable solution for you? They would then also show up again on maps.google.com as well as the API.

zwa... Thank you.

Here is what I did - I went into photos.google.com. Some albums showed as shared, other not, so I shared all of them to Google+. Presto! Two more photo spheres appeared on my Contributions Panel.

My Contributions Panel is here:
 https://www.google.com/maps/contrib/100021531180702848716/photos/

I scrolled down to the very bottom - Moonstone County Park. I clicked on it. It came up and I extracted the new panoID from the URL. None of the 7 other photo spheres in this constellation were in the constributions panel itself. But after I clicked on Moonstone County Park, these 7 photo spheres were in the image carousel. So I expect that I can bring them up and extract a new panoID from their URLs, too. The Moonstone County Park photo sphere is not in a constellation when I use the new panoID, even though it is in a constellation when I use the old panoID. In the migration from Views, all my other constellations persisted. It is okay. If/when constellations are put back into operation, I can join them at that time.

So far, I have recorded this:

Moonstone Beach County Park
 lat-long  =  41.0288869, -124.1111539
 old panoID = PNwQR-SLJRgAAAQZCagiww
 new panoID = F:-zpz1570v0EA/VIO8v72-jxI/AAAAAAAADTc/3BNKlz6ZhOU

Lupines in the Bald Hills
 lat-long  =  41.1597631, -123.8939511
 old panoID = e5N6fTWaFbUAAAQY-8rTSw
 new panoID = F:-CBXN6HS_QVc/VHEeHLn-MaI/AAAAAAAADUw/TcqnIGjyeRM

The lupines photo sphere is in separate location, and was never in a constellation.

I am very pleased with progress so far. These photo spheres work fine now in the javascript API, either with the old or new pano ID. My problem with the javascript API is fully resolved!

But... I still see no blue dots on Google Maps. You have gone above and beyond already. But if you have any other thoughts on how to get the blue dots back on Google Maps, I would appreciate them. Thanks again.

While photo publishing is near instant, some of the spatial indexing is an offline process and may take some time (order of day(s)) 

If you reshared them and they're publicly accessibly, it's very well possible the blue dots will be back on Google Maps as well soon. (it would be my guess... if not please ping here again)

zwa... Re. #88
You were correct. They are all back on Maps this morning. Thank you!

google.maps.streetViewViewer = 'photosphere';

Overall looks good for Standard Streetview.  The smoother pano transitions is a great plus.  Can't wait to take it to production when it implements the PanoProvider.

One request: Will it be possible to keep the old chevrons OR give styling options for the Chevron SVG?

On the new Style Chevrons : Does it support labels?

Re #90,
I have comparison links in #78 above.
The new smooth panning and smooth pano transitions are welcome changes.
However, labels and old chevrons are not supported in this pre-release.
In release version, could you please restore both?

Hi There
Has anyone tested the "google.maps.streetViewViewer = 'photosphere';" on Ios/I-Pad, in my testing seems to be very difficult to rotate and then freezes or am I missing something/faulty I-Pad? I don't generally use I-Pad myself (but many do) and it works brilliantly on Android/laptop. 
Is their an issue with using the new API and Ios?

Re #92: Thanks. I just gave it a go on my iPad and it works ok in Chrome but not on Safari. We'll investigate.

How can I get the Pano Id from my photo sphere? I read that it is changed and now I'm not able to find it.

You can use the API to get the ID out. Ideally you should not store the key, but the location and use that, (you the NEAREST strategy to always get your pano) as there are no definite guarantees ids are actually stable, although in practice especially photosphere ones often are.

But if you want to get the ID, here is a jsFiddle to get it out of the API:
https://jsfiddle.net/ufynrgav/

You can plug in the latlng of your photosphere and you'll get the ID.

I got the Pano ID, but it doesn't work! I can I have my Iframe with the street view of my photosphere.
I have this Iframe but it doesn work:
<iframe width='640' height='480' frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="https://maps.google.com/maps?layer=c&amp;panoid=-hDxiaavr0go%2FVofGnW6U8TI%2FAAAAAAAAMn4%2F88AebwCS79A&amp;ie=UTF8&amp;source=embed&amp;output=svembed&amp;cbp=13%2C174.9068%2C%2C0%2C0"></iframe>
Please help me!

https://www.panowalks.com/pano.php?id=F:-hDxiaavr0go/VofGnW6U8TI/AAAAAAAAMn4/88AebwCS79A&h=141.52&p=-0.21&z=1.09

Use the link above or get the "Embedder for Google Business View" plugin for Google Chrome to generate an embed code. Check here: http://panowalks.com/resources/images/embedder.jpg

Re. #97, iframe doesn't work:

I just posted an iframe embedding tool that may help you:

 http://suddenlink.net/popenoe/tools/embedding-tool.htm

You can also review how Google recommends embedding photo spheres:

 https://developers.google.com/streetview/

@GoogleDevTeam:

As a monthly routine I tried out teh 3.EXP with google.maps.streetViewViewer = 'photosphere'.  The ONLY reasons why we are still not using it in walkinto.  And trust me we are SO eager to upgrade because of the smooth PAN TO features and the support for newer spheres.

(1)WalkInto supports PanoProvider.  Now, we know exactly which pano is coming from Google and which is a custom.  Is it possible to set the appropriate value to 
google.maps.streetViewViewer property to switch the viewer dynamically?  I am guessing not.  I tried to set null & delete the property without any luck.

-In short when will you be able to support PanoProvider construct?

(2)It might not seem so intuitive to the product team there.  But your users LOVE having those labelled arrows (LINKS) visible.  So, hiding it for some UX purity may not be a great idea.  Would it be possible to add an option to show the Links (with labels) ?

Totally agree with Boni's point #100
I have stopped posting standalone photospheres for that very reason so google is loosing quality (well I think so!) content..... 

Something more to add on the Links.
-Noticed that the new Viewer paints the labels for Links nicely on the 'Road' for example When I am at an intersection shown in the attached image 'Delancey St' is probably the label of the link in that direction.  I am not very sure.
-However when I add a new link or edit this link to set a new label to it the SVG for the new text does not get refreshed.
-Interestingly the refresh do happen IF that link is deleted.

Ideally it is expected (as it happens in 3.22) when label changes and SteetviewPanorama Links changes, all linked paints including label refresh need to happen.

This seems to be a missign feature unless there are some new API constructs added to repaint.

	new_links.jpeg 81.6 KB   View   Download

Any updates on this bug fix?

By jeanot

Please maken panoid visible

Yes please restore ability to add links and labels 

#100:
1- The PanoProvider should be working since April's release... Let us know if you have any problems with it.
2- This hasn't been on our radar yet... But I see the point. Let me verify the quick feasibility of this, or whether this is a larger project.

#102:
Currently we only paint street labels, as we no longer matched them with the links they were disconnected. But I see what you mean. We probably should have API hooks. See previous comment.

#104:
I'm not sure what you mean by make panoid visible? You can get the ids out of the viewer,can't you? I'm not sure what you mean.

#105:
You can alter and add change links for a while now, no? See the previous comments about the labels?

#100:
1- The PanoProvider should be working since April's release... Let us know if you have any problems with it.


Confirming : while using the new viewer, google.maps.streetViewViewer = 'photosphere' , setPanoProvider is respected?

Is this what you meant?

Alright! Game ON.  well done guys.  PanoProvider almost works with the new viewer.  LInks are rendered in the old format. 

pov_change is not redrawing the arrow link SVGs for custom panos.  So when you rotate (pan to effect pov_change) the arrow cluster stays put.  This probably is a bug.  

I have noticed a few other minor issues but those seem to be in all likelihood on our end.  Will be spending more time a little later in the afternoon.  THANK YOU!!!

The jank on PoV in custom pano is UNACCEPTABLY large.  I am attaching the timeline data.  That being said, the FPS meter is behaving oddly.  I could clear see and feel the jank on custom pano, but it is keeping a constant 60fps.  very very weird.

Is it the WEBGL mode or is it degrading to the HTML4 mode for custom panos?

Secondly, I can see that some change has since happened to the LINK redraw on custom pano.  Looks like there is a 3D yaw difference of +90 degree is needed for the SVG to draw correctly.  Currently it is looking not in the horizon plane.

TimelineRawData-20160506T142509.json 0 bytes   Download

Unfortunately because custom imagery might not be correctly CORS-headered (nor can we detect in advance whether all incoming imagery will be so), we drop rendering context for custom panoramas from Webgl to 2d canvas, which on larger pixel areas will undoubtedly be affecting some performance.

It will not drop back to HTML4, it will still be projected correctly.

The imagery is CORS headered. By the way there is reasonably accurate way of checking CORS enabled using header parsing.  We do it on the server side to ensure that the image sources registered are CORS enabled.  We could also do it on client side using canvas and an <IMG> equivalence.  Anyways, that is besides the point.

Jank is real.  You must test it with custom panos with links.  In my rudementary testing the SVG drawing of links on custom pano seems to be the source of jank.

Secondly, switching pano (using setPano) from a custom pano (with PanoProvider) to StreetviewPano (with your default PanoProvider?) blanks out teh screen.  Canvas becomes black.

This is not a problem if the switch is from StreetviewPano to CustomPano.

Lastly, how can your beautiful pano_change animation be made available for custom panos also?  Currently it is not available.

The issue is, we cannot tell when the Panorama is declared whether all images will be cors headered. Nor can we tell after the first image, since subsequent images might not be cors headered.
There are many customPanoramas in the wild, probably many which are not appropriately cors headered. If we do opt to go for webgl, we will be breaking sites which are currently working.
So we're a little caught between a rock and hard place, as there is no moment in time we could tell, and we opted to keep sites working over the optimal performance.
(BTW could you tell me what machine under what condition you're experiencing loss of performance? On my machine with Chrome/Linux I also get the degraded performance with 2d canvas and svg, but only when the developer tools are open. When the page is loaded with them closed, I haven't seen this performance loss... Is that identical on your side? Or else could you specify the conditions browsers+os etc of your condition?)

I still have submitted one fix (internally) on custom panoramas (especially with regards to sometimes showing a black panorama) which has not been published in the experimental js bundle.
Please reconfirm after next weeks release whether this issue persists.

Unfortunately the animation is not available for custom panorama's... You can file a FR for this and we can triage it. But the reason why this is not part of the roll out is that Google Provided Street View have depth data, which allows us to do the transition, while we currently have no api to specify this depth data.

(1) BUT!! We hope, if {mode:'webgl'} is set (after due consideration of CORS) StreetviewPanorama will continue to implicitly use webgl, just the way it does now.  Even for custom panorama.  Please confirm.

(2)You could be right.  DevTools might be a parameter here.  That'd explain the 60fps and jank feeling also.

(3)Thank you for the custom to regular pano_change black screen fix.  Will test and confirm next week.  Fingers crossed.

(4)Ahh!  finally someone accepts that the depth info xml.  It's quite some technology your cars carry.  Amazing stuff.  BUT, how do you guys calculate the depth info on SeeInside imagery shot with DSLR camera?  That does not sound right.  And if you really have that good photogammetry lying around, why not consider releasing it?  I'll file an FR and will wait for an FIR.

One clarification on the transition animations - I understand the importance of depth data to do the Surface_Rectangle transition animation.  That is very cool too!  How about the clickToGo transition animations?  That seems to be a pixel to pixel skew on canvas.  That shouldn't be dependent on depth data.  Am I wrong?

Question: when using the Api with connected photospheres (new feature of the Android Street View App) the navigation arrows are pointing in the wrong direction, they point backwards and the animation is also reversed. Are you aware of this issue.

@GoogleDev ZWA #113

Verified that Jank is NOT just with dev tools open.  On custom pano, pov_change fires imagery_viewer.js:AnimationFrameFired:L722 .  This call takes 54ms on my machine (with devtools open).

Google Chrome | Ubuntu Trusty | i7 | 32Gb RAM | No GPU

withlinks_pov_change_animationfired-costly.json 6.5 MB   Download

Some clarifications:

Depth data comes into two types. One that tells for a given panorama how far away facades/roads etc are. And one that that tells how far away neighboring panoramas are.

Without the first one (like it happens in some places) we can still do some transition, as we assume a half dome. You don't get the entire niceness of the transition, but it will do. Closer things move at the same speed as further away objects during transition.
Without the second one, we can't do a transition.

We currently have no API to either supply the first or the second one. So with launch there will be no transition for custom panoramas... We could take that as a feature request.

In response to #117... It was our initial planning to always punt custom panoramas to 2d canvas... but I get the feeling that that would make you (and probably other developers unhappy)... Let me triage this FR.

@ZWA: 

Depth Data #2
Isn't Lat-Lng good enough find the distance between panos?  Yes the onus is on the creators.  Since you have given API to setLocation and assumign responsible use, we are giving you data to find transition distance in physical units.

Depth Data #1 : Probably should add this to Spherical Camera API.

We need WebGL on custom panos also.  We won't use it when there is no CORS support.  Just document it and we will be responsible.  peace?

Also, There is going to be transition from Streetview to custom pano and back.  A lot.  This is not new.  It is verymuch in action right now.  For example here, Ricoh Theta custom panos living happily with Streetview Panos.  So for consistent UX it is important to compute some default velocity and have a transition.

eg. https://walkinto.in/tour/bJLcspyKkbb1eU9iTJKy-

Have submitted a new new issue for CustomPano / Canvas2D.  It is not a FR.  It is a bug.
https://code.google.com/p/gmaps-api-issues/issues/detail?id=9775

#121

Nice timing :-) I just reached agreement on this. We concluded we do want to offer a way to support webgl rendering for custom panoramas, you've made a well reasoned point it just makes sense, so we probably should just do it. So rest assured we're going to roll this out. It will come with an API interface change, so we don't break existing customers.

(Note that we never did support webgl in the past, we had a hook for this, but it wasn't something that was supported nor documented)

Glad to hear.  How about the transition animation?  Isn't Lat-Lng good enough find physical distance to compute the velocity?

#116
benny: Don't expect answers here unless you work for a certain company. You need to switch to the experimental API and turn linksControl off, to get rid of the old chevrons. 3.23 is still a mess. Then your links will show up same direction as in Google Maps. :-)

#123...

Transition animation is more complex. We could probably use the destination latlng for a transition to a custom panorama, as that information is synchronously available. But going from a custom panorama to a non-custom image, that information is behind a network request, and we don't want to put all animations behind a network ping.

So from custom to custom will probably be fine, from sv to custom might be fine, and from sv to sv might be fine, but from custom to sv, I'm not sure whether there is a clear path.

You would understand these type of changes impact many people, so let me do some careful investigation to what is and what isn't possible for animations.

That makes sense.  Link does not carry any more information about the pano than the pano id and direction.  It is too less.  See, this is too scant in a scenario where SV and CUSTOM are mixed.  We had ended up using some creative hacks to identify whether a pano to load is custom or streetview.  Would have been nice to have API support for it.  

Link --> {type,panoid,heading,pitch,latLng} ?

Adding elements to json should not break anything in current use cases, would it?

 Issue 9775  has been merged into this issue.

Looking back re. google.maps.streetViewViewer = 'photosphere';

#78 - 20 Nov 2015 - I requested "capability to add custom link descriptions".

#90 - 09 Dec 2015 - "Will it be possible to keep the old chevrons OR give styling options for the Chevron SVG? On the new Style Chevrons : Does it support labels?"

#100 - 20 Jan 2016 - "Would it be possible to add an option to show the Links (with labels) ?"

#106 - 05 May 2016 - "This hasn't been on our radar yet..."

#128 - 25 May 2016 - To elevate this and ensure this is really on your radar, I posted it as a new issue:

 https://code.google.com/p/gmaps-api-issues/issues/detail?id=9831

Any more updates?  Now that publishing via StreetviewApp is going to be main stream, it is important that this bug is resolved in release version.

We have done a roll over of versions. So the current release version is what used to be experimental a month ago. That should have all its abilities of google.maps.streetViewViewer

We working on making that renderer more default and less of an opt in, but you would understand that with the many different configurations that are out there, we do this carefully.

Making cors work with custom imagery is next on my list. Your blink between photospheres and Street View imagery should be gone.

Excellent.  Couldn't get around to testing it yesterday.  Looking at the weekend it might not be before Monday that I'd get to it.  Thank you!

In the mean time, I had question (sort of related).  In 3D space what is the spatial relation between StreetviewPanoramaData.centerHeading, StreetviewPanorama.getPhotographerPov().heading and Link.heading  ?  Will be useful to setup the Links in Streetview VR experience we are experimenting with.  An example that works quite well here:

LIFE MAGAZINE Top Places Collection : https://secure.walkinto.in/vr/-y-HhEz5pg-JlbHnEf5Tl

I confirm that your new viewer renders custom panorama tiles for me.

By default the old version rendered custom tiles as cylinders:
 http://suddenlink.net/popenoe/panoramas/test/beachwalk.htm

The new version renders them as spheres:
 http://suddenlink.net/popenoe/panoramas/test/beachwalk-newviewer.htm

But the new version omits link descriptions.

Google has an official example containing both street views and custom tiles:
 https://developers.google.com/maps/documentation/javascript/examples/streetview-custom-tiles

This worked in the old version, but when I specify the new viewer, panoramas render black.