Thanks @ludovic-cheval-bentley-systems for opening this PR! @kring do you mind taking a look?

Just realized this PR is still marked as draft; @ludovic-cheval-bentley-systems let us know when it's officially ready for review.

@ludovic-cheval-bentley-systems now that this is passing CI, go ahead and hit that "Ready for review" button and we'll take a look. Unless there is more you want to do with it first?
Thanks again for working on this and for opening a PR!

Thanks again for the PR @ludovic-cheval-bentley-systems. It looks good, but I have a couple of questions about use-cases.

1. Can you elaborate on why you need to separate credits from raster overlays versus "everything else"? I can see why it'd be useful to be able to display credits per dataset (whether a Tileset, raster overlay, or something else), but I'm less convinced it's useful to separate out the credits from all raster overlays.

2. In Add support for reporting credits per TilesetViewGroup #1260, I suggested adding a getCreditsSnapshot method to TilesetViewGroup. Would that be a worse interface from your perspective, or was it just more difficult to implement?

Hello @kring

Since we can load 3D Tiles with different data sources (for example, Google Maps imagery applied on Cesium ION terrain), we need to distinguish these credits'sources for legal compliance and ensure we display which credit belongs to which source (instead of a soup of credentials from undistinguished sources).

Regarding the getCreditSnapshot implementation: Since I don’t have deep mastery of Cesium internals, I didn’t see a way to implement this without iterating through each TileSet credit snapshot and checking against TileSetViewGroup’s CreditReferencer via the new method I added.
However, that approach means looping through all TileSet credits for every TileSetViewGroup — and then looping again through each group’s credit snapshot in our application.
So I opted for a simpler approach:

• Loop once through all TileSet credits in our application.
• Check them against the TileSetViewGroups we’re working with via the new methods I added.

This minimizes code changes and reduces the risk of me introducing bugs 😅.
That said, I guess a getCreditSnapshot method could still be useful in some scenarios 🤔.

Thanks @ludovic-cheval-bentley-systems!

Since we can load 3D Tiles with different data sources (for example, Google Maps imagery applied on Cesium ION terrain), we need to distinguish these credits'sources for legal compliance and ensure we display which credit belongs to which source (instead of a soup of credentials from undistinguished sources).

That's not a legal requirement we've run into anywhere else, as far as I know. But if you do need to separate credits by data source, then the implementation in this PR is insufficient anyway, because it doesn't allow you to separate credits that come from two different tilesets or from two different raster overlays. Perhaps you're getting away with it for now because you are only displaying one tileset and one raster overlay. I think that's very likely to change in the future, though.

Let me think about how it might be possible to provide credits both per view and per data source. It's not entirely straightforward to do it efficiently...

However, that approach means looping through all TileSet credits for every TileSetViewGroup — and then looping again through each group’s credit snapshot in our application.

Ok, so it sounds like the interface in this PR is more convenient for your application, even if we put aside any difficulties in implementation getCreditSnapshot on the cesium-native side?

FYI @ludovic-cheval-bentley-systems I'm working on a system to allow us to identify exactly which tileset or raster overlay a Credit comes from. I should have a PR with it open by this time tomorrow so you can take a look and make sure it satisfies your use-cases.

Hello

That's not a legal requirement we've run into anywhere else, as far as I know. But if you do need to separate credits by data source, then the implementation in this PR is insufficient anyway, because it doesn't allow you to separate credits that come from two different tilesets or from two different raster overlays. Perhaps you're getting away with it for now because you are only displaying one tileset and one raster overlay. I think that's very likely to change in the future, though.

To be honest, the minimum expected for that legal requirement is simply to display the credits. That's why associating all tileset's credit to each viewgroup is acceptable since it will overdisplay credit but none would be missing. However, it might be a little odd to explain why we display credits from view 2 area in view 1 (and vice versa) 😅.
No. The main reason we need to identify them is for presentation and clarity when multiple providers (and multiple view) are involved: we don't want to display credits from Provider 1 next to the logo of Provider 2.

That said, this approach only addresses our current needs. I’m fully aware it won’t cover future scenarios where we might have multiple raster overlay providers or several tileset providers combined into a single 3DTile. For now, the only supported use case on our side is one tileset provider, potentially with a different raster overlay provider.
This solution works for now and gives us time to design a more sustainable approach that can handle all use cases in the future 👍

Ok, so it sounds like the interface in this PR is more convenient for your application, even if we put aside any difficulties in implementation getCreditSnapshot on the cesium-native side?

Yes, it is. But it might just be convenient for us. If you need or want to redesign that solution and implement a getCreditSnapshot, I can update our code to adapt.
However, our schedule is tight for the next major release, so if it can be integrated into the upcoming Cesium version in December and redesigned later, I would greatly appreciate it 🙏