This section describes how multiple geometries are handled in the CityGML Reader and writer, how levels of detail are portrayed, and explains the feature hierarchy that is created when the CityGML Reader interprets a CityGML dataset.
CityGML features read from the CityGML Reader are named the same in FME as they are in the application schema. For example, a CityGML Building will create a feature type named Building in FME. The only exception to this is GenericCityObjects. As generic objects, the name of the feature-type will match the name of its gml_name attribute whenever possible.
Multiple Geometries
In a CityGML dataset, the same feature may be represented in multiple levels of detail simultaneously. Since the FME does not support multiple geometries on a feature, the CityGML reader will create a single aggregate of geometries for a feature-type, one geometry for each level of detail.
Should only one level of detail be available for a feature-type, then a non-aggregate geometry representing the feature will be created.
As multiple geometries defined in CityGML may map to a single FME geometry, we keep the original CityGML geometry in a trait called gml_geometry.
This flexibility of geometry poses a problem for users wishing to write CityGML. Given a feature with some geometry, how will the writer interpret the role of the geometry. For example, a Building supports over a dozen different geometry elements. How will the writer determine the appropriate role for the geometry? In general, you must mark each geometry component with a geometry trait that defines the geometry role that the geometry plays. For example, if you are writing a Building that has both a multi-surface geometry and a solid geometry, you can use a GeometryPropertySetter transformer to set the attribute citygml_lod_name to establish the roles, marking the multisurface with, for example, lod3MultiSurface and the solid with Lod2Solid. In some cases, it may be necessary to use a Deaggreagator transformer to split the geometries up, mark each component, and then aggregate them together again.
The value of the citygml_lod_name attribute must also be compatible with the geometry type. For example, a geometry tagged with lod3MultiSurface must be a MultiSurface, or the geometry will not be written out. In some cases, a geometry that is not valid for a given role will be converted to a geometry that is valid. For example, a Surface tagged with lod3MultiSurface will be wrapped in a MultiSurface, and a BRepSolid tagged with lod2MultiCurve will be converted to a MultiCurve.
In order to aid in automatic translations, geometries without a citygml_lod_name trait will be assumed to be lod4Geometry elements if their feature-type is GenericCityObject.
Level of Detail
In order to keep track of the particular level of detail a feature with a geometry has, the CityGML Reader will create a list attribute called citygml_level_of_detail. The list element values will be integers between zero and four, inclusive. If the feature-type is an aggregate of features, then the list attribute will contain as many elements as there are geometries in that aggregate. Geometries in an aggregate maintain their order, and the list attribute keeps track of the levels of detail of each geometry in sequence.
If a non-aggregate geometry is created, the citygml_level_of_detail list attribute will only contain a single element referring to the level of detail the geometry created.
In addition to the citygml_level_of_detail list attribute, two geometry traits will be put on the geometry itself in order to identify its level of detail: citygml_level_of_detail and citygml_lod_name.
Mapping File Syntax Example
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Feature Type: CityFurniture'
Attribute(string): citygml_class' has value 1000'
Attribute(string): citygml_function' has value 1080'
Attribute(string): citygml_level_of_detail{0}' has value 2'
Attribute(string): fme_feature_type' has value CityFurniture'
Attribute(string): fme_geometry' has value fme_point'
Attribute(string): fme_type' has value fme_point'
Attribute(string): gml_id' has value gml-id01'
Attribute(string): xml_type' has value xml_point'
Attribute: citygml_level_of_detail{0}' is sequenced
Coordinate System: '
Geometry Type: IFMEPoint
Number of Geometry Traits: 1
GeometryTrait(string): citygml_level_of_detail' has value 2'
GeometryTrait(string): citygml_lod_name' has value lod2Geometry'
Coordinate Dimension: 3
(0,0,0)
=======================================================================
Feature Hierarchy
The design principle for CityGML is to model real-world entities as features, such as buildings and walls, and to maintain ‘part-of’ relationships between features. For example, a window and a door may be on the same semantic level, thus they can both be ‘part-of’ the same wall.
The CityGML Reader mimics this hierarchy with regards to the CityGML Thematic Model by creating a feature for each of the CityGML features, and maintains the ‘part-of’ relationships through gml_id and gml_parent_id attributes. In the example above, both the window and the door would specify a gml_parent_id equivalent to the gml_id of the wall that they would be a part of.
The reading of texture data may also be suppressed through the APPEARANCES parameter in order to speed up translations. If texture reading is suppressed, X3DMaterial, GeoreferencedTexture, and ParameterizedTexture features will always be created.
Data features with no geometries but with a reference point (for example, in the case of implicit geometries) will have a point geometry created corresponding to this reference point.
The CityGML Writer similarly uses the gml_id and gml_parent_id attributes to determine feature hierarchy.
The following is deprecated and only applies if the MATERIAL_FEATURES directive is set to Yes:
Previously, the CityGML Reader didn’t support the FME geometry appearance mode. Thus, the CityGML material XML elements, the X3DMaterial(s), GeoreferencedTexture(s), and ParameterizedTexture(s) elements were read as separate feature types. The CityGML appearance information is now automatically applied to the specified target surfaces; the creation of feature types from X3DMaterial, GeoreferencedTexture, and ParameterizedTexture elements are thus unnecessary and suppressed by default.