Future Swedish 3D City Models—Specifications, Test Data, and Evaluation

Round 1

Reviewer 1 Report

The manuscript ‘Future Swedish 3D City Models – Specifications, Test data and Evaluation’ deals with standardization efforts for 3D city models in Sweden. A model called ‘3CIM’ is presented, which is based on CityGML version 2.0. Nearly all modules (Buildings, Transportation, Vegetation, Relief, Core, Utilities, …) of CityGML are used and discussed, which is rarely the case in publications. Many modelling problems in the modules are discussed and solved, relevant applications (Visualization, Noise simulation, Daylight Flood simulations) and the suitability of 3CIM for these applications are discussed. 3CIM is based on version 2.0 of CityGML, but the shortcomings of 2.0 which are solved in version 3.0 (which has been released two years ago, at least the conceptual model) are discussed (versions, flexible LoD concept). Hence, the manuscript is a very valuable contribution and of interest for everyone which designs national 3C city model standards in its broad range of modules and applications, in the context of the transition from CityGML 2.0 to 3.0. The manuscript is well written in good English language and technically correct (some problems are mentioned below).

The main problem of the manuscript is that the conclusions section (sec. 7) is much too short (5 lines) and does not present the contribution of the manuscript adequately. The contribution in sec. 7 would not justify a journal publication. Hence, it has to be extended significantly (It is not my point that there is no contribution, but the contribution is not obvious from sec. 7.

There are some other problems, more on a technical level:

•    Line 123: You state that you use the LoD definitions of Biljecki, Ledoux and Stoter 2016. These definitions refine each of the CityGML levels 0 to 3 by four sub levels (0.0 – 0.3, 1.0 – 1.3, 2.0-2.3, 3.0-3.3). In CityGML 2.0, geometry is represented by properties for levels 0 to 3, not for sub levels. How are the refined levels represented? Please explain.
•    Sect. 3.3, line 385; What is 3CIM technically? This is not stated explicitly. I think it is CityGML + Utility ADE + ADE for References, restricted by profiles (modelling only of specific LoD in particular modules) and by data capturing rules (minimal dimensions).
•    The ‘thin’ ADE is mainly for the representation of references to objects in other data sets. Why did you not use external references? Please discuss.
•    Line 358: You state that the names of codelists are extended from four to five digits. There is no restriction to four digits in CityGML. The example codelists from the SIG 3D have ids with four digits, but this is not part of the standard.
•    Line 399: You add a data type for geometry metadata. GML already provides a metadata concept for geometry.  Why didn’t you use this concept?
•    Line 407: You extend Buildings by an ID and version attribute.  On which concept is the extension based on? On an ADE?

Author Response

Dear reviewer,

Thanks for insightful comments (in italics below). Below is our response to them. The paper has also gone through a professional English language editing service and figure 6 and 17 has been improved. One additional change has been made in the paper since 3CIM ver 1.0 was just released. In practice, the differences between these versions are small (almost none in a general description as in this paper), and the test dataset are according to version 0.2 (as noted in the paper). 

The main problem of the manuscript is that the conclusions section (sec. 7) is much too short (5 lines) and does not present the contribution of the manuscript adequately. The contribution in sec. 7 would not justify a journal publication. Hence, it has to be extended significantly (It is not my point that there is no contribution, but the contribution is not obvious from sec. 7.

We agree that the conclusions needs to be improved. The new version is:

The main contributions of this study are the 3D city model specifications, denoted as 3CIM; the process to create these specifications in a collaborative manner; and the creation and evaluation of the test data. During this study, we encountered several design deci-sions and challenges.

We decided, before the project started, that 3CIM should be based on an international standard. The design decision was then to use CityGML 2.0. Since then, we have seen that several features added into the CityGML 3.0 conceptual model would be interesting for a future version of 3CIM (especially the handling of versions and logical spaces); however, the considered cities regard the tools available for CityGML 3.0 as not yet mature enough for production use.

Another design solution was to use a thin extension of CityGML (ADE), instead link-ing to external data bases and operational systems. This approach was evaluated for road data (e.g., connecting 3CIM to external road databases) and noise simulations. The main advantage of this approach is that it will be easier to maintain the data in a production environment; meanwhile, the challenges are that it is more complicated to create the city model data (as its object structure must be coherent with the external data), and that an ETL process is required to generate input data (e.g., for simulations). We have been able to cope with both these challenges.

The specifications in this paper are based on 3CIM ver. 1.0, the first official version of 3CIM. However, as noted above, 3CIM needs to be developed further. Themes that must be addressed in the next version likely include land-use and height/relief. Another important issue is that the 3CIM model must be harmonised with the National Specifications of Geoda-ta, which are also currently under development. 

In the project, we created test data for three study areas, one in each city. The main sources for the 3CIM data were 2D municipality maps, 3D building models, and some additional municipality models. The creation process was, to a large degree, interactive and even manual, which made it labour-intensive. This calls for further studies regarding the automation of the 3CIM data creation based on available data sources, and especially automated methods to connect 3CIM data to external databases and operational systems.

It is important that tools exist to handle the 3CIM data. As part of the study, we cre-ated many visualisations of the 3CIM data. Two examples of visualisations of the Malmö data were included in this paper, and three more visualisation tools have been used in the other cities. Our experience here is that the 3CIM data are appropriate for the most com-mon visualisation tools. We also showed that the 3CIM data can be utilised in several simulation tools (with the utilisation of an ETL process to generate input data). The main challenge, from a tool perspective, is to find a good storage environment which includes import and export functionalities, as well as supports updates. We tested the spatial da-tabase 3DCityDB (on top of PostGIS) and would like to continue to use this tool. More work is, however, needed to extend the 3DCityDB with functionality to handle the 3CIM ADE. In the future, we also need to extend the database solution with better versioning capabilities; hopefully, this could come together with the implementation of CityGML 3.0 in 3DCityDB. 

To create the 3CIM specifications, test data and the evaluations have been an exten-sive project spanning two and a half years, with a workload corresponding to a full-time equivalent of about four years. It is important that this investment can be paid off through the practical use of 3CIM. The current main obstacle to implementing the 3CIM model in Stockholm, Gothenburg, and Malmö, as well as in other Swedish cities, is likely the time and cost burdens related to creating and maintaining the 3CIM data.

One main strength of the 3CIM model is that it was developed by the three largest cit-ies in Sweden, in cooperation with Lund University. The fact that these four organisations have created this common ground together has paved the road for other Swedish cities to work with city information models in a standardised manner.

 

There are some other problems, more on a technical level:

• Line 123: You state that you use the LoD definitions of Biljecki, Ledoux and Stoter 2016. These definitions refine each of the CityGML levels 0 to 3 by four sub levels (0.0 – 0.3, 1.0 – 1.3, 2.0-2.3, 3.0-3.3). In CityGML 2.0, geometry is represented by properties for levels 0 to 3, not for sub levels. How are the refined levels represented? Please explain.

Good point, thanks. We removed the sentence in line 123, and instead added text about this in section 3.3.1. There it is now stated: “The building object are based on the CityGML 2.0 definitions with refined sub-levels ac-cording to Biljecki et al. [40]. Details of the sub-levels are specified in the measuring guide-lines.

To facilitate a mapping between buildings in 3CIM and the national specifications, it was decided that the same measuring guidelines as the national specifications [52] should be used within 3CIM. Therefore, 3CIM has cooperated with the national mapping agency to develop the measuring guidelines to provide detailed information about how to model Buildings, BuildingParts, and BuildingInstallations in different LoDs. Minimum sizes of objects to models are given, as well as details about what objects (e.g., canopies and dormers) should be modelled as Building/BuildingPart or BuildingInstallation. One example is given in Table 1; for further details, see [52].”  

• Sect. 3.3, line 385; What is 3CIM technically? This is not stated explicitly. I think it is CityGML + Utility ADE + ADE for References, restricted by profiles (modelling only of specific LoD in particular modules) and by data capturing rules (minimal dimensions).

Thanks for the comment. We agree that this was not clearly stated. To clarify we have included the UML-diagram for the transportation theme since that theme included both an additional class (Markings) and additional attributes in the ADE as Figure 3 with caption:

“Figure 3. UML-diagram of the transportation theme ADE. The ADE-attributes are added below the namespace <<3CIM>> in the existing CityGML classes and the ADE-class marking has the namespace <<3CIM>> added before the class name.”

We have also added a paragraph along with the figure:

“Technically, the UML-diagrams of the 3CIM specifications were created in the soft-ware Enterprise Architect (Sparx Systems) with a new namespace 3CIM for the ADE-elements. The UML-diagram for the transportation theme is shown in Figure 3 (original UML-diagrams for all themes are available at [60]). The ADE attributes are added below the namespace <<3CIM>> in the existing classes in CityGML and the ADE-class marking has the namespace <<3CIM>> included before the name of the class. The XSD-schema files were created by manually editing the CityGML 2.0 schema file based on XSD schemas for existing ADEs.”

• The ‘thin’ ADE is mainly for the representation of references to objects in other data sets. Why did you not use external references? Please discuss.

Actually, we use “External references” but have missed to state this in the text. We have updated section 3.3.2 with the following sentence “These linkages are implemented using the CityGML External References class.”. Thanks for pointing this out.

We also interpret this comment as connected to the comment above about what 3CIM is technically. As clarified above, the 3CIM ADE also includes additional attributes for all included themes. These attributes are to a large extent added to harmonize 3CIM with other national standards. We hope that the changes we made to better explain the more technical part about the 3CIM ADE will partly answer this comment as well. We mention it is section 3.3.2: “However, 3CIM has an ADE, but this ADE is mainly for harmonizing 3CIM to national standards and for tailoring data to facilitate references to external databases (see 3.3 below).”

We have also added a clarification in the abstract that the ADE is mainly to harmonize with other national standards: “The ADE is semantically thin, mainly extending CityGML 2.0 to harmonize with national standards, and instead 3CIM is mainly based on linkages to external databases, registers and operational systems for the semantic part.”

Your comment can also be interpreted as that is a design choice which attributes that are stored in the ADE and which one that are linked by External references. We added a paragraph to discuss this in the discussion section 6.1:

“3CIM is mainly a thin model where most attributes are stored in external databases / operational systems (using ExternalReference). However, some classes attributes are added to the 3CIM model using an ADE. In most cases you could apply any of the technical solutions. When we created 3CIM we had a strategy that we stored classes/attributes in the ADE for adherence to national standards and for including a few attributes that are commonly used in many applications. But in total few attributes where actually added in the ADE. The practical implementation and use of 3CIM will give us feedback of whether our strategy was good, and we see this as a part of the iterative development. ”

• Line 358: You state that the names of codelists are extended from four to five digits. There is no restriction to four digits in CityGML. The example codelists from the SIG 3D have ids with four digits, but this is not part of the standard.

Thanks for the comment. We have reformulated and removed the word “extended”: “The values in the code lists (gml:name) consists of five digits to enable a hierarchical structure for the attributes Class and Function where the first digit gives the more general level (class) and the later digits the more specialized level for function (cf. the four digit values in the suggested code lists for CityGML ). This enables 3CIM to use the same code lists as the national specifications.”

• Line 399: You add a data type for geometry metadata. GML already provides a metadata concept for geometry. Why didn’t you use this concept?

The reason for adding the data type for geometry is that we want the geometry metadata to follow the national specifications. The text is reformulated as an attempt to further stress this: “The Core module was extended with a data type GeometryMetadata to enable 3CIM to follow the specifications, including code lists, for geometry metadata described in the framework from the national specifications [52]; among others the metadata include quality elements such as time for observation of geometry, time for control of geometry, measurement technique and absolute positional accuracy.”

• Line 407: You extend Buildings by an ID and version attribute. On which concept is the extension based on? On an ADE?

Thanks for the comment. We agree that this should be clarified and have reformulated the first sentence in the Section: “The building theme in 3CIM is identical to CityGML 2.0 except for some additional attributes that were added as an ADE (namespace = 3CIM).”

Reviewer 2 Report

Abstract is not written in the standard format. It should have less general descriptions and more clear explanations about the proposed method of the paper. In the end of abstract, the quantitative results of the proposed method should be mentioned.

The literature review section of this paper is too long. It is like a book not an article. Please summarize the explanations and refer to the references for more study.

I suggest combining the Introduction and Literature Review sections in one section. In the end of this section, the innovation and contributions of the paper should be clearly mentioned.

Author Response

Dear reviewer,

Thanks for insightful comments (in italics below). Below is our response to them. The paper has also gone through a professional English language editing service, figure 6 and 17 has been improved, and concluding remarks extended. One additional change has been made in the paper since 3CIM ver 1.0 was just released. In practice, the differences between these versions are small (almost none in a general description as in this paper), and the test dataset are according to version 0.2 (as noted in the paper). 

Abstract is not written in the standard format. It should have less general descriptions and more clear explanations about the proposed method of the paper. In the end of abstract, the quantitative results of the proposed method should be mentioned.

Good point. We have removed some of the general text and instead provided more details about the study. The main outcome of this study is the national profile of the city models (called 3CIM) and the process to develop the specifications. There is not much quantitative result.

The literature review section of this paper is too long. It is like a book not an article. Please summarize the explanations and refer to the references for more study.

We do not agree that the literature review is too long. It is around 1300 words that provides a background to the most central part of our study. What has been missing, however, is a stronger linkage between the literature study and the discussion. This has now been strengthened by adding more discussions about for example CityJSON and applications supported (see e.g. section 6.2). 

I suggest combining the Introduction and Literature Review sections in one section. In the end of this section, the innovation and contributions of the paper should be clearly mentioned.

We want to keep the introduction and literature review separate, but we think your proposal of adding a paragraph about the main contribution is good. We have therefore added the following paragraph last the introduction. “The main contribution of this study is the 3D city model specifications as well as the process of creating these specifications, in particular how we have combined user needs, specification writing, test data creation and evaluation of specifications and data in an iterative process.”

Reviewer 3 Report

Well written paper that contributes to the challenge of creating standardized  specifications of 3D models of cities. Paper describes well the process used, developed solution and how it was tested. It was good that paper describes how data could be used for some smart city applications. Authors note how difficult it was to create the test data which shows well how far cities are now in the implementation of real 3D models that could be used for analyses. 

Authors do not describe nor discuss whether alternative solutions could have been used like not using the CityGML structure at all. As the storage of data was not really solved in study a question can be raised whether use of CityGML structure really bring any benefits as there will be always an ETL process needed. This could have been further analysed in the paper. Authors also mention CityJSON some times in paper but do not discuss this further. One possibility could have been that CityJSON would have been used in the data transfer as there are now APIs supporting it. 

I would recommend authors to discuss alternative options a bit more like

a) Was the decision to base the specification to CityGML a good one and would there be other options in the future. The complexity of the model and difficulties to create data, data storage question but also rather complex process to create working solutions might indicate that the selected approach should be changed. 

b) data quality was not really addressed in the paper. There are existing ways how data quality can be tested. At the minimum this should be discussed and the reason why data quality was not a concern. Obiviously data quality issues can been seen in many solution test. Could data quality already be part of the specifications?

 

Author Response

Dear reviewer,

Thanks for insightful comments (in italics below). Below is our response to them. The paper has also gone through a professional English language editing service, figure 6 and 17 has been improved, and concluding remarks extended. One additional change has been made in the paper since 3CIM ver 1.0 was just released. In practice, the differences between these versions are small (almost none in a general description as in this paper), and the test dataset are according to version 0.2 (as noted in the paper). 

Well written paper that contributes to the challenge of creating standardized specifications of 3D models of cities. Paper describes well the process used, developed solution and how it was tested. It was good that paper describes how data could be used for some smart city applications. Authors note how difficult it was to create the test data which shows well how far cities are now in the implementation of real 3D models that could be used for analyses. 

Thanks.

Authors do not describe nor discuss whether alternative solutions could have been used like not using the CityGML structure at all. As the storage of data was not really solved in study a question can be raised whether use of CityGML structure really bring any benefits as there will be always an ETL process needed. This could have been further analysed in the paper. Authors also mention CityJSON some times in paper but do not discuss this further. One possibility could have been that CityJSON would have been used in the data transfer as there are now APIs supporting it. 

I would recommend authors to discuss alternative options a bit more like

1. a) Was the decision to base the specification to CityGML a good one and would there be other options in the future. The complexity of the model and difficulties to create data, data storage question but also rather complex process to create working solutions might indicate that the selected approach should be changed. 

This is a good point, thanks. The former section called “CityGML2.0 vs. 3.0” is now moved (and re-named) and extended to incorporate other information models, including CityJSON. The new section is as follows:

6.2. International standards

It was early decided that 3CIM should be based on CityGML 2.0. One question that should be raised is whether this choice was good in terms of applications supported (section 2.1). We can conclude that 3CIM, in its current version, does not fully support applications in the built environment process, chiefly due to that versioning is not included. Another limitation with 3CIM for these applications is that it only models physical features, i.e. administrative features are not modelled. This implies that vital features such as (3D) cadaster information is not included. Both of these limitations could be solved in a later version of 3CIM that is based on CityGML 3.0. This new version of CityGML introduces a new versioning mechanism [57] as well as the possibility to model logical spaces [38].

Many simulations, such as some daylight metrics (cf. [72]), require indoor information. 3CIM allows indoor information to be stored since it allows CityGML LoD4 buildings (for details, see [36]). However, LoD4 buildings require much modeling that might not be of interest in this context. CityGML 3.0 has a more flexible LoD definition which allow indoor information to be stored in lower LoDs (see [38, 82]) which is a potential benefit for the 3CIM specifications. The aspects above points out that CityGML 3.0 would be preferable as a base for 3CIM.

On the other hand, it has been shown that CityGML2.0 has interoperability challenges due to its complexity and possibility to handle several geometric types [20], and these challenges could be increased with the new possibilities provided in version 3.0. A question is whether it would have been better to use another international standard as a base of 3CIM. The CityJSON standard is similar to CityGML in terms of information model, but has removed some parts to improve the interoperability [42]. The new CityJSON ver. 1.1[1] support the CityGML 3.0 information model apart from some specific features which potentially could make it more interoperable. Hence, CityJSON 1.1 could be an interesting option for later 3CIM versions.

It should be noted here that the main interest for selecting international standards as a base for 3CIM is the information model, and not the data format. It is hard to predict which information model that will be the best in longer terms. Apart from that the information model must support common applications, the choice of information model also depends on the development of tools, and especially the development of database tools (including appropriate import and export tools). Since 3CIM is designed as a semantically thin model that depends on external data sources for attribute information it will always relies on ETL processes to generate input data to most analyses and simulations. In this respect, the main requirement is that the data model used must be possible to be imported into the ETL tool.

1. b) data quality was not really addressed in the paper. There are existing ways how data quality can be tested. At the minimum this should be discussed and the reason why data quality was not a concern. Obiviously data quality issues can been seen in many solution test. Could data quality already be part of the specifications?

This is also a good point, thanks. In the paper we earlier stated in section 3.2.4 that:

“However, on a more general level 3CIM has made several decisions to harmonize with the national specifications e.g.: (1) it was decided to follow the geometry and geometry metadata specifications as described in the framework for the national specifications”.

And in section 3.4.1 (according to new section numbering) it was stated that:

 “In 3CIM the Core module was extended with a data type GeometryMetadata for storing geometry metadata according to the framework from the national specifications [52].”

But we did not make any connection to data quality. What has now been added is the following:

In 3.4.1 we added a sentence: … The Core module was extended with a data type GeometryMetadata (as and ADE) to enable 3CIM to follow the specifications, including code lists, for geometry metadata described in the framework from the national specifications [52]; among others the metadata include quality elements such as time for observation of geometry, time for control of geometry, measurement technique and absolute positional accuracy. .

And a new section is added to the discussion:

6.5 Data quality issues

The 3CIM specifications include both rules to guarantee that the data is of good quality and possibilities to store quality information on object level. The data quality rules are provided in the measurement guidelines. Among other, these guidelines state which measurement techniques that should be used. The detailed measurement procedures are then specified in the national measurement manuals (HMK). In these manuals it is stated that urban data, for example 3D city models, should have a positional accuracy on dm level.

All 3CIM objects have data quality elements enforced by the ADE (cf. section 3.4.1). In our study we tested to populate these elements with values taken from data production systems (applied in the Stockholm test data set). This implies that data quality values are stored on object level in the 3CIM data.

What remains to be evaluated is whether the quality specifications in the measurement guidelines and the data quality elements together support common applications of the 3CIM data. Early studies in Pantazatou et al. [73] reveal that the positional accuracy recommendations are sufficient for daylight simulations, but more studies are needed in the future. 

 

Reviewer 4 Report

The authors of this work discuss the creation of 3CIM, a new Swedish standard for 3D city models. 3CIM is a collaboration between Sweden's three major cities, Stockholm, Gothenburg, and Malmö. 3CIM is a technical extension of the OGC standard CityGML that has been implemented as an application domain extension (ADE). The paper is well-written; however, there are some missing parts that need to be clarified by the authors:

1-      The data model of the proposed 3DCIM ADE is not provided in the paper. In other words, should provide UML diagrams within the paper to describe how the CityGML standard is extended and what kind of new attributes, classes and relationships are defined within the proposed ADE based on the specific requirements in the context of Sweden.

2-      The paper does not include a methodology section to describe the particular steps that the authors have undertaken to develop the proposed ADE (i.e. 3DCIM). These should be described in a way that the other jurisdictions should be able to replicate the authors’ methodology for creating their own 3D city models.

Author Response

Dear reviewer,

Thanks for insightful comments (in italics below). Below is our response to them. The paper has also gone through a professional English language editing service, figure 6 and 17 has been improved, and concluding remarks extended. One additional change has been made in the paper since 3CIM ver 1.0 was just released. In practice, the differences between these versions are small (almost none in a general description as in this paper), and the test dataset are according to version 0.2 (as noted in the paper). 

The authors of this work discuss the creation of 3CIM, a new Swedish standard for 3D city models. 3CIM is a collaboration between Sweden's three major cities, Stockholm, Gothenburg, and Malmö. 3CIM is a technical extension of the OGC standard CityGML that has been implemented as an application domain extension (ADE). The paper is well-written; however, there are some missing parts that need to be clarified by the authors:

1-      The data model of the proposed 3DCIM ADE is not provided in the paper. In other words, should provide UML diagrams within the paper to describe how the CityGML standard is extended and what kind of new attributes, classes and relationships are defined within the proposed ADE based on the specific requirements in the context of Sweden.

Thanks for pointing this out. We agree that we should include UML-diagrams in the paper and not only provide them online at the 3CIM project pages. We do however, think that including UML-diagrams for all themes in 3CIM would lengthen the paper without adding much information. Instead we have included the UML-diagram for the transportation theme as an example since this theme includes both ADE-attributes and an ADE-class (see Figure 3 and response to comment #2 below). We have also explicitly mentioned the 3CIM ADE when introducing the attributes and classes that are part of the ADE when we give an overview of 3CIM in Section 3.4 to be more specific.

2-      The paper does not include a methodology section to describe the particular steps that the authors have undertaken to develop the proposed ADE (i.e. 3DCIM). These should be described in a way that the other jurisdictions should be able to replicate the authors’ methodology for creating their own 3D city models.

Good point, thanks. We have added a new section 3.2 (an extended section from the previous section about “iterative development”. This section includes both the work process and some technical details of generating the ADE.

 

3.2. Methodology to design the 3CIM specifications

The 3CIM specifications have been developed in an iterative process where a version of the specifications is developed during a series of workshops with participants from all three cities. On average there were two workshops per theme resulting in more than ten work-shops in total. Test data was then created according the current version of the specifications to perform practical test of the information model. The test data creation and practical test were then followed by a new series of workshops based on feedback from the practical test and the information model was updated to a new version which could also include new themes. The test data was then updated according to the new version of the specifications and new practical tests were performed and evaluated. In addition to the workshop within 3CIM, around ten workshops were held together with Lantmäteriet (the Swedish NMA) to guarantee harmonization between 3CIM and the Swedish national specifications for geodata, especially concerning common measuring guidelines.

Technically, the UML-diagrams of the 3CIM specifications were created in the soft-ware Enterprise Architect (Sparx Systems) with a new namespace 3CIM for the ADE-elements. The UML-diagram for the transportation theme is shown in Figure 3 (original UML-diagrams for all themes are available at [60]). The ADE attributes are added below the namespace <<3CIM>> in the existing classes in CityGML and the ADE-class marking has the namespace <<3CIM>> included before the name of the class. The XSD-schema files were created by manually editing the CityGML 2.0 schema file based on XSD schemas for existing ADEs.

 

And in the end of the discussion section 6.1.

 

“In this study the ADE was generated manually from the UML using a reverse engineering approach (looking at other examples) and several tests that the ADE was correct. This approach was possible since the ADE was thin. There was initial work performed using the ShapeChange tool[1] (in a similar manner as used in e.g. [3] and [4]) but this work was ended due to technical problems. In future work we need to find a more automated solution for the ADE generation.”