Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Examine the effects of 'semantics' for the validation #261

Open
javagl opened this issue Jan 11, 2023 · 0 comments
Open

Examine the effects of 'semantics' for the validation #261

javagl opened this issue Jan 11, 2023 · 0 comments

Comments

@javagl
Copy link
Contributor

javagl commented Jan 11, 2023

tl;dr: The 'semantics' for metadata may cause certain tileset properties to be 'overridden'. It is not clear how this affects the validity of tilesets.


There is a set of predefined semantics for metadata properties. In some cases, these may just be a "name" for a certain type of additional information. In other cases, these semantics are supposed to essentially override existing properties. For example, when a tile has a property with the TILE_BOUNDING_BOX semantic, then this overrides the tile.boundingVolume.box.

This raises some questions for the validation. The semantics are decoupled from the 3D Tiles specification itself. They are supposed to be defined and used by certain applications. Therefore, they can hardly be integrated into the validator generically.

For example, the specification says that the tile.boundingVolume must enclose all the contents. When the validator is supposed to check this, then it would determine the bounding volume of the contents, and check whether it is contained in the tile.boundingVolume. If this is not the case, an 'error' will be generated. But the tile may have a property with the TILE_BOUNDING_BOX semantic, and maybe this bounding volume is valid. It is not clear how this is supposed to be handled by the validator. The semantics do not define the overridden property in a "machine-processable" sense, but only via a statement in their description. (And there is no limit in which meaning a third-party application could assign to their third-party semantics...)

With some effort, a special treatment could be added manually, for the semantics that are currently known. But even there, the effect that this will have on the validity of a tileset will have to be examined carefully. Referring to the example above: When there is an invalid tile.boundingVolume, then this is an 'error'. But when there is a TILE_BOUNDING_BOX semantic, then this 'error' might become a 'warning'. Completely omitting it would classify the tileset to be 'valid', but it wouldn't be valid according the the core specification - or for an application that is not aware of the TILE_BOUNDING_BOX semantic...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant