ANALYSIS AND IMPLEMENTATION OF APPLICATION SCHEMAS FOR THE INSPIRE BUILDINGS THEME

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 BuildingsExtendedBase abstract XML schema was also needed when using the previous schemas. There is now a need to create these missing XML schemas.


Analysis of the INSPIRE Buildings theme
The 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 national coordinating body for this purpose was set up in each participating country.Coordination is ensured on the national level.In the Czech Republic, implementation 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 promoting 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 strategy 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 document 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 administers 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 coordinator has been appointed for some of the other themes, but they have not yet been fully implemented.Full implementation requires harmonized data, services 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.

Introduction to the Buildings theme
The newest version of the Data Specification on Buildings 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 publishing 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 information about the content.The key chapter for transforming the data is under the heading Data Content and Structure.This chapter provides an overview and a detailed description of the application schemas, including code lists, enumerations, geometric representation 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 "Portrayal".This chapter defines default styles for use in View Services.The most important chapters for implementation, and the chapters that are most analyzed, are "Data content and structure" and "Portrayal".
According to the specification, two different feature types shall be implementedbuilding 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].

Data content and structure
Six application schemas are defined in the Data specification for the Buildings theme (Fig. 2).
Two of the schemas contain only abstract feature types.As in object programming, this means that a single feature cannot be an instance of an abstract feature type, but other feature types can inherit attributes from them.These two abstract application schemas are called BuildingsBase and BuildingsExtended, and they contain basically all semantic information.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.According to the geometry and the semantic depth, distinctions are made between the application schemas Build-ingsCore2D, BuildingsExtended2D, BuildingsCore3D and BuildingsExtended3D.
It was necessary to analyze the data sources before making a decision on the application schema that would be best for use over the data from the department of the Czech Office for Surveying, Mapping and Cadastre (including data from the Land Survey Office).
Three atabases contain reference data on buildings: the Information System of the Cadastre of Real Estates (ISKN) and the Information System of Territorial Identification (ISUI) managed by the Czech Office for Surveying, Mapping and Cadastre and Fundamental Base of Geographic Data (ZABAGED ) 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 Identification, 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 intersection 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 applicable -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, AbstractBuilding, that inherits from AbstractConstruction, Building and BuildingPart, inheriting from AbstractBuilding.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 AbstractConstructionfeature type from the BuildingsBase application schema: the obligatory Inspire Id and voidable information about the life cycle of the feature, dates of construction/demolition/renovation, condition, elevation, the name and the height above ground of the structure and an external reference to the spatial object 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 buildings 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 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 following the BuildingsCore2D application schema offers no benefits in comparison with national products published 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 application 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 Consortium (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 correspondence 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 BuildingsExtended 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).

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.  1.For the Buildings 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.

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 implementation 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 application 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 considerably 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 meaning, 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 defaulting 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.

Schema modelling
Two XML schemas were designed in order to fulfil application 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 creating content of complex types by other elements, and various types of compositors define various relations between these elements.Wildcards can serve as any element, or as any attribute, and they are used mainly in abstract elements.Finally there are directives import, include and redefine for using and extending elements from other XML schemas.Feature 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  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 containing sequence compositor, that extends content by another element (buildingInfo).
The design of the XML schema began by importing inherited XML schemas and defining their namespaces.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 AbstractOtherConstruction, 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 implementation are Building and BuildingPart from the application schema BuildingsExtended2D.They inherit 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 application 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 creating a new attribute of the Building feature type, that contains this instance of BuildingInfo.It is not possible to create instances of abstract feature types, so it was necessary to design a new BuildingInfo feature type in the XML schema BuildingsExtended2D, which 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 official XML schemas for the BuildingsExtendedBase and BuildingsExtended2D application schemas1 .

Publication of INSPIRE data
The whole implementation process will escalate with the publication of data according to Commission Regulations 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 Technical 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.

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 tables 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 format 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 problem 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 building from different databases to be merged.In the ISKN database, there is basically better geometric information, and it contains a link to a cadastral parcel.However, the ISUI database contains much more detailed semantic information, and there is also a connection 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 provide 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 polygonal 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.According 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].for searching in the metadata records of data and services present in the metadata catalogue, Transformation Services are used to transform schemas and coordinates [6].

Services
Direct access to the data or to pre-defined datasets is allowed by the Download service.Technical Guidance 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 standard [9].The basic requirements for INSPIRE compliant service are the publication of pre-defined datasets via either ATOM or WFS, and a direct access download 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 transformation process and for setting up services on the transformed data.

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 information about the origin of the data, about the data provider, the quality and the date, and is to be consistent to the ISO 19115 standard.Services are also to be provided with metadata.The authoritative document for the services metadata is the ISO 19119  This validator is very complex, and reflects not only metadata conformity, but also quality and requirements 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 updated 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 frequently changed, and some of the conditions required for full conformity are not achievable at the present time.This problem is connected with the representation 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 metadata 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 managed by the Maintenance and Implementation Group (MIG), an INSPIRE body comprising representatives from member states.

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 multiple 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 application 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 Buildings theme in the Czech Republic is stored in three databases: ISKN, ISUI and ZABAGED .ZABAGED has no links to other databases.However, 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.

Figure 1 .
Figure 1.Example of the feature catalogue for the Building spatial object.

Figure 2 .
Figure 2. Application schemas for the Buildings theme.

Figure 3 .
Figure 3. Building and BuildingPparts shown with default style.

Figure 5 .
Figure 5. Building element from the BuildingsExtended2D XML schema shown in the design mode of the oXygen Developer software.
Two kinds of services are required for the publication of INSPIRE data -Download Services and View Services.The furtermore services are considered as INSPIRE Network Services.Discovery Service is used

Figure 6 .
Figure 6.Schema of tables of the publication database related to the Buildings theme.

Figure 7 .
Figure 7. Schema of the data transformation process.
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.

Table 1 .
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 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 standard.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 published 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].