Relation between openings and boundary surfaces

Boundary surfaces such as wall or roof surfaces as well as openings such as doors and windows are both modelled as elements of the semantic surfaces array as shown in the following example:

 "semantics": {
  "values": [ ... ],
  "surfaces": [
   {
    "type": "Window"
   },
   {
    "type": "WallSurface"
   }
  ]
 }

Now, typically, a window or door belongs to a wall or roof. But this relation is not explicit in the current encoding. Thus, a query like "get all doors belonging to a given wall" cannot be answered directly but requires additional knowledge. This knowledge could be derived, for instance, from a spatial check, which however requires clean geometry and might be expensive.

It would therefore be great if this knowledge would be directly available. One solution could be to specify that a "Window" or "Door" belongs to that boundary surface (e.g. "WallSurface" or "RoofSurface") which is its direct predecessor in the "surfaces" array. The above snippet would therefore be invalid because the "Window" does not have a predecessor.

Another solution could be to use the "parent" and "children" properties introduced with CityJSON 0.8 (using the array index as value). For example:

 "semantics": {
  "values": [ ... ],
  "surfaces": [
   {
    "type": "Window",
    "parent": 1
   },
   {
    "type": "WallSurface",
    "children": [0]
   }
  ]
 }

This relation is also relevant when mapping CityJSON to CityGML. Typically <Window> and <Door> are given as nested elements of their boundary surface, such as:

<bldg:WallSurface>
 <bldg:opening>
  <bldg:Door>
   ...
  </bldg:Door>
 </bldg:opening>
</bldg:WallSurface>

For citygml4j, I have implemented the first solution simply because "parent" and "children" have not been available before 0.8. But I would prefer that CityJSON states how to derive this relation or at least recommends a best practice.

cityjson / specs

Relation between openings and boundary surfaces #28