Consider adding in support for mutlitple metadata entities into the tiles 3DTILES_metadata schema about 3d-tiles HOT 4 OPEN

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.

from 3d-tiles.

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.

from 3d-tiles.

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.

from 3d-tiles.

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.

from 3d-tiles.