What is Association Composition and Aggregation

Documentation for modeling the geographic information of the official surveying and mapping (GeoInfoDok)


1 Documentation for modeling the geographic information of the official surveying and mapping (GeoInfoDok) Main document Version 6.0 Status: Working group of the surveying administrations of the federal states of the Federal Republic of Germany (AdV)


3 4.4.

4 1 Structure, content and objective 1.1 Initial situation, motives and objectives The surveying and cadastral administrations of the federal states have the task of providing spatial basic data (geographic reference data) for administration, business and private users, increasingly in digital form. We reacted to this very early on and began to digitally record the data from the real estate cadastre in the ALK (Automated Real Estate Map) and ALB (Automated Real Estate Book) projects as well as the data from the topographical land survey in the ATKIS project (Official Topographical-Cartographic Information System) across Germany and to use it To make available. In most federal states it is regulated by cabinet resolution that the ALK, ALB and ATKIS data are to be used as the basis for other specialist information systems (FIS). The concepts according to which ALB, ALK and ATKIS were built date from the 70s and 80s of the 20th century. They still serve today as a platform for building up the corresponding geographic base data. In addition, further extensive digital databases were built up according to the federal states' own concepts, e. B. Digital orthophotos, raster data from the topographic national maps and digital elevation models. Against the background of the rapidly developing technology, the extensive experience of manufacturers in data acquisition and the changed requirements on the part of users resulting from the use of data, it was necessary to review and further develop these concepts. The previous information systems ALK and ALB will therefore be integrated in the information system ALKIS (official real estate cadastre information system) in the future, with the further development of 3D geographic base data being taken up. Especially with the buildings in ALKIS, there is a need to be able to store 3D information as an option. In addition, formal, content and semantic harmonization with ATKIS was carried out. The digital terrain models (DGM) are not assigned to a specific digital landscape model (DLM) in the relief object area in ATKIS, as was previously the case, but are shown as an independent component under the object-structured data. In this way, similar to the fixed points of the basic survey, the universal usability of the DGM as an independent database is made clear and the status: page 4

5 Possibility of creating combined databases or products using data from other product groups better highlighted. For the digital orthophotos (DOP) there is an AdV standard which, according to the previous understanding, is not an application of the common application scheme, but which is nevertheless included in the overall documentation under the heading Photo-based data in Chapter 2 The AFIS-ALKIS-ATKIS reference model and the Product groups is included. The derivation of 3D city and landscape models from the geographic base data is made possible by the combination of 3D information in ALKIS and the DTM in ATKIS as well as the terrain texturing with DOP. In order to use the properties of geographic information systems defined for the 2D area, the basic classes for modeling 3D information were integrated into the basic scheme. As a result, the ALKIS continuation processes could also be used for the economic continuation of the 3D geospatial base data. The geographic information of the official surveying and mapping also includes the information on the fixed points. Since the fixed points originally belong neither to the ALK nor to ATKIS, their modeling is now carried out in a separate information system, the Official Fixed Point Information System (AFIS), using a separate feature catalog. The AdV projects AFIS, ALKIS and ATKIS with their transnationally defined properties are jointly described under the heading Documentation for modeling the geographic information of the official surveying and mapping. They are related to one another in a common reference model and are described in the following chapters as a common application scheme for AFIS, ALKIS and ATKIS within the scope of this documentation. The common application scheme provides for the acquisition and management of metadata and quality data in accordance with ISO specifications. 1.2 Basic data stock, feature catalogs and versioning The basic data stock is the data stock to be kept uniformly in AFIS, ALKIS and ATKIS by all surveying administrations in the federal states of the Federal Republic of Germany and which is available to the user across borders. This includes status: page 5

6 also the corresponding metadata. A later expansion of the basic database is to be expected. The property catalogs of the real estate cadastre and the land survey were semantically harmonized as far as possible and meaningful in the interest of a real world modeling that is as uniform as possible. The harmonization has advantages for internal use as well as in the external area. It is based on the previous catalogs (sample OBAK, directory of types of use, ATKIS-OK). A version concept is introduced in connection with the description of the procedure for user-related inventory data update (NBA). Countries that use history management in the sense of the step-by-step solution for ALKIS decided by the AdV base their modeling and the functionality of history management based on it on this application scheme, which has been expanded to include the version concept. With regard to history management, ATKIS considers the storage of the respective data stocks on the reference date to be sufficient. With the integration of 3D information in the common application scheme for AFIS, ALKIS and ATKIS, the need for a versioning and historization concept for 3D geospatial base data is also covered. 1.3 Target group and users Supraregional users and the GIS industry are calling for a nationwide uniform basic database to be established with regard to the content and structuring of the geospatial base data as well as for reasons of economic efficiency. From the holistic point of view of official surveying, the basic data stocks of AFIS, ALKIS and ATKIS are to be merged into this basic data stock of geodata of official surveying. With the European framework directive for the development of a geospatial infrastructure in Europe INSPIRE, the standard-compliant modeling of geospatial base data plays an important role. A central goal of INSPIRE is the provision of more and, above all, uniform spatial data for community policy and its implementation in the member states at all levels. The focus is on environmental policy. In a European spatial data infrastructure, the various spatial data can show a different degree of harmonization even within a specialist administration. INSPIRE therefore contains three different appendices that relate to different subject areas of spatial data that are required for a wide range of environmental policy measures. Depending on whether geodata for the stand: page 6

7 Georeferencing of other data is used or harmonized spatial data is required for political measures with direct or indirect effects on the environment, and depending on the degree of harmonization that has already been achieved in the Community, different target periods for fulfilling the requirements of INSPIRE as well as different harmonization specifications apply. How this geodata is to be organized and harmonized is not regulated here, but in the technical implementation regulations. INSPIRE does not create a comprehensive program for the collection of new spatial data in the member states. Instead, the documentation of existing geodata is required in order to optimize the use of already available data. For this purpose, services (web services) are specified that make spatial data more accessible and interoperable, and attempts are made to solve problems with the use of spatial data (access rights, prices, etc.). INSPIRE will thus pave the way to a gradual harmonization of spatial data in the member states. With the AFIS-ALKIS-ATKIS application scheme, the AdV is already sufficiently prepared for INSPIRE-compliant data delivery. The GIS and CAD users are also very interested in building a 3D model based on the data of the official real estate cadastre in order to be able to represent and better visualize their plans on this official basis. Furthermore, the resulting 3D information finds a suitable platform for storage in a uniform 3D model based on GeoInfoDok. There is currently no official evidence for this information. The EU guideline for the reduction of environmental noise (2002/49 / EG) requires regular detailed noise propagation calculations in the future, which can only be carried out on the basis of continuously updated 3D city models. 3D information based on the GeoInfoDok provides the basis for determining the ambient noise data, offers continuation mechanisms and enables the required regular review of the noise maps by using the versioning / historization concept. For the migration from the previous evidence, a basic procedure in the form of a step-by-step concept is provided. The detailed elaboration of migration concepts must be carried out on a country-specific basis. A back migration into the interfaces of the previous systems for a temporary supply of the users with data is still conceivable for a longer transition period. The migration concept is only of temporary importance and is therefore not included in the overall documentation. Status: page 7

8 2 The AFIS-ALKIS-ATKIS reference model The AFIS-ALKIS-ATKIS reference model has the task of presenting the data sets described in this documentation with their relationships in context. The aim is to identify components, to facilitate modularization, to show the connection to the standards and to avoid duplication within the components. AFIS is the Official Fixed Point Information System and contains descriptive and illustrative data on the following product groups: AFIS inventory data, digital AFIS extracts and analog AFIS extracts. ALKIS is the official real estate cadastre information system and contains property describing and representing data in the following product groups: ALKIS inventory data (optionally also expansion with 3D information), digital ALKIS extracts and analog ALKIS extracts. ATKIS is the official topographic-cartographic information system of the German land survey. ATKIS describes the landscape with different application goals in the following product groups: digital landscape models (ATKIS-DLM and additional data) including digital terrain models (DGM), digital topographic maps (DTK), analog excerpts from the DTK (topographic maps) and digital image models (DBM) in form digital orthophotos (DOP). The contents, structures and manufacturing specifications of the products of the reference model are defined at the control level by the feature catalogs (OK) and signature catalogs (SK). These include: Regulations for mapping the information of the fixed points, the real estate cadastre and the topography, status: page 8

9 Regulations for the creation of presentation and map geometry objects (additional data), regulations for the representation and cartographic design of the objects. Regulations for the design of analog extracts The entry templates on the production level are subdivided into landscape, digital image models (digital orthophotos) as well as maps and other documents. The landscape as the source of the original information will be used as a recording source, especially in the context of the continuation. Thanks to the digital data flow, data registered in the field flow into the inventory data of AFIS, ALKIS and ATKIS either directly or after structuring and classification without the detour via analog media. The built-up geographic base data stocks can at the same time serve as a recording source for derived data stocks, e.g. are parts of the ALKIS inventory data, in particular the building data, the basis for deriving the corresponding data for the ATKIS-DLM. The acquisition process also includes the creation of presentation and map geometry objects and thus also includes the process of cartographic generalization. Status: page 9

10 Production level landscape maps and other digital image model documents (DBM) is mapped in TIFF control level communication level is given to users of image-structured data is recorded for feature catalog (OK) signature catalog (SK) AFIS ALKIS ATKIS regulates describes inventory data AFIS ALKIS ATKIS - DLM additional data Digital extracts AFIS ALKIS ATKIS- DTK is mapped in NAS is processed as mapped in TIFF, DXF, NAS is given to users of object-structured data is given to users of processed information is printed as analog extracts AFIS ALKIS topographic maps given to users of analogue excerpts Figure 1: Common AFIS-ALKIS-ATKIS reference model (source: The common ALKIS-ATKIS reference model, 1996) The existing data differ in the degree of abstraction with which they model the earth's surface and related facts. They show their status: page 10

11 properties such as object structuring and geocoding. In addition to the technical objects with their semantic and geometric information, they also contain the additional data required for the presentation: namely the presentation objects for text and signatures as well as the map geometry objects linked to the topographical objects by a one-sided relationship with the respective map geometry for a certain map scale. The inventory data contain the complete description of technical objects including the data for their cartographic or textual representation in one or more target scales. This means that the inventory data is modeled in such a way that it can be displayed completely automatically during the presentation, i.e. without further interactive intervention, in the intended output form. Object- or image-structured data, processed information or analogue extracts are sent to the user on the communication level, which can include the complete data content, any extracts according to content and area as well as continuation data from any time period. Status: page 11

12 3 The conceptual model of the AAA basic scheme 3.1 Principles of modeling Norms and standards International standardization activities in the field of geographic information are currently taking place in the following bodies: ISO / TC 211 Geographic Information / Geomatics Open Geospatial Consortium (OGC) The aim is to create of the basics for the common, holistic and interdisciplinary use of geodata in different locations by people, applications and systems on the basis of a uniform description of the content of existing or planned databases, the functionalities of data processing and communication. The modeling is based on the results of ISO / TC 211 in the form of the family of standards in the current processing status. In the area of ​​the data exchange interface, parts of the OGC specifications are also used. For the integration of 3D information, CityGML (OGC Best Practices Document in version 0.4.0) forms the basis for the modeling and description language To describe the application schema and the feature catalogs, the AdV decided to use the data modeling language Unified Modeling Language (UML) . It is also used by ISO / TC 211 in the standardization of geographic information. UML was developed by the Object Management Group (OMG) to describe application schemas. The semantics and notation of UML are described in the UML Notation Guide. In order to ensure uniform use of UML in the area of ​​the family of standards, its use is specified in the ISO specification Conceptual schema language. The purpose is to provide a complete and unequivocally interpretable, formal description of the content and structure of data stocks. The description is independent of the type of implementation and the programming language used. A uniform description of all spatial data can be achieved with formal languages. The application schemes described in this way can be automatically interpreted by suitable programs and translated into internal data structures or database structures. Status: page 12

13 A universal and system-independent data exchange or file format results automatically in connection with so-called coding rules. These coding rules are created in accordance with the ISO standards Encoding and Geography Markup Language (GML). The format used is the XML (Extensible Markup Language) of the World Wide Web Consortium (W3C). 3.2 Task and structure An application schema provides the formal description for data structures and data content in one or more applications. It contains the complete description of a database and can contain not only the geographical but also other related data. A basic concept for abstracting the real world is the introduction of the subject and rules on how it is recorded and continued.The specialist objects are classified according to type. At the type level, the application schema describes the types of objects in the real world. Data itself exists at the instance level. They represent individual copies of an object type in the real world and can be interpreted by the application schema, see also ISO19101 Reference model and Rules for application schema. The purpose of an application schema is to achieve a common and uniform understanding of the data and to document the data content for a specific application environment in such a way that clear information about the data is obtained. Data level Real world Modeling level Data acquisition Abstraction Geographical database Defines content and structures Application schema Figure 2: The role of the application schema The common AFIS-ALKIS-ATKIS application schema offers a uniform and object-oriented model approach for AFIS, ALKIS and ATKIS, which is as compatible as possible with the status: Page 13

14 customary and state-of-the-art GIS programs are to be mapped and managed. An application scheme can use specifications from various sub-schemes. In the case of the AFIS-ALKIS-ATKIS application scheme, sub-schemes from the ISO standard family are mainly used. In areas in which ISO has not yet made any stipulations, schemes from the OpenGIS consortium are also used. << Application schema >> AFIS-ALKIS-ATKIS application schema << Application schema >> Web feature service extensions ISO19100 << Application schema >> Web feature service << Application schema >> OWS Common Figure 3: Dependency of AFIS-ALKIS-ATKIS -Application schemes from the standardized structures from ISO and OGC ISO Temporal ISO GML ISO Rules for Application Schema ISO Coverages ISO Feature Cataloging ISO Spatial Schema ISO Spatial Referencing by Coordinates <> Spatial Examples from ISO ISO Metadata ISO Conceptual Schema Language Figure 4: Parts used from the ISO standard family: page 14

15 The AFIS-ALKIS-ATKIS application scheme is divided into the basic scheme (section 3.3), the versioning scheme (section 3.4), the AFIS-ALKIS-ATKIS technical scheme (chapters 5 to 8), the NAS operations (section 10.2) and the AFIS-ALKIS-ATKIS output catalog (Sections 6.2 and 7.2). The basic scheme is the basis for modeling the technical objects in the technical schemes. The versioning scheme shows the concept for historizing specialist objects. An internal schema is not part of the joint modeling; it is created by mapping the conceptual application schema in specific GIS systems in the course of implementation. On the basis of the application scheme, operations for data exchange and technical specifications for data output are finally defined. ISO19100 << Application Schema >> Filter Encoding Capabilities << Application Schema >> Web Feature Service Capabilities << Leaf >> AAA_Katalog << Application Schema >> OWS Common <> AAA Versioning Scheme AAA Basic Scheme << Application Schema >> Web Feature Service Extensions NAS operations AFIS-ALKIS-ATKIS Technical scheme AFIS-ALKIS-ATKIS output catalog (from NAS operations) Figure 5: The components of the AFIS-ALKIS-ATKIS application scheme 3.3 The AFIS-ALKIS-ATKIS basic scheme The AFIS- ALKIS-ATKIS basic scheme (AAA basic scheme) forms the basis for the technical modeling of AFIS, ALKIS and ATKIS objects and for data exchange. The technical schemes are created on this basis. Its use is not limited to AFIS, ALKIS and ATKIS. Other specialized information systems can also use the classes defined in the basic schema to model their technical schema. Status: page 15

16 The addition of the AAA basic schema classes is necessary for the creation of a 3D technical schema, as the basic schema does not contain any geometry types for the description of volumetric objects. << Application schema >> AAA basic schema << Application schema >> Technical schema AFIS-ALKIS-ATKIS << Application schema >> Technical schema X << Application schema >> Technical schema Y AFIS, ALKIS and ATKIS) The basic scheme is divided into the eleven (twelve or fourteen) packages "AAA_Basisklassen", "AAA_Katalog", "AAA_SpatialSchema", "AAA_GemeinsameGeometrie", "AAA_Unabhaengigegeometrie," AAA_UnabhaengigeGeometrie, "AAA_objekteobjekteometrie", "AAA_CodeAeisten" AAA_CodeAeists "," AAA_CodeAeists " AAA_Projektsteuerung, AAA_Nutzerprofile, AAA_Operationen, AAA_Praesentationsobjekte_3D, AAA_SpatialSchema_3D and AAA_Unabhaengige Geometrie_3D. The packages AAA_User Profile and AAA_Operationen only serve to anchor user administration or operation modeling in the basic scheme. They only contain empty, abstract classes that have to be filled in by the respective technical schemes. They are therefore not explained further in the following. The following system is used to clearly name the defined classes: 1. Standardized classes keep the respective standardized prefix in the class name (eg FC for "Feature Catalog", MD for "Metadata") 2. Classes as AFIS-ALKIS-ATKIS-specific additions in the standardized feature catalog are given the prefix AC 3. Classes with basic meaning for AFIS, ALKIS and ATKIS are given the prefix AA 4. Classes derived from the ISO TS_ * component classes ("simple topology") are given the prefix TA ; likewise the correspondingly formed class for stand: page 16

17 topological surfaces with multiple, spatially separated geometry (TA_MultiSurfaceComponent) 5. Classes with shared geometry are given the prefix AG 6. Classes of independent geometry are given the prefix AU 7. Classes of presentation objects are given the prefix AP 8.

18 << Leaf >> AAA_Praesentationsobjekte 3D + + AP_DateiTyp_3D AP_KPO_3D + AP_TransformationsMatrix_3D << Leaf >> AAA_Spatial scheme 3D + + AA_REO_3D TA_Component_3D + + TA_CompositeSolidComponent_3D TA_CurveComponent_3D + + TA_PointComponent_3D TA_SurfaceComponent_3D + TA_TopologieThema_3D << Leaf >> AAA_Unabhaengige geometry 3D + + AA_MehrfachFlaechenGeometrie_3D AA_MehrfachLinienGeometrie_3D + AA_Punktgeometrie_3D + AU_GeometrieObjekt_3D + AU_Geometrie_3D + AU_KoerperObjekt_3D + AU_MehrfachFlaechenObjekt_3D + AU_MehrfachLinienObjekt_3D + AU_ObjektMitUnabhaengigerGeometrie_3D + AU_PunkthaufenObjekt_3D + AU_Punktobjekt_3D + AU_TrianguliertesOberflaechenObjekt_3D + AU_UmringObjekt_3D Figure 8: 3D elements of the base schema object formation principles the rules for creating application schemas are defined by the standard "rules for application schema" of the ISO / TC 211 . This standard also contains the general model for describing and creating technical objects (General Feature Model). The common basic scheme is connected to the General Feature Model from ISO and this is extended by the metaclass "AA_ObjektOhneRaumverarbeitung" to be able to create object classes for which no spatial reference is permitted. The formation of independent objects results from the technical object view. Objects with geometrical characteristics can have point, line, area and volume descriptions or be of the point set object type. Objects without spatial reference (e.g. people) have no geometry and cannot be fixed to a specific location. However, they can be related to other spatial and non-spatial objects, e.g. B. with parcels, buildings or addresses. To systematize and support the creation of the technical diagrams, five general types of object characteristics are predefined in the common AAA basic diagram: Room-related elementary objects (AA_REO) Room-related elementary objects are to be created if in addition to the technical status: page 18

19 properties geometric or topological properties are to be verified. Space-related elementary objects 3D (AA_REO_3D) A space-related elementary object for 3D specialist applications (AA_REO_3D) is an object that receives its spatial reference, its geometric and topological description by one or more 0- to 3-dimensional spatial reference basic forms, whereby all coordinates (DirectPosition) of the spatial reference basic forms 3 Have coordinate values ​​for easting, northing and elevation. Space-related elementary objects for 3D specialist applications are assigned to different levels of detail, analogous to different generalization levels for 2D geometries at different map scales. 3D technical objects refer to the associated technical object with a more detailed 3D geometry (levelofdetail) in a generalized manner via the relation role. The inverse relation role detailed refers to the associated technical object with a 3D geometry in a lower level of detail (e.g. a cuboid 3D geometry that is derived from the 2D floor plan and the object height for buildings). For 3-dimensional, space-related elementary objects, the model provides further subclasses with specific space-related properties; Only from these should the specific technical objects with 3D spatial reference be derived. Non-spatial elementary objects (AA_NREO) Non-spatial elementary objects are to be created if only technical, but no geometric or topological properties are to be proven. Compound objects (AA_ZUSO) Compound objects are formed in order to create the connection of any number and mixture of semantically related spatial elementary objects, non-spatial elementary objects or composite objects. However, a composite object must have at least one object as a component. Point set objects (AA_PMO) For certain specialist object types, which consist of a large number of geometric locations with the same types of attributes (e.g. digital terrain models, temperature and air pressure distributions), it is more advantageous to use a so-called point set object instead of individual REOs for an object that includes all information: Page 19

20 use. A point set object is a mapping of a set of geometries onto the associated attribute values. Elementary objects are the smallest possible functional unit. The creation of object parts or lines as object components with technical information as in the previous ALK and ATKIS systems is no longer necessary. The management of the history of objects is supported. Options for integrating and linking the specialist objects with the specialist data from other specialist areas are also supported. All instantiable technical object classes are to be derived in the application-related subschemas of the following object classes of the basic schema by inheritance: AA_ZUSO AA_NREO TA_PointComponent TA_CurveComponent TA_SurfaceComponent TA_MultiSurfaceComponent TA_CompositeSolidComponent_3D TA_CurveComponent_3D TA_PointComponent_3D TA_SurfaceComponent_3D TA_TopologieThema_3D TA_Component_3D AG_Objekt AG_Punktobjekt AG_Linienobjekt AG_Flaechenobjekt AU_Objekt AU_Punktobjekt AU_Punkthaufenobjekt AU_Linienobjekt AU_KontinuierlichesLinienobjekt AU_Flaechenobjekt AU_Punktobjekt_3D AU_Umringobjekt_3D AU_Punkthaufenobjekt_3D AU_Mehrfachflächenobjekt_3D as of page 20

21 AU_MehrfachlinienObjekt_3D AU_Geometrieobjekt_3D AU_KoerperObjekt_3D AU_TrianguliertesOberflaechenObjekt_3D AD_PunktCoverage AD_GitterCoverage for presentation objects following object classes of the basic schema can be used directly or be instantiated: AP_PPO AP_PTO AP_LTO AP_LPO AP_FPO AP_Darstellung AP_KPO_3D alternative is allowed to be derived from these object classes of the basic schema through inheritance more instantiable technical object classes Attributes in the Technical diagrams to be described objects can have self-related properties (attributes). Attributes are the carriers of the static information of the objects. Attributes are always defined using a name and a value type. Value types can be basic data types (numbers, strings, dates and times) as well as complex data types such as geometries or quality features. Attributes can in principle be multiple and strings of any length. Attributes of the type date and / or time specification ("DateTime") are modeled in accordance with the specifications of ISO 8601, chapter in connection with. The variant with a separator is selected here. Time accuracy is the full second, the time zone is always UTC (Universal Time Coordinated, Greenwich Mean Time, abbreviation: Z). Example: T10: 15: 30Z Relationships The objects to be described in the technical diagrams can have externally related properties (relationships or relations). Different types of relationships can be used in the technical diagrams: Status: page 21

22 According to ISO's General Feature Model, technical objects can enter into any relationship with one another. These are defined in the subject-specific sub-schemes. In addition, some relationships between objects are already fixed in the common basic scheme: Relation to the formation of composite objects (ZUSO) A ZUSO is composed of at least one object. The brackets around these objects form the association composition between "AA_ZUSO" and "AA_Object". Underpass relation Underpass relation (hatdirektbelow) are used to map a relative vertical position of individual objects in relation to other objects. It is not possible to specify an absolute height level by using overpass or underpass relations, since such relations always only contain the two-way relationship between the objects involved. Map geometry The relation of map geometry objects (= generalized geometry, to the associated base objects (is derived from) indicates the objects from which the map geometry objects are derived. Generalization 3D subject objects refer via the relation role generalized to the associated subject object with a more detailed 3D geometry (levelofdetail). The inverse relation role detailed refers to the associated subject object with a 3D geometry in a lower level of detail (e.g. a cuboid 3D geometry, which is derived from the 2D floor plan and the object height in buildings). <> AA_Objekt (from AAA_Basisklassen) <> Identifier: AA_UUID lifetime interval: AA_L Lebenszeitintervall model type: Set occasion [0..1]: Sequence points to external [0..1]: Set <> AA_LevelOfDetail (from codelists) lod1 = 1 lod2 = 2 lod3 = 3 generalization + generalized detailed < > AA_REO_3D levelofdetail: AA_LevelOfDetail context AA_REO3D inv: (self.levelofdetail> self.detailliert.levelofdetail) and (self.levelofdetail

23 Technical data connection If an AFIS, ALKIS or ATKIS object is to point to a technical data object that is managed in a third-party technical data system, this can optionally be described using the pointing to external attribute. The establishment of the technical data connection makes sense in order to take into account the existence of technical data stocks when using and continuing ALKIS. A technical data connection must always be created when 3D city models exist and are to be linked to the 2D database. The technical data connection is then to be established from the AX building to the corresponding 3D objects. There is no explicit inverse relation at this point. Presentation relation Presentation objects are used to represent objects from the inventory data. This relationship is demonstrated by the reference used to represent between the presentation object and other objects. Status: page 23

24 context AA_Object inv: self.anlass-> notempty implies self.anlass.length <= 2 <> AA_Objekt <> Identifier: AA_UUID lifetime interval: AA_livedtime interval model type: Set anlass [0..1] : Sequence points to external [0..1]: Set + consists of 1 .. * {Set} + is part of <> AA_PMO name [0..1]: CharacterString description [0..1] : CharacterString expansion: GM_Envelope + has directly below + is derived from <> 0 .. * 0 .. * AA_REO {set} {set} 0 .. * 0 .. * + carrying <> AA_NREO Instance of {Set} <> AA_ZUSO 0 .. * Instance of Instance of <> GF_FeatureType (from General Feature Model) Instance of <> AA_ObjektOhneRaumverarbeitung Number of GF_SpatialAttributeType equal to zero and number of GF_AssociationRole to GF_AssociationRole equal to zero >> AA_Life time interval begins: DateTime ends [0..1]: DateTime <> AA_UUID UUID: CharacterString UUIDu ndZeit: CharacterString <> AA_Fachdatenverbindungen type: URI technical data object: AA_Fachdatenobjekt The attribute "ends" is only to be used when the object goes down. The time specification for the data type "DateTime" corresponds to the specifications of ISO 8601, chapter in connection with time accuracy is the full second. The time is always specified in UTC (Universal Time Coordinated, Greenwich Mean Time).

25 3.3 The standard also contains spatial operations that use the geometric and topological objects (GM_Object or TP_Object) as parameters (create, delete, change, spatial evaluations ...). The defined classes are not used directly, i.e. they cannot be instantiated. Their use in special application schemes is achieved by means of inheritance; If the classes of the spatial schema for AFIS, ALKIS and ATKIS are not supplemented by special properties, they are used directly in this application area for simplification. Status: page 25

26 Interface with Figure 11: Commonly used interface The basic spatial reference forms are usually managed as self-related properties (attributes) of the objects; However, this does not mean that the verification of the geometry is always redundant.The common AFIS-ALKIS-ATKIS application scheme has the following options with regard to the connection of the spatial reference: Formation of node-shaped, edge-shaped and mesh-shaped objects with "simple topology". In addition, mesh-shaped objects with a simple topology that consist of two or more meshes that are spatially separated (required for modeling over hooked parcels). The ISO scheme "Simple Topology" is used, which expresses topological properties through geometric properties, but offers topological functionality. Formation of point, line, area and volume objects that share lines and points. Formation of point, line, area and volume objects with "independent" geometry. Formation of topological and geometrical "themes" which allow to selectively combine types of objects into so-called complexes in order to express geometrical identities and / or topological relationships. TriangulatedSurface (basis for 3D-DTM) Status: page 26

27 A triangulated surface results from the surface division into triangles, through triangulation using certain algorithms, e.g. by Delaunay triangulation. For example, the geometry of a tin relief is defined by the GML geometry type gml: triangulatedsurface. In technical schemes, either the geometry type gml: triangulatedsurface or its subclass gml: tin can be used. Each spatial AFIS-ALKIS-ATKIS technical object (AA_REO) refers to a maximum of one geometry. If it is necessary to have several geometries available for a real-world object (e.g. generalization, different coordinate reference systems, point and surface geometry), an independent technical object (possibly as a map geometry object) must be created in each case. The necessary extensions and restrictions of the spatial schema from ISO are summarized in the following figures: Status: Page 27

28 TS_SurfaceComponent (from Simple Topology) TS_CurveComponent (from Simple Topology) TS_PointComponent (from Simple Topology) TS_FeatureComponent (from Simple Topology) <> TA_SurfaceComponent <> TA_CurveComponent> > TA_CurveComponent> TA_Component> TA <> GM_MultiSurface (from Geometric aggregates) <> AA_REO (from AAA_Basisklassen) <> AG_ObjektMitGemeinsamerGeometrie + mesh 1 .. * TS_Face (from Simple Topology) The meshes of the TA_MultiSurface realize the meshes of the TA_MultiSurface Realization TA_MultiSurfaceComponent is. + element 0 .. * <> AU_ObjektMitUnabündigerGeometrie + topic 0 .. * <> AA_PunktLinienThema name: CharacterString TS_Theme (from Simple Topology) <> GM_OrientableSurface (from Geometric primitive) Line and point geometry of the elements of a dot-line theme belong to the same GM_Complex. Surface geometry is not part of the complex. Points and lines are only smashed if they are exactly on top of each other; Lines that cross do not smash. All elements of a theme must have the model type identifier for which the theme was defined in the catalog. Figure 12: Summary of the additions required for AFIS-ALKIS-ATKIS to the standardized spatial scheme as of: Page 28

29 <> AA_REO (from AAA_Basisklassen) Only the following types of curve segments (interpolation types) are permitted as geometry for lines or area surrounds: GM_LineSegment, GM_LineString, GM_Arc, GM_Circle and GM_CubicSpline In the middle third of GM_Arc, the 2nd of the circular arc lie; if s possible, the apex of the arc should be taken. With GM_Circle, the respective distances between the ControlPoints (1 = 4,2,3) must not be less than one sixth of the circumference of the circle. The instantiable classes for the spatial technical objects are to be derived exclusively from the following abstract super types defined in the common basic scheme: a) Objects with simple topology: TA_PointComponent, TA_CurveComponent, TA_SurfaceComponent, TA_MultiSurfaceComponent b) Objects with common point and / or line object: AG_Object , AG_Linienobjekt, AG_Flaechenobjekt c) Objects with independent geometry: AU_Objekt, AU_Punktobjekt, AU_Linienobjekt, AU_KontinulichesLinienobjekt AU_Flächeobjekt The following types are to be used for presentation objects. These classes can also be instantiated directly. AP_PPO, AP_PTO AP_LTO, AP_LPO AP_FPO <> AA_Liniengeometrie line: GM_Curve compound line: GM_CompositeCurve <> AA_Flaechengeometrie Area: GM_PolyhedralSurface: GM_PolyhedralSurface is only allowed if the GM_PolyhedralSurface components are GM_PolyhedralSurface 2, the number of GM_CurveSurface is allowed, if the GM_CurveSurface is 2, the number of GM_CurveSurface is allowed, if the GM_CurveCurface is allowed again only have GM_PolyhedralSurface. GM_MultiSurface is only permitted if the number of GM_PolyhedralSurface contained is> = 2 and spatially separated surfaces must be verified. Figure 13: Restrictions regarding the geometry and instantiable classes Status: Page 29