You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
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)
The current
content.schema.json
allows assigning agroup
name to tile content. The idea is to define groups liketrees
,buildings
andcars
(as in the example image in3DTILES_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:
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.The text was updated successfully, but these errors were encountered: