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

Should tile content support multiple groups? #637

Open
javagl opened this issue Feb 23, 2022 · 2 comments
Open

Should tile content support multiple groups? #637

javagl opened this issue Feb 23, 2022 · 2 comments

Comments

@javagl
Copy link
Contributor

javagl commented Feb 23, 2022

The current content.schema.json allows assigning a group name to tile content. The idea is to define groups like trees, buildings and cars (as in the example image in 3DTILES_multiple_contents).

One could make a case for allowing the definitions of multiple groups for each content.

The arbitrary nature of what could be considered to be a "group" in each possible domain makes it easy to come up with examples, even though they might not be specific, realistic examples, but are rather intended to underline the question of whether this should be possible conceptually:

Cesium multiple groups for content

Thinking this further, it raises questions about the details of what could or should be specified here.

One could just consider these group names as some sort of "tags", that might have a meaning that depends on the domain and use case, but without any further constraints.

If this was supposed to be used and defined a bit more formally, it might be necessary to define something like a "grouping", so that the group assignments yield a partition of a set. Referring to the example: If one content has the groups ["greenBuildings", "officeBuildings"] then this is fine. If one content has the groups [ "greenBuildings", "blueBuildings" ], then this could raise questions. A "grouping" in that manner could be defined as the set of group names for one partition, and each content may only belong to (at most) one of them. This would have to be defined in a "top-level" object. But further details have to be sorted out if the option to assign multiple groups is actually considered, and depending on the constraints that should be applied for these group names.

@lilleyse
Copy link
Contributor

One could just consider these group names as some sort of "tags", that might have a meaning that depends on the domain and use case, but without any further constraints.

This is how I think of groups, the most general interpretation possible. Additional constraints might be best left out of scope for now.

Slightly orthogonal - but I wonder if the top level groups should be an array instead of a dictionary, and references should be indices instead of strings (each group definition would have an id property). That way contents could be assigned to groups efficiently, if say we started encoding tiles in binary, CC #635.

@lilleyse
Copy link
Contributor

I wonder if the top level groups should be an array instead of a dictionary, and references should be indices instead of strings (each group definition would have an id property)

I implicitly started to make this change by adding the CONTENT_GROUP_ID semantic which is an index instead of a string: https://github.com/CesiumGS/3d-tiles/tree/extension-revisions/specification/Metadata/Semantics

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

2 participants