Consider adding in support for mutlitple metadata entities into the tiles 3DTILES_metadata schema

[LewisSpencerVaarst]

I'm working for a company that is making use of 3D tiles and Cesium for Unreal plugin. We have forked the plugin and added in support for the 3DTILES_metatdata extension into the plugin for our own internal usage. While the current extension (which has become core with 1.1) supports most of our use cases, we need to associate multiple metadata entities with a given tile. As it's currently defined there is no clean way to do this while conforming to the specification. The best I can think of is to make use of the multiple content extension and link to a different tileset whose only purpose is to store a singular metadata entity.

To me that feels like a workaround for what I would think is quite a common requirement, instead, we have forked the specification and made the simple change to the schema so we have an array of metadata entities with a minimum of 1 now. See this PR

I don't like the idea of doing this at all but it does solve our current use case, but we are breaking portability doing this. Would you consider changing this limitation in future iterations of the specification to allow multiple metadata entities in a given tile?

[javagl]

It could be helpful if you described what your use case is. What are you trying to model, or what is such an "entity" supposed to be in your context?

On a very abstract level, one could probably think of things that could be modeled with multiple metadata entities - basically, when the schema defines two classes, and the entities should each represent one instance of that class.

But such a change is very unlikely to make it into the specification: Changing the current metadata property to be a metadataEntities (plural, array) would be breaking change, requiring a version 2.0 release. Adding a metadataEntities property (and keeping the metadata property) would be possible in a backward-compatible way, but would still require a version 1.2 release (and this is not on the radar right now). And an aside: If we added an array of metadataEntities to the tile, then it should also be added to tileset, group and subtree, for consistency.

One workaround might be to add child tiles to this tile, with the child tiles being empty except for the metadataEntity objects. It would still only be a wrokaround, but a bit easier and maybe cleaner than the approach of using multiple contents and external tilesets for that. But again: The details here depend on what you are trying to model with these entities.

[LewisSpencerVaarst]

Thanks, @javagl for the reply. Yes, some context on what we are doing here is that we have built a tileset for industrial pieces of equipment where instead of it being spatial divided up each level of the hierarchy is a component of the equipment with its children being the individual components that compose it and so on and so forth.

With these components, we have various different data that we collect from inspections of the installed equipment. For example, that could be video, audio or an inspector's comments. All that data can be mapped to different schemas e.g. one for video data and one for text data, but then all the metadataEntities need to be assigned to the component in question.

But such a change is very unlikely to make it into the specification: Changing the current metadata property to be a metadataEntities (plural, array) would be breaking change, requiring a version 2.0 release. Adding a metadataEntities property (and keeping the metadata property) would be possible in a backward-compatible way, but would still require a version 1.2 release (and this is not on the radar right now). And an aside: If we added an array of metadataEntities to the tile, then it should also be added to tileset, group and subtree, for consistency.

Yes, I agree with this we aren't requesting this change would come in 1.1 just that it's considered for 1.2/2.0. I also agree what I have done is not backwards compatible or complete (which it would have to be for a spec change ), it's just what I did to get it working for our use case.

One workaround might be to add child tiles to this tile, with the child tiles being empty except for the metadataEntity objects. It would still only be a wrokaround, but a bit easier and maybe cleaner than the approach of using multiple contents and external tilesets for that. But again: The details here depend on what you are trying to model with these entities.

Yes this is something I considered doing, but ruled it out as I am tracing against the bounding volumes to retrieve the data on mouse clicks, adding more children tile in the same position would overtly complicate things in this regards.

[javagl]

I am tracing against the bounding volumes to retrieve the data on mouse clicks, adding more children tile in the same position would overtly complicate things in this regards.

Some brainstorming:

Options like making the bounding volumes of these "metadata tiles" really tiny, or making the click-tracing code somehow "aware" of these tiles could be considered.

Other alternatives would be to merge all schemas into one, and try to squeeze the intended data model into that, with some arrays and/or by making all properties 'optional' and picking the desired ones out of the entity at runtime.

You mentioned...

The best I can think of is to make use of the multiple content extension and link to a different tileset whose only purpose is to store a singular metadata entity.

and I wondered whether there could be a way to at least not require an actual external tileset. (Having a real external tileset implies that the tile may not have other children). One could associate the metadata entities with the content objects, but ... each content requires a uri, and it's not clear what that should be for these "dummy" contents.

But I see that all these options may be complicating things. Having multiple entities would be a more desirable solution for this kind of problem.

[LewisSpencerVaarst]

Thanks @javagl for your brainstorming, there are certainly ways around the limitation that we could implement, but I think at best it would be clunky and at worst a hack. I think for the moment we will stick with deviating from the 1.1 spec since we are not sharing the tileset's we create with 3rd parties and it's only being used internally by our own software.

If that changed I am confident that I could alter the output of what we produce to conform to 1.1 but I would rather not do that until that is a real need. Really what I am hoping (I know you said it's not on your radar to happen anytime soon), but that this would get addressed in the next version of the spec be it a braking or backwards-compatible change and then we could update to that.