Acta Polytechnica doi:10.14311/AP.2016.56.0291 Acta Polytechnica 56(4):291–300, 2016 © Czech Technical University in Prague, 2016 available online at http://ojs.cvut.cz/ojs/index.php/ap ANALYSIS AND IMPLEMENTATION OF APPLICATION SCHEMAS FOR THE INSPIRE BUILDINGS THEME Michal Meda, b, ∗, Petr Součekb, a a Faculty of Civil Engineering, Czech Technical University in Prague, Thákurova 2077/7, Prague, Czech Republic b Czech Office for Surveying, Mapping and Cadastre, Pod Sídlištěm 1800/9, Prague, Czech Republic ∗ corresponding author: michal.med@fsv.cvut.cz Abstract. Implementing the INSPIRE directive involves transforming various data themes into the structure and content given by Data Specifications published by the Joint Research Center of the European Commission. The data is to be published in the GML format, which is the standard for the Open Geospatial Consortium. The validity of the data structure is ensured by validation against XML schemas. These schemas are usually also provided by JRC, though not necessarily for all application schemas. Six application schemas are defined for the currently implemented Buildings theme, but XML schemas are available for only three of them. All application schemas have been analyzed, and it has been found that the most suitable data model corresponds most closely to the BuildingsExtended2D application schema. No XML schema has been provided by JRC in the current version. The Building- sExtendedBase abstract XML schema was also needed when using the previous schemas. There is now a need to create these missing XML schemas. Keywords: INSPIRE, Buildings, XML schema, GML format, web service. 1. Analysis of the INSPIRE Buildings theme The Infrastructure for Spatial Information in Europe (INSPIRE) is a directive of the European Commission and Council aimed at standardizing spatial informa- tion in the member countries of EU, and at enabling information to be shared among public sector organiza- tions. The Infrastructure began to be implemented on 15th May 2007, when Directive 2007/2/EC of the Eu- ropean Parliament and Council came into force. Inter- operability of spatial datasets and services is ensured by Commission Regulation No 1089/2010 of 23rd November 2010. This regulation has been amended by Commission Regulation 102/2011 of 4th February 2011 and by Commission Regulation 1253/2013 of 21st October 2013. The directive will be implemented in a number of stages, and full implementation is required by 2021. This date has been changed in the past. In the Czech Republic, the directive was enacted by an amendment to Act no. 123/1998 Coll., on the right to access information about the environment, which came into force on 23rd October 2009. The Joint Research Center has no legal right to require national mapping agencies to publish IN- SPIRE–compliant data, metadata and services. This right is vested in the European Commission. A na- tional coordinating body for this purpose was set up in each participating country. Coordination is ensured on the national level. In the Czech Republic, imple- mentation of INSPIRE is coordinated by the Czech Information Agency for the Environment (CENIA). On 4th November 2010, a Coordinating Committee for INSPIRE (KOVIN) was set up as an advisory body of the Ministry of the Environment. Its tasks are to implement INSPIRE, to evaluate progress in promot- ing the implementation of INSPIRE, and to analyze the results of the implementation and coordination of data providers. This is done through technical working groups focused on partial implementation steps, such as metadata, services, strategy, legislation, e.g., [1] Since the beginning of 2014, the implementation has been documented and directed by the national strat- egy for the implementation of INSPIRE [2]. According to the strategy, the main target in implementing IN- SPIRE is to form, maintain and develop the spatial information infrastructure in the Czech Republic as a part of the European infrastructure. The directive divides the spatial data into themes. Each theme is described by a Data Specification doc- ument published by the Joint Research Center (JRC). Each country is responsible for implementation in its own territory. For each theme, there is a national coordinator. This is usually the organization that ad- ministers the data. The coordinator is responsible for ensuring that the work is implemented properly. Each theme can have a number of participators, but only one coordinator. At the time of writing, at least eight themes have been implemented in the Czech Republic. The themes are coordinated either by the Czech Office for Surveying, Mapping and Cadastre (CUZK), or by the Land Survey Office (ZU). In addition, a coordina- tor has been appointed for some of the other themes, but they have not yet been fully implemented. Full implementation requires harmonized data, services 291 http://dx.doi.org/10.14311/AP.2016.56.0291 http://ojs.cvut.cz/ojs/index.php/ap Michal Med, Petr Souček Acta Polytechnica Figure 1. Example of the feature catalogue for the Building spatial object. and metadata. For the Buildings theme, which is at the focus of our attention here, only three application schemas out of six have been provided with corresponding XML schemas. The European Commission has not yet provided the remaining schemas, and as of the end of 2014 it had announced no time plan for providing them. No other countries were implementing extended data models on Buildings, probably because they had not yet progressed so far in the implementation. We therefore undertook an extra step, and created an XML schema covering the missing application schemas. We also tested the schemas and, considered how they were to be implemented in the future. 1.1. Introduction to the Buildings theme The newest version of the Data Specification on Build- ings is version number 3.0, which was published on 10th December 2013. It made major changes to the two years older Data Specification on Buildings, in version 2.0. The first action to be taken after pub- lishing a Data Specification document is to analyze it. The implementation of the Buildings theme in the Czech Republic is based on Data Specification version 3.0. The Data Specification document consists of an overview and scopes, which determine the basic in- formation about the content. The key chapter for transforming the data is under the heading Data Con- tent and Structure. This chapter provides an overview and a detailed description of the application schemas, including code lists, enumerations, geometric represen- tation and feature catalogues. The feature catalogue is a detailed description of features belonging to the application schema, in this case in a structured form Fig. 1. The structured form for technical use is in the form of an XML Schema Definition document [3]. Further information about the XML schemas is provided in sections 1.2 and 2. Other chapters deal with reference systems, metadata, data quality and delivery. These chapters are very similar for each theme. Finally, a really important chapter for implementation is “Por- trayal”. This chapter defines default styles for use in View Services. The most important chapters for imple- mentation, and the chapters that are most analyzed, are “Data content and structure” and “Portrayal”. According to the specification, two different feature types shall be implemented — building and building part. Buildings are enclosed structures above and/or underground, which are intended for or used for the shelter of humans, animals and things, or for the production of economic goods, and Buildings are any structure permanently constructed or erected on a site. A BuildingPart is a sub-division of a Building that might be considered as a building and that is homogeneously related to its physical, functional or temporal aspects. It is up to each data producer to define what is considered as a Building and what is considered as a BuildingPart (if this concept is used) [4]. 1.2. Data content and structure Six application schemas are defined in the Data speci- fication for the Buildings theme (Fig. 2). Two of the schemas contain only abstract feature types. As in object programming, this means that a 292 vol. 56 no. 4/2016 Implementation of the INSPIRE Theme Buildings Figure 2. Application schemas for the Buildings theme. single feature cannot be an instance of an abstract feature type, but other feature types can inherit at- tributes from them. These two abstract application schemas are called BuildingsBase and BuildingsEx- tended, and they contain basically all semantic infor- mation. The four other application schemas differ in the type of geometry used on 2D and 3D, and in the abstract schema that they inherit from. Accord- ing to the geometry and the semantic depth, distinc- tions are made between the application schemas Build- ingsCore2D, BuildingsExtended2D, BuildingsCore3D and BuildingsExtended3D. It was necessary to analyze the data sources be- fore making a decision on the application schema that would be best for use over the data from the depart- ment of the Czech Office for Surveying, Mapping and Cadastre (including data from the Land Survey Of- fice). Three atabases contain reference data on build- ings: the Information System of the Cadastre of Real Estates (ISKN) and the Information System of Ter- ritorial Identification (ISUI) managed by the Czech Office for Surveying, Mapping and Cadastre and Fun- damental Base of Geographic Data (ZABAGED r) managed by the Land Survey Office. The data in the first two systems refers to the legal status (both are source databases of the Register of Territorial Identi- fication, Addresses and Real Estates), while the data from ZABAGED refers to the status in the terrain. Unfortunately, the data in the databases is not properly connected between these two organizations. The data used for creating the series of datasets for the Buildings theme come from ISKN and ISUI. All data corresponding with the possible content of the Buildings theme has only 2D geometry. Most of the buildings are represented as a polygon of the inter- section of the walls with the ground. Some of the buildings are represented only as the reference points of the buildings, lying somewhere inside the body of the building. The spatial objects to be represented as a building featureType building were clear – buildings themselves. In the case of buildingParts there were two options: data on buildings in ISKN have their parts as inner drawings. However, buildings in ISUI have their parts represented as entries, where each entry consists of technical and economic information, such as number of floors, dwellings, connection to the engineering networks, property value, etc. Among the various options, data for buildings taken both from ISKN and ISUI, with entries from ISUI used as build- ingParts , were considered to be the most usable for implementation. Due to the lack of three dimensional data, only two non–abstract application schemas are applica- ble – BuildingsCore2D which inherits from Build- ingsBase and BuildingsExtended2D, which inherits from BuildingsExtended. The semantic model of BuildingsBase is very flat. It contains four abstract feature types – AbstractConstruction, AbstractBuild- ing, that inherits from AbstractConstruction, Build- ing and BuildingPart, inheriting from AbstractBuild- ing. The only extension given to Building is parts attribute. Its content is a reference to feature(s) of the BuildingParttype. Little semantic information is given about the structure by the AbstractConstruc- tionfeature type from the BuildingsBase application schema: the obligatory Inspire Id and voidable infor- mation about the life cycle of the feature, dates of construction/demolition/renovation, condition, eleva- tion, the name and the height above ground of the structure and an external reference to the spatial ob- ject in another register, e.g. cadastral viewer. The Ab- stractBuilding feature type provides further semantic information on the nature of the building, its current use and the numbers of dwellings, building units and floors. As was mentioned above, source databases contain much more detailed information about build- ings and their parts. Besides technical and economic information, there are links to other spatial objects, such as the cadastral parcel on which the building is constructed and also the delivery points belonging to the building in the source databases. While INSPIRE was being implemented, parcels, municipalities and address points were already implemented (in the scope of INSPIRE themes Cadastral Parcels, Administrative Units and Addresses). Information about connections 293 Michal Med, Petr Souček Acta Polytechnica Figure 3. Building and BuildingPparts shown with default style. between features form various series of datasets, and this is one of the biggest advantages of INSPIRE. It is therefore really important to have links connecting buildings with other features. Otherwise, publication of the Building theme fol- lowing the BuildingsCore2D application schema offers no benefits in comparison with national products pub- lished using data based on the same source databases other than the standardized structure. On the basis of the previous analysis, it was decided to transform data according to the BuildingsExtended2D applica- tion schema . As we stated above in Section 1, application schemas contain structured information about data content and structure in the text form. However, the data itself will be published in the GML 3.2.1 format, which is the format standardized by the Open Geospatial Consor- tium (OGC) [5]. The validity of the data content and structure is ensured by validation against the XML schemas. The Joint Research Center publishes XML schemas for INSPIRE application schemas on its web page http://inspire.ec.europa.eu/schemas/. For the Buildings theme, only three application schemas have corresponding XML schemas that have already been published. Unfortunately, Building- sExtended, BuidlingsExtended2D and BuidlingsEx- tended3D are missing. At the end of 2014, after cor- respondence with Michael Lutz, the JRCs Technical / data modelling contact point for INSPIRE data specifications, it was clear, that JRC will not create XML schemas for the BuildingsExtended application schemas in the near future. It was pointless to publish buildings according to an application schema other than BuildingsExtended2D. It was therefore necessary to write my own XML schemas for the BuildingsEx- tended and BuildingsExtended2D application schemas. Some other problems have appeared in the feature catalogue. In the BuildingsExtended2D application schema, two attributes are used for the number of floors. One of them will contain the number of floors above ground, while the second attribute contains only the number of floors below ground level. In the source databases for the implementation of the Buildings theme in the Czech Republic, there is only one information item about the floors of buildings, and it sums all floors (above ground and below ground) together. Some other problems were found in the code lists for materials that are used, for the current use of buildings, and for the nature of the buildings. The code list values used in ISUI are quite difficult to pair with the values from the INSPIRE code lists. Some of them were transformed into INSPIRE values, while others were left empty. In the future, it could be fixed on the side of transformation between ISUI and INSPIRE compliant data. All the information mediated by problematic code lists is voidable, according to the Data specification on Buildings. Problems and issues on the INSPIRE Buildings theme (and other themes related to topography or cadastre) are reported and discussed in the INSPIRE Thematic Clusters (http:// themes.jrc.ec.europa.eu/groups/profile/209/ topographic-and-cadastral-reference-data). 1.3. Portrayal Chapter “Portrayal” in the Data specification defines rules for layers and styles to be used for portrayal of the spatial objects defined in Specification. These rules are used during implementation of INSPIRE View Services according to the Technical Guidance for the implementation of INSPIRE View Services in the version 3.11 of 4th April 2013 (http://inspire. ec.europa.eu/documents/Network_Services/ TechnicalGuidance_ViewServices_v3.11.pdf). Basically, this guidance shows how to implement view services using the OGC standard for the Web Map Service in version 1.3.0, in accordance with 294 http://inspire.ec.europa.eu/schemas/ http://themes.jrc.ec.europa.eu/groups/profile/209/topographic-and-cadastral-reference-data http://themes.jrc.ec.europa.eu/groups/profile/209/topographic-and-cadastral-reference-data http://themes.jrc.ec.europa.eu/groups/profile/209/topographic-and-cadastral-reference-data http://inspire.ec.europa.eu/documents/Network_Services/TechnicalGuidance_ViewServices_v3.11.pdf http://inspire.ec.europa.eu/documents/Network_Services/TechnicalGuidance_ViewServices_v3.11.pdf http://inspire.ec.europa.eu/documents/Network_Services/TechnicalGuidance_ViewServices_v3.11.pdf vol. 56 no. 4/2016 Implementation of the INSPIRE Theme Buildings Layer Name Layer Title Feature Type(s) BU.Building Building Building BU.BuildingPart BuildingPart BuildingPart Table 1. Layers defined for Portrayal. ISO 19128, and/or the Web Map Tile Service in version 1.0.0. The guidance describes mandatory and optional operations required for the implementation of INSPIRE–compliant View services. The chapter on “Portrayal” defines the human- and machine–readable names of the layers and the default style. The default INSPIRE style will be available in the service, but any additional national style can also be defined. Layers defined for the view service for the Buildings INSPIRE theme are shown in Table 1. For the Build- ings theme, only 2D styles are defined. Originally, this was due to the lack of SLD for 3D data [4]. For the implementation of Buildings in the Czech Republic it is irrelevant at the moment, because no 3D data on geometric representation is available. A Building can be represented as a polygon or as a definition point. A Building Part is represented by border lines or by a definition point. A Building as a polygon is represented as solid gray with a black outline. The definition point of a building is shown as a solid dark gray point without any outline. The colour difference between point and polygon filling is clearly visible. The surface style for a building part is hollow with a solid black outline. However, the point geometry for building parts is a solid grey circle without any outline. It has the same colour as the filling of a polygon in the case of surface geometry for the building. Simply said, the building parts are not visible on the Buildings layer. As can be seen in picture 4, on the building in the north–eastern corner, the building parts points are visible only when they cross the outline of the Buildings polygons. A short–term solution is to define one’s own style, in which a building part point would have a different colour from the building polygon. The long–term solution lies in the hands of JRC, and it involves making an official change of style in the INSPIRE Data specification. This problem has been reported to the INSPIRE Thematic Clusters. 2. Designing and extending INSPIRE schemas The main findings of the Data Specification Analysis are a lack of XML schemas for extended application schemas, expected source of data to use for the imple- mentation and an unfortunate choice of layer styles. The only problem that prevents implementation is the lack of XML schemas, and the main object of the work described in this paper is to deal with this shortcoming. It was necessary to create two appli- cation schemas – one for the BuidlingsExtendedBase abstract application schema and the other for Build- ingsExtended2D, which inherits from the other schema. This work has been supported by the Grant Agency of the Czech Technical University in Prague, under grant No. SGS15/056/OHK1/1T/11. According to the standard, the XML Schema Definition Language (XSD) is defined as a language that offers facilities for describing the structure and constraining the contents of XML documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in an XML vocabulary and uses namespaces, substantially reconstructs and consider- ably extends the capabilities found in XML document type definitions (DTDs). Its purpose is to define and describe a class of XML documents by using schema components to constrain and document the mean- ing, usage and relationships of their constituent parts: datatypes, elements and their content, their attributes and their values. Schemas can also enable additional document information, e.g. normalization and default- ing of attribute and element values. Schemas have facilities for self-documentation [3]. A file in XSD format is also an XML file, so it is suitable to use professional software for editing and creating XML files. The author has personal experience with oXygen software, which is produced by Syncro Soft SRL. The specialized oXygen XML Developer program is used for creating XSD files. This program contains tools that enable better work with XML schemas, including the schema designer and the XSLT editor and debugger. We plan in the next few years to develop very useful XSLT transformations. 2.1. Schema modelling Two XML schemas were designed in order to fulfil ap- plication schemas for the implementation of Buildings with 2D geometry and extended semantics. These schemas inherit a a great deal from the feature types defined in BuildingsCore2D and BuildingsBase. All relations are shown in the Figure 4. A small number of basic components are used in the design of the XML schema: elements, complex types, simple types and attributes. They can be put together in groups or in attribute groups. Compositors and wildcards are used to define the relations among them. Compositors are used for cre- ating content of complex types by other elements, and various types of compositors define various rela- tions between these elements. Wildcards can serve as any element, or as any attribute, and they are used mainly in abstract elements. Finally there are direc- tives import, include and redefine for using and extending elements from other XML schemas. Fea- ture types in XML schemas BuildingsExtendedBase and buildingsExtended2D are represented by complex type elements. Most of the relations creating their content are sequence compositors.Each element has 295 Michal Med, Petr Souček Acta Polytechnica Figure 4. The whole model of featureTypes of the BuildingsBase, BuildingsCore2D, BuildingsExtended and BuildingsExtended2D application schemas. Figure 5. Building element from the BuildingsExtended2D XML schema shown in the design mode of the oXygen Developer software. annotations, containing the name and the definition of the element. Each element has a given type, which has to be present in the current or imported XSD file. Complex types can include compositors such as sequence, that allow other elements to be used as a content. In Figure 5 there is element Building with annotation and defined complex type contain- ing sequence compositor, that extends content by another element (buildingInfo). The design of the XML schema began by importing inherited XML schemas and defining their names- paces. Iimported schemas include schemas needed for using certain attributes, such as BaseTypes, GML or GMD, and also INSPIRE Addresses, Cadastral Parcels and Geographical Names. It is much better to use as an attribute type, a data type, that has already been designed in another schema, rather than create a new one. Figure 4 shows AbstractOtherConstruc- tion, AbstractInstallation and AbstractBuildingUnit and OtherConstruction, Installation and BuildingUnit, which inherits from them. These feature types are not use in the Czech implementation of the Buildings theme, but are they are included in the XML schema. We set out to design the XML schemas as close as possible to the application schemas described in the data specification document, including feature types not intended to be used in the implementation itself. The most important feature types for the imple- mentation are Building and BuildingPart from the application schema BuildingsExtended2D. They in- herit both from BuildingInfo and homonymous feature type from the application schema BuildingsCore2D. Technically, it is not really possible for one feature type to inherit from more than one other feature type. All semantic information given by the base ap- plication schemas and geometry representation are inherited from the Building (or BuildingPart) feature type, and extended semantics are to be inherited from the BuildingInfo feature type, which is abstract. The solution of the problem with multiple inheritance was solved by creating an instance of BuildingInfo and cre- ating a new attribute of the Building feature type, that contains this instance of BuildingInfo. It is not pos- sible to create instances of abstract feature types, so it was necessary to design a new BuildingInfo feature type in the XML schema BuildingsExtended2D, which 296 vol. 56 no. 4/2016 Implementation of the INSPIRE Theme Buildings inherits from the BuildingInfofeature type from the BuildingsExtendedBase schema, but is not abstract. According to the latest information received from JRC, the newly-created XML schemas presented in this paper are currently being tested for use as offi- cial XML schemas for the BuildingsExtendedBase and BuildingsExtended2D application schemas1. 3. Publication of INSPIRE data The whole implementation process will escalate with the publication of data according to Commission Reg- ulations No. 976/2009 of 19th October 2009 and No. 1311/2014 of 10th December 2014, amending Regulation No. 976/2009. The ways in which the data will be published are described in detail in the Tech- nical Guidance documents for the implementation of INSPIRE Network services. For publication of the data, specific details are given in Download Services and figuratively in View Services [6]. The publication process consists of three stages: data transformation, setting up services, and creation of metadata. 3.1. Transformation process Initially, the data is stored in source database(or databases). These databases usually have their own purpose-built structure. INSPIRE-compliant datasets can have various purposes. The data transformation process therefore has more than one stage (Fig. 7). First, the data from the source databases has to be transformed into a publication database. In the tables of this database, the data structure basically respects the structure of Source Databases (Fig. 6). There are some more tables that ensure interoperability of the data from two (or more) databases. For the purposes of data publication, database views are created in the publication database. The views use data from the ta- bles in the source structure, putting them into the IN- SPIRE structure, more or less following the INSPIRE application and the XML schemas. From the database views, the data is transformed on the fly into GML for- mat in the structure valid against XML schemas. An exception is the publication of pre–defined data files (one for each municipality). These files are generated daily, and they are valid until early in the morning of each day (all changes are published the next day, early in the morning). In the first stage of transformation, the biggest prob- lem was to unify identifiers of the buildings and their parts from different databases. Table PUB_mustek was created, as shown in the Figure 6. Attribute Id in this table is automatically generated from the sequence and is further used as a unique INSPIRE feature identifier. Connecting the data through this identifier allows information about the same build- ing from different databases to be merged. In the ISKN database, there is basically better geometric 1This was said by Robert Tomas at the INSPIRUJME SE . . . 2015 international conference, which was held on Novem- ber 24–25, 2015 in Bratislava, Slovakia information, and it contains a link to a cadastral par- cel. However, the ISUI database contains much more detailed semantic information, and there is also a con- nection to an address, as an attribute of a Building Part. When the database views were being created, it was important to decide which source of information is more relevant in cases when the two databases pro- vide different values for the same attribute. This can happen for geometry, link to municipality or part of municipality, and current use of buildings. The most frequent case is multiple geometry. The first choice of geometry is polygonal geometry coming from ISKN, the second choice is point geometry from ISUI, and the last choice is to use the point geometry coming from ISKN. In many cases, ISUI also contains polygo- nal geometry, but it is always taken from ISKN, which is preferable. Two main database views are created for the publication of feature types – Buildings and BuildingParts – and some more are created for the complex types used in the GML structure, e.g. Exter- nalReference or BuildingGeometry2D. The names of the attributes in the database views are the same as the names of the GML attributes. Data structures are given by XML schemas, but the content also depends on local data. In order to investigate the possibilities, sample files were created. Each sample file tries to cover one of the possibilities. Samples vary according to the geometry type and source, or the number of building parts belonging to the building. Further information is available in [7] (in Czech language). With the samples come out a need of converting national code lists into INSPIRE code lists as well. For every code list is created new converter table in the publication database. Accord- ing to the latest version of sample file, third step of transformation is done. The third step of the transformation transforms data from the publication database into GML form. There are two cases in which this transformation is invoked. This is consistent with the ways in which the data is published – data is published either through direct access or as pre–defined files. Pre–defined files are generated daily for a predetermined area. For the Buildings theme, each file contains all features in the area of a single municipality. These files are generated each day in the early morning hours. Direct access via the Web Feature Service provides recent data (no more than two hours old), but each individual request goes straight into the database. These two modes are recommended by the Technical Guidance for implementing the INSPIRE Download Service in version 3.1 [8]. 3.2. Services Two kinds of services are required for the publica- tion of INSPIRE data – Download Services and View Services. The furtermore services are considered as INSPIRE Network Services. Discovery Service is used 297 Michal Med, Petr Souček Acta Polytechnica Figure 6. Schema of tables of the publication database related to the Buildings theme. Figure 7. Schema of the data transformation process. for searching in the metadata records of data and services present in the metadata catalogue, Transfor- mation Services are used to transform schemas and coordinates [6]. Direct access to the data or to pre–defined datasets is allowed by the Download service. Technical Guid- ance for the implementation of Download Services contains a set of recommendations and requirements referencing the standards ISO 19142 and ISO 19143 standards and/or standard for ATOM. ISO standards describe the use and the conformance classes of the Web Feature Service as defined in the OGC stan- dard [9]. The basic requirements for INSPIRE compli- ant service are the publication of pre–defined datasets via either ATOM or WFS, and a direct access down- load service using WFS. The quality of the INSPIRE Download Services provided by the Czech Office for Surveying, Mapping and Cadastre were tested by the Technical University of Ostrava [10]. Another service used for access to the data is the View service. HOwever, a user does not get the data itself in the GML format, only an its image of the data. Technical Guidance for the implementation of View Services uses references to ISO standard 19128, referring to the Web Map Service as defined in the OGC standard [11]. The minimum requirements for the INSPIRE service is the usage of GetMap and GetCapabalities operations. GetCapabilities is will be extended according to the Technical Guidance. The appearance of the data images returned as the WMS Service response depends on the portrayal defined in Section 1.3. Implementation of the INSPIRE services is usually a part of the Spatial Data Infrastructure (SDI). At the Czech Office for Surveying, Mapping and Cadastre, the Marushka® program is used both for transfor- mation process and for setting up services on the transformed data. 3.3. Metadata Without information about the data, the data itself is useless. The data therefore has to be provided with metadata records. The metadata is to contain infor- mation about the origin of the data, about the data provider, the quality and the date, and is to be consis- tent to the ISO 19115 standard. Services are also to be provided with metadata. The authoritative document for the services metadata is the ISO 19119 standard. 298 vol. 56 no. 4/2016 Implementation of the INSPIRE Theme Buildings All INSPIRE recommendations and requirements on both data and services metadata can be found in the INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and on EN ISO 19119 [12]. The ISO 19115 standard is widely used in the Czech Republic, but conformance with ISO 19115 does not in itself mean that the metadata is INSPIRE–compatible [13]. In the Czech Republic, the National Metadata Catalogue is managed and pub- lished by the Technical Working Group for Metadata, established under the Coordinating Committee for INSPIRE (KOVIN). This metadata Catalogue fully covers the INSPIRE requirements on metadata. Some organizations (e.g. the Czech Office for Surveying, Mapping and Cadastre) have their own Metadata Profiles, which extend the National Metadata profile. Consistency of metadata records can be checked in the INSPIRE metadata validator, which is accessible through the INSPIRE geoportal [14]. This validator is very complex, and reflects not only metadata conformity, but also quality and re- quirements for services. Metadata is created in the oXygen XML Editor program, which is specialized in developing and also in editing XML files. Metadata records are actually written as templates, because only a small number of metadata elements are up- dated frequently, and these elements are generated automatically from the database with a daily update period. Basically, this concerns information about the date of the metadata, the date of the last update of the data, and information about data (and/or service) quality. Templates are stored in the database, as is the information that is updated. Metadata is updated daily. Metadata are not 100 % conform to the INSPIRE validator, because the rules on the validator are fre- quently changed, and some of the conditions required for full conformity are not achievable at the present time. This problem is connected with the representa- tion of the data as INSPIRE data sets or as INSPIRE series of data sets. According to INSPIRE, every data set is to have its own download service and a single metadata record. Moreover, there is to be one meta- data record for the whole set of data sets belonging to a single theme, called the INSPIRE Series Metadata record. For Buildings (and for most other INSPIRE themes implemented in the Czech Republic), a single data set presents the data in a single pre-defined file, e.g. a municipality. However, the download service covers all data, so the metadata of the service refers to the series as a coupled resource. This has to be man- aged by the Maintenance and Implementation Group (MIG), an INSPIRE body comprising representatives from member states. 4. Conclusions The analysis of the Data specification on Buildings in version 3.0 from the 10th December 2013, revealed that is was necessary for a meaningful implementation of the INSPIRE Buildings theme, it was necessary to create XML schemas following the BuildingsExtended- Base and BuildingsExtended2D application schemas. The joint Research Center by European Commission does have not enough resources to cover everything, thus it has to have priorities. Some problems appeared during the design of the schemas. The application schema anticipated multi- ple inheritances for the Building and BuildingPart feature types. However, this cannot be designed easily and effectively. It therefore has to be dealt with in some other way that does not correspond with the application schema. For future work in the field, it will be necessary to design new models. Experience of creating XML schemas according to the existing appli- cation schemas and models has made clear the need for closer cooperation between designing the model and creating its technical representation, i.e. the XML schema. The opportunities provided by the technical representation tools are very broad, but they are not unlimited. Datasets created according to the models defined by the INSPIRE Directive are not always ideal for the needs for data usage on the national level. This is because the INSPIRE models are created as a common minimum across almost 30 European countries. The full potential of the standardization of data using the INSPIRE Directive lies in the common way of sharing information in the structured form. INSPIRE schemas will increasingly be extended for national needs, but it is necessary to keep to the basics of the INSPIRE Directive. All the datasets across Europe will then have common ground on which all the datasets will be understandable. Designers of extended models must be aware of the technical possibilities. The source data for implementing the Build- ings theme in the Czech Republic is stored in three databases: ISKN, ISUI and ZABAGEDr. ZABAGED has no links to other databases. How- ever, this will probably change in the next few years. Data from the source databases is transformed into a publication database and, according to the sample file, it is transformed into the GML format. According to the idea of reusing spatial information in Europe, the data will be managed on the level where it is most effective and will not be copied. The idea here is that further datasets are published from one or more data storage, but no data is copied, INSPIRE thoughts exactly The data itself has links with other data, preferable by URI. Acknowledgements This work has been supported by the Grant Agency of the Czech Technical University in Prague, under grant SGS15/056/OHK1/1T/11. References [1] CENIA. Koordinační výbor pro INSPIRE (KOVIN), 2015. Accessed: 2015-12-08, http://inspire.gov.cz/kovin. 299 http://inspire.gov.cz/kovin Michal Med, Petr Souček Acta Polytechnica [2] Koordinační výbor pro INSPIRE. Strategie implementace INSPIRE, 2015. http://inspire.gov.cz/sites/default/files/ documents/StrategieImplementaceINSPIRE.pdf. [3] W3C. W3C XML schema definition language (XSD) 1.1 part 1: Structures, 2012. http://www.w3.org/TR/xmlschema11-1/. [4] INSPIRE Thematic Working Group Buildings. D2.8.III.2 INSPIRE Data Specificationin on Buildings – Technical Guidelines, 3rd edn., 2013. http://inspire. ec.europa.eu/documents/Data_Specifications/ INSPIRE_DataSpecification_BU_v3.0.pdf. [5] C. Portele. Geography Markup Language Encoding Standard. Open Geospatial Consortium Inc., 3rd edn., 2007. http://opengeospatial.org/files/?artifact_ id=20509. [6] European Commission. Network services. Accessed: 2015-12-08, http://inspire.ec.europa.eu/index.cfm/pageid/5. [7] M. Med. Pozadí tvorby datových sad v souladu se směrnicí INSPIRE na ČÚZK. Geodetický a kartografický obzor 61(103)(5):94–100, 2015. http://egako.eu/ wp-content/uploads/2015/05/gako_2015_051.pdf. [8] Initial Operating Capability Task Force for Network Services. Technical Guidance for the implementation of INSPIRE Download Services, 3rd edn., 2013. http://inspire.ec.europa.eu/documents/Network_ Services/Technical_Guidance_Download_Services_ v3.1.pdf. [9] P. P. A. Vretanos. OpenGIS Web Feature Service 2.0 Interface Standard. Open Geospatial Consortium Inc., 2nd edn., 2010. http://opengeospatial.org/files/? artifact_id=39967. [10] A. J. Horák Jiří, Růzicka Jan. Performance testing of download services of COSMC. Geoinformatics FCE CTU 10:5–14, 2013. doi:10.14311/gi.10.1. [11] J. de la Beaujardiere. OpenGIS Web Map Server Implementation Specification. Open Geospatial Consortium Inc., 1st edn., 2006. http:// opengeospatial.org/files/?artifact_id=14416. [12] Drafting Team Metadata and European Commission Joint Research Center. INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119, 1st edn., 2013. http://inspire.ec.europa.eu/documents/Metadata/ MD_IR_and_ISO_20131029.pdf. [13] J. Růzicka. ISO 19115 for GeoWeb services orchestration. Geoinformatics FCE CTU 3:51–66, 2008. doi:10.14311/gi.3.5. [14] European Commission. INSPIRE geoportal. Accessed: 2015-12-08, http://inspire-geoportal.ec.europa.eu/. [15] M. Med, P. Souček. Development and testing of inspire themes addresses (ad) and aministrative units (au) managed by cosmc. Geoinformatics FCE CTU 11:77–83, 2013. doi:10.14311/gi.11.6. [16] P. Tryhubová. Evropská směrnice INSPIRE. Geoinformatics FCE CTU 1:176–183, 2006. doi:10.14311/gi.1.20. [17] J. Poláček, P. Souček. Implementing INSPIRE for the Czech Cadastre of Real Estates. Geoinformatics FCE CTU 8:9–16, 2012. doi:10.14311/gi.8.1. 300 http://inspire.gov.cz/sites/default/files/documents/Strategie ImplementaceINSPIRE.pdf http://inspire.gov.cz/sites/default/files/documents/Strategie ImplementaceINSPIRE.pdf http://www.w3.org/TR/xmlschema11-1/ http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_BU_v3.0.pdf http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_BU_v3.0.pdf http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_BU_v3.0.pdf http://opengeospatial.org/files/?artifact_id=20509 http://opengeospatial.org/files/?artifact_id=20509 http://inspire.ec.europa.eu/index.cfm/pageid/5 http://egako.eu/wp-content/uploads/2015/05/gako_2015_051.pdf http://egako.eu/wp-content/uploads/2015/05/gako_2015_051.pdf http://inspire.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf http://inspire.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf http://inspire.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf http://opengeospatial.org/files/?artifact_id=39967 http://opengeospatial.org/files/?artifact_id=39967 http://dx.doi.org/10.14311/gi.10.1 http://opengeospatial.org/files/?artifact_id=14416 http://opengeospatial.org/files/?artifact_id=14416 http://inspire.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf http://inspire.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf http://dx.doi.org/10.14311/gi.3.5 http://inspire-geoportal.ec.europa.eu/ http://dx.doi.org/10.14311/gi.11.6 http://dx.doi.org/10.14311/gi.1.20 http://dx.doi.org/10.14311/gi.8.1 Acta Polytechnica 56(4):291–300, 2016 1 Analysis of the INSPIRE Buildings theme 1.1 Introduction to the Buildings theme 1.2 Data content and structure 1.3 Portrayal 2 Designing and extending INSPIRE schemas 2.1 Schema modelling 3 Publication of INSPIRE data 3.1 Transformation process 3.2 Services 3.3 Metadata 4 Conclusions Acknowledgements References