- Overview CityGML modules
- Generics module
- Specific CityGML v3.0 features not supported
- Extra features in CityJSON but not in CityGML
CityJSON v2.0 partially implements the CityGML v3.0 data model and includes a JSON-specific extension mechanism (akin to CityGML ADEs).
The CityGML conceptual model is thematically decomposed into one Core module and 16 extension modules. Below we list each of the modules and describe what is supported and what not.
|partially supported (often missing features are for the sake of an efficient implementation)|
|module not supported at all|
|CityGML module||compliant?||extra info|
|Core||all geometries can be represented, Implicit Geometries are supported (called Geometry Templates). Only the |
|Appearance||the CityGML class |
|CityObjectGroup||groups of City Objects are supported, but not groups of parts of objects (eg it is not possible to group some walls of a building together)|
|Generics||everything supported, but implemention differs, see details below|
|PointCloud||this Extension can be used|
|Relief||only the |
|Versioning||instead, CityJSON aims at offering a Git-based alternative, see our work-in-progress|
The generics module is for:
- adding generic attributes that are not prescribed by the CityGML data model
- representing city objects that are not described in the CityGML data model
CityJSON implements these but the handling differs from CityGML slightly.
One of the philosophy of JSON is being”schema-less”, which means that one is allowed to define new properties for the JSON objects without documenting them in a JSON schema. While this is in contrast to CityGML (and GML as a whole) where the schemas are central, the schemas of CityJSON are partly following that philosophy. That is, for a given City Object, the “allowed” properties/attributes are listed in the schema, but it is not an error to add new ones. The “official validator” of CityJSON (cjval) does more than simply validate a dataset against the schemas, and will return a warning if an attribute is not in the schema, but it is not considered as invalid in CityJSON.
To add new city objects, CityGML has the ADE mecanism (Application Domain Extensions). CityJSON has a similar concept, called Extensions. Extensions do not follow the same rules and thus cannot be considered as a direct JSON translation of ADEs. They are deliberately simpler than ADEs, with the aim of being easy to use in practice (ADEs are generally not very user-friendly).
Extensions allows us to: (1) add new complex attributes to existing City Objects; (2) add new properties at the root of a document; (3) create a new City Object, or “extending” one, and defining complex geometries; (4) create new Semantic Surfaces.
- Several CRSs in the same datasets. In CityJSON, all geometries in a given CityJSON object must use the same CRS. In CityGML, 3 adjacent buildings can all have different CRSs, and some of the geometries to represent the walls can be in yet another CRS (although admittedly it is seldom used!).
- Identifiers for low-level geometries. In CityGML most objects can have an ID (usually a
gml:id). That is, not only can one building have an ID, but also each of the 3D primitives forming its geometry can have an ID. In CityJSON, only city objects and semantic surfaces can have IDs.
- topological relationships, eg relativeToTerrain and relativeToWater, which qualify relationships, are not supported. XLinks to identify that some surfaces are shared between 2 objects is also not supported, however the fact that more topology is explicitly stored compensates somehow.
- Terrain Intersection Curve (TIC). This feature of CityGML is seldom used in practice it seems, and can always be simply computed on-the-fly: intersection between the solid of the buildings (or other objects) and the terrain. Furthermore, it is dependent on the LoD of the object (different LoDs can have different footprints)
- Complex attributes have been simplified. For instance, several attributes in CityGML are derived from
bldg:measuredHeight), and thus you cannot just store a value but also have to store the unit of measurement. This is not represented in CityJSON directly, an Extension must be used. Also, generic attributes in CityGML cannot be mapped simply because in CityJSON you can add any attributes you like (inline with the JSON philosophy).
- CityJSON supports the so-called “TU Delft LoDs”, which refine and improve the 5 LoDs in CityGML (only for buildings).
- CityJSON addresses the issue of very large files, and how to stream them.
- CityJSON offers the possibility to store metadata, 6 ISO19115 properties are supported, and with the Metadata Extension more can be stored.