Requirements, Development, and Evaluation of A National Building Standard—A Swedish Case Study

Review comments

Response

14 - "the aim of this paper is to create a proposal for" -> the aim of the paper is to present, illustrate your proposal not creating it. Aim of your work =/= aim paper

Thank you, we agree, and it has been changed to present a proposal (lines 14 and 76).

Figure 2: In BIM we usually distinguish, level of detail (geom), level of developpement (geom. data) and level of information (data): depending on the nomenclature.
Here you only discuss level of detail is it intended? The paper seems to discuss both geometric and semantic harmonization.

Yes, this paper uses the LOD concept as it is defined in CityGML, that is where geometry, topology and semantics are described with varying complexity. The LOD concept can be confusing as the same acronym has a different meaning in BIM. A short description of this is added on line 317:

Another example is the LOD concept, in IFC LOD stands for Level of Development and in CityGML for Level of Detail, and the two LODs do not match.

333 - the question interoperability if part of your research requires more in-depth research than talking about BIM and 3D city models.
Which models, from which software, in which format...

That is a good point, we agree and have added a description of this on line 309:

There are many challenges to overcome to be able to exchange 3D building information between BIM and geodata formats. Often a BIM model is transformed to a geodata models and the software and format in which the BIM model was created, and to which geodata format it should be transformed, have a substantial influence on the complexity of the transformation.

Your recommendations, although useful are still rather vague or not precise. A more in depth and practical set of rules or guidelines would be relevant for future research or to improve the potential outcome of your research.

We agree that in many cases rules or guidelines are useful and we also suggest that a building standard should be complemented with guidelines on how the standard should be interpreted in order to get more uniform implementations. But, in section eight we discuss various options to consider and choices you must make when developing a building standard. In most cases there are several options to choose among and we wanted to show that there are advantages and disadvantages with most of these options. As we describe in section 8.3 (line 777) the choices you make should reflect what the building information (or city model) should be used for, which can vary from case to case, and therefore we did not want to define any rules or guidelines.

Review comments

Respons

As general comment: the relation to classification systems and registers is of high interest. Although it is not the main topic of the contribution, it could be highlighted a bit more

Thank you, we also find the relation to classification systems and registers both interesting and important.

The Swedish classification system is described in section 3.7 (line 232) and descriptions of how it could be used are spread throughout the paper:

·         to overcome interoperable issues between BIM and 3D city models (lines 57, 72, 338, 619, 734, 821, 828, 844);

·         to enable common definition of terms (lines 60, 72, 821, 844);

·         for automated check of building permit applications (line 344);

·         as a requirement for the new Swedish building standard (line 451, 672);

How a standard could refer to other registers is described in section 4.4 (line 350). Some descriptions exist throughout the paper:

·         possibility to refer to other registers from the new Swedish building standard (lines 39, 461)

·         link 3D cadaster registers to 3D city models (lines 372, 459)

·         use the external reference concept in CityGML for the referencing to external register in the new Swedish standard (line 455)

In figure 1 the output is divided into applications coming from 3D spatial information infrastructure and output coming from 3D game engine-based application development. The first mentions information visualization and cartography, the second interaction, immersion, user engagement. From our point of view this is a methodological mismatch: cartography is the overall method to communicate spatial information. 3D visualization, interaction, immersion and user engagement are requirements to make this communication successfull. I refer to topics like multimedia cartography et al. This methodological mismatch occurs throughout the paper.

Clarification of the comment on "methodological mismatch":

Figure 1 is an example from a paper from Juhlin et al. (2018) and describes their proposal on how to harmonise a 3D city model so that it can be used for multiple purposes. Therefore this figure cannot be changed.

We agree that cartography could be a misleading term in figure 1, but this figure is an example from a paper from Juhlin et al. (2018), so therefore we cannot make any changes in it. The figure describes Juhlin et al.’s proposal on how to harmonise a 3D city model so that it can be used for multiple purposes.

We do not have any propositions on the output from a building model or 3D city model in our paper as this is dependent on the application. What we try to emphasise is that 3D city models can be used for many different purposes and that requirements on the model should be defined before the model is implemented. This will ensure that the model include the information needed for its intended purpose.

What we try to emphasise in our paper is that 3D city models can be used for many different purposes and that requirements on the model should be defined before the model is implemented. This ensures that the model can be used for its intended purpose and will hopefully also better satisfy the users.

The section "4.6 building permit process" seems to be an important information, but it is misleading. The whole section seems to be misplaced in the overall redline of the contribution. The building permit process is not refered to elsewhere. Maybe it can be reduced to 1-2 sentences within the register section?

Yes, the building permit process is important in this study. One of the requirements for the new Swedish national building standard is that it should support the building permit process (line 463). In the methodology we describe that the requirements from the building permit process should be evaluated (line 512) and in section 7.5 (line 631) this evaluation is described in detail.

In section 5, line 413-414: the complexity of the model is also influenced by cartographic visualisation...and not only by the requirements of analysis. In cartographic visualisation 3D building data need to be generalized in order to guarantee communication success.

That is a good point, we have added a description about this, line 418:

Both cases can affect the complexity of the model, but in different ways. For cartographic visualisation, the building information may need to be generalized to improve performance.

On page 11, line 449: the external referencing could be highlighted. Are there any examples, architectures, concepts?

Yes, we agree. We have tried to clarify this in the text by describing that linking to cadastre information and to additional information needed in the building permit process should use external referencing, lines 459, 461 and 465

In section "6.2.4 Transform the UML model to an XSD schema file" you mention certain tag values. Which ones? For a re-evaluation of the transformation, a more detailed description would be helpful.

ShapeChange is a simple tool to use once it has been configured, but to configure it is both complex and time consuming. Unfortunately, there is no comprehensive guide on how to do this. We have added examples of tagged values needed in the paper, line 547: …, for example the tags targetNamespace, version and xmlns must have values at the application schema level

To describe all configuration that need to be done would require much more text to be included.

In section "8.2 Information architecture" beginning from line 755, three layers are defined. In fact the representation layer as 4th layer is missing.

Thank you, yes this is important to notice. A short text describing this has been added, line 774:

Neither of the above-mentioned examples provide a presentation layer, i.e. a layer including details of the cartographic solution. This layer is in many practical applications important and could act as a fourth layer.