4.5.8.6. <lods> parameter

The <lods> parameter lists the level of details (LoD) that shall be exported for the requested feature types.

The LoDs to be exported are given as list of one or more <lod> elements having an integer value between 0 and 4. The optional mode attribute specifies whether a feature must have a spatial representation in all of the enumerated LoDs to be exported (mode = and), or whether it is enough that the feature has a spatial representation in at least one LoD from the list (mode = or) (default). The modes minimum and maximum are special cases of the or mode, for which only the lowest respectively highest of the matching LoDs is exported. If a feature has additional spatial representations in LoDs that are not listed, then these representations are not exported. If a feature does not satisfy the LoD filter condition at all, then it is skipped from the export.

Many feature types in CityGML can have nested sub-features. In such cases, the top-level feature itself is not required to have a spatial property, but the geometry can be modelled for its nested sub-features. For example, a bldg:Building feature does not need to provide an LoD 2 geometry through its own bldg:lod2Solid or bldg:lod2MultiSurface properties. Instead, it can have a list of nested boundary surfaces such as bldg:WallSurface and bldg:RoofSurface features that have own LoD 2 representations. Nevertheless, in this case the bldg:Building is considered to be represented in LoD 2.

To handle these cases, the <lods> parameter offers the optional searchMode attribute. When set to all, then all nested features are recursively scanned for having a spatial representation in the provided list of LoDs. If an LoD representation is found for any (transitive) sub-feature, then the top-level feature is considered to satisfy the filter condition. The all mode is, however, expensive because it requires many joins and sub-queries on the database level. When setting searchMode to depth instead, you can use the additional searchDepth attribute to specify the maximum depth to which nested sub-features are searched for LoD representations.

For example, the following bldg:Building feature has a nested bldg:BuildingInstallation sub-feature and a nested bldg:WallSurface sub-feature. Moreover, the bldg:BuildingInstallation itself has a nested bldg:RoofSurface sub-feature.

<bldg:Building>
  …
  <bldg:outerBuildingInstallation>
    <bldg:BuildingInstallation>
      <bldg:boundedBy>
        <bldg:RoofSurface> … </bldg:RoofSurface>
      </bldg:boundedBy>
    </bldg:BuildingInstallation>
  </bldg:outerBuildingInstallation>
  …
  <bldg:boundedBy>
    <bldg:WallSurface> … </bldg:WallSurface>
  </bldg:boundedBy>
  …
</bldg:Building>

When setting searchDepth to 1 in this example, then not only the bldg:Building but also its nested bldg:BuildingInstallation and bldg:WallSurface are searched for a matching LoD representation, but not the bldg:RoofSurface of the bldg:BuildingInstallation. This roof surface is on the nesting depth 2 when counted from the bldg:Building. Thus, searchDepth would have to be set to 2 to also consider this bldg:RoofSurface feature.

Per default, searchMode is set to depth with a searchDepth of 1.

The following listing exemplifies the use of the <lods> parameter. In this example, all tunnels shall be exported that have either an LoD 2 or LoD 3 representation. LoD representations are also searched on sub-features up to a nesting depth of 2.

<query>
  <typeNames>
    <typeName>tun:Tunnel</typeName>
  </typeNames>
  <lods mode="or" searchMode="depth" searchDepth="2">
    <lod>2</lod>
    <lod>3</lod>
  </lods>
</query>