Question

What is the CityGML format and how can you work with it in FME?

Answer

Description

FME's CityGML Reader and Writer currently support CityGML 0.3.0 and 0.4.0. The reader additionally supports the NoiseADE.

CityGML Reader

The CityGML Reader reads CityGML versions 0.3.0 and 0.4.0.

CityGML is an XML-based format which has a combination of a fixed set of feature-types and two types of extension mechanisms. The first type of extension mechanism is simply to have a feature-type of GenericCityObject. This allows the reader to provide different features types from GenericCityObject elements based on the gml:name element that it contains. That is, many users of CityGML will want to have features which conform to the CityGML schema for GenericCityObject, but which are treated differently in the workspace. Rather than require the user to manually filter based on an attribute, where possible a GenericCityObject will have its feature-type set by the gml:name element. This provides a convenient way to grouping objects which are all underlyingly GenericCityObject elements, but which for your particular purposes you want to treat differently. This is a very light-weight method of extension and is handled automatically by the CityGML Reader.

The second extension mechanism is mandated by the CityGML Schema, which is to add an Application Domain Extension, such as the NoiseADE. Currently the NoiseADE is the only ADE that the CityGML Reader supports, but as more are created additional support will be provided. If the user wants to read CityGML that has been extended with the NoiseADE, there is a settings box/workspace parameter which must be set.

CityGML Writer

The CityGML Writer currently only writes CityGML version 0.4.0. Where possible 0.3.0 data types are converted to 0.4.0 types. For example, in CityGML 0.3.0, a ParameterizedTexture was an extension of the gml Surface element. In CityGML 0.4.0, the decision was made to deprecate the use of the ParameterizedTexture and instead have a strict seperation between the geometry (the surface) and the Texture. If the writer is handed a geometry which represents a ParameterizedTexture, it will attempt to construct a texture element of the appropriate type and link it to the geometry via the gml:id attribute on the geometry.

The attached zip file (3D Workshop.zip) includes a 3DWorkshop with sample data and workspaces. Section 3 of the workshop deals specifically with writing 3D data and textures into CityGML using FME. 

Geometry Representation

CityGML allows a feature to have many geometries, each playing a different role for the feature. Since the FME currently only allows a single geometry per feature, the solution has been to aggregate the geometries within the FME (as the reader does automatically) and then identify the role of the geometry via a trait on the geometry. That is, the geometry may be an aggregate of a surface and a line, but each component will have a trait citygml_lod_name, and the value of this trait will indicate the role that it will play for the feature.

If you are writing to CityGML from CityGML, then obviously the reader will have set up these aggregates and their traits. However if the source data is some other format that the traits will not be set up and the likely outcome is that the geometry will simply not be written (since it is very difficult to decide what the 'default' meaning of a geometry should be). The exception is that for GenericCityObjects (or any object whose feature-type name doesn't match one of the CityGML specified feature-types) if there are no traits on the geometry, then the writer will interpret the geometry as 'lod4Geometry' which is the most flexible geometry that CityGML has. Those wishing to take more control over the geometry will need to use the trait-setter and aggregate functions of the FME to set up the geometry roles.

See the entry in the FME Readers and Writers manual for LandXML for a format with a similar structure for geometries.