REVISITING THE CONCEPT OF LEVEL OF DETAIL IN 3D CITY MODELLING

: This review paper discusses the concept of level of detail in 3D city modelling, and is a ﬁrst step towards a foundation for a standardised deﬁnition. As an introduction, a few level of detail speciﬁcations, outlooks and approaches are given from the industry. The paper analyses the general uncertainties and shortcomings around the concept of level of detail in 3D city modelling such as ordinality and inconsistencies, and identiﬁes factors that constitute a speciﬁc level of detail. The paper proposes a framework for a new consistent LoD deﬁnition which would consolidate present and future LoD paradigms, gives an example of an LoD speciﬁcation, discusses open questions such as the contexts for which 3D city models are used in practice, and gives prospects for a future quantiﬁcation and sorting of levels of detail.


INTRODUCTION
Level of detail (LoD), pioneered by Clark (1976), is one of the key terms used in GIS and 3D city modelling to describe the complexity of the representation of a geographic object.The concept of LoD has been borrowed from computer graphics (Luebke et al., 2003), where the aim is to reduce the geometrical complexity of an object for visualisation performance, and LoDs are errorbounded simplified versions of a model that can be displayed more quickly (Erikson et al., 2001).The main question is how to represent an object without the user noticing its degraded geometric quality.This is both a technical challenge and a cognitive one (C ¸öltekin and Reichenbacher, 2011).
Considering the strong foundation in computer graphics, in 3D city modelling the concept is extended with several aspects which we identify in this paper.
First, we consider that the motivation of having LoDs in 3D city modelling is two-fold, rather than simply reducing the complexity of object's geometry for visualisation purposes (dynamic rendering) and balancing between the computational aspects and aesthetic wishes: 1. LoD as an acquisition-model and product specification for a client and data provider (e.g. a municipality requesting a 3D city model with a specific level of detail for buildings, and a company marketing its product range with the LoD designation), and 2. LoD as a generalisation step specification (e.g.generalisation from finer to a coarser LoD), i.e. reduction of the complexity if one LoD is available.This should not be confused with the visualisation (on-the-fly) process as in computer graphics, and is analogous to cartographic generalisation (e.g.producing a 1:20k map from 1:10k).
Second, on top of the geometry as in computer graphics, models in 3D city modelling are complemented with semantical properties, application considerations, acquisition method (and accuracy), and a conceptual separation between exterior and interior geometry.For instance, LOD3 in CityGML (Open Geospatial Consortium, 2012), besides specifying fine geometric details, implies a precise acquisition method such as photogrammetry with high-resolution imagery, rich semantical classes, and a selection of suitable applications for which this LoD is required.
Third, LoDs in 3D city modelling are more related to modelling concerning multiple application requirements, but in computer graphics are used specifically for facilitating visualisation.While choosing a level of detail in computer graphics, several factors considering the scene are taken into account such as the distance to the observer, while in 3D city modelling practitioners usually refer to the joint LoD of all objects regardless of where are they positioned and how are visualised in a scene.
Further, the concept of level of detail in 3D city modelling rarely consider computer graphics concepts, such as mesh simplification and specification of the number of polygons per LoD, and in practice, these are never specified.To conclude, the concept of LoD in 3D city modelling currently covers the wider but separate workflow than in computer graphics: from acquisition and modelling towards storage and query, but in the end the models are visualised according to computer graphics techniques, which are not covered in 3D city modelling and belong to the computer science domain.
Despite its significance, the term LoD has not been clarified and defined enough in 3D city modelling as shown in Section 2. For instance, although there are widely used standards for 3D city models that partially define LoD, such as CityGML (Open Geospatial Consortium, 2012) the concept of level of detail varies in different approaches for 3D city modelling and a common approach is not widely standardised, and there is no consensus on LoD: it is not unambiguous what an LoD is in 3D city modelling, nor is there a single and widely-accepted LoD paradigm in 3D city modelling.The philosophy and the criteria that drive the LoD in 3D city modelling are usually vague and undefined, and inconsistent at best.Consequently, guidelines and technical specifications such as accuracy and precision requirements are not commonly addressed for a certain LoD, and if they are, this is often overlooked.
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 Considering the number of LoD term occurrences in GIS/3D city modelling publications, and the amount of LOD related publications in computer graphics, it is surprising that in 3D city modelling this term has not been researched and defined throughly.In order to tackle this, there are continuous and ongoing attempts to improve the concept of level of detail in 3D city modelling, such as its revamping in CityGML for the upcoming version 3.0.
We believe that currently there are several important aspects and questions which amplify the confusion around the term of level of detail and should be taken into consideration, for instance: what constitutes a level of detail, and how to define it?What drives the levels of detail?What is the difference between level of detail and scale?How to sort multiple LoDs, and is there a way to quantify them?And should there be constraints and strict specifications for each LoD?
The aim of this paper is to structure the existing ideas, uses and definitions of levels of detail in 3D city modelling in order to obtain a more formal and standardised definition in future work which will, we hope, help define the LoD concept in a future standard such as CityGML, and serve as an basis for proprietary standards.
It is composed in three parts: (1) in Section 2 we analyse and evaluate the existing approaches and identify their disadvantages which should be overcome, and (2) in Section 3 determine the considerations and key factors that should be a basis for the formal LoD definition, and finally (3) in Section 4 propose a framework for a new definition with an example of a simple LoD specification, and discusses how to denominate and compare different levels of detail.Section 5 contains conclusions and prospects for future work.

ANALYSIS OF VARIOUS APPROACHES OF LEVEL OF DETAIL IN 3D CITY MODELLING
This section gives an overview of LoD concepts found in four different standards or products: the CityGML standard (Section 2.1), Blom3D product range, the NAVTEQ's datasets for navigational devices, and models produced by Vertex Modelling (Section 2.2).Further, internal guidelines and experiences from three companies are given (Section 2.3).The selection of these concepts was motivated by their wide range, different applications and targeted users.Each standard is described with its official definition if available, and a critical overview is given in Section 2.4.

CityGML
CityGML is a common information model and XML-based encoding for the representation, storage, and exchange of digital 3D city and landscape models.It is arguably the most prominent standard in 3D city modelling.CityGML provides a standard model and mechanism for describing 3D objects with respect to their geometry, topology, semantics and appearance, and defines five different LoDs to reflect independent data collection processes with differing application requirements.Included are also generalisation hierarchies between thematic classes, aggregations, relations between objects, and spatial properties (Kolbe, n.d.).
The CityGML standard (Open Geospatial Consortium, 2012) describes its LoD approach as being required to reflect independent data collection processes with differing application requirements, and facilitating efficient visualisation and data analysis.The standard also defines each level of detail with regard to buildings and other objects, e.g."a building in LOD2 has differentiated roof structures and thematically differentiated boundary surfaces." An example of a house represented in CityGML with different LoDs is shown in Fig. 1, adopted from Häfele (2011).A few observations can be made from the standard and practical usage of CityGML data: • Although LOD0 serves various 3D application requirements (e.g.hydrological modelling), it cannot be considered as a "true" 3D city model from a formal perspective, since it is a boundary representation in 2D with a height as an attribute.If considering LOD0 as 3D, more distinction should be made in applications that do need true 3D (LOD1-LOD3) and others that can work with LOD0.
• The structural complexity of a 3D model with respect to geometry, topology, semantics, and appearance is not covered by the current CityGML LoD concept because LoDs in CityGML are neither driven by geometry nor semantics only, and the geometric and semantic hierarchies are separated (Nagel, 2011).Each LoD has a minimum level of semantic information, which is specified by the UML data models and the normative conformance requirements.However, there is no normative requirement to have more semantic entities beyond that minimum level.
• Neglecting minor improvements in the exterior, LOD3 is in practice in most of the cases basically an LOD2 with openings (e.g.windows and doors).
• LOD4 is an LOD3 upgraded with interior.The LoD of external geometry and the semantics remain equal.
• There is not a robust link between LoDs in the standard and the implementation.For instance, in LOD3 when adding windows to a wall, the definition of the wall cannot be reused from the LOD2.
• The levels of details for features other than buildings, such as trees and roads, are not clearly defined.
Finally, as Fan and Meng (2012)  This contribution has been peer-reviewed.The double-blind peer-review was conducted on the basis of the full paper.64

Proprietary standards
BLOM is a Geomatics company from Norway.BLOM3D TM is the product name of its archive 3D models, which detail more than 20 million buildings in 340 urban models.The BLOM3D TM models have four different LoDs, ranging from simple wire frames to fully textured models.The product and LoD are described in BLOM's white paper (Blom ASA, 2011).
The descriptions of LoDs are listed for an overview: The second considered proprietary standard is the guideline from NAVTEQ, an American company that provides geo-information data for navigational products, and since they are specifically suited for navigation, they are different from the formats and standards presented so far.
Their products relevant to this research are (a) 3D city models, as untextured polygons outlining the footprint of a building, with basic rooftop shape and a building height attribute, (b) enhanced 3D City Models, whose improvement over the above product is that they contain texture, which improves consumer guidance experience by making relevant buildings more realistic, and (c) 3D Landmarks are photorealistic models of prominent landmarks such as a monument, building or other structure which can improve user orientation and sense of place in unfamiliar or complex situations (NAVTEQ, 2011).
The first two products have one LoD respectively.However, together they can be seen as one product with two LoDs distinguished only by texture.
Landmarks have a finer geometry, and photorealistic textures.Each structure is delivered in two LoDs, which are distinguished by their varying polygon count (up to 500, and 1000, respectively).There is not a clear boundary between these levels, since one object in light resolution can contain more polygons than another object in a standard resolution.
The Figure 3 shows an example of a combination of the products Enhanced 3D City Model, and 3D Landmarks.This is essentially a city model with a different combination of LoDs: the buildings have textures from a generic library, while landmarks such as churches have a finer geometry and a texture derived from photographs of the actual object.Summing up the products listed above, we can conclude that NAVTEQ offers four levels of detail for their 3D city modelling products.The difference to the previous paradigms is that not every LoD is applicable to every structure in the model.Landmarks are never represented in a low LoD, while buildings and other regular objects are never represented by photorealistic textures or fine geometry as landmarks.
Another interesting example is the product classification of Vertex Modelling (http://www.vertexmodelling.co.uk/), a UK based company.They offer 3D city models in four LoDs which specifications are extensible to the client's needs.All four LoDs are produced with photogrammetric mapping, and they are differentiated by the wealth of details.The level 1 contains building shapes only, while level 2 (Fig. 4a) contains major roof details, and road layouts and basic land use in addition to buildings.The LoD3 (Fig. 4b) adds other roof structures, pavements, finer land use and roads, green spaces, tracks, etc.The finest level (LoD4) include facade details, but no textures by default.

Internal standards
Many companies in the geospatial industry have their own internal standards for 3D city modelling or tailor it according to the customer's needs.Although these are not open standards and are variable, a couple of examples will be briefly mentioned in the continuation to support the claim that the LoD specifications are diverse, and present public standards may not satisfy all the producers and clients.The information was acquired by direct inquiry.
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.65 The German company Hansa Luftbild (http://www.hansaluftbild.de/)acquires data with stereo restitution of aerial images or LiDAR point clouds, and generally differ between four LoDs (0-3): (0) DTM with texture (orthophoto or true orthophoto), ( 1): simple block model with or without roof geometries, (2) detailed building model with complex textures for roofs and walls and photographic textures, (3) detailed architecture model with precise design for roofs and walls with photographic textures and virtual materials (e.g. for vegetation).The models can be textured, but that does not affect the LoD.COWI (http://www.cowi.com/),headquartered in Denmark, let clients define the LoD in their specifications.In most cases the clients refer to CityGML LoD specifications, but their experience is that the CityGML specifications are very general and not enough in most cases, especially in data higher than LoD2.Therefore, they use an "intermediary" level of detail LoD2+, which is LoD2 including superstructures like dormers and chimneys (e.g.bigger 3 sq.m or higher than 1 m).Texturing is handled separately and it is not linked with the LoD.All LoDs can be textured.
Geofoto from Croatia (http://www.geofoto.hr/)as well uses variable guidelines when producing 3D models, but as documented by Franić et al. (2009) and Novaković (2011), the 3D city models made for physical models are interesting: in a single LoD, the building's base is defined as untextured CityGML's LoD1, while their roof structure and all of the landmarks are modelled as CityGML's LoD3 with texture (true orthophoto 10 cm), see Fig. 5 for an example.

Analysis of given LoD approaches, their uncertainties and shortcomings
From this analysis, discussing the topic with other researchers and practitioners, and using different datasets, we identify the following nine major uncertainties and shortcomings of the term and concept of level of detail in 3D city modelling.We list and describe them in this section for the benefit of discussing the considerations for a formal LoD definition, and our proposed framework for a definition of level of detail (Sections 3 and 4).

Multiple paradigms with different driving factors
As shown in the previous section, there is a number of different standards and manufacturer guidelines with different requirements for each level of detail.
Among researchers and practitioners in 3D city modelling, the CityGML level of detail guideline is considered as a lingua franca of LoD in 3D city modelling, so it is not uncommon to read about LOD3 products, even if the product is not delivered in the CityGML format and does not have any relation to it.Having multiple paradigms where different concepts are given focus, means having a different nomination and meaning (e.g.CityGML LOD3 is not equal to Blom3D's LOD3) which may lead to confusion and inconsistency.

Intermediary levels of detail and application-specific requirement
The most important observation relevant to use-cases is that the presented LoD paradigms show that in 3D city modelling there is not a uniform approach to what defines an LoD, and what drives their definition.The levels are generated regardless of the application or the context, e.g. they are the same whether the 3D city model is used for estimating the solar potential or for urbanism applications.
In some projects or products, companies or users may refer to specific and customised levels of detail which are not covered by any standard or manufacturer guideline in order to meet the requirement of an application, for instance LOD2 with air conditioning units and fences of balconies.
These are not standardised, and are essentially new levels of detail.The application of a 3D city model and the required LoD should have more attention in order to avoid having special and vague LoD specifications.
3. Single object standards, and lack of generalisation specification for the generation of lower levels of detail Levels of detail lower (i.e. with less detail) than the finest LoD can be generated either by generalisation or independent modelling of each LoD.However, hardly any current LoD paradigm supports that objects at lower LoD constitute of object-elements of higher levels of detail, and do not offer generalisation rules in their specifications.If this is the case, in practice it is used rarely.
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.66 Another relevant observation is that currently LoDs are defined per object (object-oriented), e.g.LOD2 of a road.Shift from single to multiple objects (aggregation), and their levels of detail, are not defined.A desired example would be houses aggregating to a residential block, and their level of detail.

Concentration of the standards on buildings
In practice, the most prominent type of object found in 3D city models are buildings, and consequentially multiple LODs are mainly defined for buildings, although the CityGML does support multi-levels for other classes such as bridges.However, the standard still needs elaboration for these other classes, underpinned with more experiences from practice (Tamminga et al., 2013).

LoD designation and ordinality of the level of measurement
Nomenclature-wise, the presented LoDs paradigms have in common that the steps (names) of the levels are on an ordinal scale (LOD1, LOD2, etc), and not on a ratio or interval scale.Therefore it means that in such paradigms there is no quantitative measure of the properties of levels of detail, for instance of the amount or quality of details, and no relative degree of difference between them, e.g. that LOD1 * 3 = LOD3, as it would be in an interval or ratio scale.
In terms of the amount of details (whether exterior geometry, texture or interior) LoDs are a monotonic increasing function that increases as the amount of detail increases, i.e.LoD(n)>LoD(n-1) for all n, however, this cannot be quantified at the moment.

Lack of quality requirements for the geometry
It is intuitive to expect that models of lower LoD are acquired with less accurate acquisition methods, than those of higher LoD.However, LoDs often do not specify the quality of the geometric data, or constraints such as it would be clear if a model with fine geometry, acquired with less precise acquisition methods, is still considered as a fine LoD.
CityGML has an accuracy requirement per each LoD, but this is often overlooked because in many cases it is not relevant.In some real-life cases, the geometry of the CityGML LOD0 can be more accurate than the LOD2, which is counterintuitive, since LOD2 could be derived with a different and less accurate acquisition technique than footprints.
Other quality measures such as temporal accuracy, thematic accuracy, and completeness (Lemmens, 2011) are not taken into account at all.

Terminology ambiguity
The terms scale and level of detail are in general used interchangeably without clear meaning, leading to confusion.Their terminology is often abused and the terms are deliberately used.Further, it is not clear what a detail represents.8. Mixing 2.5D/3D data in the same concept CityGML LOD0 is 2.5D, which is not a "full" 3D model, but is still considered a level of detail.The different geometric dimensionality in the same concept may lead to inconsistencies, especially since 2.5D and 3D may have their own levels of detail which can hardly be compared in the same concept.

Semantic properties and hierarchy, and their level of detail
The semantics are an important property in the concept of level of detail and 3D city modelling in general, and the level of detail of the semantical classes is an important quality measure of the data.Depending on the application domain, semantics are needed to perform proper analyses (Stadler and Kolbe, 2007), however, they are often overshadowed by the geometry, and are not given enough meaning in the standards.

CONSIDERATION FOR A FORMAL LOD DEFINITION
This section discusses the main considerations which should be taken into account while defining the concept of level of detail.
First in Section 3.1 we identify and analyse the main driving components of levels of detail that are in the focus of the standards presented in Section 2. Section 3.2 lists and describes all factors that we consider forming the relevant properties of a level of detail.The last section (3.3) briefly discusses their relation.

Components and sub-levels of detail as driving factors of current approaches
The interrelation between the levels in all paradigms is of interest to note as well.This section analyses the given LoD approaches in 3D city modelling according to different variables which will serve as input for the improved and standardised definition of level of detail in our research.
We observe that the three most prominent components in the presented LoD approaches are: • Exterior geometry, or simply: exterior • Interior geometry, or furniture (not to be confused with city furniture) • (External) appearance, e.g.texture Their relation and inclusion (position) varies between the presented paradigms.By isolating each component above, we can observe that the LoDs are made of different combinations of the components, and that the LoDs are driven by them.We can define these as sub-levels of detail (SLoD).This should be seen as a decomposition of an LoD, rather than its hierarchy.Two examples are given: CityGML and BLOM3D, and visually backed up with the Fig. 6.
CityGML (Fig. 6a) has five LoDs.The LoDs from LoD0 until LoD3 are distinguished by the number and quality of details in the exterior geometry, i.e. there is a progressive increase in exterior detail.The highest LoD, LoD4, is basically an LoD3 with added interior, meaning that LoD3 and LoD4 share the same LoD with respect to the exterior.Considering the interior, all LoDs except the LoD4 share the same level of detail of the interior-i.e.none.
• One SLoD for the interior: 1 (LoD4) since LoD0, LoD1, LoD2, LoD3 do not contain any interior (we designate such as 0).Notice that the first SLoD in case of the exterior is 1, while the first SLoD for the (empty) interior variable is 0. This is because the first SLoD for the interior does not contain any detail, which is contrary to the CityGML definition where the LoD0 is not "empty".

ISPRS
A similar reasoning can be applied to the case for BLOM3D, but in this case with the texture instead of the interior.The BLOM's approach has four LoDs, however, the last three share the same exterior geometry, meaning that in such case there are only two distinctive LoDs representing the exterior.The last three levels (LoD2, LoD3, LoD4) are distinguished by the detail of their texture.Therefore BLOM3D is first exterior-driven, and then texture-driven.
It is important to note that in all the presented paradigms, the amount and quality of details increase or stay the same with the level of detail, regardless of the variable involved.This might seem obvious, but there is not any mixing of different SLoDs, as having a coarse exterior and fine interior, which can also be seen as a constraint (e.g. the interior in CityGML requires minimum the exterior geometry found in LoD3).
Another observation that we can make, is that the SLoDs never progress together.In the CityGML case, first the details of the exterior increase, and finally the interior is added without improving the quality or detail of the exterior, i.e. the details of the exterior and the interior do not progress together with respect to the LoDs.Such thought is shown in the Figure 7 for the case of BLOM.The first two LoDs see the increase of the exterior detail without any texture involved, while the texture progresses only after the highest SLoD of the exterior.Afterwards, there is no improvement in the detail with respect to the exterior.The red dots denote the LoDs.
Since the progressiveness of sub-LoDs are not related and progress separately, this relation could be seen as "perpendicular", as visible in Figure 6.
When considering the three NAVTEQ products as one, a similar analyses can be made, but with different results.This is shown in Figure 8.The buildings which are by navigational standards not of special interest (e.g.residential objects) are stored in two LoDs which have the same exterior detail but are distinguished by texture (Fig. 8a).The landmarks have both a finer exterior and texture, and their SLoDs progress together, hence this advancement could be seen as also object class-driven.It is clear that the LoDs for regular objects and landmarks are separated (Fig. 8b).This is also interesting to note as their product visualisations include a mixture of different LoDs, and the LoDs never overlap for the two classes of structures.The last referenced proprietary standard, by Vertex Modelling, does not feature the interior, but it is significant to note that is driven only by the wealth of details, similarly as the internal standards listed in Section 2.3.

Identified factors that form the properties of a level of detail
Choosing an optimal level of detail for an application is about balancing the selection of various factors for both the user and the producer for economical, functional and computational reasons.By finding the ingredients of the quality of a model, it is possible to list several variables that may constitute the level of detail.We find these factors as the leading consideration in defining an LoD.
By comparing different LoD paradigms, and examining different use-cases, apart from the driving components presented in the previous section, we have identified the following factors that form a classification basis (nomination) for level of detail and are driven by them.These should not be confused with SLoDs, rather as properties (or metadata) of a level of detail.
• The presence of certain object classes (city objects), such as bridges, roads and buildings with various properties.For instance, an LoD may be specified as including all residential buildings with a footprint larger than 50 sq.m, and roads wider than 3 m.This property is binary (the city object is included or not).
• The presence and the geometrical complexity of geometric details that are a part of city objects (e.g.roof structure, roof overhanging parts, balconies, tables in the interior geometry).These two are related, but should not be confused.The presence of details is a binary property (the chimney on the roof may be present or not), while the geometrical complexity may be defined in various ways such as the number of vertices or polygons, or the geometric dimension.For instance, a tree in two datasets may be represented as a line (1D), and a fine 3D tree with branches and leaves.
• Texture type, quality and source, and other appearance data such as the dominant colour of a wall.
• Positional accuracy of the geometry (e.g. standard deviation, or more loose-acquisition method).
• Depth and granularity of the semantic hierarchy (e.g.number of classes), i.e. quality of semantical details.
• Other attribute data assigned to a city object and its details, such as material of a structure, vegetation type, walkability of the roof.These attributes are directly related to the application and use-case.
We consider the listed factors important metadata and quality measures of a level of detail, and should be treated in the way to allow their different values and combinations to be considered as different levels of detail.

Constraints and measures for a level of detail
Levels of detail in both computer graphics and 3D city modelling are expressed as a monotonic progressive function, where subsequent levels are of higher quality than the preceding.Being flexible with the terms, higher LoDs are considered better, but the two key questions are what means better, and by how much?
Another aspect to look into is that the presented paradigms are all one-"dimensional".Considering the sub LoDs and factors presented in the previous subsections, LoDs can be decomposed in separate functions and measures, allowing the multi-"dimensionality" of the progressiveness of LoDs.
However, not all of them can be related together in a straightforward manner.The positional accuracy is a linear value which for instance can be represented as standard deviation or a ordinal quality measure (good, very good).Conversely, while the amount of details is intuitive, it is not straightforward to quantify it.
On the other hand, while the factors are independent, they are in practice interrelated (e.g.there is no use of a very detailed model but of poor accuracy), so their functions should be consistent by progressing together, i.e. defining constraints for each level of detail.These constraints should be robust, but should also retain flexibility by allowing users to build different combinations of customised LoDs.

OUR PROPOSED FRAMEWORK FOR A DEFINITION OF LEVEL OF DETAIL
This section deals with proposing a framework for a definition of a level of detail.The main questions arising from the previous sections that should be considered for this framework are: • What is a level of detail, and how can all present and future LoD paradigms (standards) in 3D city modelling be covered by one concept (Section 4.1), and how this can be realised for industrial purposes (Section 4.2)?
• How to denote, combine and sort different LoDs in one range (Section 4.3)?

Towards the definition the level of detail
Computer graphics researchers Luebke et al. (2003) state that level of detail is used to improve the performance and quality of three-dimensional (3D) visualisation in computer graphics.Their definition is that level of detail is "the real-time 3D computer graphics technique in which a complex object is represented at various resolutions and the most appropriate representation chosen in real time in order to create a trade-off between image fidelity and frame rate.Here, the term level of detail is often used interchangeably to refer to both the graphics technique and a single representation of an object." However, a definition of level of detail has been almost nonexisting in literature related to 3D city modelling.Usually, where the topic is tackled, researchers either relate to LoDs as seen from the computer graphics perspective, or assume common knowledge of the term.Meng and Forberg (2007); Fan et al. (2011) detect the ambiguity that level of detail is uniformly defined as a number of milestones along the scale space when taking the scale space of 3D buildings as a linear continuum, but there are no agreed LoDs for 3D buildings because LoD frameworks are normally established according to the spatial accuracy, the semantic precision, and the complexity of buildings required for different applications.
In this section we discuss the framework of the concept of the LoD in 3D city modelling that serve as a basis towards its definition.
The factors presented in section 3.2 imply that levels of detail are a measure of completeness of data, and the level of measure of their quality.There is certainly a connection between the three, but LoDs are not equivalent to level of completeness and level of quality.
We define a level of detail of a model as a quality measure of the model which has a minimum and sufficient and sensible mix of the amount of each factor for usable applications.The balance between the factors are related to an application, i.e. context.The criteria that influence the selection of the optimal level of detail are application, economical and computational aspects, and visualisation aspects, and the selected level of detail should contain the minimum amount of objects with certain properties in order to complete the required task according to acceptable standards in that domain.
Prospects which should be taken into account while giving a new definition for LoD in 3D city modelling are: • It should be possible to specify which city objects (e.g.rivers and buildings) are present in each LoD.
• Constraints should be an integral part in an LoD specification.For instance, the texture and interior geometry of an object cannot be present without its exterior geometry.Also, when defining an LoD with fine geometric representation (a building with balconies and fences), a minimum geometric accuracy requirement cannot be low.
• It should be possible to create any number of LoDs.The number of LoDs in the standard is discrete and limited to a few of them (e.g.NAVTEQ's two LoDs), which can be limited for a number of applications where a finer partition and specifications would be useful.
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.69 • The definition should be wide in order to consolidate all available LoD paradigms and enable defining different combinations of properties, such as interior and texture in specific city objects, e.g.having an LoD where residential objects do not have a texture and interior, but where landmarks are required to have photorealistic textures and interior geometry.Although in most applications this would not be feasible and might be confusing, it should be made possible to define it as one LoD rather than a combination of multiple LoDs.
• Translation.The new LoD classification should be easily translated to existing standards such as the ones listed in Section 2, and vice-versa.
The basis for a definition is shown as a UML diagram in Figure 9.
With this definition, any practitioner may define their level of detail specification within a consistent frame.This framework should cover most, if not all, cases of LoD specifications, including the customised cases mentioned in Section 2.
We direct the LoD specification towards an object by decomposing each LoD as a set of properties described in Section 3.1 into four independent levels of detail which are related to a city object, rather than a whole dataset, with the added semantics since we consider semantics to be an important constitute of a level of detail: exteriorLoD, interiorLoD, appearanceLoD, semanticLoD.Separating each component for each city object permits us mixing and matching different specifications, and a finer guideline.Further, the integral part of the LoD specification is the property of the presence of city object classes, and the presence (wealth) of their integral parts which we call elements.With this framework we give the following propositions: • The LoD specification is divided in two parts: the object domain, and context (application) domain.The specification in the object domain allows finer definition of LoD per each object class, e.g.city furniture objects, and specify guidelines such as the composition of external and internal elements of a city object -exteriorElement and interiorElement (e.g.roof of a building, or interior wall of a tunnel), their appearance (texturing or colour), and semantic hierarchy.This allows us to have different specifications for each city object in a fine and consistent way.
The context domain is related to the use-case of the LoD, and joint specification (generalFactor) for all object classes, such as type of texture, minimum real-world area of an object to be acquired, and presence of the interior in the LoD.The inventory of these factors is not defined, and depends on the use-case.This is essentially the set of metadata of an LoD covering all city objects.
• Each city object is geometrically composed of elements in a geometric and semantic hierarchy, which should be defined by a user.For instance, for an object class Tree, the elements may be Trunk, Canopy and Leaf.Elements may form the exterior or the interior, and are distinguished in these two categories.Furthermore, an element can be a (sub)part of an element, e.g. a dormer is an element of the element roof.These relations should be constrained, e.g. a balcony fence cannot be present without the balcony, and if that an element is a part of another element, it can have only one parent element.
The hierarchy for each object should be determined in general regardless of an LoD.At this moment the CityGML does not provide a hierarchy.
• While the geometric object is formed by its exterior and interior, which are conceptually separated, they are constrained -the interior cannot exist without the exterior (containedBy).
• Separation of the properties of presence and geometrical complexity are taken into account.Apart from their presence, the elements are defined by their geometrical complexity.For instance, in two different LoDs, a bridge may have the cables modelled, however, in one of the LoDs the 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.70 cables are modelled with higher geometric complexity (e.g.lines vs. cylinders).
• City object and LoD-related requirements are both included.
For instance, a specification may require that all residential objects with a footprint larger than 50 square metres are included.However, atop, an LoD may require the presence of all structures which are at least 5 m high, and this requirement applies to all object classes.
• The attribute geometryType of an cityObject specifies the type of geometry with which the city object is represented.We define the following geometry types: 0D (point, symbol), 1D (line, most useful for roads and rivers), 2D and 2.5D (footprints), 3D ("regular" city models), and 3D+interior (3D city model with included interior).
• The appearance is associated with elements, rather than objects.The textures should be defined for each element, rather as a property of an object, since textures are draped over parts of objects and may be partial, e.g. as shown in Figure 5 where the texture is present only on the roof structure.
• The same applies to the semantic properties.We consider that the geometric and semantic hierarchies are separated, and should be connected.This is not a new concept, however, we consider the semantics as a constitutional sub LoD for each city object, and that two datasets with the same geometric data but with different semantic properties (e.g.number of classes) cannot be considered being equal LoDs.An example is shown in Figure 10 with three LoD of a house which contains the elements of the walls, roof and chimney.However, semantically these are considered different in the three sub LoDs of semantics.More focus is given to semantical differences, and a link should be established between the two hierarchies.The presented model contains considerations for a semantic LoD, however, the linking between the two hierarchies is left for future work.• The framework should support automated generalisation by linking objects and their features in multiple LoDs.The binary attribute multiObject denotes if the object has been generalised and forms multiple objects in a higher LoD.

Example of an LoD specification as the realisation of the presented framework
In this section, a realisation of the framework discussed in the previous section is shown as an example.The specification of two levels of detail is given, in a tabular form presented in Figure 11.
A user may give a request list for modelling a 3D city model dataset in a given area for an unspecified application.The given example is a simplified version containing a handful of city objects, elements, factors and attributes for legibility and simplicity.In practice, the specification would be considerably larger for most applications.The objects and elements shown here as an example have arbitrary name and hierarchy, and are not standardised.
The user requests two LoDs, calling them LOD-A and LOD-B.
The general factors are determined for each level: the first one requires all the geometric data to be acquired with the accuracy of 0.5 m, while the geometric data in the other level should be acquired with the accuracy of 0.2 m.The LOD-A requires texture which can either be from a generic library or photographs (LOD-B does not require any texture).The interior cannot be present in LOD-A, while LOD-B allows it and at this point does not specify more requirements.
Required city objects to be modelled in both LoDs are buildings, roads wider than 3 metres, and trees.In addition, LOD-A requires lamp posts which in contrast are not included in LOD-B.Buildings are composed of elements Roof, Dormer, Walls, and the interior element Rooms.Dormers are a subelement of the element Roof and denoted as Roof: Dormer.The first LoD does not require dormers to be modelled, so the element Roof: Dormer is disregarded in the specifications.The LOD-B requires dormers to be modelled.
In the different city object, the roads can be composed of Center-Line and TrafficArea, however, the LOD-A requires only the first element to be present, while the LOD-B the latter.Notice that the geometryType of the two is different: 1D and 2D, respectively.This is an example of two considerably different LoDs for the same type of city object.
A tree in both LoDs is constructed by only one element (Canopy), but in the first LoD it is modelled only as a point (which later can be referenced to a library) without any appearance and attributes, and in the second LoD, beside modelling it with a line, also the type of the tree and its dominant colour have to be modelled.
The lamp posts also have only one element (LampPole) which is required by LOD-A.However, in LOD-B this type of object is not included and therefore completely ignored.
The semanticLoD is realised with the semanticClass.Each element has to have a semantic class in which it is modelled, or be left empty (this is characteristic to computer graphics and CAD and formats such as KML).In LOD-A the Roof and Walls are modelled as Building, i.e. share the same class, while this is not the case in LOD-B.
This tabular example shows one of the possible realisations of the presented approach to LoDs as a user requirement specification, and that there could exist many different combinations of levels of detail, practically opening the door for fine and consistent specifications taking into account user needs.This framework enables finer LoD specification than CityGML benefiting users and practitioners eliminating ambiguity.For instance, one of the problems of CityGML is that two different datasets may fall 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.71  the same LOD, while with this more specific framework this is solved.

Level of Detail Level of Detail Level of Detail LOD-A LOD-A LOD-A LOD-A LOD-A LOD-B LOD-B LOD-B LOD-B LOD-B
Other advantages are treating separately the properties and factors that constitute a level of detail, with the decomposition of the exterior and interior geometry, semantics and appearance into different sub levels of detail, and their consideration to each city object, rather than all objects together.However, this LoD framework is not limited only to CityGML, it is a wide approach that can be modified and extended.

Denomination, sorting, and quantification of LoDs
While the presented framework may define any number of LoDs from different standards, manufacturers and acquisition techniques, and helps distinguishing similar datasets with different combinations of specifications, a pending question is how to denote and sort multiple available LoDs, especially if they are available from different data sources, and with focus on different components.For instance, while the CityGML LOD3 is in general of better quality then the LOD2, this can be irrelevant to some applications since the improvements in data may not be relevant to a certain application and may be computationally unfeasible.Further, an LOD2 can be acquired with higher geometrical accuracy or semantic classes, which might be more relevant for an application, and make it a more desirable LoD.
Consider the example presented in the previous section.The LOD-A has lower accuracy requirements, but its objects contain a better appearance.While LOD-B, beside single-colour appearance in some elements, does not include texture, it includes the basic interior, more attribute information (such as the material of a wall of a building), and all the geometry is acquired with better accuracy.Although it is not specified, the LOD-A may be more suitable for navigation, while LOD-B for analysis such as solar potential estimation.
The point that we are raising here is that LoDs cannot be easily compared and denominated in a single concept, and this example shows that the designations are at this moment nominal and no sorting (or even further -quantification) is attempted.Which LoD is better mostly depends on the application for which the user requires such levels of detail.
We therefore link the sorting of each LoD to the concept of quality and context or application.The quality is a relative term since it is strongly dependant on the application for which the 3D city model is used.We argue that each LoD could be denominated and sorted separately for each application for which is used by calculating the offset in quality of the results between the used LoDs of the same spatial extent for the same application.Consequently, LoDs could be sorted differently by each application, and their comparison is relative only when taking a context into account.
Due to their finer and more comparable specifications, sub LoDs are a step closer to comparison and sorting.Considering the example presented in Figure 11, it is clear that it is easier to compare, for instance, the different sub levels of detail of the appearance, rather than the level of detail as one.This shows one of the advantages of decomposing an LoD into sub LoDs.However, this leads to the multi-"dimensionality" of the denomination and quantification of the levels, i.e. if each sub LOD is quantified with a single designation, the LoD cannot be easily denominated with one name.
There are different ways how the LoD range and LoDs could be quantified and how they related to each other: ordinal (LOD1, LOD2, etc. or good, better, best) with no measure on the relation in between, except of each being better than the other.And interval (LOD1, LOD2, etc. where the measures are algebraically related, i.e.LOD2/LOD1 = 2).
Precise quantification of LoDs is a relevant topic for initiatives such as the integration of levels of detail as a spatial dimension (van Oosterom and Stoter, 2010;Stoter et al., 2012) and varioscale geo-information (van Oosterom and Meijers, 2011), where the interval quantification is desirable in order to place multiple LoDs on a hyper-spatial axis.However, because of different measurements of the factors, it is not straightforward to use the interval scale.It could be argued that for instance 150 vertices of a building are double than 75 vertices, however, it is not clear can a positional accuracy of 1 metre be considered twice as good than the one of 2 m considering economic, computational and practical aspects.Moreover, different combinations of factors, each being a separate function, may lead to a multiple dimensionality while sorting different LoDs.
While it would be challenging to construct an interval level of measurement, it could be approximated with well-established statistical methods, such as with calculating the Spearman's rank correlation coefficient (Spearman, 1904).This is part of future work.
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.72 In this paper we survey several different LoD paradigms, identify their main characteristics and disadvantages, and discuss LoDrelated issues that GIS researchers and practitioners encounter when dealing with 3D city models.
We set a foundation of a new definition for the concept of level of detail in 3D city modelling, identifying the factors which compose a level of detail, and argue that there should be a relation in between in forms of constraints.Further, we build a hierarchy, and define four main driving factors which contribute to a notion of quality or fineness of a dataset, i.e. level of detail.This is different from previous approaches since it is not based on a onedimensional approach where all levels are driven by one main factor, or more factors together.We argue that this framework benefits users and producers of the 3D city models, than current standards offer, by allowing finer and more consistent specifications that may be tailored for each user's needs and considerations.The present standards could be integrated well in this wide framework, and their LoD concepts could be expressed in this manner.
With such definition the traditional term level of detail may be misleading, since in this paper we do not to define the term detail, and express the LoD rather as a level of quality and completeness of the data from the perspective of several components and factors.The term level of detail implies the fineness (or intricacy) of elements which constitute an object in a dataset.However, we argue that the definition of an LoD includes more than that.
In this paper we also discuss the separation of geometric and semantic LoD hierarchies, which is not a new concept, however we give more focus to semantics than previous attempts.This is especially important when distinguishing models from CAD and GIS.The constraints which should be a part of an LoD specification are also discussed.
We believe that the presented framework can serve as a basis for a robust LoD definition in the frame of 3D city modelling, encompassing present and future standards and integrates well with CityGML and its future versions.The presented framework enables practitioners a finer specification that CityGML provides, regards the application for which a 3D city model is used, and allows flexibility of defining own rules and specifications.
The example presented in Section 4.2 may be a good basis for future user requests lists and product specifications, and a general or application-based standard could arise from it.
Among open questions which should be addressed in future work are: • The full inventory of factors which will be acquired by investigating several use-cases.Here the focus was given mostly on the geometric accuracy which is a common consideration in most of the applications, however, the list of factors depends mostly on the use-case.For instance, the application of solar potential estimation may require 3D city models with factors which are not required by other applications (e.g.ownership information, and accessibility information for all city objects).
• How to support continuous LoDs?This framework is aimed at discrete LoDs, however, there are developments and trends of continuous LoDs in 3D city modelling (Döllner and Buchholz, 2005) which should be included as well.
• Is it possible to specify a general LoD specification in the table-like format presented in Section 4.2 to be used by most of the applications?
• How to quantify and denominate LoDs in such standard?
The LoD designation should be straightforward and preferably linear.One of the reason of the success of CityGML's LoD standard is that it is defined with just one number.The presented approach of separating the LoDs per each city object, and into four sub LoDs makes it difficult to denominate LoDs with a single designation.
• Constraining of the factors and specification.The progressiveness of LoDs is multidimensional, e.g.any improvement in the exterior, interior, texture and semantics is considered a separate LoD.However, this could lead to practical inconsistencies, such as a combination of a high detail model acquired with poor accuracy which can be unusable.
• LoDs are not integrated in a single data model, and features present in multiple levels are not re-used.The generalisation aspects should be covered as well.
We plan to research these topics in future work and after surveys of several use-cases.

Figure 3 :
Figure 3: Mixed-LoD 3D city model of Munich by NAVTEQ as a combination of the Enhanced 3D City Model, and 3D Landmarks.Source: NAVTEQ.

Figure 4 :
Figure 4: An example of 3D city models in level of detail 2 and 3 produced by Vertex Modelling.The images are reproduced from the producer's website.

Figure 5 :
Figure 5: A 3D city model of Zagreb, Croatia made by Geofoto, intended for 3D printing combining CityGML LODs 1 and 3 in single objects, and varying in texture.Courtesy of the company.

Figure 6 :
Figure 6: Viewing LoDs as a composition of multiple SLoDs.Example for CityGML and BLOM3D.

Figure 7 :Figure 8 :
Figure 7: The two elements (exterior and texture) of the LoD paradigm of BLOM progress separately.It is similar as CityGML if considering the interior instead of the texture.

Figure 9 :
Figure 9: UML diagram showing the proposed framework for an LoD definition.The framework is separated into an object and a context domain, and the relation between LoDs, sub LoDs and their objects is emphasised.

Figure 10 :
Figure 10: Three datasets in same geometric level of detail with different semantic detail and granularity.Since the semantics are different, we consider these as three different levels of detail.

Figure 11 :
Figure 11: Example of a user requirement or company offer specification for two levels of detail of a 3D city model.
Volume II-2/W1, ISPRS 8th 3DGeoInfo Conference & WG II/2 Workshop, 27 -29 November 2013, Istanbul, Turkey observe, CityGML does not indicate methods for the automatic derivation of the different LoDs, and relationships between different LoDs are not maintained.ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences,