Add credit to tileset.json

[pjcozzi]

Like glTF's copyright property, This could be as simple as:

{
    "asset" : {
        "credit": "a string"
    }
}

However, it would force converters to generate multiple tileset.json files (which could still reference each other to form a tree) to support per-tile credits. So we can move "copyright" to each tile, e.g.,

{
    "root": {
        "credit": "a string"
        // ...
        "children": [{
            "credit": "another string or omit to inherit"
            // ...
        }]
    }
}

The "credit" could inherit from the parent, and its display would be based on the refinement type because refinement impacts which tiles are rendered. This works well for common uses cases:

• Replacement refinement of terrain with global low-resolution data combined with local high-resolution data. When zoomed out, the low-res credit is displayed. When zoomed in close, only the high-res credit is displayed. In between, both are displayed
• Additive refinement of 3D buildings where "low-res" buildings are from one source and high-res buildings are from another. When zoomed out, just the low-res credit is displayed, when zoomed in, both credits are displayed.

[pjcozzi]

@abwood any thoughts on this given your experience with terrain?

[abwood]

As you know, for terrain we currently have a single static attribution property in the layer.json. One issue to consider is how credit strings are merged. For example, your highres terrain may also contain elevations sourced from the low res base terrain (e.g. void values in the highres were filled from the lowres data). The highres tiles will therefore require attribution of both data sources. For horizon views, if both lowres tiles and highres tiles are in view, you would have to identify that the lowres tiles are already credited by the lowres tiles (or vice versa).

For per-tile credits to work well with terrain, you may want to have a list of all credit strings at the document root, while the child tiles determine which credits in that list are "active" based on the tiles in view.

[pjcozzi]

For per-tile credits to work well with terrain, you may want to have a list of all credit strings at the document root, while the child tiles determine which credits in that list are "active" based on the tiles in view.

I thought about doing this to save space, but didn't think about this use case. Good call. Will look into it.

[pjcozzi]

Also see the in-progress KHR_XMP glTF extension, KhronosGroup/glTF#1553. It could make sense to support this at the tileset level so that credits can be merged together when a large glTF or several glTFs are converted to a 3D tileset.

[lilleyse]

Credits could be stored at tileset or tile (or vertex) granularity with 3DTILES_metadata using the variable length array of string type and a newly defined CREDITS semantic.

CC #554 for tighter integration of XMP with 3D Tiles metadata.

[donmccurdy]

A minor point, but I think the term "attribution" would be more common than the term "credit" here, distinct from both license and copyright.