ENHANCED LOD CONCEPTS FOR VIRTUAL 3D CITY MODELS

: Virtual 3D city models contain digital three dimensional representations of city objects like buildings, streets or technical infrastructure. Because size and complexity of these models continuously grow, a Level of Detail (LoD) concept effectively supporting the partitioning of a complete model into alternative models of different complexity and providing metadata, addressing informational content, complexity and quality of each alternative model is indispensable. After a short overview on various LoD concepts, this paper discusses the existing LoD concept of the CityGML standard for 3D city models and identifies a number of deficits. Based on this analysis, an alternative concept is developed and illustrated with several examples. It differentiates between first, a Geometric Level of Detail (GLoD) and a Semantic Level of Detail (SLoD), and second between the interior building and its exterior shell. Finally, a possible implementation of the new concept is demonstrated by means of an UML model.


INTRODUCTION
Virtual 3D city models are used to represent single buildings, city quarters, urban districts, cities and regions.Usually such models cover not only buildings but also other real world objects such as infrastructure, vegetation and terrain.The quality of city models varies in geometrical accuracy, in semantic richness and in realism of its appearance.
Depending on the techniques used for data acquisition and data processing and depending on the intended purpose of the city model different levels of data quality (precision and content) are achieved or required.Generally, different degrees of data quality have to be reflected in a Level of Detail (LoD) concept.
Beyond visualisation of city models, a pure geometrical LoD as available in some graphic formats is not sufficient.With the introduction of semantic data models like CityGML (Gröger et al. 2012) another dimension in the definition of LoD has to be considered.Besides geometry, semantic data models offer objects (features) with properties (attributes) and relations.In this case the city model can not only be refined by increasing its geometrical accuracy but also by the increasing semantic richness.Some application areas like emergency management (Zlatanova and Li, 2008) and indoor navigation (Becker et al. 2009) require information of the building's interior even on a city or regional level.This requires a LoD concept covering a similar range of data quality for both building's exterior and interior, which simultaneously is flexible enough to allow for different Levels of Detail for the building's exterior and interior.
After giving an overview of existing LoD concepts in general and describing the deficits of the CityGML version 2.0 LoD concept in particular, this paper will focus on extensions and improvements of the LoD concept of CityGML.Our approach, described in this paper, is to clearly distinguish between geometric and semantic LoDs.It is an evolution of the existing CityGML concept, enhancing it by adding metadata for describing the semantic LoD.In addition, our approach transfers the LoD concept of the building's exterior shell to the building's interior.The new concept will be explained in detail for the CityGML Building module.A possible implementation by means of an UML class model will be discussed and some examples will be given.The main target of this approach is to enhance the functional spectrum of CityGML and to add information about the semantic LoD without totally breaking with the current CityGML standard.It is intended to have clearly defined mapping rules between the current and the new model.

STATE OF THE ART IN LOD CONCEPTS FOR 3D CITY MODELS
In this section, a survey on LoD concepts for 3D city models is provided and scientific approaches which use or refer to LoDs are discussed.
LoD concepts for 3D city models can be categorized with regard to the criteria for which the levels are defined, and into discrete (fixed number of levels) and continuous concepts.The LoD concept which traditionally is used in Computer Graphics models and tools is continuous and defined purely with regard to geometrical of graphical aspects.This concept targets at efficient visualisation: Spatial objects which are far away from the viewpoint of the user are depicted coarsely, whereas objects near to the user are shown with high degree of detail (c.f.Luebke et al. 2002).The visualisation tool Google Earth operating on KML/KMZ data is an example (Wilson, 2008).Figure 1 illustrates the LoD switches depending on the distance to the observer in another graphic format, VRML/X3D.In ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume II-2/W1, ISPRS 8th 3DGeoInfo Conference & WG II/2 Workshop, 27 -29 November 2013, Istanbul, Turkey This contribution has been peer-reviewed.The double-blind peer-review was conducted on the basis of the full paper.51 contrast, the LoD concept of CityGML is defined with regard to both geometry and semantics, and it is discrete: there are five levels LoD0 -LoD4, three of which (LoD1 -LoD3) have already been defined in earlier approaches (Köninger and Bartel, 1998;Coors and Flick, 1998;Schilcher et al., 1999).
There are numerous approaches which define non-geometrical LoDs for 3D city models.Hagedorn et al. (2009) propose discrete indoor LoDs for route planning and visualisation purposes.There is a close analogy to the CityGML LoDs: each CityGML LoD is in principle extended by indoor or navigation structures of corresponding detail level.LoD1, for example, is extended by the building's access point and 2D floor plans, whereas 2D spaces, walls and openings, as well as a more detailed route graph are added to CityGML LoD2.Another extension of CityGML's LoD concept has been introduced by Mignard et al., (2011).Their 'Contextual LoDs' (C-LoDs) focus on visualization, but the selection of the LoD which is appropriate for a particular visualisation does not depend on geometrical aspects only, i.e., the closeness to the observer.In In addition, the 'semantic distance' is taken into account.This continuous measure depends on the context of the user, on the properties of the object to be visualized, or on external criteria such as day or night, or weather conditions.Continuous 'Levels of Quality' (CLOQ) for 3D city models have been introduced by Döllner and Buchholz (2005).The incremental refinement of buildings is supported by this concept.The floor is the key conceptual element in the underlying semantic model.
The CityGML LoD concept allows to simultaneously representing different LoDs for the same spatial object.Kolbe and Gröger (2003) focus on the consistency between these multiple representations, which typically are organized hierarchically.They present rules which select a set of spatial objects from different LoDs which can be analysed and visualised together.The rules guarantee that each real-world object is represented exactly once in the application or scene.Stadler and Kolbe (2007) introduced the definition of spatiosemantical coherence, which is closely related to the LoD concept.Six different categories with varying complexity of geometry and semantics are presented.Geometry and semantics each can either be 'missing', be 'simple' or be 'complex', where 'complex' refers to an explicit representation of the parts of a building (rooms, boundary surfaces, …).The most elaborate combination provides a complex geometry and complex semantics: all parts of a building are represented semantically in a detailed way, where each semantic object has its own geometry.This concept can be applied to a single LoD, but no rules for consistency between objects in different LoDs are provided.
Meta data are a means to complement or to partially replace LoDs.Dietze et al. (2007) discuss the suitability of current metadata models (ISO 19115) for 3D city models.Meta data such as planimetric or height accuracy can be represented, as well as the type of geometry used for spatial representation, e.g.solid or multi surface for representing the outer building shape.An extension of ISO 19115 is proposed to accommodate for metadata such as the representation of the LoD value as an attribute of a feature.Many researchers present generalization methods which use CityGML as a base or as a target model.Glander and Döllner (2009) present a method to automatically generalise a CityGML model consisting of buildings, an infrastructure network and a land use coverage.Several representations of increasing levels of abstractions are created, in order to reduce the visual complexity of visualizations for easier comprehension by the user.In this approach, the focus is set on landmark buildings, which are highlighted graphically.Fan et al. ( 2009) sketch a procedure to generalize a CityGML LoD based on the next higher LoD (e.g., LoD3 models from LoD4 models, or LoD2 from LoD3).Götzelmann et al. (2009) propose the mutual generalisation of the terrain and of buildings in the context of CityGML for visualisation purposes.The relation between buildings and the terrain is preserved in their approach.A multiple representation structure for CityGML is proposed by Mao et al. (2009;2011).This structure, which is called 'CityTree', represents the result of a generalisation process, in particular the aggregation of buildings.Dynamic zooming functionality in real time is enabled by this approach.The generalisation process for CityGML models is separated into modules by Guerke et al. (2009), in order to enable the use of services.Nurminen (2007) presents a wireless network protocol for the efficient visualisation of CityGML data on mobile devices, in particular on smart phones, in the context of navigation applications.
IFC does not provide a LoD concept.However, the same object can be represented by multiple geometries simultaneously (c.f. Figure 2).These representations are not systematically assigned to a specific LoD.

DEFICITS OF THE CITYGML LOD CONCEPT
Due to its simplicity and vividness, the LoD concept is one of the most successful and most cited parts of the standard.For a rough characterisation of a 3D city model and its geometric and semantic content, it is in fact excellently usable.However, an LoD characterisation should be more than a marketing instrument.It should provide information, whether a concrete CityGML instance model really is suited for a specific application and how a switching between different LoDs (if available) can be performed.In this context, the CityGML LoD concept shows a number of deficits.Furthermore, the realization of the LoD concept in the actual CityGML 2.0 data model partially increases the data model complexity unnecessarily (e.g.there are 17 geometric properties in AbstractBuilding), and simultaneously imposes severe restrictions on the applicability of CityGML.Finally, the usage of the same LoD concept for all thematic areas of the standard (except the Digital Terrain Model) is problematic and partly may produce absurd results.
The problems of generalising the CityGML LoD concept to other thematic areas as Building are discussed in chapter 3.1.
The remaining parts of this paragraph deal with the shortcomings of the Building LoD itself.

Uniform LoD concept for all CityGML thematic modules
The five levels LoD0 to LoD4 were primarily developed for the classification of building models, and the concept very often is illustrated by showing pictures of buildings modelled with increasing geometric and semantic complexity (see Figure 3).This concept easily can be generalised for technical city objects like tunnels or bridges showing the following characteristics:  Geometrically they can be represented in different manners: As 2D or 2.5D plane, as 3D vertical extrusion body, or as 3D shape with different geometrical accuracy.
 They have a hierarchical structure, splitting a complex object into smaller parts and eventually classifying the visible parts of the object semantically.
 They have a relevant "Interior Model", consisting of independent objects or geometry parts which are not visible from outside.
For many thematic modules of CityGML, one or even all of these conditions fail.One example for the latter is the Digital Terrain Model, which consequently has a different LoD concept.The LoD of a ReliefFeature is expressed as integer attribute lod with values between 0 and 4. Unfortunately, the specification only states that the value of lod indicates an accuracy of the relief model, without giving precise definitions or providing suitable metadata.
All other thematic modules of CityGML realize the LoD concept of the Building module and define geometry properties lodX… (X = 1, 2, 3, 4).This especially concerns the LandUse class, representing a semantic classification of the earth relief due to it physical structure (Land Cover) or socio-economic usage (Land Use).There is no obvious reason why ReliefFeature and LandUse use different LoD concepts.
The simple transfer of the Building LoD concept to city objects without semantic structure (e.g.GenericCityObject or CityFurniture) or without relevant interior model is also problematic.It is not very useful and unnecessarily increases the complexity of the CityGML data model to provide a LoD4 representation for SolitaryVegetationObjects (to represent squirrels?)or WaterBodys (to represent fishes?)

Strict coupling of geometric and semantic complexity
One of the main characteristics of the LoD concept is a strict coupling between geometric and semantic complexity of a building model.In LoD0 and LoD1, no further decomposition of a Building into other feature classes or semantic classification of the geometry is possible.For LoD2 to LoD4, the complexity and accuracy of the geometric representation increase, and simultaneously a semantic structuring of a building is possible.
But there is a central difference between geometry and semantics.A specified LoD enforces a certain geometric representation and has to guarantee a minimum accuracy, defined as discrepancy between real object and model.On the other hand, the increase of semantic complexity is only optional.So, there are 12 legal variants (including textured and non-textured models) of the same building which all must be classified as LoD2 (see Figure 4).

Severely restricted model for building's interior components
It has already been mentioned that especially the definition of LoD4 causes problems in the actual usage of CityGML.The actual data model implies that interior components of a building have only one (geometrically exact) representation, and that the building's interior can only be represented if simultaneously the exterior shell is represented with highest semantic complexity and geometric accuracy.Both implications severely restrict the usage of CityGML.Especially in the application range of indoor navigation, multiple representations of rooms and their movable and non-movable inventory are requested (Domínguez et al. 2011).Other application areas, where detailed information on the building's internal structure has a higher priority than a geometrically exact representation of the exterior shell, are fire fighting, emergency operations or estimations of energy performance.In all these cases it would be beneficial to combine a rough (LoD1 or LoD2) model of the exterior shell with a detailed interior model (see Figure 5), which currently is not supported by CityGML.The lack of significant metadata especially concerns LoD1, where the majority of currently available models are assigned to.Currently, there is no formal way to specify which part of the real building (e. g. footprint or roof edge) was used as basis for the extrusion, on which vertical height the lower extrusion surface is located, and up to which height (e.g.eaves or ridge height) the volume is extruded.

NEW CITYGML LOD CONCEPT
The analysis of the current CityGML 2.0 LoD concept revealed a number of deficits, which partly could only be handled by major modifications and extensions of the existing data model.Such modifications principally hamper or inhibit an easy migration of existing CityGML 2.0 models, which would negatively influence the acceptance of the standard.Therefore, for the new concept two side conditions were kept in mind:  Existing CityGML 2.0 models should be easily transformable into the new model, e. g. by means of a simple XSLT transformation.In particular, no application of complex geometric algorithms should be necessary, provided that the initial data have a quality suited for the chosen new LoD.
 The current levels LoD0 -LoD4 can be embedded into the new concept.
The Building module is the most important and most frequently used thematic area of CityGML.The new LoD concept therefore is first of all defined for this part of the standard.The adaptation of this concept to other thematic areas will be performed in a second step and is not topic of this paper.However, while defining the building LoDs it was kept in mind to develop a modular concept, separating general features (e.g. the quality of the geometrical representation of a spatially related object) from specific ones (e.g. a semantic decomposition or a distinction between "interior" and "exterior").This will strongly facilitate the transfer of the Building LoD concept to other thematic areas.

General features of the new Building LoD concept
Central idea of the new Building LoD concept is to split the five existing levels into "Geometric Levels of Detail" (GLoD) and "Semantic Levels of Detail" (SLoD).The GLoD characterises the geometric representation of an object and the quality of geometric conformance between model and real object.The SLoD specifies to which degree a complex object is semantically decomposed and structured.GLoD and SLoD are specified separately for the exterior shell (GLoD-E/SLoD-E) and the interior components (GLoD-I/SLoD-I) of a building.
The central advantage of the new concept is that the actual geometrical and semantical content of a CityObject can be explicitly represented by suited metadata (see chapter 4.3).In existing CityGML, an application has to scan the complete XML-representation of an object in order to check the actually used properties, which is very much simplified here.Furthermore, in the new concept the features corresponding to the building's exterior shall have one geometry property less, which simplifies the data model for all cases the building interior is not important.
The SLoD-E (Table 1) specifies whether an object of type Building or BuildingPart refers to other features semantically decomposing the exterior shell.These features are either BuildingInstallations or AbstractBoundarySurfaces (WallSurface, RoofSurface, GroundSurface, OuterFloor-Surface, OuterCeilingSurface or ClosureSurface), which in the highest SLoD-E refer to AbstractOpenings (Doors and Windows).The GLoD-E (Table 2) addresses the geometric representation of a Building / BuildingPart and the geometric accuracy of this representation.Figure 6 shows a building with exact geometric representation (GLoD-E3) and four different levels of semantic representation as an example.This contribution has been peer-reviewed.The double-blind peer-review was conducted on the basis of the full paper.55 generalized geometrical representation of internal components or the combination of a detailed internal model with a rough external model, which also cannot be represented with CityGML 2.0, is sufficient.

Integration of the existing LoD concept into the new proposal
Each LoD is characterised by the four values SLoD-E, GLoD-E, SLoD-I and GLoD-I in the new concept.Because each component of this LoD vector may take four discrete values, 256 different LoDs are representable in principle.Not all of these are really meaningful.For the strongly generalised representations of GLoD-0 and GLoD-1, the provision on an additional semantic structuring of a Building or a Room object seems not to be necessary.The semantic meaning of e. g. the bottom surface (ground surface) or the top surface (roof) of a GLoD-E1 extrusion is implicitly obvious.

Forbidden Table 5: Embedding of old LoDs into the new concept
There remain 10 meaningful combinations of GLoD and SLoD for both the exterior and interior models and the existing classification LoD0 -LoD4 can be mapped into the new schema (see Table 5).
Table 5 shows that for modelling the exterior parts of a building the new LoD concept goes very little beyond the capabilities of CityGML 2.0.Due to the separate indication of a SLoD, the former LoDs 2 and 3 are split into 3 resp.4 variants.The only new model variant is GLoD-E2/SLoD-E3, supporting building models with generalised geometry, but explicit representation of doors and windows in the building's exterior shell.This new modelling variant may be very attractive for the application area "energy demand estimation".Here, it is not necessary to represent every geometrical detail of an outer wall or roof surface, a generalized representation corresponding to GLOD-2 will be sufficient.However, size, structure and technical parameters of doors and windows are highly important for estimating the heating demand, which calls for an explicit representation of these objects.
For the representation of interior building components, the situation is different.The new model offers a lot of modelling variants which cannot be realized in CityGML 2.0 and which might be beneficial for certain application scenarios.
The next question to be discussed concerns the combination of exterior and interior models.Table 6 shows the 110 possible combinations of exterior and interior Levels of Detail.The proposal does not imply any restrictions on the possible combinations of exterior and interior GLoD/SLoD, with the exception that Buildings / BuildingParts without any geometric modelling of the exterior shell are not feasible.In Table 6 also a natural extension of the CityGML 2.0 LoD values is indicated.
We propose to use decimal numbers with one decimal place, where (except of LoD4) the digit before the decimal point specifies the exterior GLoD and the digit after the decimal point the interior GLoD.Though this classification does not regard the semantic complexity, it may in some cases be sufficient to indicate the model complexity.This contribution has been peer-reviewed.The double-blind peer-review was conducted on the basis of the full paper.56

UML model
An alternative conceptual model for CityGML 2.0 has been developed and realized as UML model.Besides the implementation of the new LoD concept discussed earlier, it contains also a number of modifications and extensions, reflecting some of the deficits mentioned in chapter 3.In particular, this concerns  A restructuring of the geometric properties in all feature classes;  The addition of metadata in different classes;  Generalisation of the geometric representation in GLoD-0;  Renaming of abstract classes for conformance with general GML naming rules.
Figure 7 shows the general structure of the model in form of the available feature classes and their relations, which is identical to CityGML 2.0.
The detailed UML model for the abstract super class AbstractBuilding is shown in Figure 9. Instead of the 17 geometrically properties of CityGML 2.0, there are only four complex properties, integrating the geometric properties of GLoD-E0 to GLoD-E3.The GLoD-E0 geometry (either a 2D, a 3D horizontal or a 2.5D MultiSurface) and the GLoD-E1 geometry (a vertical extrusion Solid) are enhanced with metadata, optionally allowing the specification of horizontal and vertical geometry references.The horizontal reference indicates which part of the real object was used for the model geometry, while the vertical references provide information on the semantic meaning of the vertical position of the geometry.
The proposal here uses ideas of the INSPIRE basic 3D data format Building3D for buildings (INSPIRE 2013).

«featureType» Building
AbstractSite Explicit information on the supported GLoDs and SLoDs is provided by the attributes interiorLOD and exteriorLOD of the Building class.Both attributes can be specified multiple times, so every GLoD/SLoD combination which is supported by the model can be explicitly listed.According to the fact that the exterior shell must be modelled geometrically, exteriorLOD must be specified at least once.Figure 13 and Figure 14 show two examples of a building with a GLoD-E1 exterior shell (vertical extrusion), but two different representations of the building's interior.In Figure 13 rooms are represented as GLoD-I0 surfaces and in Figure 14 as GLoD-I1 solids.Both modelling variants are interesting for indoor navigation applications.Here, neither the building exterior nor the building interior have to be represented with highest geometrical accuracy, but it is important to identify rooms and to extract the topological room structure.The next step in extending the existing CityGML standard will be to transfer the Building LoD concept to other CityGML modules.For the geometric LoD this will not cause major problems, only the definition of geometric representations assigned to certain levels needs to be adapted.
Although the proposal already resolves a lot of deficits of the existing CityGML standard, still a lot of improvements are needed.This especially concerns the characterisation of modelling quality and complexity by means of metadata.For GLoD greater 1, the actual proposal does not provide explicit information on the structural complexity of the geometry model (e.g. the availability of volumetric information), the existence of a terrain intersection curve, or the availability and semantic meaning of appearance information.Quantitative information on the accuracy of the geometrical representation is missing as well.
The proposed data model is more flexible than the existing standard, but there are still some relevant applications which are not adequately supported.Building models with mixed geometric LoD, where e. g. the roof surface has a higher accuracy than the building facade, cannot be handled.The proposed Building model and the corresponding LoD concept neither support volumetric building elements like walls, beams or roofs, nor geometrically and semantically represented holes (Openings) in building elements, which may be filled with Door or Window objects.

Figure 3 :
Figure 3: Geometric and semantic Level of Detail for buildings in CityGML 2.0 (source KIT)

Figure 5 :
Figure 5: Building with detailed interior structure and an extrusion as exterior shell (source KIT) 3.4 Missing metadata characterising different LoD One deficiency of the actual CityGML data model is the almost complete lack of metadata complementing the LoD information.The Building class contains no explicit property indicating an application, which LoDs are actually supported.The application in fact has to check a lot of properties of Building and other classes referenced by Building, whether their names contain the text lod0, lod1, ….If an object uses properties of more than one LoD or features referenced by Building use different lodx properties, it is not clear which combinations are feasible.

Figure 6 :
Figure 6: Example of different SLoD-E The SLoD-I (Table 3) has the same role as SLoD-E for the feature class Room.It specifies whether a Room refers to AbstractBoundarySurfaces (InteriorWallSurface, FloorSurface, CeilingSurface, ClosureSurface), whether IntBuilding-Installations and BuildingFurniture objects are available, and whether AbstractBoundarySurfaces are related to AbstractOpenings.GLoD-I (Table4) describes the geometric accuracy of a Room and its inventory.This is the main difference between old and new concept.While CityGML 2.0 only regards one representation of the internal building components with highest geometrical complexity, now different representations reflecting specific application demands are possible.Chapter 5 will show some examples where a

Figure 7 :
Figure 7: General structure of the CityGML Building module

Figure 8 :
Figure 8: Metadata of Building class

Figure 9 :
Figure 9: Proposal for class AbstractBuilding The UML representation of the Room class (Figure 11) is similar to AbstractBuilding.With exception of a missing TerrainIntersectionCurve, the data types BuildingLODx-Representation and RoomLODxRepresentation are identical.

Figure 11 :
Figure 11: Room class 5. EXAMPLES In this paragraph a number of examples demonstrating the capabilities of the proposed data model and corresponding use cases are shown.The geometrically most generalised version of a building model is show in Figure 12, where both the building footprint and the footprints of the rooms are represented by horizontal surfaces.By texturing the surfaces representing rooms with the corresponding 2D architectural drawings, a 3D architectural drawing model has been generated.Such a representation might help people being not accustomed in interpreting complex 2D architectural drawings in understanding the 3D structure of a planned new building.

Figure 12 :
Figure 12: Building exterior and interior as horizontal textured surfaces

Figure 15 :
Figure 15: Representation of the exterior shell with generalised geometry, wall and roof surfaces (GLoD-E2/SLoD-E2), and representation of rooms as GLoD-I1 solids CityGML models with this level of geometrical and semantical complexity are suited for rough estimation of a building's heating energy demand.The GLOD-2 representation of the exterior shell enables the estimation of energy losses and gains, while the volumetric representation of rooms, combined with a

Figure 16 :
Figure 16: Representation of the exterior shell with generalised geometry, wall and roof surfaces (GLoD-E2/SLoD-E2), and representation of rooms with highest level of detail (GLoD-I3/SLoD-I3)Finally, the most detailed variant of the building model conforming the CityGML LoD4, is shown in Figure17.Models of such a high quality normally are only necessary for applications like architectural design, where the user of the virtual 3D city model needs to easily recognize a specific building from different interior and exterior viewpoints.

Figure 17 :
Figure 17: Building model with highest level of detail 6. CONCLUSION AND OUTLOOK The Level of Detail concept of CityGML is an established and frequently used tool for representing city objects with varying geometric and semantic complexity, supporting the scaling of city models with respect to the user's needs.Nevertheless, it has been shown that the current concept is deficient in relation to applications and verifiability.Main shortcomings are the lack of metadata, the missing distinction between interior and exterior representation and the arbitrary assignment of one LoD concept for almost all CityGML modules.In this paper an enhanced Level of Detail concept for CityGML and its implementation by an UML model has been developed.The new concept differentiates between a Geometric Level of Detail (GLoD) and a Semantic Level of Detail (SLoD) for both the exterior (-E) and interior (-I) components of a building.Proposals for the four new classification schemata (GLoD-E, SLoD-E, GLoD-I, SLoD-I), their feasible combinations and the embedding of the current CityGML LoD concept into the new one were presented.The main advantages of the new concept are:  A substantially higher informative value for the Level of Detail, due to the separate specification of geometric and semantic LoDs. A broadening of the CityGML capabilities to model the building's interior and to combine interior and exterior models of different geometric and semantic complexity.

LoD greater than 30 m LoD between 20-30 m LoD between 10-10 m LoD less than 10 m 14
This contribution has been peer-reviewed.The double-blind peer-review was conducted on the basis of the full paper.52

Table 3 :
Levels of Detail for the semantic structuring of Room

Table 6 :
Combination of interior and exterior models, qualified by an extension of the CityGML LoD.The colour schema of Table 5 is used.ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume II-2/W1, ISPRS 8th 3DGeoInfo Conference & WG II/2 Workshop, 27 -29 November 2013, Istanbul, Turkey