Credits for imagery

Kevin and I had a discussion about placement of imagery credits, such as the Bing logo (when using Bing imagery) and the other credits which are typically line(s) of text.

The CentralBody has a “logoOffset” parameter (with a few known bugs) that controls the lower-left anchor point of these imagery credits. Some thoughts:

  • Should the credits become HTML DOM nodes, instead of burned into the canvas? Nothing else in core Cesium manipulates DOM outside the canvas, and also the canvas.toDataURL function would get a screenshot with no credits if we move to DOM. My personal vote is to keep the credits on the canvas.

  • Should the credits be managed by Scene instead of CentralBody? This would allow for future things like model credits, and the Cesium credit itself. It would mean the CB would have to publish imagery credits to the scene, but Kevin suggested the underlying providers were already publishing to CB in a manner similar to what would be needed.

  • Can we specify a full bounding box, with an anchor (corner or side), instead of logoOffset? This would more accurately allocate some screen space for display of credits, but would require some logic to make sure the credits fit into the allocated space.

  • Do we need to word-wrap the credits?

The current CesiumViewerWidget provides its own Bing logo on the imagery dropdown, but fails to erase the canvas logo (it asks for it to go offscreen, but it is clamped on-screen, hidden behind the opaque timeline bar, causing problems on the playback branch). This is a problem if the user swaps out the imagery, because the Bing logo remains, and the new imagery credits appear behind the timeline (issue 413). Perhaps we should provide an option to explicitly hide a particular imagery credit in case it is shown elsewhere on the page? Or should we redesign the imagery selector to not have Bing hardcoded into it, and put the credits above the timeline?


I’m probably an outlier and my use of Cesium falls outside the norm. Nevertheless, you may find what I have to say interesting.

A little over a year ago, my partner and I decided to raise our middle fingers to both Google and Microsoft and build our own GIS infrastructure. We are entering a business where maps are an essential functional and visual component and there is no way we’re going to allow less than 100% control of the user experience. Given the fact that today one can create their own maps with freely available resources (OSM, Leaflet, OpenLayers, CloudMade, MapBox, etc), I would certainly not assume that Bing will always be the imagery provider, and thus steer clear of hard-coding their logo anywhere …



Ed - one more use case:

  • An imagery server with imagery composited from multiple sources that need to be credited. As the viewer moves around, the credit line changes based on what’s in view.
    The advantage of HTML DOM elements is that they can be placed outside of the canvas, which could be desirable for some apps (assuming the credit isn’t required to be directly over the 3D window). Perhaps the user would have access to the CSS for position and styling with their app.

I also think the Scene or something higher-level than the CentralBody needs to manage these given the use cases you mention. Vector data credits is another.

Other comments:

Can we specify a full bounding box, with an anchor (corner or side), instead of logoOffset? This would more accurately allocate some screen space for display of credits, but would require some logic to make sure the credits fit into the allocated space.

Sounds like a pain.

Do we need to word-wrap the credits?

Ugh, I guess so.

I’m OK with just solving the current hiding problem, but if you want to take it to the next level now, that also works for me.


Peter, just to clarify, nothing is actually hard-coded anywhere. Each imagery provider has the option to provide a credit on the screen when imagery from that provider is being drawn. If a provider has all of its imagery culled, the credit is not displayed. As I’m sure you are aware, many imagery sets have such stipulations (even some free data does). So in the case of Bing, the Bing provider is the only place with the Bing logo.

While I’m sure many people on the Cesium team would love to see more free data and free sources, at a project level our goal is to be compatible with both commercial and non-commercial sources and make it easy for customers to easily obey the licensing rules of any data it uses.

Hi Matt, just a small clarification to the clarification here. The CesiumViewerWidget has a Dojo Dropdown, which is temporary code of course, that lets you select a Bing image source, and has the Bing logo on it. This is the logo I’m referring to as “hard coded” for now.

It’s a problem here because the CesiumViewerWidget can be programmed to display non-Bing imagery, but all of the imagery credits are (poorly) hidden (intended to be offscreen but in reality obscured by the timeline) so as to avoid showing the Bing logo twice in the same widget.

So, Bing is always visible and other imagery goes uncredited. This will of course be fixed when we write a new imagery selector, but we may have to avoid putting the credit on the selector itself, and instead get the main credit system in better shape.