Introduction

In recent years, 3D semantic models have been increasingly used in many disciplines. In particular, the field of 3D city models is developing increasingly innovative and automated procedures for the reconstruction of semantic 3D city models from different sources of data (e.g. geodata, BIM models and point clouds) (Biljecki et al. 2015).

Over the past few years, various approaches to generating 3D city models in explicit parametric modelling environments with VPL (Visual Programming Languages) have emerged due to their information flexibility. These attempts grew into a school of thought called ‘parametric urbanism’ (De Jesus et al. 2018; Fink et al. 2019).

For a 3D city model to be defined as semantic, it must follow standards in terms of levels of geometric detail (LoDs) and geometric-attribute relationships. The main references are CityGML and CityJSON standards, which are widely applied in geomatics applications (Ledoux et al. 2019; Nys et al. 2020). However, although the parametric VPL environment allows for maximum flexibility, it appears that these standards are not yet being applied, thus limiting the interoperability and adoption of parametric 3D semantic city models.

The Research

The aim of the work presented in this research is to create a semantic workflow which enables a standardised semantic structure for parametric 3D city models. The pipeline of work proposed facilitates and improves the information enrichment of the different geometric components within a parametric 3D city model and also normalises its semantics by creating a structure taking as reference the international standard of CityJSON. This operation is essential to manage and quickly access all the information from the material collected during the survey phases in order to convey all the useful information such as construction period, material, construction techniques, thicknesses, etc. The application shown in this research regards the creation of a semantic 3D city-block created starting from a terrestrial laser point cloud acquired in the historical center of the city of Catania (Fig. 1).

Fig. 1
figure 1

Source: author’s image

View of the historical city-block (top) and its parametric model (bottom).

Full size image

In the parametric domain, although there is a large use of VPLs for spatial and urban modelling, there is still no format to unify all the experiences conducted and to facilitate interoperability. Therefore, 3D city models in the parametric context are developed through different methods depending on the modeller's skills, but their semantic utilisation stops at these individual applications. The alternative is to fall back on a format linked to the BIM or GIS sphere, thus vanishing the efforts to adopt a holistic approach offered by City Information Modelling (which combines effectively the latter ones methods in a comprehensive approach for 3D city models) (Xue et al. 2021; Zhang et al. 2021). It is worth mentioning that, concerning the field of formats for the dissemination of 3D city models, CityJSON format is gaining popularity due to its simple structure and ease of development within various programming environments.

The data structure of CityJSON provides for two types of objects, first- and second-level CityObjects. Second-level CityObjects belong to the first-level ones. In addition, a first-level CityObject called CityObjectGroup can be used as 'containers' of first-level CityObjects (useful when clustering to indicate a specific aggregate) (Fig. 2a) (Arroyo Ohori et al. 2022).

Fig. 2
figure 2

Source: Arroyo Ohori et al. (2022)

(From left) a Hierarchical structure of CityObjects in CityJSON; b example of a first-level CityObject (Building) containing related second-level CityObjects; c a complete (empty) CityJSON file.

Full size image

In this work, a VPL code was realised, which allows the creation of first- and second-level objects and, from their combination, to obtain a 3D city model file. Since its world-wide use, the VPL Grasshopper and its data structure (Data Tree) has been chosen as parametric environment. The plugin obtained was named CityGH by analogy with CityJSON.

In CityJSON (specifically, version 1.12), first-level CityObjects are data dictionaries that contain all dependant second-level CityObjects. It is therefore a nesting of dictionaries on several levels. Below is an example of a first-level CityObject (Building) containing related second-level CityObjects (Fig. 2b). Multiple first-level CityObjects are all contained in the main top-level dictionary which is constituted by the CityJSON file. Below an example of complete but empty CityJSON object (Fig. 2c). The value of “CityObject” is a list of dictionaries each one of them represents a specific CityObject of 1st level.

As can be seen from the examples shown, CityObjects present in their structure initially values that refer to attributes or metadata such as: "type" (indicating the type of CityObject), "attributes" (consisting of a user-customised dictionary that allows all the desired attributes to be collected), "parents" and "children" (indicating the semantic relationships between objects), “lod” (which shows the LoD or LoDS used as reference for the geometries stored), etc. The last element is always the geometry, which is represented by means of a list of vertex identifiers collected in the CityJSON object, thus allowing geometries to be transformed into text according to the OBJ format. It is noteworthy that the name of the individual object that is stored by the key “id” is up to the user.

The prototype developed in this work currently provides two types of Grasshopper “components” (VPL algorithm nodes) that allow the creation of any type of first- and second-level CityObject. Depending on the specification of the object, these components can be changed by means of a series of input lists and sliders that allow the CityObject type to be changed quickly. The function of the components for level 1 and level 2 is the same. They collect the input data reflecting the order of the key-value pairs described in the CityJSON specification and organise them in the data lists in Grasshopper.

Compared to the structure of CityJSON, there are two main differences in the CityGH proposal. The first one relates to the geometries since they are stored as the last item in the list (and not decomposed into points) in accordance with the types of geometry allowed by Grassopper (curves, surfaces, BReps, etc.). The second difference concerns the naming of the individual CityObject. In CityJSON it is chosen freely by the user, whereas in CityGH the “id” is taken from the index path generated by Grasshopper (Fig. 3) and is appropriately manipulated to have an identification code which, through the semantics of Grasshopper, allows an exhaustive description of the semantics and type of the CityObject created.

Fig. 3
figure 3

Source: author’s image

Visualisation of coloured openings in relation to the facade they belong to. Each opening has an individual index describing its semantics thanks to DataTree structure manipolation in Grasshopper.

Full size image

Once the building components were created, they were used to build the first-level CityObjects. Afterwards, first-level CityObjects have been defined, they are grouped under a CityObjectGroup that contains attributes related to the entire city block. Since the scale of the city block has been reached, all that remains is to complete the data tree with the final construction of the CityGH Object. This last object is used to create metadata relating to the model such as author, entity, etc. In accordance with the CityJSON specification (Fig. 4).

Fig. 4
figure 4

Source: author’s image

VPL code developed in Grasshopper for the application of CityGH.

Full size image

The CityGHObject consists of a single tree representing the entire city represented and has branches at different levels. At each level of depth of semantics, a digit is added to the index path of the object in Grasshopper. In analogy to the tree structure, the CityGH components allow this information to be layered in descending order so that each individual object has a unique identifier. In Fig. 5a, each circle corresponds to a different semantic depth level. Starting from the centre, there is therefore only one number used for the index. Grasshopper uses {0} as standard, but it appeared significant for the purposes of this work to use the code that the municipality of Catania has attributed to the city block under study (id 470) as the index of the urban block level. Next there are the first-level CityObjects so a digit, the second, is added to represent the building in relation to the block. Therefore there will be {470;0}, {470;1} and so on.

Fig. 5
figure 5

Source: author’s image

(From left) CityGH DataTree semantic structure scheme; content of final CityGHObject.

Full size image

The application starts with the construction of second-level CityObjects concerning three types of building components: interior walls, floors and windows. The inputs were defined in accordance with the specifications according to CityJSON 1.1.2. In addition, among the inputs of this CityGH Object, it is required to enter the code of the city-block to which the building component belongs to.

The third digit is added with the creation of the second-level CityObjects (the building components). In this case, it is not a progressive number but each of the types used is associated with a meaning. 0 stands for floors, 1 stands for internal walls and 2 stands for windows. The fourth digit is instead the identifier proper to that element and defines its uniqueness in the entire model. By way of example, an object having index {470;2;0;1} means that it is an object belonging to building ‘2’ in block ‘470’, and it is a slab (‘0’) at the first level (‘1’). Figure 5b shows the content of the final CityGH Object by reading from the panel component.

Conclusion

CityGH makes it possible to normalize 3D city models, thus laying the foundations for further development concerning the interoperability between CityJSON and CityGH, by making these models more and more widely deployable. The data structure created makes it possible to define with methodological rigor the correct stratification of the different levels of the city, giving a common vision without limiting the modeling approaches, which by the nature of the work itself always remain differentiated and dependent on the resources employed.

However, the future applications are numerous since what has been realized is a high-performance container whose content can be any discipline that relates to the urban environment (transport, heat island analysis, hydrogeological risk, urban planning, urban landscape, drones, economics, etc.). The development of this format also aims to provide practicality to the definitions of City Information Modelling, hoping for greater adoption of this approach in many disciplines.