Geoinformation Metadata in INSPIRE and SDI: Understanding. Editing. Publishing

Lecture Notes in Geoinformation and Cartography Series Editors: William Cartwright, Georg Gartner, Liqiu Meng, Michael P. Peterson

For further volumes: http://www.springer.com/series/7418

.

Leszek Litwin

l

Maciej Rossa

Geoinformation Metadata in INSPIRE and SDI Understanding. Editing. Publishing

Leszek Litwin Institute of Spatial and Cadastral Systems Dworcowa 56 44-100 Gliwice Poland [email protected]

Maciej Rossa General Directorate for Environmental Protection Wawelska 52/54 00-922 Warsaw Poland [email protected]

ISSN 1863-2246 e-ISSN 1863-2351 ISBN 978-3-642-15861-2 e-ISBN 978-3-642-15862-9 DOI 10.1007/978-3-642-15862-9 Springer Heidelberg Dordrecht London New York Library of Congress Control Number: 2011932430 # Springer-Verlag Berlin Heidelberg 2011 This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilm or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Cover design: deblik Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

Preface

On May 15, 2007, Directive 2007/2/EC by European Parliament and the Council entered into force on establishment of European Spatial Data Infrastructure (ESDI). The assumption is that ESDI is to be the sum of National Spatial Data Infrastructures. One of the first stages of building the ESDI is the establishment by Member States of metadata for spatial data series, collections and services, in specified and legally sanctioned terms. Metadata, defined as “data on data”, shall serve a number of purposes in the ESDI, amongst others being the publication of information on spatial data resources made available under SDI by many institutions, including governmental ones. Additionally, establishment of metadata allows inventorying of spatial data resources and related services, and makes them more accessible to citizens of Member States (as well as Internet users). Resources of spatial data have a huge value, which is also commercial. Based on a EU report during the early twenty-first century spatial data constitutes 60–80% base for issuance of administrative decisions. Furthermore spatial data is required in public safety, spatial administration, planning, transport, business, as well as military and intelligence sectors. Although the commercial value of spatial data is estimated in the billions of Euro, still the access to spatial data is inhibited due to hitherto highly difficult ways of making such data available. Describing spatial data using meta data should then allow more efficient and cost-effective utilization and management of such resources. Creation of metadata also requires familiarization with relevant ISO standards (series 19100), Open Geospatial Consortium (OGC) standards, and World Wide Web Consortium (W3C) standards. It also, or perhaps most of all, requires understanding of the role and significance of metadata to all persons utilizing – consciously or not – the resources of spatial data.

v

vi

Preface

Our objective was to discuss certain important matters concerning metadata – we hope we have achieved this objective. We hope that information included in this book shall help you to “understand, edit and publish geoinformation metadata”. Gliwice, Poland Warsaw, Poland

Leszek Litwin Maciej Rossa

Acknowledgements

We wish to offer our thanks to all the people who contributed to this book, most of all the Authors of publications quoted here and persons with whom we had opportunity to discuss the subject of metadata. Special thanks are in order to Ms. Urszula Mizia and Mr. Paweł Czepelak.

vii

.

Contents

1

2

Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Is Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition of Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata in Geoinformation (Geomatics) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Role of Metadata in Geoinformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Spatial Data Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Benefits of the Use of Metadata in Geoinformation . . . . . . . . . . . . . . . . . . . Responsibilities of the Creation of Geoinformation Metadata . . . . . . . . . . . . Metadata in the European Infrastructure for Spatial Information INSPIRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata in the Polish Spatial Data Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . Introduction to PSDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Existing National Laws Relating to Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . Standards and Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Why Do We Use Standards? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standards, Norms, Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard and Norm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . To Whom for a Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standardisation Organisations in the Field of Geoinformation (Geomatics) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How Geoinformation Standards Are Developed . . . . . . . . . . . . . . . . . . . . . . . . . . . OGC Specifications or ISO 19100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ISO 19100 Series of Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OGC Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata Standards for Geoinformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ISO 19115:2003 Geographic Information: Metadata . . . . . . . . . . . . . . . . . . .

1 1 3 4 6 7 7 9 10 10 30 30 30 39 39 39 40 41 42 43 48 64 65 65 69 69

ix

x

Contents

ISO/TS 19139:2007 Geographic Information: Metadata: XML Schema Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 ISO 19119:2005 Geographic Information: Services . . . . . . . . . . . . . . . . . . . . 71 ISO 19135:2005 Geographic Information: Procedures for Item Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3

Metadata Profiles Based on ISO 19115 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Is a Metadata Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Structure of Metadata Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Metadata Elements and Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packages (Sections) of Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Metadata Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata Entities in the ISO 19115 Documented by Other ISO Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Types and Their Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extensions of Metadata Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples of Metadata Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mandatory Metadata Profile According to ISO 19115 Standard . . . . . . . Base Profile (Core) of ISO Metadata for Spatial Datasets . . . . . . . . . . . . . . INSPIRE Metadata Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75 75 76 77 78 78 78 83 85 87 87 87 88

4

Metadata Description Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 What Is the XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 XML Schema and Metadata Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 XML Schema and ISO 19139 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Other Applications of XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Applications of the XML to Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 GML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5

Applications for Creating and Publishing Geoinformation Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requirements for Metadata Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Review and Comparison of Selected Metadata Editors . . . . . . . . . . . . . . . . Requirements for Metadata Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples of Metadata Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

113 113 113 115 122 123

How to Properly Create Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles and Good Practices for Creating Metadata . . . . . . . . . . . . . . . . . . . . Regulatory Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Resources Should Be Described by Metadata . . . . . . . . . . . . . . . . . . . Stages of Metadata Creation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Metadata Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

127 127 128 129 130 131

6

Contents

Rules for the Use of Special Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Principles of Setting Up a Hierarchy Consisting of Series and Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure of Metadata Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadata File Format and Application Schema . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of the Construction of Multilingual Versions of Metadata . . . . Naming Principles for Data Sets and Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Time Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Contact Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Categorizing Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Rules for Creating Metadata Files Identifiers . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Information on Metadata Standard Version . . . . Principles of Specifying General Information Describing the Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Restrictions to the Use of Resources . . . . . . . . Principles of Specifying Information on the Maintenance of a Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Spatial Coverage of the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Spatial Reference System . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Information on the Distribution of the Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Quality of the Resource . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Information on Geoinformation Services . . . . . . Principles of Specifying Information for Individual Elements of Metadata About Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Information for Metadata Elements Identifying the Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Information for Individual Metadata Elements Regarding Classification of Spatial Data and Services . . . . . . . . Principles of Specifying Information for Metadata Elements Regarding Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Information for Individual Metadata Elements Regarding Geographic Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Information for Individual Metadata Elements Regarding Temporal References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Information for Individual Items of Metadata Regarding Quality and Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Information for Individual Metadata Elements Regarding Conformity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Information for Metadata Elements Regarding Conditions Applying to Access and Use . . . . . . . . . . . . . . . . . . . . . . Principles of Specifying Information for Metadata Elements Regarding Limitations on Public Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xi

131 132 132 132 133 133 134 135 135 136 136 137 137 138 139 139 140 140 141 141 142 142 143 143 144 144 145 145 146 146

xii

Contents

Principles of Specifying Information for Metadata Elements Regarding Organisations Responsible for the Establishment, Management, Maintenance and Distribution of Spatial Data Sets and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Examples of Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Examples of Metadata Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explanations to the Following Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name and Name of Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Short Names and Domain Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Descriptors: Mandatory/Conditional/Optional . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mandatory (M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conditional (C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Optional (O) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maximum Number of Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 1: Base Profile (Core), ISO 19115 154 . . . . . . . . . . . . . . . . . . . . . . . . . Example 2: INSPIRE Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

151 151 151 152 152 152 152 153 153 153 153 154 158

About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

165

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

167

7

Chapter 1

Metadata

What Is Metadata Imagine that we are in a great library filled with thousands of books and we want to find all the books about, for example, butterflies. These books are of different authors, issued over considerable span of years, having various titles and are placed on some shelves of many bookcases, and it just so happens that there is no one around who could help us (Fig. 1.1). In this situation the only solution is to use the library catalogue (see Fig. 1.2), which contains brief information on books kept in the library, such as: title, author’s name, year of publication, publisher, “keywords”, numbers (indexes) and other information which allow to locate bookcases and shelfs where the books of your interest can be found. With these brief descriptions, containing concise information about each book and its location in the library, we can quickly find, among thousands of books, the ones that interest us. These brief descriptions of books in the library are being considered as metadata and consequently, library catalogue can be regarded as a classic example of a metadata set. Therefore, every one of us who had used library catalogue has already used metadata. Modern catalogues of metadata of libraries take the form of computer databases that are inter-connected via the Internet. The use of computer nets facilities, search for data of interest is much easier, faster and give possibility of searching through libraries located thousands of miles away, such as the Library of Congress (http:// catalog.loc.gov/) (Fig. 1.3) without moving from your computer.

L. Litwin and M. Rossa, Geoinformation Metadata in INSPIRE and SDI, Lecture Notes in Geoinformation and Cartography, DOI 10.1007/978-3-642-15862-9_1, # Springer-Verlag Berlin Heidelberg 2011

1

2

Fig. 1.1 Library

Fig. 1.2 Library catalogues

1 Metadata

Definition of Metadata

3

Fig. 1.3 Library of Congress online catalogue

Definition of Metadata Metadata are descriptively defined as data about data (information about contents of data). So, they are “data” with the prefix “meta” which comes from Greek and means: “among”, “between”, “after”, “behind” or “change”, while in science it is used with the meaning “above”, “beyond”, “of something in a different context”. Metaphysics – it is knowledge “beyond physics” Metascience – means “science about science” Metaknowledge – “knowledge about knowledge” Metadata – “data (information) about contents of data” Creating and using metadata is indispensable for large data sets, which are stored in computer files or in “analogue” form – like books in a library.

In the systems of electronic document management, the metadata consist of specification of documents containing the basic information describing the documents. In the case of databases, the metadata consist of, for example, definitions of tables, views, keys, etc.

4

1 Metadata

Metadata in Geoinformation (Geomatics) The basis for the functioning of the geoinformation – GIS, LIS, SIS, etc. – and many sciences with the prefix “geo” – Geomatics, Geodesy, Geology, Geography – are spatial data and related descriptive data (attributes). Spatial data take the form of computer files in various vector formats (e.g., shape), raster formats (e.g., GeoTIFF) or descriptive formats (e.g., GML, SWD). Spatial data are gathered mostly in the databases but can be stored in files directly on your hard disk (or other storage medium). Gathering data in the databases makes it easier to manage, update, share or exchange them. Spatial data that exist in “analogue” form also may, or rather should be described by metadata – library being a good example again. Currently, spatial data infrastructures (SDI) are to be created that access to the data becomes as easy as to the books in the library. Development of SDI should ensure connection between spatial databases via networks (Internet, Intranet). As a result, it will be possible (in part already is) to have access to vast resources of spatial data through a computer. But, there are the questions: how to navigate through these data? How to find just the data that are needed? Who created the data and who distributes/sells them? Are they up-to-date? The answer is evident . . . using metadata. As classic example of a metadata set for spatial data as the library catalogue for books, are marginalia, which have been used for centuries. These descriptions of maps contain information on the emblem and name of the sheet, used symbols (legend), author, date of issue, etc. (Fig. 1.4). In practice, metadata take the form of tags or markers, which allow describe and identify all types of information, including geoinformation. The metadata can describe each of the hierarchy levels of resources and different degrees of details – they can describe the whole systems and their discrete components – the smallest indivisible components of the system. In the geoinformation, metadata may relate to the entire project, individual sheet of a map or aerial photograph, as well as to the class of objects (object type) in a given set, a concrete instance of an object, or even to the type of attributes or attribute itself. They can also characterise the functions and procedures, models and even software or computer hardware [PN-EN ISO 19115:2005]. However, in most cases, they describe spatial data sets, spatial data set series and related services (web services, e.g., geoportals). Development of such metadata is required by the INSPIRE Directive. At the most basic level, metadata should characterise an element by answering at least the following questions: “What?, Why?, When?, Who?, How?”, and in the case of metadata for geoinformation, additional question is “Where?”. What? – what it is and what it refers to Why? – to what purpose it was created When? – when it was produced, published and updated Who? – who developed it

Metadata in Geoinformation (Geomatics)

5

Fig. 1.4 Marginalia of geological map as an example of metadata

How? – how it was produced, is it reliable, how you can get access to this Where? – what area (space) it refers to It is assumed that a properly prepared metadata describing spatial data set, should provide information on: the location and type of objects and their attributes, origin, accuracy, level of detail and timeliness of the data set, applied standards, property rights and copyright, rates, terms and conditions of obtaining access to data collection and their use for a specific purpose (Gaz´dzicki 2003).

To ensure the functioning of metadata in computer networks (Internet/Intranet) and to achieve full interoperability between meta-information systems (metadata), it is necessary that both the metadata and these systems are based on clearly defined standards for geoinformation.

6

1 Metadata

Types of Metadata According to the definition proposed by the GSDI (Global Spatial Data Infrastructure) organisation, three levels of metadata and associated three types of metadata can be identified (Gaz´dzicki 2003; The SDI Cookbook 2004). The primary metadata type is discovery metadata. They are used to select spatial data sets and/or spatial data services that may be of interest to the user with specific requirements. This metadata type answers the questions: “what?, why?, when? who?, where?, how?”. In the case of spatial data, discovery metadata provide basic information including: • • • • •

Name and description of the spatial data set (abstract/summary) Basic purpose and scope of spatial data Date of acquisition and update of spatial data Producer, provider and main users of spatial data Area to which data relate – defined by the co-ordinates, geographical names or administrative subdivisions • Structure of the set and method of access to spatial data Another type of metadata is exploration metadata. They contain more detailed information to allow the user to: • Evaluate the properties of the spatial data set • Determine the suitability of the spatial data set in terms of needs • Contact the custodian of the spatial data for further information (conditions of use, etc.) Exploration metadata answer the following questions: • • • •

What is the content of the spatial data resource? What is their accuracy? What is the origin of the source data? What is the frequency of updates?

Another type of metadata is called exploitation metadata. This type defines the set of properties that are needed to read and transfer the data and for data interpretation and practical use by the user’s software. These metadata gives answers to the following questions: • • • •

What is a co-ordinate system? What is the format of spatial data? How to acquire/buy the spatial data? How to import the data into user’s application?

These three levels of metadata types and corresponding metadata form the hierarchical structure of choices (decisions) made by users and enabling them to determine which data sets are within their interests, which fulfil their requirements, how to access them as well as how to transfer selected spatial data and use them in an appropriate manner according to their needs (Gaz´dzicki 2003).

The Role of Metadata in Geoinformation

7

Currently, a combination of discovery and exploration metadata is most commonly used. However, as practice shows, the most desired information is a phone number of contact person who can give us comprehensive information about found data set. This is because the timeliness and completeness of metadata is still insufficient (Iwaniak 2006).

The Role of Metadata in Geoinformation Metadata are one of the key elements in the spatial data infrastructures and are of vital importance to them. Thus, discussing the role of metadata, the concept of Spatial Data Infrastructure (SDI) should be defined.

Spatial Data Infrastructure Spatial data infrastructure (SDI) – legal, organisational, economic and technical means, which provide universal access to geoinformation services regarding a particular area, contribute to the effective use of geoinformation for sustainable development of this area and enable the rational management of geoinformation resources. Depending on the area to be covered by the SDI, it can have different characteristics: • • • • •

Global (GSDI – Global SDI) International/European (ESDI – INSPIRE) State/national (NSDI – National SDI) Regional Local (e.g., municipal or county)

Spatial data infrastructure includes: interconnected, interoperable systems and spatial databases containing spatial data and metadata of appropriate content and quality, information and geomatic technologies in accordance with generally accepted standards, legislation, organisational structures, economic solutions and human resources as well as users creating geoinformation society. SDI serves the purpose of searching, evaluation, transfer and use of spatial data by users at all levels of public administration, business sector, social sector (non profit) and academia and by citizens in general (Gaz´dzicki 2003). Nowadays, spatial data infrastructures are being built in over 30 countries around the world (Senkler 2006), including Poland. Some of the examples of such systems are: • NSDI (National Spatial Data Infrastructure) in the USA • NCGI (National Clearinghouse Geoinformatie) in the Netherlands • ASDI (Australian Spatial Data Infrastructure) in Australia (ANSLIC)

8

1 Metadata

• GDI-DE (Geodateninfrastruktur Deutschland), Germany • INSPIRE (Infrastructure for Spatial Information in Europe) in the European Union Recently, the interest in geoinformation has grown considerably. This area, in addition to biotechnology, IT and cosmetics, is one of the fastest growing today. The global rate of revenue increase in this sector is 10% and growing every year (Iwaniak 2006). The popularisation of geoinformation on the Internet has significant impact on this situation, mainly due to the services as Google Maps, Google Earth and others of the type. Not without significance is also an increasing number of Web locators (e.g., Zumi.pl) and geo-portals (e.g., geoportal.gov.pl, geoportaltatry.pl). They are introduced and run by different entities, from big corporations (e.g., zumi.pl), through government agencies (e.g., geoportal.gov.pl, ikar.pgi.gov.pl), open communities (e.g., http://www.openstreetmap.org) and even by individuals. Development of geoinformation is also significantly influenced by widely available car navigation systems and multifunction mobile devices, which become more and more popular. Significant development of geoinformation is closely linked to a rapid progress, which takes place in computer science and computer technology. One of the most important elements in the development of geoinformation is current evolution of closed, monolithic spatial information systems (“Desktop GIS”) into network distributed systems – spatial data infrastructures based on standardised interfaces (Michalak 2003; Senkler 2006). This process is presented schematically in Fig. 1.5. All this results in an increased demand for spatial data. There is a growing number of producers (creators), distributors and users of geoinformation, or rather

Fig. 1.5 Schematic representation of the evolution of monolithic GIS systems to geoinformation infrastructures based on standardised interfaces (after: Senkler 2006, amended)

The Benefits of the Use of Metadata in Geoinformation

9

“co-users”, since spatial data resources can be shared today by all participants of spatial information infrastructures (SDIs). Nowadays more and more organisations (including those outside Earth sciences sector) are able to develop and modify spatial information, and even more sees the need to use it in their activities. The result is a substantial increase in the number of collected geoinformation resources. In this situation it becomes increasingly important that the information (metainformation) is adequately elaborated and made available, which allows search for resources and assess them in terms of individual needs, mainly suitability for specific applications. This requirement is satisfied by the metadata, available through the special network services, using the so-called catalogue servers. These services play a similar role in the field of geo-information as Internet search engines such as Google – and allow to search for the desired spatial data (Iwaniak 2006). It should be emphasised that the standardisation of metadata and services associated with them is the prerequisite for implementing this type of search. Nowadays, there are thousands of servers on the Internet providing spatial data from around the world. The importance of these services to a wide range of users would be much more limited without an effective resources search system based on metadata (Iwaniak 2006). Timeline application | monolithic GIS | internal connection to the DBMS | examples: Bentley GIS, Arc/Info Internal data exchange formats application | hardware and software GIS tools | Traditional DBMS | examples: ArcSDE, ArcIMS, Oracle Spatial Standardised interfaces application | geoinformation services | universal spatial data server | examples: CSW, WMS, WFS, WCS

The Benefits of the Use of Metadata in Geoinformation In addition to the basic tasks of metadata, which are: describing the spatial data and related services as well as enabling the search for adequate resources and their assessment in terms of individual needs, mainly suitability for specific applications, metadata perform other functions, giving other benefits. The most frequently mentioned benefits of using metadata are (after: Gaz´dzicki 2003) that the metadata: • Facilitate the organisation and management of data sets (geoinformation resources) within the organisation responsible for the data (resources) • Facilitate the identification and re-use of data

10

1 Metadata

• Facilitate the use of accumulated resources according to current needs, as well as create opportunities to use them in the future, when they will become historical (archival) materials • Make it easier to locate, access, evaluate, acquire and use spatial data • Allow optimisation of projects regarding acquisition and revision of data • Enable users to determine whether the spatial data contained in the resource will be useful for them • Enable expanding the range of users of spatial data • Facilitate providing essential services within the spatial data infrastructures • Help eliminate redundant data – give possibility to avoid multiplication of data sets, which contain information already gathered by other organisations • Facilitate obtaining of information on all data sets (resources) available for the area of interest Moreover, the metadata are the key to true and full interoperability in the geospatial environment. They extend the idea of exchanging data between organisations and users – sharing spatial data. Metadata increase the usefulness and value of spatial data resources (GIS-Nature 2005). The resources that do not have adequately prepared metadata, have a significantly lower value, and in extreme cases may become completely useless (Gaz´dzicki 2003).

Responsibilities of the Creation of Geoinformation Metadata The obligation to create and distribute metadata describing the spatial data resources may result from the European law, national laws or internal rules (e.g., trade). The details of the requirements for use of geoinformation metadata under European Union law and Polish national law are presented and discussed below.

Metadata in the European Infrastructure for Spatial Information INSPIRE Introduction to INSPIRE The concept of building a European infrastructure for spatial information has long tradition in the European Union. Its full implementation has not yet been possible for many reasons. The most important reasons, according to the experts, include: • • • •

Large variety of models and spatial data formats Incomplete coverage of some areas Lack of standardised reference systems Difficulties with access to spatial data and the relatively high cost of acquisition (purchase)

Responsibilities of the Creation of Geoinformation Metadata

11

Moreover, many of the source data (reference data) is mutually incompatible, and their levels of details in the same scales are different (Michalak 2003; Inspire http://inspire.jrc.it). The lack of adequate metadata, compliant with geoinformation standards, can be also another obstacle. To overcome these barriers, on 11 April 2002, three Commissioners of the European Union for environment, science (Joint Research Centre JRC) and finance (Eurostat), signed a memorandum establishing the initiative to create European spatial information infrastructure INSPIRE (INfrastructure for SPatial InfoRmation in Europe). The Basic and Main Objective of INSPIRE Initiative “To make spatial information adequate, harmonised and high quality and available for formulating, implementing, monitoring and evaluating of Community policy and for the citizens. . . by establishing integrated spatial information services, based upon a network of distributed databases linked by common standards and protocols to ensure compatibility and inter-operability . . .” (Michalak 2003; Inspire http://inspire.jrc.it). Since the establishment of INSPIRE Initiative, the ideas behind it, schedules (roadmap) and means of delivery, changed several times. Current process of implementing the INSPIRE initiative is relatively complex. It consists of three main phases: • The Preparatory Phase – already completed, implemented in 2005–2006, which included among others: development of co-decision procedures, the development of INSPIRE Directive project and initiating the preparation of technical guidelines for the Directives, so called INSPIRE Implementing Rules (IR) • The Transposition Phase, implemented since 2007 – in practice, this phase ended in 2009 – which includes among others: coming into force of the INSPIRE Directive and its transposition into national law, development and adoption of: implementation policy and various technical guidelines – INSPIRE Implementation Rules (IR) • The Implementation Phase, this phase began in 2009 and is expected to last for more than 10 years, this phase includes implementation and monitoring of the implementation of INSPIRE. In fact, for metadata, this phase has already started in 2008 The most current information on the progress and plans for the implementation of INSPIRE can be found on the official website presenting a roadmap for INSPIRE: http://inspire.jrc.ec.europa.eu/index.cfm/pageid/44.

12

1 Metadata

One of the major activities undertaken under the INSPIRE Initiative was to prepare a draft of INSPIRE Directive. Work on this project started even before the Preparation Phase. On 23 July 2004, the European Commission presented the first draft of the Directive. Work on this project continued almost until the adoption of a directive by European Parliament and the Council of Europe on 14 March 2007. Eventually, INSPIRE Directive was published in the Official Journal of the EU No. 108 on 25 April 2007 and if in force from 15 May 2007. Brief description of the legislative process of INSPIRE can be found on INSPIRE web site at: (http://inspire. jrc.ec.europa.eu/directive.cfm), and detailed information on this subject can be found on the European Commission website (http://ec.europe.eu/PreLex/detail_dossier_ real.cfm?CL¼en&DosId¼191582). The official Polish text of the Directive is available at: http://eur-lex.europe.eu/LexUriServ/LexUriServ.to?uri¼OJ:L:2007: 108:0001:0014:EN:PDF In order to develop appropriate technical guidelines, so called INSPIRE Implementing Rules (IR), five editorial boards (DT – Drafting Teams) were created for: • • • •

Metadata (DT 1; http://inspire.jrc.ec.europa.eu/index.cfm/pageid/101) Data specification (DT 2; http://inspire.jrc.ec.europa.eu/index.cfm/pageid/2) Network services (DT 3; http://inspire.jrc.ec.europa.eu/index.cfm/pageid/5) Data and service sharing (DT 4; http://inspire.jrc.ec.europa.eu/index.cfm/ pageid/62) • Monitoring and reporting the implementation of INSPIRE (DT 5; http://inspire. jrc.ec.europa.eu/index.cfm/pageid/182) The metadata drafting team (DT 1), has prepared appropriate technical guidelines and already completed their work (see “Metadata in the INSPIRE Directive”). The data specification drafting team has been extended by a group of thematic experts and turned into a nine Thematic Working Groups (TWG), corresponding to the spatial data themes listed in Annex I of INSPIRE. Subsequently, Thematic Working Groups corresponding to the spatial data themes listed in Annexes II and III of INSPIRE will be designated. Thematic Groups aim to prepare and develop a specification containing data models in the form of abstract diagrams expressed in UML – Uniform Modelling Language and application schemas in GML (Geographical Markup Language) for individual data themes listed in the Annexes of INSPIRE. Work on specifications for data themes listed in Annex I of the INSPIRE Directive has been finalized and the results of the work are available on the INSPIRE website. However, work on other specifications for data themes listed in Annexes II and III of INSPIRE and on technical guidelines is at different stages of development and is still underway in drafting teams DT 3, DT 4 and DT 5. Detailed information on developed documents can be found on INSPIRE website at (http://inspire.jrc.ec.europa.eu/reports.cfm).

Responsibilities of the Creation of Geoinformation Metadata

13

As was mentioned earlier, the relevant regulations on the use of metadata in the INSPIRE have already been developed, approved and published, and therefore, they are formally in force. The first is a legal document – Commission Regulation No 1205/2008 of 3 December 2008 implementing the INSPIRE Directive regarding the metadata. The Regulation was published in the Official Journal of the EU No 326 on 4 December 2008 and it entered into force on 24 December 2008. It should be noted that under EU law, regulations of this type are directly applicable and do not require a separate transposition into national law – automatically on the date of entry into force, they become binding in all EU Member States. The text of the regulation is available on European Union website at (http://eur-lex.europa.eu/LexUriServ/LexUriServ.do? uri¼CELEX:32008R1205:PL:NOT). The second document covers the technical guidelines for the implementation of INSPIRE regarding metadata – “The INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119”, published December 19, 2008. The text of these guidelines can be found on INSPIRE website at (http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/metadata/MD_IR_and_ ISO_20081219.pdf). The methodology and procedure for the completion of the INSPIRE initiative requires that the draft documents related to Inspire were consulted by community and tested. These rules concerned both the project of the INSPIRE Directive and, at present, the INSPIRE Implementation Rules. Consultation and testing are conducted within the INSPIRE organisations of the following types: • LMO (Legally Mandated Organisation) – an organisation that has a legal mandate to deal with issues of spatial information in the country • SDIC (Spatial Data Interest Community) – communities with a special interest in spatial information: companies, associations, agencies, organisations, etc., which have a stake in development of the infrastructure for spatial information In Poland, the LMO organisation is the Head Office of Geodesy and Cartography (GUGiK), which (on behalf of the Minister of Interior and Administration) is a government institution responsible for the implementation of INSPIRE in Poland, and also acts as a Polish point of contact for INSPIRE. Moreover, following Polish organisations were registered as LMOs: Central Statistical Office, Chief Inspectorate for Environmental Protection, General Directorate for Environmental Protection, National Water Management Authority and the Institute of Geodesy and Cartography, Institute of Spatial Planning and Housing and the Institute for Conservation of Nature (in the absence of statutory legislative powers three institutes should be registered as SDICs). Polish institutions registered as an independent SDICs are: the Institute of Geodesy and Cartography (IGiK), Polish Geological Institute (reported as SDICs of two state services: geological and hydro-geological) and the Polish Association for Spatial Information (PASI). Additionally, Institute of Spatial and Cadastral Systems SA – geoinformation company, dealing with, inter alia, issues of spatial data and metadata, is the member of Nature GIS SDIC.

14

1 Metadata

There is also a significant number of Polish institutions, which function as members of larger SDIC organisations, for example, General Directorate for Environmental Protection (GDOS´), Chief Inspectorate for Environmental Protection (GIOS), National Water Management Authority (KZGW). This group also includes Polish Geological Institute, which is an independent SDIC, and as a member of EuroGeoSurveys (Association of European Geological Surveys), belongs to a SDIC associating European geological surveys. More complete and detailed information about the issues discussed above can be found on INSPIRE website (http://inspire.jrc.it). The European Union Directive is an act of secondary law, by which EU Member States are obliged to introduce legal regulations to achieve the desired state of affairs specified in the Directive. The legislation adopted jointly by the European Parliament and the Council of the European Union, as well as the Directives addressed to all Member States are published in the Official Journal of the European Union and enter into force on specified date, or on the 20th day after they have been published. It should be noted that the Directives are of varying importance: the recommended, binding and temporary. In addition, the Directives leave member states with considerable margin of freedom in how to achieve the desired result. Even though the Directive explicitly only requires member states to establish a legal order, in light of the European Court of Justice’s (ECJ) decision, if the country fails to implement Directive, the citizen has the right to directly refer to the Directive against any national provisions incompatible with the Directive. It is necessary to note, that according to ECJ decision, the direct application of the Directive can be invoked only if the provisions of the Directive appear to be unconditional and sufficiently precise [http://pl.wikipedia.org/wiki/Dyrektywa_ (Unia_Europejska)].

What Is the INSPIRE Directive About? In force since May 15, 2007, the INSPIRE Directive lays down the infrastructure for spatial information in Europe (known as INSPIRE) and determines the principles for the infrastructure operation regarding metadata, spatial data and services associated with them. In addition it provides rules for the provision, sharing and use of resources. It also introduces mechanisms (processes and procedures) for coordinating, monitoring and reporting the implementation of INSPIRE. It also specifies that INSPIRE will not be treated as a separate infrastructure, but will be composed of infrastructures for spatial information, established and operated by the member states (Chapter 1, Article 1, Section 2). The full text of the INSPIRE Directive is available on the European Commission website (http://eur-lex.europa.eu/LexUriServ/ LexUriServ.do?uri¼OJ:L:2007:108:0001:0014:PL:PDF).

Responsibilities of the Creation of Geoinformation Metadata

15

What Are the Area and the Scope the INSPIRE Directive Refers to? According to the provisions of the Directive, project INSPIRE, in terms of area, refers only to the territories of the EU member states and to the areas under their jurisdiction (Chapter I, Article 4, Paragraph 1, Letter a), while in terms of the subjects, the INSPIRE is limited to spatial information about environment (Chapter I, Article 1, Section 1) – in particular to the 34 data themes listed in the Annexes to the Directive: Annex I includes: 1. 2. 3. 4. 5. 6. 7. 8. 9.

Co-ordinate reference systems Geographical grid systems Geographical names Administration units Addresses Cadastral parcels Transport networks Hydrography Protected sites

Annex II includes: 1. 2. 3. 4.

Elevation Land cover Orthoimagery Geology (including hydro-geology)

Appendix III includes: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

Statistics units Buildings Soil Land use Human health and safety Utilities and governmental services Environmental monitoring facilities Production and industrial facilities Agricultural and aquaculture facilities Population distribution and demography Land management/restriction/regulation zones and reporting units Natural risk zones Atmospherics conditions Meteorology – geographical features Oceanography – geographical features Sea regions Bio-geographical regions

16

18. 19. 20. 21.

1 Metadata

Habitats, and biotopes Species distribution Energy resources Mineral resources

Who Is Affected by INSPIRE Directive? INSPIRE Directive applies to virtually all participants in European spatial information infrastructure. However, its provisions (Chapter I, Article 3, Paragraph 9) formally define entities for which it is mandatory: • Any government or other public administration, including public advisory bodies at national, regional or local levels • Any person or legal person performing public administration functions under national law, including specific duties, activities or services in relation to the environment • Any person or legal person having public responsibilities or functions or providing public services in relation to environment and being under the control of a body or person described above

Metadata in the INSPIRE Directive Metadata play a crucial role in INSPIRE and are given priority, as reflected in the provisions of the Directive. Already in the preamble to the Directive (point 15) we find a reference to the key role of the metadata. There we read that “the loss of time and resources in searching for existing spatial data or establishing whether they may be used for a particular purpose is a key obstacle to the full exploitation of the data available. Member States should therefore provide descriptions of available spatial data sets and services in the form of metadata.” Moreover, the Directive defines the basic terms associated with spatial information infrastructure (Chapter I, Article I, Paragraphs 1–9), including metadata. According to the definition used in the Directive, metadata is “information describing spatial data sets and spatial data services and making it possible to discover, inventory and use them” (Chapter I, Article 3, Section 6). It should be emphasised that the whole Chapter II of the Directive is specifically dedicated to the metadata. It states that the metadata implementing rules should be adopted by 15 May 2008 (before all other INSPIRE Implementing Rules) and “take account of relevant, existing international standards and user requirements, in particular with relation to validation metadata” (Chapter II, Article 5, Paragraph 4).

Responsibilities of the Creation of Geoinformation Metadata

17

What Are the Basic Responsibilities Concerning Metadata Resulting from the INSPIRE Directive? The INSPIRE Directive primarily imposes an obligation on Member States to ensure “that metadata are created for the spatial data sets and services corresponding to the themes listed in Annexes I, II and III, and that those metadata are kept up to date” (Chapter II, Article 5, Paragraph 1). In addition, Member States are to “take the necessary measures to ensure that metadata are complete and of a quality sufficient to ‘discover, inventory and use spatial data’” (Chapter II, Article 5, Paragraph 3).

What Resources Should Have Metadata Recorded According to the INSPIRE? The INSPIRE Directive requires the metadata to be developed for those spatial data sets, series and spatial data services, which (Chapter I, Article 4, points 1): • Relate to an area where a Member State has or exercises jurisdictional rights • Are in electronic form • Are held by or on behalf of public authorities (see “Who Is Affected by the INSPIRE Directive?”) • Relate to one or more of the themes listed in Annexes I, II, or III It is worth noting that on the one hand, this Directive does not require the collection of new spatial data resources (Chapter I, Article 4, Section 4), which means that in the INSPIRE metadata should be developed only for existing resources. On the other hand, one must remember that these resources will have to comply with the guidelines set in the INSPIRE Implementation Rules. So, to achieve full compliance with the guidelines there may be a need to transform the existing spatial data resources, complement and in some cases to obtain the missing resources. It should be also added that the Directive sets out the obligation to create the metadata for the newly emerging resource. Also, from the viewpoint of organising resources, metadata for archival resources should also be created.

What Information Should Be Included in Metadata? According to the INSPIRE Directive (Chapter II, Article 5, Paragraph 2) geoinformation metadata should include information on the following: • The conformity of spatial data sets with the implementing rules (it’s the reference to the INSPIRE Directive Implementing Rules) • Conditions for access to spatial data and spatial data services, and conditions of use of the data • The corresponding data use fees – where applicable

18

1 Metadata

• Quality and validity of spatial data sets • Public authorities responsible for the establishment, management, maintenance and distribution of spatial data sets and services • Restrictions on public access and the reasons for such restrictions. The restrictions are mostly caused by the following: the adverse impact on international relations, public security, national defence, the confidentiality of the proceedings of public authorities, the course of justice, the confidentiality of commercial or industrial information including maintaining statistical confidentiality and tax secrecy, intellectual property rights, the confidentiality of personal data and protection of the environment in terms of information about locations of rare species. These issues are regulated in detail by Article 13 of the INSPIRE Directive

What Is the Timeframe for Implementation of INSPIRE Regarding Metadata? The INSPIRE Directive provides detailed timetable for the implementation of metadata (Chapter II, Article 6), under which Member States have to create metadata: • For spatial data themes listed in Annexes I and II not later than 2 years after the adoption of implementing rules • For spatial data themes listed in Annex III not later than 5 years from the date of adoption of implementing rules The records relate to the INSPIRE Implementation Rules for metadata, which according to the requirement of the Directive (Chapter II, Article 5, Section 4) should have been adopted not later than 15 May 2008. However, these principles were adopted by the Technical Committee INSPIRE at its meeting on 14 May 2008, Consequently, the principles came into effect only in the second half of December 2008 (see Commission Regulation No 1205/2008 of 3 December 2008 implementing the INSPIRE Directive as regards metadata and the document “The INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119”). This means that under the INSPIRE roadmap, metadata for spatial data sets corresponding to the themes listed in Annexes I and II should be developed by 3 December 2010, while in case of spatial data sets corresponding to the themes listed in Annex III, not later than 3 December 2013. Since the INSPIRE Implementing Rules (the documents that describe how to implement metadata for INSPIRE) officially came to effect in December 2008, that is more than 7 months after the date of approval. This delay would, de facto, reduce implementation periods given by the Directive for the metadata from 2 years for data specified by Annex I and II, and from 5 to 4 years and 3 months for data specified in Annex III. In the first case the period would by shortened by 29%, in the second case by 12%.

Responsibilities of the Creation of Geoinformation Metadata

19

What Metadata Services Should Operate Within INSPIRE? Besides the metadata itself, member states are obliged to establish and maintain a specific network services related to the handling of metadata (Chapter IV, Article 11, Paragraph 1). In accordance with the INSPIRE Directive, these services should be: • Discovery services that allow search for spatial data sets services based on the contents of the corresponding metadata, as well as make it possible to display the content of the metadata • View services, which allow at least to display, navigate, zoom out, pan, or overlay spatial data sets and to display legend information and any relevant information from content metadata Member States are also obliged to ensure that public authorities are given the appropriate technical measures to link metadata and related services to the network (Chapter IV, Article 12), referred to in Chapter II, Article 11, Clause 1. Services are: • Search services – Internet services performed by the catalogue servers according to standard OGC CS-W (Catalogue Service for Web) • View services – Internet services for sharing maps, so called WebMapping implemented by the map servers using the standard OGC WMS (Web Map Service) Both services and associated standards are described in more detail in subsequent chapters.

Rules for the Implementation of INSPIRE Some of the basic objectives of the functioning of INSPIRE is the possibility of finding spatial data sets and spatial data services which may be of interest to users (participants),,, and then to determine under what conditions and for what purpose, to what extent and in what capacity these resources can be used by them. To achieve these objectives, spatial data sets and services must be described by metadata. Metadata should be fully compatible and usable in a community and transboundary context. In practice this means the need for development and approval of the detailed rules for the creation and functioning of the INSPIRE metadata. These policies should reflect (comply with) applicable international standards in geo-information. The INSPIRE Directive, similarly to the Acts of Parliament in the Polish law, lays down only general rules governing the creation and operation of infrastructure for spatial information, including the metadata. Therefore, like other such provisions, it requires a certain amount of detail and clarification by establishing the appropriate implementation legislation, i.e., regulations, technical guidelines and instructions. This also applies to the implementing rules for metadata.

20

1 Metadata

There are currently two documents defining the rules for the implementation of INSPIRE with regard to metadata. The first is the Regulation – a document of a formal nature, being an official law enforcing implementation of the Directive. The second – INSPIRE Implementing Rules – is a document of a more practical nature, including specific technical guidelines. Broadly and simply speaking, the Regulation defines a set of metadata elements required by the INSPIRE, and Implementing Rules describe how to describe the specific resources using this set. These rules for the implementation of the INSPIRE Directive are described and commented on in more detail below.

Regulation to the INSPIRE Directive Regarding Metadata The official and full name of the document is: Commission Regulation (EC) No 1205/2008 of 3 December 2008 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata. The text of the Regulation is available on the European Union websites in all official languages of the European community – the address given below leads to the version in Polish (http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri¼ CELEX:32008R1205:PL:NOT). According to the INSPIRE Directive, as it was mentioned before, adequate legislation for its implementation with regard to metadata should had been be adopted by 15 May 2008 (INSPIRE Directive, Chapter II, Article 5, Paragraph 4). The original version of the Regulation, prepared by Metadata Drafting Team, was approved by the INSPIRE Technical Committee on 14 May 2008 – the day before the date required by the Directive. Subsequently, the Regulation content was subjected to discussions and arrangements conducted by the European Commission, for more than 7 months and it was finally adopted only on 3 December 2008. The Regulation was published on 4 December 2008 in the Official Journal of the European Union No. L 326. It came into force on the 20th day after publication, i.e., on 24 December 2008. From that moment it is binding in all Member States, including Poland. It should be emphasised that the Commission regulations are directly applicable legal acts and do not require a separate transposition into national law. Article 1 of Regulation states that it establishes requirements for the creation and maintenance of metadata for spatial data sets, data series and spatial data services relating to the themes listed in Annexes I, II and III of the INSPIRE Directive. In fact, it establishes a set, that allows to describe: spatial data sets, series of sets and spatial data services in the form of metadata in accordance with the requirements of INSPIRE. It also defines the set of metadata elements, their value ranges and the multiplicity of elements, and indicates which elements are mandatory for INSPIRE. It should be noted that this Regulation gives metadata specification at minimal range, which just meets the requirements of INSPIRE, it only describes the resources at a very basic level – not always sufficient or satisfactory for users. However, this Regulation in no way limits the possibility of expanding this set of metadata with additional elements. However, it imposes a requirement as to the

Responsibilities of the Creation of Geoinformation Metadata

21

origin of these elements. They should be introduced in accordance with international standards or practices adopted by the industry. In practice, this means that this set can be extended with existing elements coming directly from ISO 19115, as well as items not appearing in this standard, but determined in accordance with the methodology of creating additional metadata elements. Analysing the text of the Regulation one can say that it establishes, formally and in accordance with the law, the INSPIRE metadata profile. Issues of metadata profiles, including an INSPIRE profile will be presented in detail in Chap. 3. The document we discuss consists of three parts: the preamble, articles and annex. The preamble to this regulation consists of five points, which justify the need to develop rules for the use of metadata in INSPIRE. The second part consists of four, one-sentence brief articles relating to, among other things, the subject matter of the regulation and mode of entry into force of the discussed legislation. The most comprehensive part is the Annex to the Regulation, which consists of four parts A, B, C and D, which from a practical point of view is the most important element of the regulation. The A part of the Annex (Interpretation) defines eight basic terms used in regulation: • • • • • • • •

Character string Free text Lineage (of data set) Metadata element Namespace Quality (of a resource) Resource Spatial data set series

Additionally, interpretation of the term: the validity of spatial data, is also included. Part B of the Annex (Metadata elements) lists 27 metadata elements of the INSPIRE, gives their numerical identifiers, brief definitions and indicates range of values. In addition, for some of those elements certain references and components (elements) of these references are identified. All these elements of the INSPIRE metadata, according to their function, were divided into ten groups. It should be stressed that hierarchy of the INSPIRE metadata is different from the hierarchy used in international geoinformation standards, which consist of: • Metadata elements • Metadata entities • Sections of the metadata Geoinformation norms and standards for metadata will be presented in detail in Chap. 3. In fact, according to the definition of the metadata element in ISO 19115, which is also the definition adopted by the Regulation, the hierarchy of the INSPIRE metadata consists of 14 metadata elements compliant with ISO. In consequence of

22

1 Metadata

the accepted model of metadata hierarchy in INSPIRE, some of the ISO metadata elements are not explicitly named and do not have a numeric identifier (they are not treated as the INSPIRE metadata elements in the strict sense), but are only described as part of references to some of the INSPIRE metadata elements (listed as such, and with a numerical identifier). Part C of the Annex describes the multiplicity and conditions of the INSPIRE metadata elements, summarised in tabular form. The first table lists information on spatial data sets or series of data sets, the second table lists information on the spatial data services. These tables include the following information: • First column contains the numerical identifier of the INSPIRE metadata element, corresponding to the position of the metadata element in the INSPIRE metadata hierarchy • The second column contains the name of the metadata element or group of metadata elements • The third column specifies the multiplicity of metadata element following the notation used in UML • Fourth column contains a conditional statement if the multiplicity of the element does not apply to all types of resources Part D of the Annex identifies six value domains for the INSPIRE metadata elements. In each domain, every value is defined by: • Numerical identifier of the value • Textual name for humans, which may be translated into different languages the Community • Neutral language name for computers • Optional description or definition For the INSPIRE metadata the following domains are defined: 1. RESOURCE TYPE – this is a value domain of INSPIRE metadata element 1.3. resource type 1.1. Spatial (geospatial) data set 1.2. Spatial (geospatial) data set series 1.3. Spatial (geospatial) data services 2. TOPIC CATEGORIES in accordance with EN ISO 19115 2.1. Farming 2.2. Biota 2.3. Boundaries 2.4. Climatology/meteorology/atmosphere 2.5. Economy 2.6. Topography 2.7. Environment 2.8. Geo-scientific information 2.9. Health

Responsibilities of the Creation of Geoinformation Metadata

23

2.10. Imagery/base maps/Earth cover 2.11. Intelligence/military 2.12. Inland waters 2.13. Location 2.14. Oceans 2.15. Planning/cadastre 2.16. Society 2.17. Structure 2.18. Transportation 2.19. Utilities/communication 3. SPATIAL DATA SERVICE TYPE – according to the INSPIRE Directive 3.1. Discovery Service 3.2. View Service 3.3. Download Service 3.4. Transformation Service 3.5. Invoke Spatial Data Service 3.6. Other Service 4. CLASSIFICATION OF SPATIAL DATA SERVICES This domain includes about 70 types of spatial data services based on geographic services taxonomy defined by ISO 19119. This taxonomy is based on the categories, the subcategories determine the value domain of classification of spatial data services. Below, only categories are listed 100. Geographic human interaction services (humanInteractionService) (10) 200. Geographic model/information management service (infoManagementService) (11) 300. Geographic workflow/task management services (taskManagementService) (3) 400. Geographic processing services – spatial (spatialProcessingService) (18) 500. Geographic processing services – thematic (thematicProcessingService) (16) 600. Geographic processing services – temporal (temporalProcessingService) (4) 700. Geographic processing services – metadata (metadataProcessingService) (2) 800. Geographic communication services (comService) (6) 5. DEGREE OF CONFORMITY 5.1. Conformant (conformant) 5.2. Not Conformant (notConformant) 5.3. Not evaluated (notEvaluated) 6. ROLE OF RESPONSIBLE ENTITY 6.1. Resource Provider (resourceProvider) – The unit supplying the resource 6.2. Custodian (custodian) – An entity that accepts the responsibility for data and ensure appropriate care and maintenance of the resource 6.3. Owner (owner)- An entity that owns the resource

24

1 Metadata

6.4. User (user) – An entity who uses the resource 6.5. Distributor (distributor) – An entity that disseminates the resource 6.6. Originator (originator) – An entity that created the resource 6.7. Point of Contact (pointOfContact) – An entity which can be contacted in order to obtain knowledge about the resource or acquisition of the resource 6.8. Principal investigator (principalInvestigator) – Key entity responsible for gather information and conducting research 6.9. Processor (processor) – An entity which has processed the data in such a manner that the resource has been modified 6.10. Publisher (publisher) – An entity which published the resource 6.11. Author (author) – An entity which formulated (edited) the resource Hierarchy of the INSPIRE metadata is as follows: 1. IDENTIFICATION – contains seven elements identifying (describing) the resource: 1.1. Resource title (the value domain of this metadata element is free text) 1.2. Resource abstract/summary (the value domain of this metadata element is free text) 1.3. Resource type (the value domain of this metadata element is defined in Part D.1 of the Annex). This metadata element can take one of three following values: Spatial data set series – series, spatial data set – dataset Spatial data service – service 1.4. Resource locator (the value domain of this metadata element is a character string, usually expressed as Uniform Resource Locator – URL) 1.5. Unique resource identifier (the value domain of this metadata element is character string code) 1.6. Coupled resource – in the case of spatial data, this metadata element identifies the target spatial data set (data sets) of services using their unique resource identifier URI – Uniform Resource Identifier (value domain of this metadata element is a character string code) 1.7. Language or languages of resource (the value domain of this metadata element consists of languages defined in ISO 639–2, e.g., pol) 2. CLASSIFICATION OF SPATIAL DATA AND SERVICES – it contains two elements for classification of geospatial data and services: 2.1. Topic category of resource (the value domain of this metadata element is defined in Part D.2 of the Annex. This metadata element can take one of the 19 values from a set of thematic categories in accordance with ISO 19115, to which this regulation additionally assigns 34 spatial data themes listed in Annexes I, II and III of INSPIRE) 2.2. Spatial data service type (the value domain of this metadata element is defined in Part D.3. of the Annex. This metadata element can take one of six values – the types of services specified by the INSPIRE Directive:

Responsibilities of the Creation of Geoinformation Metadata

25

discovery service, view service, download service, transformation service, invoke service, other services) 3. KEYWORD – contains two components designed to provide keywords: 3.1. Keyword value (the value domain of this metadata element is free text with the following restrictions; in the case of spatial data or spatial data set series, at least one keyword must be provided from the general environmental multilingual thesaurus GEMET and correspond to the spatial data theme defined in Annexes I, II or III of the INSPIRE Directive; in the case of spatial data, at least one keyword from Part D.4 of the Annex should be used. This metadata element can take one of 70 values – types of spatial data services) 3.2. Originating controlled vocabulary (element should include at least the title of the dictionary and its date of publication and/or last revision, and/or creation) Keywords are derived from geographic services taxonomy of EN ISO 19119. This taxonomy is based on the categories, the subcategories determine the value domain of classification of spatial data services. 4. GEOGRAPHIC LOCATION – contains only one element used to identify the location of geographical resource: 4.1. Geographic bounding box – specifies the extent of the resource in the geographic space expressed as a bounding box. Rectangle of the bounding should be identified by westbound and eastbound longitudes, and by the southbound and northbound latitudes in decimal degrees with a precision of at least two decimal digits 5. TEMPORAL REFERENCE – four elements. Group of elements defining the temporal reference: 5.1. Temporal extent (which gives the time period covered by the resource, can be expressed as: date, interval of dates, a combination of date and interval of dates) 5.2. Date of publication 5.3. Date of last revision 5.4. Date of creation 6. QUALITY AND VALIDITY – Group of elements determining the quality and validity of the resource: 6.1. Lineage – a process history and/or overall quality of the resource (domain: free text) 6.2. Spatial resolution – the level of detail (domain: for the vector data it is the denominator of the scale, for raster data it is raster resolution in units of length)

26

1 Metadata

7. CONFORMITY – Group of elements describing conformity of resource: 7.1. Specification – citation of implementing rules, including rules of INSPIRE. This citation should include at least the title and reference date (date of publication, date of last revision or of creation) 7.2. Degree (of conformity) (the domain values are described in Part D.5. of Annex: conformant, not conformant, not evaluated) 8. CONSTRAINT RELATED TO ACCESS AND USE – Group of elements defining the constraints on access to the data resource and on its use: 8.1. Conditions applying to access and use (domain: free text) 8.2. Limitations on public access (domain: free text) 9. ORGANISATIONS RESPONSIBLE FOR THE ESTABLISHMENT, MANAGEMENT, MAINTENANCE AND DISTRIBUTION OF SPATIAL DATA SETS AND SERVICES – Group of elements defining the organisations responsible for the creation of spatial data and spatial data services and for management, storage and distribution (2 items): 9.1. Responsible party (including organisation name and means of contact – e-mail address) 9.2. Responsible party role 10. METADATA ON METADATA – Group elements defining the metadata on the created metadata (3 items): 10.1. Metadata point of contact (including organisation name and means of contact – e-mail address) 10.2. Metadata date – date of creation or last update of metadata (ISO 8601) 10.3. Metadata language (ISO 639–2)

The Implementing Rules of INSPIRE Directive (IR – Implementing Rules) Regarding Metadata The official and full name of the document is: INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119 (Revised edition). Its identifier as a document of INSPIRE is: MD_IR_and_ISO_20090203. This is the second version of the document, published on 3 February 2009 – the first version of the IR (First Edition) was published on 28 October 2008. The text of this document is available only in English at INSPIRE website: (http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/metadata/MD_IR_and_ ISO_20090203.pdf). The document in question was published on 19 December 2008. Work on it was carried out by the editorial staff of the Metadata Drafting Team 1 (DT 1),

Responsibilities of the Creation of Geoinformation Metadata

27

since October 2007. In fact, work on technical specifications for the implementation of the INSPIRE metadata began in 2006. On 2 February 2007, a second draft version of the specification – “Draft Implementing Rules for Metadata v 2” was presented. It was then subject to public consultation within the INSPIRE LMO and SDIC organisations. As a result of these consultations, some changes were introduced and the third draft of the specification – “Draft Implementing Rules for Metadata (Version 3)” was developed along with a document describing the changes between version 2 and 3. Both documents were published on 26 October 2007. Further work on the specification was conducted in the context of the relationship between the INSPIRE specifications and the standards ISO 19115 and ISO 19119. The first document describing this relations “Relation Between ISO 19115 and ISO 19119 and the elements of the INSPIRE draft metadata implementing rules” was published on 10 December 2007. Another, which became a first draft of the specification we discuss, “Draft Guidelines – metadata INSPIRE Implementing rules based on ISO 19115 and ISO 19119” was presented on 25 April 2008. The texts of these documents and more detailed information on the process of their development can be found on INSPIRE website (http:// inspire.jrc.it). These INSPIRE Implementing Rules for Metadata are the official technical specification of INSPIRE. They are also the documentation for implementing the INSPIRE metadata profile, which was defined in the Regulation to the Directive. This specification defines how to map metadata elements between the Inspire profile and core ISO profile. He describes how metadata should be developed for spatial data, spatial data sets series and spatial data services, in accordance with the standards ISO 19115 and ISO 19119 using the new set of metadata elements specified in the Regulation to INSPIRE Directive. In addition, it presents the way to express metadata using XML as specified by ISO/TS 19139. Methodology described in the specification is supplemented with numerous examples of specific implementations of metadata elements. The document in question consists of three chapters and one annex. The first chapter concerns the relation between the INSPIRE metadata profile, and the basic profile of metadata in ISO 1911. In the first part, both metadata profiles were presented and correlated in two tables – separately for spatial data sets and spatial data sets series and for spatial data services. In summary of this comparison it is stated, that compliance with the basic metadata profile of ISO 19115 does not guarantee compliance with the INSPIRE. However, the specifications for creating INSPIRE metadata are not in conflict with ISO 19115. Still, the achievement of full compliance with ISO 19115 requires the use of additional metadata elements that are not required by INSPIRE. The second part of the first chapter presents a list of 18 constraints resulting from the requirements of INSPIRE. The final, third part of the chapter presents the extensions

28

1 Metadata

introduced by INSPIRE with regard to the types of spatial data services and their classification. The second chapter concerns the basic mapping the INSPIRE metadata and metadata defined by ISO 19115 and ISO 19119. For each element of the INSPIRE metadata profile there is a table presenting their main characteristics and main features of the corresponding metadata element in accordance with ISO 19115 or ISO 19119. In the first case the characteristics are: • • • •

Numerical identifier of the metadata element according to the regulation The name of metadata element according to the Regulation Information if the item is mandatory Multiplicity of the metadata element In the second case the characteristics are:

• • • • • • •

Number identifying the metadata element in the ISO 19115 or ISO 19119 Element name used by ISO standard Definition of the element in accordance with ISO XPath expression – locator of metadata element as defined by ISO standard Data type Domain value Example

For certain items some additional implementing instructions are provided. For each item of metadata there is also an example of coding in XML. This is the XML snippet created and verified by the INSPIRE Metadata editor, available on the INSPIRE Geoportal (http://www.inspire-geoportal.eu/inspireEditor.htm). The order of the description of the various elements of the metadata follows the hierarchy of INSPIRE metadata elements specified in the regulation. Below is a sample table that presents the basic mapping for the metadata element “Resource title”, and an example of XML code (Table 1.1):

Table 1.1 An example of mapping of a metadata element named ‘Resource title’ using Inspire Implementing Rules (IR) in accordance with the ISO 19115 and the resulting XML snippet Reference Part B 1.1 Element name Resource title Obligation/condition Mandatory IR Multiplicity [1] Number 360 Name Title Definition Name by which the cited resource is known XPath IdentificationInfo [1]/*/citation/*/title Data type CharacterString Domain Free text ISO 19115 Example Image2000 Product 1 (nl2) Multispectral Implementing instructions None

Responsibilities of the Creation of Geoinformation Metadata

29

The third chapter of this specification presents the detailed mapping of the INSPIRE metadata and metadata in accordance with ISO 19115 and ISO 19119. This mapping is is presented as a set of template instances of ISO 19115 and ISO 19119 classes. The template instance of a class is defined by the property instances. Description of each instance consists of: • • • • •

A “+” sign starting the description of the property instance Instance label Cardinality of the instance described between square brackets Description (title) of an instance or reference Example

It should be emphasised that the hierarchy used in the templates is conformant with ISO 19115. Below, a sample template of detailed mapping for a group of metadata elements “Conformity” is presented (Fig. 1.6). The last part of the specification – Annex A, defines the encoding of INSPIRE metadata elements in XML in accordance with ISO/TS 19139. The encoding is based on XML Schemas, which are derived from UML models included in the standards ISO 19115 and ISO 19119, using the encoding rules defined in ISO/TS 19139. Above, the details and nuances of encoding (recording) metadata in XML were described and commented on. These issues will be presented in more detail in the chapter on metadata profiles. From a practical point of view, the Annex discussed above can be very useful because it provides examples of XML metadata files compliant with ISO\TS 19139, for both spatial data sets and spatial data services.

30

1 Metadata

+ report

[0..*] : DQ_Element............................................ See note 1 and 2 : MD_Identifier................... See note 3 : DQ_ConformanceResult + specification [1] : CI_Citation ................................ Specification (See 2.8.2) + explanation [1] : CharacterString .......................... See Note 4 + pass [1] : Boolean ................................................. Degree (See 2.8.1) Notes: 1. ISO 19115 only reports the result of the conformance evaluation. There may be no information about the conformity to the INSPIRE Conformance specifications, if the conformance has not been evaluated. 2. DQ_Element is an abstract class. It has to be instantiated through one of its concrete subclasses. The appropriate subclass depends on the quality criteria concerned by the quality measure. DQ_DomainConsistency will be used when the conformance does not involve a more precise quality criterion. 3. This metadata element of ISO 19115 will contain the identifier of the conformity statement. This identifier will be used by the application to differentiate the conformance statement related to INSPIRE from others. 4. ISO 19115 mandates an explanation of the meaning of the conformance for this result. A default explanation such as “See the referenced specification” can be used. + measureIdentification[1] + result[1]

Fig. 1.6 Example template of detailed mapping for a group of metadata elements “Conformity” – INSPIRE Metadata Implementing Rules

Metadata in the Polish Spatial Data Infrastructure Introduction to PSDI In Poland, over the years, there were many attempts to develop a coherent approach to the creation of a national spatial data infrastructure (PSDI), but those efforts failed to bring the desired effects. The first effective actions in this regard were taken with the emergence of a new concept of a European spatial information infrastructure – INSPIRE initiative. The current concept of PSDI is based on Inspire solutions, extended to encompass Polish specific requirements. This also applies to metadata. The present approach is a direct consequence of the need to transpose the INSPIRE Directive into national law and of the obligation to contribute to European infrastructure, INSPIRE, which builds upon national infrastructures. INSPIRE Directive is the base for the concept of PSDI, while the detailed arrangements are still under development. It stems from the fact that this concept is developed in parallel with the ongoing process of development of subsequent INSPIRE implementation rules. At the time of preparation of this book a legislation regarding spatial information infrastructure has already been signed by the Speaker of the Parliament (20.04.2010).It should be emphasized that together with the Act, relevant regulations, including one for metadata are also being prepared. However, the work on them, conducted by a group of experts is still in progress (May 2010).

Existing National Laws Relating to Metadata Since December 2008, issues of spatial metadata are regulated by the relevant EU Regulation. It should be noted, however, that the regulation only applies to geospatial metadata associated with the INSPIRE infrastructure. Other metadata for

Metadata in the Polish Spatial Data Infrastructure

31

geo-information can be recorded according to these guidelines, but they will not have in this case, the legal character but only technical. A large part of geo-information resources, including those covered by INSPIRE, should be available in the public registers such as EGiB (Land and Building Register) or TERYT (National Register of Territorial Division).

According to the Act on the Computerisation of the Operations of the Entities Performing Public Tasks from 17 February 2005 (Journal of Laws -Dziennik Ustaw of 2005 No. 64, item 565, as amended.) Register is a public “register, list, directory, index or other form of record used for performing public tasks, conducted by a public entity under separate laws.” A more detailed definition of a public register specifies that the register is a collection of information about people, things, or rights, which has the following characteristics: • It is formed under the law (regulations at least provide for its creation) • It is run by a public registering body • Acceptance, preservation and then disclosure of the information in a register is, as a rule, implemented by decision • Keeping a record or disclosure of data contained in it produces legal effects for both the person to whom the entry relates, and for the body which maintains the register • It is public List of records (including public registers) currently held in the National Register of Telecommunications Systems and Public Registers maintained by the Department of Information Technology Ministry (Ministry of Internal Affairs and Administration) (http://bip.mswia.gov.pl/portal/bip/13/Rejestry_ewidencje_archiwa.html). In the Act on the Computerisation of the Operations of the Entities Performing Public Tasks, the concept of metadata is not directly used, however, the act speaks of metainformation systems and metadata. In line with the above definitions a public register itself may be a metadata registry or directory. According to Article 14 of this Act a public entity maintaining the public register shall: 1. Keep the register so as to ensure compliance with the minimum requirements for data communication systems, when the register is maintained using Information and communication technologies (ICT) 2. Keep the register in accordance with the minimum requirements for public records and for information exchange in electronic form 3. Enable electronic delivery of information to the registry and electronic sharing of information from that register, if this register is maintained using ICT systems In addition, the National Register of Communication Systems and Public Registers can be thought of as an example of metainformation system. In

32

1 Metadata

accordance with Article 20 of the discussed Act it shall include the following information: • • • • • •

Date when performing public tasks using a public register starts Legal basis and the goal of establishing a public register Organisation unit which maintains the public register Scope of information collected in the public register Information if the public register is maintained by the ICT system Indication, which of the data specified in the application is protected as classified information or other information legally protected, to what extent and on what legal basis

In the cases, when ICT system is used to perform public duties, following information should be additionally included: • Date when performing public tasks using ICT systems starts • Public tasks for which computerised system is used, indicating the legal basis for performing these tasks • Organisation unit that uses the computerised system • Technical description of the computerised system • Indication, which of the data specified in the application is protected as classified information or other information legally protected, to what extent and on what legal basis Each public body is obliged to report this information to the National Register within 30 days from the date of commencement of performing public tasks. The act in question states, that public records should meet the minimum requirements for telecommunications systems specified in the relevant legislation – in this case the Regulation of the Council of Ministers of 11.10.2005 (Dziennik Ustaw of 28.10.2005 r.). Generally, all the ICT systems, used by public entities to perform public tasks, should comply with the requirements of this Regulation. According to Paragraph 2, Section 1 of the Regulation, these ICT systems should have, in terms of functionality, reliability, usability, efficiency, portability and maintainability, qualities and characteristics as required by ISO standards approved by the national standardisation body, when being designed, developed, implemented and modified. And in step B1 of Annex 2 “Data formats to ensure access to information resources provided through electronic systems used to perform public tasks”, it is concluded that to define information structures involving the identification of information elements and relations between them, the following formats shall be used: 1.1 XML (Extensible Markup Language) standard of universal text format used to store data in electronic form – W3C 1.2 XSD (XML Schema) – standard of defining the structure of documents stored in XML – W3C 1.3 GML (Geography Markup Language) – OGC

Metadata in the Polish Spatial Data Infrastructure

33

The above mentioned provisions clearly indicate that for spatial metadata (included in public registers) ISO series 19100 standards should be used. They were adopted as Polish PN standards – as in the case of INSPIRE. One detail, however, should be brought to attention – PN standards are published in English and so, in accordance with Polish law, they cannot be invoked within legal system until they are published in Polish. These issues are presented in detail in Chap. 2. Some of the spatial data resources are to be transferred to state archives, which involves the development of appropriate metadata. These issues are governed by two regulations to the Act of 14 July 1983 on national archive resources and archives (Dziennik Ustaw 2002, No. 171, item. 1396, as amended.), which entered into force on 17 May 2007: • Regulation of Minister of Interior and Administration of 30 October 2006 on the necessary elements of the structure of electronic documents (Dziennik Ustaw of 17 November 2006 No. 206 pos.1517) • Regulation on technical requirements for formats and information storage media on which archival materials transferred to state archives are recorded The first of these Regulations defines (}2. 1) metadata as a set of structured information, which is logically associated with an electronic document and describes the document to facilitate its discovery, control, understanding and long-term storage and management. It also defines the necessary elements of the structure of electronic documents (metadata elements) created and stored by government and other state bodies, and all local government organisational units (} 1): 1. ID – document tag, unique for a collection of documents, which enables its identification 2. Originator – the party responsible for the content of the document, including its role in the creation or approval of the document 3. Title – the name of the document 4. Date – the date of an event associated with the creation of the document 5. Format – name of data format used for the document 6. Access – information who, under what conditions and to what extent can acquire access to a document 7. Type – basic document type (e.g., text, sound, picture, motion picture, collection) based on a list of types of the Dublin Core Metadata Initiative and its potential further specification (e.g., presentation, invoice, the parliament bill, note, regulation, letter) 8. Relationship – identification of a direct relation to the other document and the nature of that relationship 9. Receiver – the party to which the document is addressed 10. Group – an indication of belonging to a set of documents 11. Classification – the category regarding archiving of the document 12. Language – the code of natural language in accordance with ISO-639-2 or other identification of the language, if it is not defined by the standard

34

1 Metadata

13. Description – a summary, table of contents or a brief description of the contents of the document 14. Privileges – an indication of the party authorised to govern the document The Regulation also states that the information described in Paragraphs 1–7 shall be mandatory for every electronic document. Items described in Paragraphs 8–14, are provided if they have been assigned to the document in the process of its creation, processing or storage. It is also possible to place in the structure of the electronic document other metadata than those mentioned above, but they cannot affect the values of necessary metadata or impede their automatic extraction. The regulation also selects XML as a way to transfer electronic documents, including their metadata, however, defines no specific structure of the file. • Other provisions helpful for the implementation of the discussed issues may be the following publications: • Act of 14 June 1960 “Administrative Procedure Code” (Dziennik Ustaw of 2000, No. 98, pos. 1071 as amended) • Act of 18 September 2001 on Electronic Signatures (Dziennik Ustaw No. 130, pos. 1450, as amended) • Regulation of Ministry of Interior and Administration of 30 October 2006 on the necessary elements of the structure of electronic documents (Dziennik Ustaw of 2006, No. 206, item 1517) • Regulation of Ministry of Interior 30 October 2006 on the specific procedures for electronic documents (Dziennik Ustaw of 2006, No. 206, item 1518) • Regulation of the Ministry of Interior and Administration of 2 November 2006 on technical requirements, formats and information storage media on which archival materials transferred to state archives are recorded.(Dziennik Ustaw of 2006, No. 206, item 1519) • Regulation of Ministry of Interior of 27 November 2006 on the preparation and delivery of documents in the electronic (Dziennik Ustaw of 2006, No. 227, item 1664) • Regulation of Council of Ministers of 28 March 2007 on the “National Computerisation Plan for 2007–2010” (Journal of Laws – Dz.U., 2007, No. 61, item 414 and 415)

Metadata in the Act on the National Spatial Data Infrastructure In accordance with Article 24 of the INSPIRE Directive, all EU member states are obliged to transpose its provisions into national law by enacting the laws, regulations and administrative provisions necessary to comply with the Directive, not later than by May 15, 2009. In Poland the provisions of this Directive are transposed by Act on national spatial data infrastructure, together with the correlated regulations. It should be noted that the discussed the Act fully implements the provisions of the Directive regarding metadata and also introduces some extensions and specifications.

Metadata in the Polish Spatial Data Infrastructure

35

As regards the definition and content of metadata, the draft of the new Act introduced only minor, stylistic changes in comparison to the original text of INSPIRE Directive. Both the draft and Directive, define metadata as information that describes the spatial data sets and spatial data services, and enable discovery, inventory and use of those data and services. In both cases, metadata should include the following information: • Conformity of spatial data sets to existing regulations regarding data themes listed in the Annex to this Act • Conditions of access to spatial data and their use • Conditions of access to spatial data services and, where applicable, appropriate fees • Quality and validity of spatial data sets • Parties responsible for the creation, management, maintenance and distribution of spatial data sets and services • Restrictions on public access to the spatial data sets and services, and reasons for these restrictions The Act of Parliament provides more details on the delegating obligations related to metadata. Directive as a general, pan-European document delegates responsibilities to individual member states. The law in question, in turn, refers to the organs of administrations and so-called “leading bodies”, including the provisions relating to metadata. Organs of administration are defined as government agencies or local government authorities or other bodies established by law or authorised by agreements to perform public tasks relating to the environment. The term “leading authority” refers to the Minister or a central government body that coordinates the work and ensures the implementation of the Act for a particular theme of spatial data (listed in the Annexes to the Directive). The leading bodies, according to the Act on SDI are (Article 20): 1. General Surveyor of Poland, the spatial data themes: Thematic Group I: 1) Co-ordinate reference systems 2) Geographical grid systems 3) Geographical names 4) Administrative units 5) Addresses 6) Cadastral parcels 7) Transport networks Thematic Group II: 1) Elevation 2) Land cover 3) Orthoimagery

36

1 Metadata

Thematic Group III: 2) Buildings 3) Soil 6) Utility and governmental services 8) Production and industrial facilities 11) Area management/restriction/regulation zones and reporting units 2. Minister responsible for spatial planning and housing, the spatial data themes: Thematic Group III: 4) Land use 15) Oceanographic geographical features 16) Sea regions 3. The Minister responsible for the environment, the spatial data themes: Thematic Group I: 9) Protected sites Thematic Group III: 12) Natural risk zones 13) Atmospheric conditions 14) Meteorological geographical features 19) Species distribution 4. The minister responsible for agriculture, the spatial data theme: Thematic Group III: 9) Agricultural and aquaculture facilities 5. The Minister responsible for health, the spatial data theme: Thematic Group III: 5) Human health and safety 6. The President of the Central Statistical Office, the spatial data themes: Thematic Group III: 1) Statistical units 10) Population distribution and demography 7. Chief National Geologist, the spatial data themes: Thematic Group II: 4) Geology Thematic Group III: 20) Energy Resources 21) Mineral Resources

Metadata in the Polish Spatial Data Infrastructure

37

8. Chief Conservator of Nature, the spatial data themes: Thematic Group III: 17) Bio-geographical regions 18) Habitats and biotopes 9. The Chief Inspector for Environmental Protection, the spatial data theme: Thematic Group III: 7) Environmental monitoring facilities 10. President of the National Water Management Authority, the spatial data theme: Thematic Group I: 8) Hydrography Moreover, the Act on SDI imposes an obligation on the public administration entities, which are responsible for the maintenance of public registers containing spatial data sets, to create, update and share of infrastructure metadata sets related to the spatial data themes listed in the Annex. The Act imposes the same obligation on third parties involved in the same metadata processes and whose data sets are to be included into the metadata infrastructure. The Act on SDI contains some provisions regarding the metadata which are not covered by the INSPIRE Directive. One of the provisions is, that the leading authorities, in consultation with the minister responsible for public administration, are obliged to establish and carry education systems, which provides training for these authorities on creating, updating and sharing the metadata. In terms of services related to metadata, the Act on SDI, apart from to specifying the delegation of duties (on administration authorities) makes only cosmetic changes in style of original provisions of INSPIRE. In both cases, the following must be prepared and maintained (Article 9 of the Act draft): 1. Discovery services, which should enable the search of spatial data sets and services, based on the contents of the corresponding metadata and enable viewing the content of metadata 2. View services, which should make possible, as a minimum, to: navigate, zoom in/out, pan or overlay viewable spatial data, and to display metadata content and explanations of cartographic symbols These services, in both cases should be available for the public by means of electronic communication. Searching for sets and spatial data services should be implemented for at least the following criteria or a combination thereof: 1. 2. 3. 4.

Keywords Classification of spatial data and spatial data services The quality and validity of spatial data The degree of compliance with technical standards for interoperability of spatial data sets and services

38

1 Metadata

5. Geographical location 6. Conditions of access and use of sets and spatial data services 7. The authorities responsible for the creation, management, maintenance and sharing of spatial data sets and services Another provision of the SDI Act, which is not listed in the INSPIRE Directive, refers to General Surveyor of Poland (Article 13, Paragraph 1 of the Act). It requires that the General Surveyor creates and maintains a geoportal for spatial data infrastructure as a central access point for spatial data in the full scope of themes and area of information available in the infrastructure, including services related to the metadata. Similarly, new provisions in relation to the INSPIRE Directive, delegate the General Surveyor to maintain a publicly available register of spatial data sets and services covered by the infrastructure and to give them a uniform identifier – which means maintaining a metadata registry (catalogue server). The rules of running this register are given in a draft of the relevant regulation prepared together with the Act on SDI. The SDI Act, as is the case with the INSPIRE Directive, sets out the timetable for the creation of metadata (Article 25 of the Act draft). According to this schedule: • By 3 December 2010 – metadata for data sets and services corresponding to the themes mentioned in the first and second thematic group of the Annex to this Act (Annex I and II of the INSPIRE Directive) shall be prepared • By 3 December 2013 – metadata for data sets and services corresponding to the themes listed in the third thematic group of the Annex to this Act (Annex III of the INSPIRE Directive) shall be prepared It should be noted that this timetable provision is an interpretation of INSPIRE Directive schedule for the creation of metadata. In this passage, the Act defines the deadlines by which metadata must be developed, taking as a starting point the date of acceptance of EU Regulation on the implementation of INSPIRE in the metadata by the EU Commission (3 December 2008).

Chapter 2

Standards and Interoperability

Why Do We Use Standards? The concept of standards is well known. Information systems, which include the spatial information systems (GIS, LIS, etc.) should be designed and built based on widely accepted and adopted standards in order to operate properly and efficiently. This principle is the foundation of modern information technology, and without following this principle, the operation of such solutions as e-mail or web sites would not be possible. Standards are the basis for interoperability of information systems and a common denominator for the exchange of information between them. These rules also apply to the metadata. In order to the metadata could be widespreadily and effectively used, they should be consistent in their form, character, nature and contents. The metadata developed and applied using various and other than standardised rules cannot be treated as the basis for comparison and objective assessment of quality of spatial data resources, even if the resource features are characterised as accurately as possible by these metadata.

Standards, Norms, Specifications In everyday use, an understanding and application of concepts such as: standard, norm, specification, and similar, is often not consistent. Therefore, before analysing issues relating to the standardisation of geoinformation metadata, we will discuss definitions of these concepts used in computing and geomatics and rules for the purpose of this publication.

L. Litwin and M. Rossa, Geoinformation Metadata in INSPIRE and SDI, Lecture Notes in Geoinformation and Cartography, DOI 10.1007/978-3-642-15862-9_2, # Springer-Verlag Berlin Heidelberg 2011

39

40

2

Standards and Interoperability

Standard and Norm Standard in computing is synonymous with norm – a pattern of hardware or software solutions certified by the standardisation institution or informally adopted because of widespread use, in the case of IT standards usually worldwide use. According to the Internet Geomatic Lexicon of Polish Association for Spatial Information (http://www.ptip.org.pl), the standard is defined in the following way: 1. In a general sense, it is the accepted quality level. 2. In the normative sense, standard is synonymous with norm and means a document adopted by agreement, the document which contains rules, guidelines, definitions or criteria that are designed to ensure the quality of materials, products, processes and services. At the same time, there is a distinction between: 1. De jure standards developed and approved by the appropriate standards organisations operating at national level (e.g. Polish Standardisation Committee), regional level such as CEN or global e.g. ISO. 2. De facto standards used because of their popularity and importance on the market, such as ODBC (Object Database Connectivity), introduced by Microsoft or WMS (Web Map Service) standard published by the OGC.

These definitions make no distinction between the concepts of standard and norm. It should be noted, however, that the term “norm” derives from French, where it is distinguished from the concept of a standard.

In continental Europe (and Poland), where the terminology connected with standardisation is mostly of French origin, the term “norm” is mostly understood as a de jure standard, while the notion of standard means the de facto standard.

An example of such an approach may be the definition of norm provided by PKN (Polish Standardisation Committee) (http://www.pkn.pl). It states that the norm is a normative document used on a voluntary basis, commonly available and accepted by a recognised standardisation body. The norm establishes the principles, guidelines or characteristics for various activities and outcomes. It is approved by consensus, and designed for common and repeated use, accepted by all stakeholders as a benefit for all. The norm introduces a code of good practice and principles of rational conduct with the current level of technology.

Standards, Norms, Specifications

41

The provisions of the norm should: • Be based on sound scientific principles and data verified in terms of technology, economy and utility. • Take into account the current state of knowledge and level of technology achieved or achievable in the near future. • Be feasible and absolutely verifiable.

Specification Overall, the concept of specification is defined as (Michalak 2003): 1. Abstract description of programmatic entity (procedure, module, class, object, database, etc.) specifying rules for the use or setting out basic principles for its implementation. 2. Document or a description that specifies in a complete, precise and verifiable way the requirements, design or characteristics of the system or its fragment, and often also the procedures for determining whether those requirements are satisfied. According to the Internet Geomatic Lexicon of Polish Association for Spatial Information (http://www.ptip.org.pl) specification is defined as follows: 1. In computing in general – it means a document or a description that specifies in a complete, precise and verifiable way the requirements, design or characteristics of the system or its fragment, and often the procedures for determining whether those requirements are satisfied. 2. In UML and consequently also in the ISO 19100 series of standards – it means a detailed and complete description identifying “what” something is or “what it is doing”. 3. According to the OGC (Open Geospatial Consortium) specifications– it means a document developed by a consortium, the technology provider or user. Such a document defines a certain area of technology issues in the field and is primarily intended for developers as a set of guidelines and recommendations for the development of implementation of this technology. The specification need not be formally recognised standard (or norm), but usually is submitted as a draft of standard for the official standardisation bodies, such as ISO. However, following the common use of the concept of norm in Polish standardisation literature, in relation to de jure standards, the term “norm” will be used for standards adopted by technical committees ISO/TC 211, CEN/TC 287 and PN/KT 297(Polish standards). Similarly, the term “pre-norms” will be used for documents, which have not yet been adopted but are currently subject to the development by these committees.

42

2

Standards and Interoperability

To Whom for a Standard Computer science, as a field of knowledge, actually does not deal with the spatial aspect of the information. Developing standards for spatial information is the responsibility of Geomatics (geoinformatics) (Michalak 2003), a distinct field of knowledge at the intersection of broadly understood Earth Sciences and computer science.

Many different organisations is involved in developing standards, including legally mandated standardisation bodies, trade associations, initiatives and organisations, non-profit organisations, and even online communities.

These standards are developed mostly within each organisation or group of closely collaborating centres. It also happens that organisations only “endorse” and publish standards, not taking part in their development. An example of such a procedure can be KML (Keyhole Markup Language) – language based on XML that allows for visualisation of three-dimensional spatial data, used in applications like: Google Earth, Google Maps, Google Mobile, Live Search Maps, Yahoo Maps, and NASA World Wind.

KML was developed by Keyhole, Inc., implemented by Google and endorsed by the OGC (Open Geospatial Consortium) as the OpenGIS standard.

Two international organisations remain leaders in developing standards for geoinformation: OGC (Open Geospatial Consortium) and one of ISO technical committees – ISO/TC 211. The roles of these organisations in the standardisation process are different. OGC deals with issues of technology and practical implementation, and ISO with the more formal and procedural approval of standards as the official documents (Michalak 2003). Therefore, in practice, OGC develops technical specifications and the ISO/TC 211 approves them as international standards – ISO 19100 series. Roles of the standardising organisations and the relationships between standards will be described later in this book. Because of the growing interest in geoinformation and its wider and deeper relations with the world of the Internet and mobile technologies, close cooperation of geomatic centres with organisations involved in standardising solutions for the Internet (W3C) and e-business (e.g. OASIS) becomes increasingly important. ebRIM standard for metadata catalogues developed by OGC in collaboration with the OASIS is an example of such co-operation.

To Whom for a Standard

43

Standardisation Organisations in the Field of Geoinformation (Geomatics) ISO: International Organisation for Standardisation (http://www.iso.org) ISO officially began operation on 23 February 1947. Before, the ISO was a nongovernmental, international standard organisation responsible for promoting and developing standards that facilitate international exchange of goods and services. ISO brings together national organisations for standardisation. Governments, despite the fact that some member organisations are part of governmental structures do, not delegate members of the ISO. This puts ISO in a special position between the state and private sector, particularly the industrial associations. Each country is represented, in principle, by only one organisation. Currently, ISO members represent 160 countries. One of founding members of ISO is Polish Committee for Standardisation (PKN). Membership fees, proportionally to the gross domestic product of a country finance ISO activities. Sale of publications, including standards brings additional income. Respecting ISO standards (norms) is voluntary. As a non-governmental organisation ISO can not impose or enforce their use. The authority of the organisation stems from the international representation, establishing standards by consensus, and from understanding the influence of standardisation on markets and economy. There are hundreds of technical committees and working groups developing the individual standards within ISO. One of the Technical Committees is ISO/TC 211, which aims to develop and implement standards (norms) for geographic information and geomatics. (Wikipedia) ISO/TC 211 Technical Committee: Geographic Information/Geomatics (http://www.isotc211.org/) Technical Committee operating within ISO structures, which work aims to establish a structured set of standards (norms) for information concerning objects or phenomena that are directly or indirectly related to the location in relation to the Earth. Committee headquarters are located in Norway. ISO/TC 211 programme of work includes the preparation of over 50 standards for spatial information and geomatics – ISO 19100 series of standards. These standards specify methods, tools and services related to the spatial data management (including the definitions and descriptions): harvesting, processing, analysing, access, presentation and transmission of such data in electronic form between users of different systems. In addition to the standardisation work ISO/TC 211 teams work on ontological and semantic aspects of spatial information.

44

2

Standards and Interoperability

Many organisations are actively involved in the work of ISO/TC 211 Technical Committee. These include CEN – European Committee for Standardisation, the national bodies for standardisation including PKN, OGC, UN agencies and international professional organisations (e.g. FIG (http://www.fig.net) and ICA (http:// www.ica.org)) and special interest organisations (e.g. DGIWG (http://www.dgiwg. org) and ICAO (http://www.icao.int)).

OGC: Open Geospatial Consortium (http://www.opengeospatial.org) The international consortium of more than 400 parties from around the world: commercial organisations, government agencies, non-profit organisations and universities. OGC is not a standards organisation. OGC was established in 1994, but until 2004 the organisation was known as the Open GIS Consortium. Currently, the only member of the OGC from Poland is Polish Association for Spatial Information (PASI), which joined the consortium in 2006. Until then this role was performed by the University of Warsaw, which joined the OGC in 1997, in the period when the consortium began operations, and was the first organisation from Eastern Europe to become OGC member.

The main task of OGC is to develop agreed and accepted specifications for interoperability issues in the field of geoinformation, i.e. the ability of systems to work together. This scope is very widely understood. Thus, specifications concern very general conceptual models as well as detailed technical documents for specific implementations (Michalak 2008). OGC works closely with organisations such as ISO (TC 211), W3C, OASIS, IETF and WfMC. It also has a branch in Europe – OGC Europe. CEN: European Committee for Standardisation (http://www.cen.eu) (french: Comite´ Europe´en de Normalisation) Private technical association which is a non-profit organisation, operating under Belgian law with its seat in Brussels. CEN was founded officially in 1974, but the beginnings of the committee go back to 1961 in Paris. The primary task of CEN is to develop, adopt and disseminate European norms (EN) and other standardisation documents in all areas of the economy with the exception of electrical engineering, electronics and telecommunication. CEN standardisation system is a multinational, multidisciplinary and decentralised organisation. CEN members are the national standards bodies of the European Union countries and European Free Trade Association (EFTA) countries. Currently, CEN has 30 members. One of them is Polish Committee for Standardisation (PKN), which was

To Whom for a Standard

45

granted full membership on 1 January 2004. CEN Members are obliged to introduce European EN standards into their national standards systems and to withdraw existing national standards conflicting with the EN standards. These rule leads to a common system of European solutions. European Standards are one of the foundations of the Single Market and important tool in removing trade barriers within the EU. CEN works closely with CENELEC (European Committee for Electrotechnical Standardisation), ETSI (European Telecommunications Standards Institute) and ISO. There are many technical committees within CEN, one of which is the Technical Committee CEN/TC 287 Geographic Information – which deals with standards in the field of spatial information.

Technical Committee CEN/TC 287: Geographic Information Most activities of CEN/TC 287 can be described by quoting the document “Business Plan of CEN/TC 287” dated March 10, 2008: The main objective is “to facilitate the building of the infrastructure for spatial information in Europe by: 1. Voting on the adoption of ISO 19100 series of standards as CEN standards. 2. Developing new standards, specifications and profiles of standards that underpin INSPIRE implementing rules as they become available. 3. Developing new standards, specifications and technical reports as necessary. 4. Ensuring interoperability by co-operation in particular with ISO/TC 211, the technical co-ordinator of INSPIRE and OGC. 5. Establishing the basic principles for implementation of cultural and linguistic adaptability in CEN member countries; and by researching the possibility of funding with the EU 7th Framework programme for project work that is essential to Europe. 6. Promoting the use of and education on standards for geographic information.”

PKN: Polish Committee for Standardisation (http://www.pkn.pl) The Polish national standard organisation (PKN) is financed from a state budget. PKN was established in 1924, and in the years 1972–1991, together with the Central Office of Weights and Measures formed the Polish Committee for Standardisation and Quality Measurement. The legal basis of PKN activities in the current scope is the Act of 12 September 2002 on standardisation (Journal of Laws – Dz.U. No.169 of 2002, pos. 1386). Since 1991, PKN (then PKNMiJ) was an affiliate of CEN (European Committee for Standardisation) and CENELEC (European Committee for Electrotechnical Standardisation), and on 1 January 2004 became a full member of both institutions. The PKN basic activities are carried out in the areas of:

46

2

Standards and Interoperability

• Determining the status and trends in development of standardisation • Organising and supervising activities related to the development and dissemination of Polish Norms (PN) and other standardisation documents • Approving and withdrawal of PNs and other standardisation documents • Representing the Republic of Poland in international and regional standards organisations • Initiating and organising the work of technical committees to perform tasks related to the development of standards • Organising and conducting training, publishing, promotional and informational activities regarding standardisation and standardisation related fields • Giving opinions on draft legislation related to standardisation Additionally, PKN is required to introduce European EN norms to the system of national standards and withdraw existing PN norms conflicting with EN standards. One of the many technical committees of the PKN is the Technical Committee PKN/KT 297 for Geographical information (http://www.pkn.pl).

The Technical Committee PKN/KT 297 for Geographic Information (http://www.gugik.gov.pl/kt297/) The Technical Committee is an organ of Polish Committee for Standardisation, acting within the scope of financial, housing and organisational resources of Head Office of Geodesy and Cartography (GUGiK). Secretariat of KT 297 operates under an agreement between PKN and GUGiK and within the GUGiK’s structures. Scope of PKN/KT 297 work covers all issues related to modelling and design of data resources in spatial information systems and also to spatial information flow between different users and systems. It has been determined in detail in the “Programme of standardisation work in the field of geographic information” accepted on 16 February 2002 (Pachelski 2002). Main objectives of standardisation activities in the KT 297 for geographical information are: • Enhancing the value and utilisation of geographic information in various fields. • Increasing the accessibility of geographic information and facilitating access to this information for various users, as well as facilitating building relations (integration) with other types of information. • Organising concepts and terminology for the development of foundations for an information communication. • Preparing appropriate foundations for designers of information systems related to geographic information. • Facilitating the efficient circulation of geographical information. • Taking part, through co-operation with international and European standardisation organisations, in the co-ordinated development of the international information community.

To Whom for a Standard

47

In addition, one of the main tasks of this committee, under the obligations to the EU, is introducing European standards EN-ISO in the field of geomatics and spatial information into the system of national standards and withdrawal of the existing PN norms conflicting with EN-ISO standards. In the case of geo-information, this means introducing ISO 19100 series of standards, adopted by the CEN as European standards EN-ISO. PKN/KT 297 committee also runs a web portal containing an electronic version of the terminology guide (e-Guide) to the Polish Norms in the field of geographical information (http://e-przewodnik.gugik.gov.pl).

W3C: World Wide Web Consortium (http://www.w3c.org) Organisation for the development of interoperable standards, enabling the exchange of online information, including standards for developing and transmission of Web pages. Tim Berners-Lee, creator of the first web browser and World Wide Web (WWW) established the W3C in 1994. Today, W3C brings together more than 300 different organisations, businesses, government agencies and universities from around the world. Specifications published by the W3C (which in this case are the de facto recommendations) have no legal force mandating their use, but the influence of the organisation makes them count. Most of common protocols and definitions for the Internet are established and maintained by the W3C, such as XML, XML Schema, WSDL, RDF, HTML, CSS, etc.

OASIS: Organisation for the Advancement of Structured Information Standards (http://www.oasis-open.org) An international non-profit consortium involved in the development of standards for e-business, including Web standards. OASIS was founded in 1993 under the name SGML Open, to promote SGML language (Standard Generalized Markup Language). Organisation name was changed in 1998 to reflect the widening area of operations. The OASIS has more than 5,000 participants from over 100 countries, including more than 600 organisations. OASIS is co-operating closely with OGC in the field of geoinformation. Decision are made by members of the consortium in an open and democratic way. Current work includes such issues as web services, e-commerce, security, law and administration, applications, documents, XML transformations or compliance and co-operation. OASIS standards include: • SAML (Security Assertion Markup Language) – XML-based standard for the secure exchange of information on authentication and authorisation.

48

2

Standards and Interoperability

• XRI (eXtensible Resource Identifier) – naming scheme and resolution protocol of abstract identifiers compatible with URI, used to identify and share resources across domains and applications. • XDI (XRI Data Interchange) – a standard for sharing, linking and synchronising data between multiple domains and applications using XML documents, XRI identifiers and link contract method. • OpenDocument – an open XML-based format for office documents such as text documents, spreadsheets, charts and presentations.

DCMI: Dublin Core Metadata Initiative (http://dublincore.org) This initiative is an open organisation involved in the development of interoperable metadata standards for the Internet, that offer a wide range of purposes, data and business models. DCMI established the Dublin Core standard (Dublin Core Metadata Element Set, DC, DCES) – a general metadata standard, adopted as ISO 15836-2003. This standard defines 15 simple elements for resource description (e.g. library resources). These elements may be encoded in various formats such as RDF (Resource Description Framework) or HTML/XHTML. Dublin Core standard of description is used for example in digital libraries of dLibra system.

How Geoinformation Standards Are Developed Initial work on geoinformation standards began in Europe in early 1990s of the twentieth century. In 1991, CEN Technical Committee TC 287 was established, which started work on the development of European standards in the field of geoinformation. Only a year later came the idea of OpenGIS (beginnings of OGC), initiated among the authors of the GRASS-GIS system from U.S. Army CERL research centre. In October 1994, OGC was founded, and in November of that year ISO/TC 211 was formed. In the mid 1990s, ISO standards and specifications of OGC were only just developing, and their preliminary nature did not allow for practical applications, while the CEN/TC 287 norms had already provided sufficiently formal basis for the design of spatial information systems. That’s why the development of projects in European Union was based on those standards. The next 3 years (1994–1997) were a period of very intensive work in both ISO/ TC 211 and OGC, but carried out separately. As a result, delay in relation to Europe was recuperated, but two different approaches to the same issues were developed (Kuhn 1997). Therefore, October 1997 saw the beginning of a close collaboration between the OGC and ISO/TC 211. One of its objectives was to achieve full compliance of developed geoinformation standards. In 1997 standards developed by CEN/TC 287 began to be published as “prenorms” ENV, with a validity of 3 years. At that time, standards of ISO/TC 211 and

How Geoinformation Standards Are Developed

49

OGC specifications were becoming increasingly important. In Europe, discussions began whether, if ISO develops so highly rated international standards, there is a need to develop separate European standards. The need for standardization in the field of geoinformation in Europe and adoption international ISO standards was also confirmed by EU research projects such as Cast (GIS Interoperability Project Stimulating Industry in Europe) – June 1998. On the other hand there were questions “Why should we give up our already developed CEN/TC 287 norms for the unfinished and foreign documents?” and the opinions that “OpenGIS is the economic aggression of American capital on the European geoinformation market”. The whole situation was complicated by the fact that European geoinformation sector was much less integrated than the similar sectors in other regions of the world, and therefore it was much more difficult to reach a consensus on matters of generally accepted standards. Furthermore, various European countries began to use various combinations of standards: national, European, ISO and OGC. Finally, pragmatism and common sense prevailed. The committee, at its meeting of CEN/TC 287 in Vienna in November 1998, decided not to approve ENV prenorms as norms. Instead, the committee undertook resolutions on the adoption of ISO/TC 211 standards as European norms (15/123) and on “suspending” the work of the technical committee CEN/TC 287 (15/129). These decisions were preceded, in September 1998, by the appointment of a special group for Europe in the OGC – Europe OGC SIG (Special Interest Group Europe OGC). And in February 1999, work on the OpenGIS standards began in Joint Research Center (JRC) – European Commission research institute in Ispra (Italy). Beginning of the twenty first century is a period of further strengthening of co-operation between the EU, ISO/TC 211 and OGC. One of the results of this collaboration was the creation, in June 2001, of OGC Europe based in London. Also, ISO/TC 211 committee began to use achievements of the CEN/TC 287 during development of ISO 19100 series. In Poland, a new Technical Committee PKN/NKP 297 was appointed (now PKN/KT 297) in June 2001 as part of PKN, with the aim of developing Polish geoinformation standards. In April 2002, INSPIRE (Infrastructure for Spatial Information in Europe), the initiative of building a European infrastructure for spatial information about the environment, was officially launched. It is the largest and most serious action of the EU so far, resulting from the decisions of the adoption of ISO/TC 211 standards as European norms. INSPIRE is to be based on ISO 19100 series of standards and the OGC specifications. Also in April 2002, the first Polish spatial data norm based on the European prenorms ENV CEN/TC 287 was developed by PKT/TK 297. At that time, the above mentioned standards were already obsolete for more than 2 years (in fact after the decisions taken at the Vienna meeting, they were only of historical significance) and CEN/TC 287 committee had been suspended for 2 years. At the same time, the whole geoinformation world was adopting ISO standards, and the European Union began the construction of INSPIRE, based on ISO standards and OGC specifications.

50

2

Standards and Interoperability

It should be strongly emphasized, that actions then undertaken by PKN/TK 297 committee were recognised by more advanced part of the Polish geoinformation community as regressive and restraining the development of Polish geoinformation (Gaz´dzicki 2002). In 2003, new circumstances, external conditions and the reform of the Polish national standardisation activities led to the need for far-reaching review and modifications of the scope, programme and forms of PKN/KT 297 activity. These new circumstances and conditions included: • QQ full membership of Poland in the CEN as of 1 January 2004, which requires European norms to be introduced as Polish Norms, including ISO 19100 series standards adopted as European norms. • Intensification of work on the INSPIRE. • Reactivation of the Technical Committee CEN/TC 287 Geographic information, as the authority responsible for building standardisation infrastructure in this field in Europe, necessary to achieve the objectives of INSPIRE. • Adoption by CEN/TC 287 of international ISO standards in the field of geographic information as a basis for building a system of European standards in this field. • Introduction of a new law on standardisation, which strengthened the role and importance of national Technical Committees for the economy and provided for their closer ties with the manufacturing practice. • And also, Polish membership in the European Union since May 1, 2004 (http:// www.Gugik.gov.pl/pkt297/). Observing the intensity of the work carried out in recent years both in Europe and in Poland regarding standards for geoinformation, we can be sure that these initial problems have been completely resolved. In 2007, the INSPIRE Directive was adopted and first guidelines for its implementation were published. Intensive work on the remaining technical guidelines is still in progress. In addition, proposal of the Act of Parliament on the Polish spatial data infrastructure, which transposes the provisions of the INSPIRE Directive into national law, is nearing completion along with the relevant regulations. All these legal solutions involve the use of adequate standards: OGC specifications and ISO 19100 series of standards – adopted as European norms CEN/TC 287 or national norms. The only point that may raise some concern is the question whether the Polish geoinformation sector and the market are adequately prepared for the challenges and responsibilities arising from the need to implement these standards. The development of geoinformation standards has not yet been completed and even if we take into account just the further evolution and development of information systems we should not assume that it will ever end. This process occurs on

How Geoinformation Standards Are Developed

51

many mutually inter wining areas, one of which concerns further development of already adopted standards. Another area is the development of new standards and ensuring full compatibility across all geoinformation standards. It is also very important to implement solutions that meet the requirements of standards in other fields. Example of using UML (Unified Modeling Language) – Collaboration Diagram: Use Case View -> three-level model of standardization and development work on interoperability in geospatial information and geomatics (elaborated in UML on the basis of ISO/TC 211 and OGC documents).

level of ISO/TC 211 standardisation work <<using UML>> ISO 19100 base standards: norm <<using UML>> adapted extensions: norm OGC specifications level (OpenGIS) basic model 1. 2. 3. 4. 5.

(OGC resolutions) Requests for standards Additions and improvements (Resolutions of ISO/TC 211) RFP Procedures Additions and improvements

<<using UML> Abstract specification topics: Abstract specification <> OGC specifications: Implementation specification The level of the general implementation work <> Implementations, services and languages: Application 6. Development 7. Revision Procedures This work is underway both in the OGC and in the ISO/TC 211. The two organisations co-operate closely in this area, as well as with other standardisation organisations such as W3C, OASIS and DCMI. As a result of this collaboration, most of the abstract specifications developed by the OGC has undergone formal procedures in ISO/TC 211 and has been approved and published as ISO 19100 series standards. By the end of April 2010 ISO/TC 211 technical committee had published and approved 30 standards and 7 technical guidelines and technical reports. In addition, committee is working on more then 14 new standards, which are in varying stages of completion (Table 2.1). The process of co-operation between the OGC and ISO/TC 211 is presented on a model of standardisation work in these organisations (Fig. 2.1).

52

2

Standards and Interoperability

Table 2.1 Comparative table of the ISO series 19100 and PN or EN standards ISO 19101: 2002 Reference Model PN-EN ISO 19101:2005 English Norm – defines the scope of the 19100 series of standards and the division into sub-scopes, objectives and means of implementation, it provides the basic terms and relationship to other documents, standards and specifications. It is an introduction and guide to the ISO 19100 series of standards for geospatial information, which enable the widespread use of digital geoinformation ISO 19101–2: 2008 Reference model – Part 2: Imagery No EN or PN standards Technical Specification – defines a reference model for standardisation in the field of geospatial imagery. Describes a reference model including grid type data, with emphasis on aerial photographs and satellite images ISO 19102 Overview No EN or PN standards The project discontinued in 2001 ISO 19103: 2005 Conceptual schema language No EN or PN standards Norm – describes the UML (Unified Modelling Language) as chosen by ISO/TC 211 for conceptual schemas. Specifies the UML Profile for spatial information. Provides rules and guidelines for the use of UML conceptual diagrams in ISO standards for geospatial information. Planned completion date of draft for EN standard: October 2010 ISO 19104: 2008 Terminology No EN or PN standard Norm – applicable to international communication in the field of spatial information. Provides guidelines for the collection and maintenance of terminology in the field of geoinformation. Establishes criteria for the selection of concepts to be covered by other standards for geospatial information (developed by ISO/TC 211), specifying the structure of the terminology and rules for the description and definition writing. This document includes a set of 11 metaterms and 1488 terms, 793 of which refer to definitions, and many symbols, abbreviations and acronyms. No information about the start of work on the drafts of EN or PN standards ISO 19105: 2000 Conformance and testing PN-EN ISO 19105:2005 English Norm – provides guidelines, concepts, criteria and methodology for verifying conformance of geospatial data, IT products and services and specifications, including profiles and functional standards to ISO standards for geospatial information. The standard defines two classes of conformance: conformance of the specifications to ISO standards series for geographic information and conformance of chapters regarding compliance with the provisions of ISO 19105. This document also sets the rules for defining abstract conformance testing, and testing procedures. In addition, the standard includes descriptions of identified types of conformance tests, conformity assessment processes and discussion on the methodology of testing ISO 19106: 2004 Profiles PN-EN ISO 19106:2006 English Norm – defines a concept of a profile of the ISO geographic information standards (developed by ISO/TC 211) and gives guidance for the creation of such profiles. According to this standard, only those components of specification, corresponding to the profile definition given by the standard, may be established and applied through the mechanisms described in the standard. These profiles may be standardised internationally. The standard also provides guidance for establishing, managing, and standardising at the national level ISO 19107: 2003 Spatial schema PN-EN ISO 19107:2010 English (continued)

How Geoinformation Standards Are Developed

53

Table 2.1 (continued) Norm – specifies conceptual schemas to describe the spatial characteristics of geographic features and to manipulate these characteristics. Features of objects are described only by the vector data. Geometrical models covered by this standard provide means for quantitative descriptions of spatial features, using the co-ordinates and mathematical functions. Topological models described in the standard provide means for qualitative descriptions of the spatial characteristics of geographic features and relationships between them ISO 19108: 2002 Temporal Schema PN-EN ISO 19108:2010 English Norm – defines concepts for describing temporal characteristics of geographic information. Defines the (conceptual) model of time for spatial information in which it provides: temporal geometric primitives and temporal topological objects, temporal location and temporal reference systems. It provides basis for defining temporal attributes, operations and relations of spatial objects, as well as temporal elements of geoinformation metadata ISO 19109: 2005 Rules for application schema PN-EN ISO 19109:2009 English Standard – defines the rules for creating and documenting application schemas, including rules for the definition of features. Includes: conceptual modelling of features and their properties from a universe of discourse; defining application schemas, use of conceptual schema language for application schemas, the integration of standardised schemas from other ISO geographic information standards with the application schema ISO 19110: 2005 Feature Cataloguing Methodology PN-EN ISO 19110:2010 English Norm – defines a methodology for cataloguing feature types and specifies how the classification of feature types is organized into a feature catalogue and presented to users of spatial data resources. This methodology is applicable to creating catalogues of feature types in previously uncatalogued areas, as well as to revising the existing feature catalogues to comply with standard practice ISO 19111: 2007 Spatial referencing by co-ordinates PN-EN ISO 19111:2007 English Norm – outlines the elements necessary to fully define the different types of co-ordinate reference systems applicable in geoinformation. It also describes the co-ordinate transformations and conversions between different co-ordinate reference systems. The annexes to the standard describe procedure for verifying compliance of the reference system description with the standard and provide example descriptions of reference systems. Extensive explanations of some terms used in the standard are also provided Spatial referencing by co-ordinates – Part 2: Extension for ISO/PRF 19111-2 parametric values No EN or PN standards The draft standard – defines the conceptual schema for describing the spatial references using the parametric values or functions. It applies the schema of ISO 19111 to combine a position referenced by co-ordinates with a parametric value to form a spatio-parametric co-ordinate reference system (CRS), which can optionally be extended to include time. Draft ISO standard – planned completion date: 12.2009 ISO 19112: 2003 Spatial referencing by geographic identifiers PN-EN ISO 19112:2005 Standard – defines the conceptual schema for spatial references based on geographic identifiers. It establishes a general model for spatial referencing using geographic identifiers, defines the components of a spatial reference system and essential components for gazetteer services. This document is in some way helps users understand the application of spatial references for the (continued)

54

2

Standards and Interoperability

Table 2.1 (continued) data. It is applicable to digital geospatial data, but its principles can be extended to other types of information such as maps, charts, text documents ISO 19113: 2002 Quality Principles PN-EN ISO 19113:2009 English Standard – defines a schema for assessing the quality of spatial data: data sets series, data sets and subsets. It defines the essential measurable and not measurable components of geographic data quality and lays down principles of organisation of information about the quality of data sets. The standard provides general guidelines for recording information about the quality. The standard is designed for producers of spatial data sets providing information on product quality and for users who want to check to what extent the product meets their expectations ISO 19114: 2003 Quality Evaluation Procedures PN-EN ISO 19114:2005 English Standard – provides guidance on procedures for the evaluation of measurable quality of geospatial data sets according to the quality model specified in ISO 19113. The document contains description of the 5-phase process of quality assessment, categorised quality assessment methods and procedures for assessing the quality of geographic data. In addition, it includes tips for recording the results of quality evaluation of geospatial data directly in metadata and in the external report. The standard is applicable for producers of geographical data sets, which supply information about the degree of conformity of data sets with the product specifications as well as for data users who wish to verify that the set contains data of adequate quality. Following documents complement the standard: ISO 19114:2003/Cor 1:2005 (PN-EN ISO 19114:2005/AC:2006) ISO 19115: 2003 Metadata PN-EN ISO 19115:2005 English Norm – provides the structure for the description of spatial data set and spatial services. It defines the metadata (data about data) to record information about the identification of geospatial data sets, data quality and coverage, applied spatial and temporal schemes, systems of reference and principles of dissemination and sharing digital spatial data. It presents the conceptual metadata schema, indicating mandatory, optional and conditional metadata elements. The document establishes common terminology for metadata and provides mechanisms for extending the normative metadata with new elements in order to meet the specific information needs of users of the standard. Metadata schema is presented in the form of UML class diagrams complemented with tabular description in a normative Annex B. The standard is intended for systems analysts, designers, systems programmers and anyone interested in the basic principles and requirements for the standardisation of spatial information. The document relates primarily to digital spatial data, but can also be applied to many other forms of spatial data, such as paper maps, charts and text documents as well as for non-geographic data. Following documents complement the standard: ISO 19115:2003/Cor 1:2006 (PN-EN ISO 19115:2005/AC:2008). Completion of Polish language version is planned for November 2010 ISO 19115–2:2009 Metadata – Part 2: Extensions for imagery and grid type data No EN or PN standard Norm – extends the existing geographic metadata standard by specifying schema required for describing the gridded data and imagery: aerial photographs and satellite images. The schema contains information about the properties of measuring devices used for data acquisition, the geometry of the measuring process and the production process including raw data digitisation. The work on draft EN standard is under way – planned completion: February 2010. No information about the start of work on the PN draft ISO 19116: 2004 Positioning services PN-EN ISO 19116:2006 English (continued)

How Geoinformation Standards Are Developed

55

Table 2.1 (continued) Norm – defines the data structure and content of an interface to allow communication between the position-providing devices and the devices using this position, to permit a consistent interpretation of information about the location and to determine whether results meet the requirements of use. A standardised interface of geographic information with position allows the integration of positional information from a variety of positioning technologies into a variety of geographic information applications, such as surveying, navigation and intelligent transportation systems ISO 19117: 2005 Portrayal PN-EN 19117:2010 English Standard – defines a schema that describes the portrayal of geographic information in a form understandable by humans. It includes the methodology for describing symbols and mapping of the schema to an application schema. This does not include standardisation of cartographic symbols and their geometric and functional description ISO 19118: 2005 Encoding PN-EN ISO 19118:2006 English Standard – specifies the requirements for defining encoding rules to be used for the exchange of spatial data within ISO international standards: creating encoding rules based on UML schemas, creating encoding services and non-regulatory, XML based encoding rule for platform-independent exchange of spatial data. The document provides rules, which are consistent with conceptual schemas used for storage or transmission, and definitions of the mapping between the language of conceptual schemas and storage rules. The document does not specify any digital media services do not define any transmission or communication protocols, nor does it specify how the on-line coding of large images ISO 19119:2005 Services PN-EN ISO 19119:2010 English Norm – identifies and defines the architecture patterns for service interfaces used for geographic information. It presents a geographic services taxonomy and a list of example geographic services placed in the services taxonomy. It contains guidelines for for the selection and specification of the geospatial services both in terms of platform-independent services, as well as specific services for specific platforms. It also defines its relationship to the Open Systems Environment model (OSE) ISO/TR 19120:2001 Functional standards No EN or PN standards Technical report – regards identifying areas in which development of ISO standards should be influenced by experience of sectors where these standards are applied. No information about the initiation of work on PN and EN draft standards ISO/TR 19121: 2000 Imagery and gridded data No EN or PN standards Technical report – regards treatment of images and grid type data(matrix) in the context of their application for graphical information and geomatics. No information about the initiation of work on EN or PN draft standards ISO/TR 19122: 2004 Qualification and certification of personnel No EN or PN standards Technical report – on an organisational system for the qualification and certification of personnel in the field of Geographic Information/Geomatics. No information about the initiation of work on EN or PN draft standards ISO 19123: 2005 Schema for terrain coverage geometry and functions PN-EN ISO 19123:2010 Polish Standard – defines a conceptual schema for the spatial characteristics of terrain coverage. This coverage supports mapping from a spatial, temporal or spatiotemporal domain to feature (continued)

56

2

Standards and Interoperability

Table 2.1 (continued) attribute values, where feature attribute types are common to all geographic positions within the domain. A coverage domain consists of a collection of direct positions in a co-ordinate space, which can be defined in up to three dimensions, as well as a temporal dimension. Examples of coverage include raster, triangulated irregular networks, points and polygon of coverage. Standard conception schema for description of spatial characteristics of terrain coverage ISO 19124 Imagery and grid data components No EN or PN standards Concepts for the description and representation of imagery and grid data in the context of other standards of this group. The project has closed ISO 19125-1: 2004 Simple feature access – Part 1: Common architecture PN-EN ISO 19125-1:2006 English Standard establishes a common, coherent structure of simple geometric objects and defines terms to use within this structure. Standardises the names and definitions of geometric types. It does not include requirements on how to define geometry types in the internal schema. Implements the spatial profile of the schema described in EN-ISO 19107. Annex A (informative) presents a relationship between common architecture concept established in this standard and the concepts of geometrical models according to EN-ISO 19107. Polish language version of that standard is under development – planned completion date: September 2010 ISO 19125-2: 2004 Simple feature access – Part 2: SQL option PN-EN ISO 19125-1:2006 Standard specifies an SQL schema that supports the storage, retrieval, query and update of simple geospatial feature collections via SQL Call Level Interface (SQL/CLI) (ISO/IEC 90753:2003). It also establishes architecture for the implementation of feature tables. Defines terms to use within the architecture. Defines the profile of EN-ISO 19107 for simple features. It describes a set of geometric data types for SQL (Geometry Type). This part of ISO 19125:2004 does not attempt to standardise and does not depend upon any part of the mechanism by which Types are added and maintained in the SQL environment, including the following: • The syntax and functionality provided for defining types • The syntax and functionality provided for defining SQL functions • The physical storage of type instances in the database • The specific terminology used to refer to User Defined Types, for example, UDT Polish language version of that standard is under development – planned completion date: November 2010 ISO 19126 Feature concept dictionaries and registers PN-EN ISO 19126:2009 Standard – a document defines the profile based on a feature dictionary and feature attributes defined in the DIGEST standard ISO/TS 19127: 2005 Geodetic codes and parameters No EN or PN standard Technical Specification – defines the rules for developing a single international database of reference systems and the spatial projections. It specifies rules for the operation and maintenance of registers of geodetic codes and parameters and identifies the data elements in accordance with ISO 19135 and ISO 19111, required within these registers. No information about the work on EN or PN standards ISO 19128:2005 Web Map Server Interface PN-EN ISO 19128:2010 (Polish) Standard – specifies the behaviour of a service that produces spatially referenced maps dynamically from geographic information. “Map” presents geographic information as a digital image stored in file in the form appropriate for display on the monitor screen. Maps produced (continued)

How Geoinformation Standards Are Developed

57

Table 2.1 (continued) by WMS are provided in the form of raster file such as PNG, GIF, JPEG, or less frequently – in the form of vector graphics SVG or WebCGM. Map is not data, therefore, WMS may not be used as a source of current feature data or coverage. Standard defines three operations: – GetCapabilities – to obtain a detailed description of the maps available on the server – GetMap – to retrieve maps, and – GetFeatureInfo – to query the server for attributes of features displayed on the map. GetCapabilities and GetMap are mandatory and therefore must be implemented in any WMS service. HTTP protocol and HTTP GET method as a basic mechanism of communication between the client and the WMS server. It makes possible sharing maps via the Internet, including the creation of maps based on queries in the form of images, set of graphical elements or set of data relating to the selected features ISO/TS 19129:2009 Imagery, gridded and coverage data framework No EN or PN standard (English) Technical specification – framework for the description and representation of images, grid data and coverage. No information about the initiation of work on EN or PN draft standards Geographic information – Imagery sensor models for ISO/TS 19130:2010 geopositioning No EN or PN standards (English) Technical specifications – the sensor model describing the physical and geometric properties, as well as data for the sensors to obtain information in the form of images and grid data. No information about the initiation of work on EN or PN draft standards ISO 19131:2007 Data product specifications PN-EN ISO 19131:2008 (English) Standard – provides requirements for the specification of geographic data products. It determines the structure and scope of the specification, and provides an example of applying the guidelines for the description of data product. The document provides detailed technical description of data set series, complemented by information on the creation, distribution and use of the product by other parties. Product specification defines a set of data in terms of requirements that the set should or could comply with ISO 19132:2007 Location-based services – Reference model PN-EN ISO 19132:2008 (English) Standard – model and a conceptual framework for location-based services (LBS), and describes the basic principles by which LBS applications may inter-operate. The document specifies the framework’s relationship to other frameworks, applications and services for geographic information and to client applications ISO 19133:2005 Location-based services – Tracking and navigation PN-EN ISO 19133:2007 (English) Standard – describes the data types, and operations associated with those types, for the implementation of tracking and navigation services. This standard is designed to specify web services that can be made available to wireless devices through web-resident proxy applications, but is not restricted to that environment ISO 19134:2007 Location-based services – Multimodal routing and navigation PN-EN ISO 19134:2008 Standard – specifies the data types and their associated operations to support the tracking and navigation applications for mobile clients, who want to get to their destination using two or more modes of transport. It describes the type of services, which support tracking and navigation, based on means of transport with strictly fixed route or timetable. The service may be made available to wireless devices through web-resident proxy applications. Services may also be implemented in other environments. The standard defines for each operation a pair – request/response and also specifies data types for the transfer, planning and information about the route of mean of transport (continued)

58

2

Standards and Interoperability

Table 2.1 (continued) ISO 19135:2005 Geographic information – Procedures for item registration PN-EN ISO 19135:2010 (Polish) Standard – specifies procedures to be followed in establishing, maintaining and publishing registers of unique, unambiguous and permanent identifiers, and meanings that are assigned to items of geographic information. To achieve this goal the document specifies the details of information that is necessary to ensure the identification and meanings of the registered items and to manage the registration of these items ISO 19136:2007 Geography Markup Language – GML PN-EN ISO 19136:2009 (English) Standard – defines the geographic markup language (GML) to introduce XML-based standard for the spatial and non-spatial properties of geographic features. GML language determines the XML Schema syntax, mechanisms and rules that form the basis for system-independent description of the geospatial application schemas. XML encoding set in GML is compliant with ISO 19118 guidelines for transportation and storage of geographic information modelled in accordance with the guidelines of the conceptual model used in the family of International Standards ISO 19100 ISO 19137:2007 Core profiles of the spatial schema PN-EN ISO 19137:2008 (English) Standard – defines a baseline profile for ISO 19107, which defines a minimal set of geometric elements needed to create geographic application schemas. Profile supports data types for zeroone-and two-dimensional simple geometric elements. A profile can be expanded in the future with a package of simple topological elements. Profile supports many of the spatial data formats and description languages already developed and in broad use within several nations or liaison organisations. Appendix A lists some specifications based on this profile. User groups can define their own profiles meeting specific requirements beyond the baseline profile. The rules for creating extensions of core profile are discussed in Appendix C ISO/TS 19138:2006 Data quality measures No EN or PN standards Technical specification – defines a set of data quality measures. These can be used when reporting data quality ISO/TS 19139:2007 Metadata – XML schema implementation CEN ISO TS 19139:2009 Metadata – XML schema implementation ISO/TS 19139:2007 defines Geographic MetaData XML (gmd) encoding ISO 19140 No EN or PN standards The project is not implemented. ISO 19141:2008 Schema for moving features PN-EN ISO 19141 Standard – defines a method to describe the geometry of a feature that moves as a rigid body. The movement has defined characteristics. The feature moves within any domain composed of spatial objects as specified in ISO 19107, following the planned route, but it may deviate from the planned route. Movement may be affected by: fields (e.g. gravitational field), inertial forces as well as by other features. Motion of a feature can also affect other features. Moving feature follows a predefined route, part of a network, and might change routes at known points. Moving features may also attract each other (may be linked) or may be pushed apart (separate), and may also be constrained to maintain a given spatial relationship for some period. Other types of change to the feature, such as deformation, succession, change of non-spatial attributes, have not been addressed. Date of publication of EN norm: August 2009. PN standard is under development – planned completion date: December 2010 (continued)

How Geoinformation Standards Are Developed

59

Table 2.1 (continued) ISO/DIS 19142 Web Feature Service prPN-EN ISO 19141 Draft standard – defines web service for access and modification of the geographic features residing in a data store on a remote server. The service also provides means for the construction, storage and confiquration of queries to the server. Control of access to geographic features is not addressed in the document. PN standard is under development – planned completion date: December 2011 ISO/DIS 19143 Filter encoding No EN or PN standards The draft standard. ISO/FDIS 19144-1: 2009 No EN or PN standards Final draft. Classification Systems – Part 2: Land cover classification system ISO/CD 19144-2 (LCCS) No EN or PN standards The draft standard. ISO/CD 19145 Registry of representations of geographic point location No EN or PN standards The draft standard. ISO/DIS 19146 Cross-domain vocabularies prPN-prEN ISO 19146 The draft standard – defines the relationship between technical dictionaries, adopted by the various industry-specific geospatial communities. It also specifies an implementation of ISO 19135 for the registration of geographic information concepts for the purpose of integrating multiple domain-based vocabularies. PN standard is under development – planned completion date: December 2011 ISO 19147 No EN or PN standards The project is not implemented. ISO/CD 19148 Location-based services – Linear referencing system prEN ISO 19148 Draft standard. Working on a draft EN standard is under way – planned completion date: October 2010 ISO/CD 19149 Rights expression language for geographic information – GeoREL No EN or PN standard The draft standard. ISO 19150 No EN or PN standard The project is not implemented. Dynamic position identification scheme for ubiquitous space ISO/NP 19151/CD (u-position) No EN or PN standards Draft standard. ISO/CD 19152 Land Administration Domain Model – LADM prEN ISO 19152 Work on draft EN standard is under way – planned completion date: December 2011 (continued)

60

2

Standards and Interoperability

Table 2.1 (continued) Geospatial Digital Rights Management Reference Model (RM ISO/CD 19153 GeoDRM) No EN or PN standards Draft standard ISO 19154 No EN or PN standards The project is not implemented ISO/CD 19155 Place Identifier (PI) Architecture No EN or PN standards Draft standard ISO/CD 19156 Observations and measurements No EN or PN standard Draft standard ISO/NP 19157 Data quality prEN ISO 19157 Work on EN standard is under way – planned completion date: February 2012 ISO/NP TS 19158 Quality assurance of supply data No EN or PN standards Draft technical specification Calibration and validation of remote sensing imagery sensors and 19159 data ISO/NP TS 19159

Approved and published ISO 19100 series standards are submitted to the Technical Committee CEN/TC 287 and after appropriate formal and legal procedures they are adopted as European norms EN ISO. In accordance with the requirements of the European Union, approved European standards shall be adopted as national standards. In Poland, the Technical Committee PKN/KT 297 is responsible for this process with regard to geoinformation. This committee is the recipient of new European standards EN ISO, which, after formal and legal procedures are adopted and published as the Polish Norm PN-EN ISO. Unfortunately, for procedural reasons the adoption of ISO standards as European standards, and then as Polish norms is relatively long and may take several years. Currently (as of end of April 2010) 30 Polish norms PN-EN ISO are already adopted, and more, gradually, pass through the approval procedure. This work also includes translations of standards from original version into Polish (see Table 2.1). Explanations to the table: Number of ISO standard Title of ISO standard Number of PN or EN standard In case of PN standards, the language in which PN was published Abstract and comments. Abstracts describing standards and projects were elaborated on the basis of information from the websites: http://www.iso.org; http://www.cen.eu; http://www.pkn.org.pl

How Geoinformation Standards Are Developed

61

Fig. 2.1 Three-level model of standardisation and development work on interoperability in geospatial information and geomatics (elaborated in UML on the basis of ISO/TC 211 and OGC documents) (Michalak 2002)

Additional information about the Polish Standards can be found on PKN/TC 297 web portal, including an electronic version of the terminology guide (e-Guide) to the Polish Standards in the field of geographical information (http://e-przewodnik.

62

2

Standards and Interoperability

Fig. 2.2 Process of developing and approving geoinformation standards (Senkler 2006 – completed)

gugik.gov.pl) . During the preparation of this book, version 2.0 of the e-Guide of 13 December 2007 was available, relating to the 21 standards for ISO. The process of development and validation of geoinformation standards described above is presented in the following diagram (Fig. 2.2).

How Geoinformation Standards Are Developed

63

CEN/ISO | ISO 191xx standards | OpenGIS specifications | PN norms Initially, European standards were adopted as Polish standards by two methods: the recognition method and so-called cover-sheet method. Introduced by these methods, norms include the full text of the European standards in their original language, i.e. in English. Standards introduced by the cover-sheet method are equipped with title page in Polish language and with additional information in Polish, such as the preface and attachments. Cover-sheet method of introducing standards is no longer used (http://www.pkn.pl). Currently, 28 of ISO 19 100 series standards adopted as European standards is also approved as Polish standards, of which only one (adopted in 2010 PN-EN ISO 19113:2009 Geographic information – Basic description of the quality) is published in Polish. Other standards are published in the original language, i.e. in English (http://www.pkn.pl). According to the information on PKN/KT 297 website (http:// www.gugik.gov.pl/ tk297), translation into Polish was prepared only for one of 27 Polish Norms PKN/TC 297 (PN-EN ISO 19115:2005 metadata). When discussing the Polish standards on geoinformation, it is important to comment on their formal, legal status and obligations and the possibility of their use, resulting from the current legal situation. The comments given below are based on the comment 17 (61/07) provided in the website of the National Land Information System Users Association (GISPOL) (http://www.gispol.org). The application of standards is voluntary. Standards organisations are nongovernmental organisations and as such may not impose or enforce the use of standards. It is the authority of the organisation, establishing standards by consensus as well as understanding of the influence of standardisation on economy that induces governments to adopt Polish, international or European standard for compulsory application. The possibility of compulsory application of the standards was clearly stated in the previous laws on standardisation: Acts of 1961 and 1993. In the current Act of 2002, it results from Article 5 paragraph 4, in the context of the wording of the PNEN 45020:2000. Under those provisions, although the application of Polish Standards is voluntary, those standards may be referenced by the legislation after their publication in Polish. The PN-EN 45020:2000 distinguishes normative references and recommendations, and introduces the term of mandatory standard – defined as the standard, which is mandated under the general law or through a reference in a provision of law requiring its use. This means, that standards for spatial information that are currently published in English, may not be referenced by the legal regulations, until they are published in Polish. It is as if those standards did not exist. This issue is important as the regulation on the minimum requirements for computer systems to the Act on the Computerisation, refers (implicitly) to the discussed here Polish standards for geoinformation. In this situation, it seems necessary to take immediate steps to develop and publish official versions of Polish Norms for geoinformation in Polish.

64

2

Standards and Interoperability

OGC Specifications or ISO 19100 In order to clarify issues related to the ISO 19100 series of standards and OGC specifications, we should answer three frequently asked questions about geoinformation standards (Michalak 2002a, b): 1. What are the main concerns of OpenGIS specifications and ISO 19100 standards? Their main concern is interoperability of geoinformation systems, which are the building blocks of spatial information infrastructures. Therefore, these specifications regard elements needed to accomplish interoperability, that is: • • • •

Unified data models Well defined interfaces Languages to access and manipulate data based on these interfaces Automatic translation of data and models

2. What aspects are not the concern of OpenGIS specifications and ISO 19100 standards? These specifications do not concern the thematic aspect (regarding specific sectors) of geoinformation e.g. they define geometric types such as point, line or polygon, but not water gauge station, river or lake. Those aspects belong to particular thematic domains for example hydrology. Issues of web applications are also beyond the scope of these specifications, except issues regarding application layer (top layer in seven-layer OSI Network model or five-layer model of Internet). Furthermore, within the mentioned application layer, specifications do not concern access rights to specific data sets in databases and processing systems or protection against unauthorised access. Also, they do not concern the system of charging for the accessed data. If a geoinformation systems require to take into account the above mentioned features, the implementation of these feature is based on general IT standards regarding those issues. In such a case, system architecture is based on the collection of standards, including geoinformation standards. 3. What documents are better: ISO 19100 series standards or OGC specifications? When a few years ago both these organisations began their operations separately, one could have an impression that the results of their actions would be different – even competing. Currently, however, co-operation is so far advanced that the results of the standardisation in this area are the joint work of both organisations – a significant part of ISO 19100 standards are adaptations of OGC specifications. The main difference between the two standards lies in the fact that the OGC specifications are technical documents, whereas ISO standards are formal, normative specifications. Geoinformation standards represent a kind of summary of the current state of knowledge in geomatics and can be considered as a basis for further research on

OGC Specifications or ISO 19100

65

these issues. However, due to the nature of the standardisation work of the technical committee ISO/TC 211, standards developed by this committee do not cover all aspects of this field. Still, they provide a framework, to which all other work on standardisation may relate, including purely research projects (Michalak 2002). Quite a substantial difference between the ISO and OGC specifications is payment for standards. OGC specifications are free of charge and can be downloaded for free from the website of the Consortium. In contrast, standards issued by ISO, CEN and PKN must be purchased. Information about current rates, and forms and methods of purchase is available on the websites of ISO, CEN and PKN.

ISO 19100 Series of Standards ISO geoinformation standards are formalised specifications and therefore differ significantly from the typical criterion standards. Another thing that sets them apart is the use of UML diagrams (Unified Modelling Language – a formal language used to describe the world of objects in object-oriented analysis and object-oriented programming), describing in detailed and precise way the conceptual models presented there (Fig. 2.3). Therefore, to use these standards fully and efficiently some knowledge of UML is needed, at least ability to read and understand class diagrams. To better present this issue, graphic notation for above mentioned conceptual models is presented, which may be helpful in reading and analysing them (Fig. 2.4). The table below, which summarises issues dealt with by ISO 19100 standards series (Table 2.1) allows to become familiar with their scope and subject matter, as well as with the timetable of ISO/TC 211 committee work (after Michalak 2002 – revised and supplemented). The discussed standards, although consist of separate documents, are closely interrelated and complementary. The relationships between ISO standards are presented in Fig. 2.5.

OGC Specifications The specifications developed by the OGC are divided into two levels in terms of generality. Some of these specifications were submitted to the Technical Committee ISO/TC 211 and after completion of formal procedures they were adopted as ISO 19100 series standards. Higher level, called the Abstract Specification is independent of the system environment. On the lower level are Implementation Standards – equivalent to the specification at a higher level but adapted to different implementation environments. This level also includes other OGC implementation documents, which do not correspond to Abstract Specification

2

Fig. 2.3 Information about a set of metadata entities – example of UML conceptual model of ISO 19115

66 Standards and Interoperability

OGC Specifications or ISO 19100

Fig. 2.4 Relationships and dependencies between selected ISO 19100 series standards

Fig. 2.5 Metadata packages according to ISO 19115

67

68

2

Standards and Interoperability

Table 2.2 OpenGIS Specifications (OGC) Date of Document title Version Document revision Topic 0 – Abstract Specification Overview 5.0 04-084 27.06.25 Presents general principles regarding the entire OpenGIS Specification, defines UML as primary description tool and lays down rules for its use in Abstract Specification. Includes an introduction and a roadmap for the OpenGIS Specification Topic 1 – Feature Geometry 5.0 01-101 10.05.2001 Defines elementary and complex geometric and topological forms and topological operators used for features. Equivalent to ISO 19107 standard Topic 2 – Spatial Reference Systems 3.0 04-046r3 11.02.2004 Addresses all issues regarding direct geospatial references Theme 3 – Locational Geometry Structures 4.0 99-103 18.03.1999 Defines structures, which determine the relationship between the conversion of one reference system into another, and mapping corresponding co-ordinate values Theme 4 – Stored Functions and Interpolation 4.0 99-104 30.03.1999 Specifies the rules for functions being the components of features related to the object-oriented paradigm derived from the UML language Topic 5 – Features 5.0 08-126 15.01.2009 Defines the most important concept in the field of spatial information: “feature is the primary (elementary) unit of a geoinformation” and a number of specific, related issues Topic 6 – The Coverage Type and its Subtypes 7.0 07-011 28.12.2007 Defines coverage as subtype of a feature, its conceptual model and a number of coverage subtypes Topic 7 – The Earth Imagery Case 5.0 04-107 15.10.2004 Defines the images of the Earth (e.g., aerial photographs and satellite images) as a special sub-type of coverage with the method of transition from picture element to the corresponding coordinates of a particular reference system. Corresponds to the ISO 19101-2 Topic 8 – Relationships Between Features 4.0 99-108r2 26.03.1999 Defines types of relationships, roles of individual features in these types of relationships, and types of roles Topic 10 – Feature Collections 4.0 99-110 07.04.1999 Defines feature collection as an abstract object that contains feature instances, including related schema Topic 11 – Metadata 5.0 01-111 08.06.2001 Defines metadata as data relating to the feature collection or to specific features which are elements of such collection. Introduces the concept of metadata entity and metadata set which is a collection of metadata entities, as well as the concept of metadata subclasses Topic 12 – OpenGIS Service Architecture 4.3 02-112 14.09.2001 Basic services, which may be used in a system environment consistent with OpenGIS Specification. Equivalent to ISO 19119 Topic 13 – Catalogue Services 4.0 99-113 31.03.1999 This is an extension to geospatial information access services, providing more detail on the related services by defining the Catalogue, Catalogue Entry, librarian and metadata entities in the catalogue Topic 14 – Semantics and Information Communities 4.0 99-114 04.04.1999 In the context of OpenGIS Specifications the notion of information communities usually means professional groups using geoinformation and exchanging this kind of information Topic 15 – Image Exploitation Services 6.0 000-115 24.04.2000 (continued)

Metadata Standards for Geoinformation

69

Table 2.2 (continued) Date of Document title Version Document revision These services include ground co-ordinate transformation, image co-ordinate transformation, imaging time determination, and image modification and transformation services Topic 16 – Image Co-ordinate Transformation Services 4.0 00-116 24.04.2000 Covers all aspects of spatial and temporal transformations of images, including orthorectification of these images Topic 17 – Location Based Mobile Services 0.0 00-117 15.05.2000 Draft specification regarding positioning services. Never formally adopted Topic 18 – Geospatial Digital Rights Management Reference Model (GeoDRM RM) 1.0.0 06-004 29.01.2007 This document is a reference model for digital rights management (DRM) functionality for geospatial resources (GeoDRM) Prepared on the basis of the information available on the website: http://www.opengeospatial.org/ and in J. Michalak elaboration (2003)

(Michalak 2003; OGC). The overall scope of issues addressed by OGC Abstract Specification is defined by 19 topics (parts). An important part of the OGC studies form OGC Implementation Standards and related documents. Implementation Standards currently regard 28 topic categories (as of end of February 2009). Table below presents issues dealt with in various OGC specifications (Table 2.2) along with their scope and subject matter (after Michalak 2002 – revised and supplemented).

Metadata Standards for Geoinformation For the purposes of characterising metadata standards for geoinformation, they can be divided into two main groups. The first group includes standards that define rules for describing resources, i.e., for creating metadata. In the second group we can place standards for the dedicated metadata services – that is, standards for metadata catalogues. Since the individual standards do not fully exhaust particular subject matters, in many places they refer to other standards. For example, if the standard for metadata requires recording creation date, the proper way to record dates is regulated by a standard for temporal references. For this reason, discussed standards can also be divided into: main standards, directly regarding metadata, and additional standards – necessary for the proper establishment and/or functioning of the metadata, but regarding other matters. The group of main standards for metadata includes primarily ISO 19115.

ISO 19115:2003 Geographic Information: Metadata ISO 19115 standard was published in May 2003. This standard was developed as the result of broad international co-operation of representatives from 33 countries

70

2

Standards and Interoperability

and 12 organisations. In developing of the standard, rich experience gained in the development and use of previous standards for metadata: the European CEN prenorm 12657 of 1998 and standard of FGDC (U.S. Federal Geographic Data Committee) of 1994, was taken into account the. ISO 19115 standard defines the schema for the description of spatial data resources and related services. It is applied to cataloguing and fully describing the metadata. Rules included in this standard can be used to describe spatial data, spatial data series and individual objects and their attributes. The standard defines sets of metadata to record information on: the identification of spatial data sets, their scope and coverage, data quality, applied spatial and temporal schemas, reference systems and mapping systems and the rules of distribution of spatial data in digital form (Fig. 2.5). The standard defines the conceptual schema of the metadata in the form of UML class diagrams complemented by a tabular description. Mandatory, optional and conditional metadata elements were indicated and ISO Metadata Profile was defined. The document establishes a uniform terminology for metadata and provides mechanisms for extending the normative metadata with new elements in order to meet the specific information needs of users of the standard – metadata creators. Although the standard was basically conceived to be used for digital data, it can also be used to describe (create metadata) for spatial information not in digital (electronic) form, e.g. for paper maps, charts and text documents and also for not spatial data resources. It should, however, be noted that some metadata elements, made by this standard obligatory, may not apply to other forms of data. In 2005, the ISO 19115 standard was adopted as European standard EN ISO 19115:2005 Geographic information – Metadata and the Polish Norm PN-EN ISO19115: 2005 Geographic information – Metadata (version in English). This standard was also translated into Polish as early as 2004 but this version was not published and distributed.

In 2006, ISO/TC 211 committee published a corrigendum to this standard: ISO 19115:2003/Cor 1:2006. It was adopted by CEN in 2008 under the name “ISO 19115:2005/AC: 2008 Geographic information – Metadata (ISO 19115:2003/Cor 1:2006) and PKN as a PN-EN ISO 19115:2005/AC:2008 Geographic information – Metadata (version in English). Neither PKN website nor PKN/KT 297 committee website give any information on the translation of this corrigendum into Polish.

In early 2009, the ISO/TC 211 committee published an extension to this standard as ISO 19115–2:2009 Geographic information – Metadata – Part 2: Extensions for

Metadata Standards for Geoinformation

71

imagery and grid data. It extends the existing standard, by providing the required schema for description (metadata) of aerial photographs, satellite imagery and grid data. This schema contains information about the parameters of measuring devices used for data acquisition, the geometry of the measuring process, data acquisition process and the production process – raw data digitisation. Currently there is no information about the approval of the extension by CEN/TC 287 or PKN/KT 297. ISO 19115 is an international standard, its national counterpart in the U.S. is, already mentioned, FDGC metadata standard endorsed in 1998. It should be stressed that currently FDGC standard is being replaced by ISO 19115. Please note that the first attempt to develop an international standard for the description of any digital resources (documents) through various types of metadata was DublinCore standard (as mentioned earlier, mainly used to describe library resources, but also used to describe digital spatial data resources). Currently DublinCore is being replaced with an ISO standard.

ISO/TS 19139:2007 Geographic Information: Metadata: XML Schema Implementation Another major standard from the first group is ISO/TC 19139. It defines a way of encoding ISO metadata in XML notation through XML Schema Definition (XSD). Applying this standard is necessary, if the metadata are to be published in the metadata catalogues and properly function in the Internet, and thus within the Spatial Data Infrastructure (SDI). ISO/TS 19139:2007 is in fact a technical specification, which defines encoding of metadata created according to ISO 19115 in XML notation. It specifies the only appropriate UML model for an interpretation of ISO 19115 abstract metadata model and defines the corresponding XML Schema (XSD) for the collection and transfer of meta-information. It was developed to provide a common XML specification for the description, verification and exchange of geoinformation metadata. It provides a formal structure for describing spatial information resources that can be managed by the catalogue services in accordance with the profile of the application. Currently, standard (Technical Specifications) has already been adopted as European standard CEN ISO/TS 19139:2009 Geographic information – Metadata – XML schema implementation (ISO/TS 19139:2007). There is no information on the planned start of work on adopting it as the Polish Norm.

ISO 19119:2005 Geographic Information: Services The most important standard from a group of standards for metadata catalogues is ISO 19119. It deals with all general spatial data services, including catalogues of metadata.

72

2

Standards and Interoperability

The standard identifies and defines the architecture patterns for service interfaces in the field of spatial information and determines their relationship to the OpenSource Software (FOSS) environment. Moreover, it presents a geographic service taxonomy and a list of example geographic services placed in the services taxonomy. It also contains guidelines for the selection and specification the spatial information services in terms of both platform-independent services, as well as platform-specific services. In 2006, the ISO 19119 standard was adopted as European standard EN ISO 19119:2006 Geographic information – services and the Polish Norm PN-EN ISO 19119:2006 Geographic information – services (English version). Translation of this standard into Polish is under way. According to the schedule of PKN/KT 297, Polish language version of this standard is to be published in late December 2009.

In 2008, ISO/TC 211 committee published an amendment to this standard as ISO 19119:2005/Amd 1:2008 Extensions of the service metadata model. This amendment concerns the extension of the specification for metadata catalogue services. Currently there is no information about the approval of the extension by the CEN/TC 287 or PKN/KT 297.

The discussed group of standards should also include specifications: OGC CSW (Catalogue Service for the Web) 2.0 and OGC CSW Application Profile for 19115 and 19119.These standards relate to the capabilities of publishing and discovery of information describing spatial data sets and spatial data services. These standards define how metadata catalogues shall be constructed, how they shall operate, and based on which metadata profile (in this case ISO). It should be noted that OGC specifications for CSW (metadata catalogue) could also be applied to different (non-ISO) profile such as: FDGC, Dublin Core, ebRIM. Relationships between the major standards for metadata are presented on the following diagram (Fig. 2.6): Additional standards regarding metadata catalogues are the following OGC documents for services and metadata (Web Registry Service): • OGC 99113, OGC Abstract Specification Topic 13: Catalogue Services • OGC 02006, OGC Abstract Specification Topic 12: OpenGIS Service Architecture • OGC 04021r3, OGC Catalogue Services Specification, v2.0.1 (with Corrigendum) • OGC 04095, OGC Filter Encoding Implementation Specification, version 1.1.0 • OGC 05008, OGC Web Services Common Specification, version 1.0

Metadata Standards for Geoinformation

73

Fig. 2.6 Diagram of relationships between standards for geospatial metadata (Senkler 2006, 2007)

ISO 19135:2005 Geographic Information: Procedures for Item Registration Another standard – that can be included in a group of additional standards – which is very important, because of the need to develop appropriate identifiers for metadata files and metadata managing systems, is ISO 19135:2005 standard (Senkler 2006, 2007). The standard defines the procedures to be followed during the establishment, maintenance and publication of registers of unique, unambiguous and permanent identifiers and meanings assigned to spatial information registry entries. To achieve this objective the standard specifies the elements of information that are necessary to ensure the identification and meaning to the registered items, and to manage the registration of these items. In 2007, ISO 19135 was adopted as European standard EN ISO 19135:2007 Geographic information – Procedures for item registration and the Polish Norm PN-EN ISO 19135:2007 Geographic information – Procedures for registration of items registered (English version). Translation of the standard into Polish is under way. According to the PKN/KT 297 roadmap, Polish language version of this standard is to be published in late December 2009.

Other additional standards indirectly relevant to the metadata, are following ISO standards (Kubik 2007): • ISO 19105:2000 Conformance and Testing • ISO 19106:2004 Profiles • ISO 19108:2002 Temporal schema

74

• • • • •

2

Standards and Interoperability

ISO 19125-1:2004 Simple feature access – Part 1: Common architecture ISO 19125-2: Simple feature access – Part 2: SQL option ISO/CD 19136:2007 Geography Markup Language (GML) ISO 639:2002 Codes for the representation of names of languages ISO 8601:2004 Representation of dates and times

W3C recommendations relevant to metadata catalogues – W3C documents on the XML applications (Kubik 2007): • W3C Recommendation January 1999, Namespaces in XML • W3C Recommendation 6 October 2000, Extensible Markup Language (XML) 1.0 (Second Edition) • W3C Recommendation 2 May 2001: XML Schema Part 0: Primer • W3C Recommendation 2 May 2001: XML Schema Part 1: Structures • W3C Recommendation 2 May 2001: XML Schema Part 2: Datatypes • W3C Recommendation (24 June 2003): SOAP Version 1.2 Part 1: Messaging Framework • WSDL, Web Services Description Language (WSDL) 1.1 Metadata are available through metadata catalogue services, which are Internet services – web services. Therefore, it is important that these sites also meet the following standards regarding the HTTP protocol (Kubik 2007): • IET F RFC 2388, Returning Values from forms: multipart/formdata • IET F RFC 2616, Hypertext Transfer Protocol HTTP/1.1 While discussing standards for metadata, one should also mention the current trends and developments in the field of standardisation. In January 2007 it was officially announced that the OGC has adopted a new standard for online catalogues of metadata – based on the ebRIM profile (e-registry information model of business) by OASIS organisation. The current version is: OASIS ebRIM, ebXML Registry Information Model Version 3.0. In future ebRIM profile is to become the preferred profile for the OGC metadata catalogues for the CSW specification (Catalogue Service for Web). This standard was chosen because of its versatility and flexibility – it allows for cataloguing and managing of services, various types of information and records such as library catalogues, co-ordination systems, application profiles and schemas, as well as spatial data and related services. This standard does not preclude the existing methods and search services provided by the previously used protocols.

Chapter 3

Metadata Profiles Based on ISO 19115

What Is a Metadata Profile The metadata profile term means a subset of the metadata classes and elements of metadata standard, possibly extended with metadata elements not included in the basic standard (Pacho´ł 2008). ISO 19115 standard defines almost 400 metadata elements, most of which are optional and their use is voluntary. The standard also specifies mandatory elements, which form a core set of metadata components. In most cases, only a chosen subset of metadata elements is used in practice. The subset, in any case, must include the core set of metadata components. Mandatory metadata elements are necessary for the correct identification of resources and to enable their cataloguing. Core ISO metadata profile is discussed in detail further in this chapter. The different communities, societies, industries or organisations can create their own metadata profiles, e.g.: • National – e.g., in Poland: National Metadata Profile for Geoinformation (ordered by GUGiK) • Regional • Sector-specific – specific to particular industry or organization – in Poland: Polish Geological Institute metadata profile • Domain-specific – for example, the metadata profile for the geophysical data • Other Profiles may include elements of the metadata defined in ISO 19115 and also additional elements which do not appear in the standard. Creating metadata profiles based on the normative elements of metadata, as well as extending the scope of profiles must be done in accordance with the principles described in International Standard. Procedures and rules for extending metadata profiles are presented in more detail further in this book. ISO 19115 standard specifies the following rules for creating profiles of metadata: L. Litwin and M. Rossa, Geoinformation Metadata in INSPIRE and SDI, Lecture Notes in Geoinformation and Cartography, DOI 10.1007/978-3-642-15862-9_3, # Springer-Verlag Berlin Heidelberg 2011

75

76

3 Metadata Profiles Based on ISO 19115

Fig. 3.1 The relationship between the core metadata components (the basic set of metadata), the comprehensive metadata application profile and community profile.

1. Before creating a profile, the user shall check registered profiles (i.e., already existing profiles) 2. A profile must adhere to the rules for defining an extension if profile contains metadata elements not defined in International Standard 3. A profile shall not change the name, definition, or data type of a metadata element 4. A profile shall include: • The core metadata collected for a digital geographic dataset • All mandatory metadata elements in all mandatory sections (Fig. 3.1) • All conditional metadata elements in all mandatory sections, if the dataset meets the condition required by the metadata element • All mandatory metadata elements in all conditional sections, if the dataset meets the condition required by the section • All conditional metadata elements in all conditional sections, if the dataset meets the condition required by the metadata element and the section 5. Relationships, as provided in Annex A, shall be defined so that a structure and schema can be determined 6. A profile shall be made available to anyone receiving metadata that was created according to that profile

The Structure of Metadata Profiles The ISO 19115 metadata have a hierarchical structure and are presented in the form of UML packages describing metadata sections. Each section of the metadata (equivalent to a package in UML terminology) includes one or more

Types of Metadata Elements and Entities

77

metadata entities (classes in UML terminology), which can be specified or generalised. Entities can be aggregated and, if necessary, repeated to meet the mandatory requirements resulting from the standard or additional user requirements. The basic unit of this structure is metadata element (attribute in UML terminology). Definitions of the structure elements according to ISO 19115: Metadata element – discrete (smallest, basic) unit of metadata. Metadata elements are unique within a metadata entity Metadata entity – set of metadata elements describing the same aspect of data. Entity can contain one or more metadata entities Metadata section – subset of metadata, which consists of a collection of related metadata entities and metadata elements

The structure of the profile is described in the standard through UML model diagrams and so-called data dictionaries for geographic metadata, with UML model diagrams considered authoritative in case of discrepancies. UML diagrams, combined with the data dictionary fully define a complete abstract model of metadata. The table presents the relationship between UML model and data dictionary for geographic metadata (Table 3.1).

Types of Metadata Elements and Entities According to the ISO 19115 standard, individual metadata entities or metadata elements can be mandatory, optional, or their use may be conditional. Mandatory elements – metadata elements that shall be documented unconditionally, that is, they must have assigned values. Optional elements – metadata elements that may, but need not be documented. Table 3.1 Relationship between a UML model and data dictionary

UML model Metadata package Superclass/generalized class Subclass/specified class Class Attribute Association

Data dictionary Metadata section Metadata entity Metadata entity Metadata entity Metadata element Metadata element

78

3 Metadata Profiles Based on ISO 19115

Optional metadata entities and optional metadata elements were defined to ensure that data could be fully documented. If an optional entity is not used, then the elements contained within this entity (including mandatory elements) also will not be used. Mandatory elements become mandatory only when the optional entity, which include these elements, is used.

The ISO standard specifies the cases in which some conditional metadata entities or conditional metadata elements become mandatory.

Each metadata entity or metadata element has attributed the maximum number of its appearance. It indicates the number of copies that a metadata entity or metadata element may have, e.g., a data set may have only one name (title) but many keywords.

Packages (Sections) of Metadata Types of Metadata Packages ISO 19115 standard specifies 14 packages of metadata (corresponding to metadata sections) which contain one or more metadata entities. Figure 2.5 illustrates relationships between metadata packages and Table 3.2 presents the relationship between metadata packages and metadata entities included in those packages.

Metadata Entities in the ISO 19115 Documented by Other ISO Standards Some entities in the ISO 19115 are taken from other ISO standards. Those “externally taken” entities are: • Date and DateTime information. Entity Date gives values for year, month and day. DateTime entity is a combination of date and time (given by an hour, minute and second). The encodings of those two entities shall follow specification given in ISO 8601. Both classes (entities) are fully documented in ISO/TS 19103. • Information about the Distance, Angle, Measure, Number, Record, type of Record (Record Type), Scale and the unit of measure length (UomLength). This classification is fully documented in ISO/TS 19103.

Packages (Sections) of Metadata

79

Table 3.2 Table of relationships between metadata packages and metadata entities (contains descriptions of packages) Package Entity Package description Information on metadata entity set MD_Metadata The information on the set consists of the mandatory MD_Metadata entity. The entity contains both, mandatory and optional metadata elements. MD_Metadata entity is an aggregate of the following entities. Information on identification MD_Identification The package contains information, which uniquely identifies the data. This includes information on the citation for the resource, an abstract, purpose, credit, the status and points of contact. The MD_Identification entity is mandatory. It contains mandatory, conditional and optional elements. The MD_Identification entity may be specified (subclassed) as MD_DataIdentification if it is used to identify data, or as MD_ServiceIdentification if it is used to identify a service. MD_ServiceIdentification provides an abstract description of the service (see: ISO 19119). • MD_Identification is an aggregate of the following entities: • MD_Format (format of the data) • MD_BrowseGraphic (graphic overview of the data) • MD_Usage (specific uses of the data) • MD_Constraints (constraints placed on the resource) • MD_Keywords (keywords describing the resource) • MD_MaintenanceInformation (how often the data is scheduled to be updated and the scope of the update) • MD_AggregateInformation (information about datasets that are aggregate parts of the dataset that the metadata describes) Elements EX_GeographicBoundingBox and EX_GeographicDescription of MD_DataIdentification entity are conditional. One of them shall be included if the dataset is spatially referenced. If necessary, both elements may be used. The characterSet element of MD_DateIdentification is conditional and should be used if ISO/IEC 10646–1 is not used. Information on constraints MD_Constraints This package contains information concerning the restrictions placed on data. MD_Constraints entity is optional and can be specified as MD_LegalConstraints and/or MD_SecurityConstraints. Element otherConstraints of MD_LegalConstraints entity shall be used only if the elements accessConstraints and/or useConstraints have a value of (continued)

80

3 Metadata Profiles Based on ISO 19115

Table 3.2 (continued) Package Package description “otherRestrictions”, which is on the MD_RestrictionCode codelist. Information on data quality The package contains an overall assessment of the quality of the data set. DQ_DataQuality entity is optional and contains the scope of the quality assessment. DQ_DataQuality is an aggregate of LI_Lineage and DQ_Element. DQ_Element can be specified as DQ_Completeness, DQ_LogicalConsistency, DQ_PositionAccuracy, DQ_ThematicAccuracy and DQ_TemporalAccuracy. Those five entities represent elements of data quality, and can be further subclassed to the sub-elements of data quality. Users may add additional elements and sub-elements of data quality by sub-classing DQ_Element or other appropriate sub-element. The package also contains information on data sources and processes used to produce the data set. LI_Lineage entity is optional and contains a statement about the lineage. LI_Lineage is the aggregate of LI_Source and LI_ProcessStep entities. Information on maintenance This package consists of information about the scope and frequency of data updates. The MD_MaintenanceInformation entity is optional and contains mandatory and optional metadata elements. Information on spatial representation The package includes information on the mechanisms used for the representation of spatial information in a dataset. MD_SpatialRepresentation entity is optional and can be further specified as MD_GridSpatialRepresentation and MD_VectorSpatialRepresentation. Each of the specified entities contains mandatory and optional metadata elements. When further description is necessary, MD_GridSpatialRepresentation may be specified as MD_Georectified and/or MD_Georeferenceable. Metadata for Spatial data representation are derived from ISO 19107. Information on reference system This package contains the description of the spatial and temporal reference system(s) used in a dataset. MD_ReferenceSystem contains an element to identify the used reference system. MD_ReferenceSystem may be subclassed as MD_CRS, which is an aggregate of MD_ProjectionParameters and MD_EllipsoidParameters.

Entity

DQ_DataQuality

MD_MaintenanceInformation

MD_SpatialRepresentation

MD_ReferenceSystem

(continued)

Packages (Sections) of Metadata Table 3.2 (continued) Package Package description MD_ProjectionParameters is an aggregate of MD_ObliqueLineAzimuth and MD_ObliqueLinePoint. Information on content This package contains information identifying the used feature catalogue (MD_FeatureCatalogueDescription) and/or information describing the content of a coverage dataset (MD_CoverageDescription). Both entities are subclasses of the MD_ContentInformation entity. MD_CoverageDescription may be subclassed as MD_ImageDescription, and has an aggregate of MD_RangeDimension. MD_RangeDimension may additionally be subclassed as MD_Band. Information on catalogue of cartographic image (portrayal catalogue) This package contains information identifying the portrayal catalogue used. It consists of the optional entity MD_PortrayalCatalogueReference. This entity contains the mandatory element used to specify which portrayal catalogue is used by the dataset. Information on distribution This package contains information about the distributor of, and options for obtaining, a resource. It contains optional MD_Distribution entity. MD_Distribution is an aggregate of the options for the digital distribution of a dataset (MD_DigitalTransferOptions), identification of the distributor (MD_Distributor) and the format of the distribution (MD_Format), which contains mandatory and optional elements. MD_DigitalTransferOptions contains the medium used for the distribution (MD_Medium) of a dataset, and is an aggregate of MD_Distributor. MD_Distributor’s other aggregate is the process for ordering a distribution (MD_StandardOrderProcess). Information on Metadata extension The package contains information about the extensions specified by the user. It contains the optional MD_MetadataExtensionInformation entity. MD_MetadataExtensionInformation is an aggregate of information describing the extended metadata elements (MD_ExtendedElementInformation). Information on application schema The package contains information about the application schema used to build the data set. It contains the optional entity MD_ApplicationSchemaInformation. The entity contains mandatory and optional elements. Information on extent The datatype in this package is an aggregate of the metadata elements that describe the spatial and

81

Entity

MD_ContentInformation

MD_PortrayalCatalogueReference

MD_Distribution

MD_MetadataExtensionInformation

MD_ApplicationSchemaInformation

EX_Extent

(continued)

82

3 Metadata Profiles Based on ISO 19115

Table 3.2 (continued) Package

Entity

Package description temporal extent. EX_Extent entity contains information about the geographic (EX_GeographicExtent), temporal (EX_TemporalExtent) and the vertical (EX_VerticalExtent) extent of the referring entity. EX_GeographicExtent can be subclassed as EX_BoundingPolygon, EX_GeographicBoundingBox and EX_GeographicDescription. The combined spatial and temporal extent(EX_SpatialTemporalExtent) is an aggregate of EX_GeographicExtent. EX_SpatialTemporalExtent is a subclass of EX_TemporalExtent. The EX_Extent entity has three optional roles named: “geographicElement”, “temporalElement”, and “verticalElement”, and an element called “description”. At least one of the four shall be used. CI_Citation Information on citation and responsible party CI_ResponsibleParty This package of datatypes provides a standardised method (CI_Citation) for citing a resource (dataset, feature, source, publication, etc.), as well as information about the party responsible (CI_ResponsibleParty) for a resource. The CI_ResponsibleParty datatype contains the identity of person(s), and/or position, and/or organisation(s) associated with the resource. The location (CI_Address) of the responsible person or organisation is also defined in the package.

• Information about the object attribute type (GF_AttributeType), feature type (GF_FeatureType) and property type (GF_PropertyType).These classes are fully documented in ISO 19109. • Information about the length of the time period – the period duration in accordance with ISO 8601 (TM_PeriodDuration) and temporal primitive – an abstract class representing a non-decomposed element of geometry or topology (TM_Primitive).This classification is fully documented in ISO 19108. • Point (GM_Point) and Object information (GM_Object).This classification is fully documented in ISO 19107. • Set and Sequence information. These classes are fully documented in ISO/TS 19103. • Type name information, including classes: AttributeName, GenericName and MemberName. These classes are fully documented in ISO/TS 19103. • Vertical datum information (SC_VerticalDatum) – set of parameters describing the relation of gravity-related heights to the Earth. This class is fully documented in ISO 19111.

Data Types and Their Domains

83

Data Types and Their Domains The data type defines a set of not repeating, the limited values (domain) used to represent metadata elements. Types of data describing the metadata elements are defined in ISO 19118 standard. The following are the examples of data types: Integer, Real, Boolean, String, Date, DateTime, SG_Point. The data type attribute is also used in the ISO 19115 standard to define metadata entities, stereotypes and metadata associations. For a metadata element, a domain specifies the values allowed or permits the use of any text. In case of metadata, the expression “free text” means that no restrictions are placed on the content of the field. The values allowed may be limited by data type or code lists (integer-based codes). ISO 19115 standard specifies 25 code lists (classes with the stereotype <>) and 2 (two) enumerations (classes with stereotype <<Enumeration>>), containing from 2 to 29 positions (codes), to represent values of metadata elements. It should be noted that the enumerations are closed lists (cannot be extended), while code lists are extendable, so new positions may be added to them in accordance with methods specified by the standard. For this reason, in classes of these two stereotypes there are no values “other” – except for: otherRestrictions; code: 008; definition: limitation not listed above, code list: MD_RestrictionCode. To bring this issue closer to the reader, the names of these lists, the number of items on the list, definition of the list, and an example (name, code, definition) are presented below: CI_DateTypeCode <> – 3 items; identification of when a given event occurred, e.g., publication; code: 002; definition: date identifies when the resource was issued. CI_OnLineFunctionCode <> – 5 items; function performed by the resource, e.g., information; code: 002; definition: online information about the resource. CI_PresentationFormCode <> – 14 items; mode in which the data is represented, e.g., mapDigital; code: 005; definition: map represented in raster or vector form. CI_RoleCode <> – 11 items; function performed by the responsible party, e.g., pointOfContact; code: 007; definition: party who can be contacted for acquiring knowledge about or acquisition of the resource. DQ_EvaluationMethodTypeCode <> – 3 items; type of method for evaluating an identified data quality measure, e.g., indirect; code: 003; definition: method of evaluating the quality of a dataset based on external knowledge. DS_AssociationTypeCode <> – 5 items; justification for the correlation of two datasets, e.g., stereoMate; code: 005; definition: part of a set of imagery that when used together, provides three-dimensional images.

84

3 Metadata Profiles Based on ISO 19115

DS_InitiativeTypeCode <> – 15 items; type of aggregation activity to which datasets are related, e.g., experiment; code: 004; definition: process designed to find if something is effective or valid. MD_CellGeometryCode <> – 2 positions, code indicating whether grid data is point or area, e.g., area; code: 002; definition: each cell represents an area. MD_CharacterSetCode <> – 29 items; name of the character coding standard used for the resource, e.g., utf8; code: 004; definition: 8-bit variable size UCS Transfer Format, based on ISO/IEC 10646 MD_ClassificationCode <> – 5 items; type of the restrictions put on the dataset, e.g., confidential; code: 003; definition: available for someone who can be entrusted with information. MD_CoverageContentTypeCode <> – 3 positions; specific type of information represented in the cell, e.g., physicalMeasurement; code: 003; definition: value in physical units of the quantity being measured. MD_DatatypeCode <> – 15 items; datatype of element or entity, e.g., class, code: 001; definition: descriptor of a set of objects that share the same attributes, operations, methods, relationships, and behavior. MD_DimensionNameTypeCode <> – 8 items, name of the dimension, e.g., column; code: 002; definition: abscissa (x) axis. MD_GeometricObjectTypeCode <> – 6 items, name of point or vector objects used to locate zero-, one-, two-, or three-dimensional spatial locations in the dataset, e.g., curve; code: 003; definition: bounded, 1-dimensional geometric primitive, representing the continuous image of a line. MD_ImagingConditionCode <> – 11 items; code which indicates conditions which may affect the image, e.g., night, code: 006; definition: image was taken at night. MD_KeywordTypeCode <> – 5 items; methods used to group similar keywords, e.g., place, code: 002, definition: keyword identifies a location. MD_MaintenanceFrequencyCode <> – 12 items; frequency with which modifications and deletions are made to the data after it is first produced, e.g., monthly, code: 005; definition: data is updated each month. MD_MediumFormatCode <> – 7 items; method used to write to the medium, e.g., tar, code: 002; Tape ARchive. MD_MediumNameCode <> – 18 items, name of the medium, e.g., dvd; code: 002; definition: digital versatile disc. MD_ObligationCode <<Enumeration>> – 3 items; obligation of the element or entity, e.g., optional; code: 002; definition: element is not required. MD_PixelOrientationCode <<Enumeration>> – 5 items; point in a pixel corresponding to the Earth location of the pixel, e.g., upperRight; code: 004; definition: next corner counterclockwise from the lower right. MD_ProgressCode <> – 7 items, status of the dataset or progress of a review, e.g., onGoing; code: 004; definition: data is continually being updated.

Data Types and Their Domains

85

MD_RestrictionCode <> – 8 items; limitation(s) placed upon the access or use of the data, e.g., copyright; code: 001; definition: exclusive right to the publication, production, or sale of the rights to a literary, dramatic, musical, or artistic work, or to the use of a commercial print or label, granted by law for a specified period of time to an author, composer, artist, distributor. MD_ScopeCode <> – 16 items; class of information to which the referencing entity applies, e.g., dataset; code: 005; definition: information applies to the dataset. MD_SpatialRepresentationTypeCode <> – 6 items; method used to represent geographic information in the dataset, e.g., vector; code: 001; definition: vector data is used to represent geographic data. MD_TopicCategoryCode <> – 19 items; high-level geographic data thematic classification to assist in the grouping and search of available geographic data sets. Can be used to group keywords as well. Listed examples are not exhaustive. NOTE: It is understood there are overlaps between general categories and the user is encouraged to select the one most appropriate. For example, geoscientificInformation; code: 008; definition: information pertaining to earth sciences. Examples: geophysical features and processes, geology, minerals, sciences dealing with the composition, structure and origin of the earth’s rocks, risks of earthquakes, volcanic activity, landslides, gravity information, soils, permafrost, hydro-geology, erosion. MD_TopologyLevelCode <> – 9 items; degree of complexity of the spatial relationships, e.g., fullTopology3D; code: 008; definition: complete coverage of a 3D Euclidean co-ordinate space.

Extensions of Metadata Profiles ISO 19115 standard as the de jure specification of a global reach was constructed in such a way that definitions and domain values are intended to be sufficiently generic to satisfy the metadata needs of various disciplines. However, the diversity of spatial data resources and a wide range of areas related to geoinformation means, that in certain situations the generic metadata contained in the ISO 19115 may not accommodate all applications. For these reasons, the standard allows to create community profiles, and gives rules for defining and applying additional metadata in order to adapt a profile to specific requirements and needs. The standard allows the following types of extensions: 1. Adding a new metadata section 2. Creating a new metadata code list to replace the domain of an existing metadata element that has “free text” listed as its domain value 3. Creating new metadata code list elements (expanding a code list) 4. Adding a new metadata element

86

3 Metadata Profiles Based on ISO 19115

5. Adding a new metadata entity 6. Imposing a more stringent obligation on an existing metadata element 7. Imposing a more restrictive domain on an existing metadata element Rules for creating extensions require, prior to the creation of extended metadata, a careful review of the existing metadata within International Standard to check whether suitable metadata does not already exist. Furthermore, for each extended metadata section, entity, and/or element, the following shall be defined: • • • • • • • •

Name Short name Definition Obligation Condition Maximum occurrence Data type Domain value

Relationships as provided in the UML model shall be defined so that the structure and profile schema can be determined. The rules for creating an extension of metadata profiles are similar to the rules for creating a metadata profile: 1. Extended metadata elements shall not be used to change the name, definition or data type of an existing element. 2. Extended metadata may be defined as entities and may include extended and existing metadata elements as components. 3. An extension is permitted to impose more stringent obligation on existing metadata elements than the standard requires.(Metadata elements that are optional in the standard may be mandatory in the extension). 4. An extension is permitted to contain metadata elements with domains that are more restrictive than the standard (Metadata elements whose domains have free text in the standard may have a closed list of appropriate values in the profile). 5. An extension is permitted to restrict the use of domain values allowed by the standard.(If the standard contains five values in the domain of an existing metadata element, the extension may specify that its domain consists of three domain values. The extension shall require that the user select a value from the three domain values). 6. An extension is permitted to expand the number of values in a code list. 7. An extension shall not permit anything not allowed by the standard. Methodology for extending the metadata described in the standard (Appendix F) gives guidance on metadata extension and provides clearly defined nine-stage methodology: Stage 1 Review of existing metadata elements. Stage 2 Definition of a new metadata section.

Examples of Metadata Profiles

87

Stage 3 Definition of a new metadata codelist. Stage 4 Definition of a new metadata codelist element. Stage 5 Definition of a new metadata element. Stage 6 Definition of a new metadata entity. Stage 7 Definition of a more stringent metadata obligation. Stage 8 Definition of more restrictive metadata codelist. Stage 9 Documentation of metadata extensions.

Examples of Metadata Profiles Mandatory Metadata Profile According to ISO 19115 Standard ISO 19115 standard defines an extensive metadata set covering almost 400 metadata elements. However, among the whole set of predefined metadata elements, only 13 elements create a minimal list of mandatory metadata elements that must always be included in the metadata profile and must be documented (must have values). Applying these metadata elements forms a basis to ensure compliance of metadata profile or metadata with ISO 19115. Use of this profile is quite limited. It can be used only for basic identification of resources and their cataloguing. These mandatory metadata elements presented in Table 3.3. They are presented in the hierarchical structure of metadata profile, using the method of presentation of metadata profile in accordance with the INSPIRE Implementing rules for metadata. The description is composed of: • A “þ” sign indicating the beginning of the description and its position in the line of text (indentation) indicates level in the hierarchy of a profile • Number in brackets indicates maximum number of occurrences • A “:” sign (colon) separates the name of the metadata element or entity from their domain or data type

Base Profile (Core) of ISO Metadata for Spatial Datasets The ISO 19115, in addition to the minimum mandatory metadata profile and full profile including all metadata elements, defines core metadata profile for spatial data. It uses mandatory, optional and conditional metadata elements. Core profile includes a list of recommended metadata elements answering the following questions: • • • •

What? – Does a dataset on a specific topic exist? Where? – Does a dataset for a specific place exist? When? – Does a dataset for a specific date or time period exist? Who? – Who is the point of contact to learn more about or to order the dataset?

88

3 Metadata Profiles Based on ISO 19115

Table 3.3 Selected obligatory elements of metadata

The use of this base profile metadata can significantly facilitate collaboration, allowing users to understand without ambiguity the spatial data and associated metadata provided by either the producer or the distributor. It is important that the dataset includes a list of core metadata elements. These elements of core metadata profile are presented in Table 3.4. Below, the core elements are presented in the hierarchical structure of the metadata profile, using the method of presentation as for the minimum mandatory metadata profile (see previous section). Presented structure of this metadata profile is described only to the level specified in the standard. Elements extending the minimum metadata profile to the core profile are presented in bold.

INSPIRE Metadata Profile INSPIRE metadata profile is defined in two documents: 1. Commission Regulation (EC) No 205/2008 of 3 December 2008 for implementation of Directive 2007/2/EC of the European Parliament and the Council regarding the metadata 2. INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119 (Implementing Rules of INSPIRE regarding metadata)

INSPIRE Metadata Profile Table 3.4 Elements of the metadata base profile

89

90

3 Metadata Profiles Based on ISO 19115

The first of those documents formally defines a set of metadata elements constituting the INSPIRE metadata profile and gives their multiplicity and value domains. The second of those documents is practically a documentation of INSPIRE metadata profile. It should be noted that for the regulation of 15 December 2009 there is a “Corrigendum to INSPIRE Metadata Regulation” – introducing two minor corrections of editorial nature. Currently, the second version of the document is in effect as regards implementing rules. This version of 3 February 2009 “INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119 (Revised edition)” is a revision of the document dated 26 October 2008 – “INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119 (First edition)”. For more information, please visit the INSPIRE Metadata tab at http://www.inspire.jrc.ec.europa.eu. INSPIRE Implementing Rules provides also a list of additional documents indispensable to be used when developing the metadata in accordance with the INSPIRE profile. This list consists of the following documents: • EN ISO 19115:2005, Geographic information – Metadata • ISO 19115/Cor.1:2006, Geographic information – Metadata, Technical Corrigendum 1 • ISO 19119:2005, Geographic information – Services • ISO 19119:2005/Amd 1:2008, Extensions of the service metadata model • EN ISO 19108:2005, Geographic information – Temporal Schema • ISO 639–2, Codes for the representation of names of languages – Part 2: Alpha-3 code • ISO 8601, Data elements and interchange formats – Information interchange – Representation of dates and times • ISO/TS 19139:2007 Geographic information – Metadata – XML Schema Implementation • CSW2 AP ISO, OpenGIS Catalogue Services Specification 2.0.2 – ISO Metadata Application Profile, Version 1.0.0, OGC 07–045, 2007 • ISO 10646–1, Information technology – Universal Multiple-Octet Coded Character Set (UCS) – Part 1: Architecture and Basic Multilingual Plane The basis for the development of the INSPIRE metadata profile was Core Metadata Profile of ISO 19115. It should be stressed that the current version of the profile (December 19, 2008) in some areas extends ISO profile, however, some of the optional elements of the core ISO profile are not included in it. In addition, the profile of Inspire is more precise and detailed then very general core ISO profile, by identifying the individual elements of these metadata entities, which were not described in detail in ISO profile. INSPIRE profile also changes the multiplicity for some of the metadata entities and metadata elements, as well as expands or restricts code lists and enumerations. All of these changes were carried out according to profile construction and extension methodologies provided by ISO 19115. In conclusion it should be noted that in order to achieve full compliance with ISO 19115, additional metadata elements

INSPIRE Metadata Profile

91

that are not required by INSPIRE, should be used. Furthermore, compliance with the core metadata profile of ISO does not guarantee compliance with INSPIRE. INSPIRE profile covers the same packages of metadata (metadata sections) as metadata profile recommended by ISO 19115, except information about the system of reference (MD_ReferenceSystem). Following metadata sections are included: • • • •

Metadata on metadata (under MD_Metadata) Information on identification (MD_Identification) Information on distribution (MD_Distribution) Information on data quality (DQ_DataQuality)

It should be emphasized that the INSPIRE profile, in accordance with INSPIRE Directive and Regulation, shall apply only to three types of resources: • Spatial data • Spatial data set series • Spatial data services The definitions of these resources, in accordance with the standard, the Directive and the Regulation are given below: Spatial data set – means an identifiable collection of data. A dataset may be a smaller grouping of data which, though limited by some constraint such as spatial extent or feature type, is located physically within a larger dataset. Theoretically, a dataset may be as small as a single feature or an object attribute contained within a larger dataset. A hardcopy map or chart may be considered a dataset Spatial data set series – a collection of spatial data sets having the same product specification Spatial data services – mean the operations which may be performed, by invoking a computer application on the spatial data contained in spatial data sets or on the related metadata The above restriction is achieved by introducing into the INSPIRE profile (extension of ISO profile) the metadata element hierarchyLevel(6) and limiting its value domain (codelist MD_ScopeCode) from 16 to 3 positions (dataset, series and services). It should also be added that the Regulation defines in fact, three profiles of the INSPIRE metadata, apart from the metadata profile for spatial data sets and for series, it also defines the metadata profile for spatial services. Profile extensions also concern the types and the classification of spatial data services. As regards types of services, this extension is achieved by adding serviceType metadata element from ISO 19119 to the SV_ServiceIdentification class. The value domain of this element is a code list which includes types of services described in the INSPIRE Directive and Part D3 of the Regulation: • Discovery Service (discovery) • View Service (view)

92

• • • •

3 Metadata Profiles Based on ISO 19115

Download Service (download) Transformation Service (transformation) Invoke Spatial Data Service (invoke) Other Service (other)

Classification of services is realised by introducing the values, from the domain defined in section D 4 of Regulation, as keywords. This classification, which is derived from ISO 19119, includes 70 types of spatial data services. Schema of INSPIRE metadata profile for spatial data and spatial data set series is as follows:

INSPIRE Metadata Profile

93

94

3 Metadata Profiles Based on ISO 19115

INSPIRE Metadata Profile

95

96

3 Metadata Profiles Based on ISO 19115

INSPIRE Metadata Profile

97

.

Chapter 4

Metadata Description Languages

What Is the XML XML – eXtensible Markup Language – it has been developed as a result of dynamic grow of the Internet usage. It is an alternative to the HTML – HyperText Markup Language – and, as more flexible for users in softwware development developers, so the HTML is gradually superseded by the XML. XML is designed for information exchange on the web (the Internet) and to represent different kinds of data in an appropriate structure. XML plays the role of meta-language, a language that describes other languages. As a meta-language it is used for defining other languages. From other hand, the XML has contributed to development of the Internet providing easy and accurate transfer of complex structure data. Moreover, the structure of the XML is well suited to transmit intuitively understood hierarchy of information significance. XML does not depend form a system platform. This allows easy exchange, between different systems, of documents saved in the XML language. The XML language specification is provided and the XML usage is recommended by World Wide Web Consortium (W3C) a standardizing organization (http://www.w3c.org).

XML Schema XML Schema is used to define the structure of XML documents. XML Schema is a part of the XML. Documents containing XML Schema definitions are usually stored in files with the extension “.xsd” (XML Schema Definition). Specification pf the XML Schema was developed by the W3C in 2001 and consists of three parts: Primer – non-normative part, which presents the basics of the XML Schema Structures – defines the XML Schema Datatypes – gives definitions of data types L. Litwin and M. Rossa, Geoinformation Metadata in INSPIRE and SDI, Lecture Notes in Geoinformation and Cartography, DOI 10.1007/978-3-642-15862-9_4, # Springer-Verlag Berlin Heidelberg 2011

99

100

4 Metadata Description Languages

XML Schema and Metadata Documents Metadata documents are stored in XML files (.xml), using the XML language standards and therefore the structure of these documents is defined using the XML Schema. New metadata documents should (must) be checked for compliance with an appropriate model defined in the XML Schema Definition files (.xsd) This process is known as a document validation and such a validation function should be available in the metadata editor.

XML Schema and Metadata Documents

101

102

4 Metadata Description Languages

XML Schema and Metadata Documents

103

104

4 Metadata Description Languages

XML Schema and Metadata Documents

105

106

4 Metadata Description Languages

XML Schema and ISO 19139 Technical specification of the XML Schema model for metadata document is given by ISO 19139:2007: “Geographic Information-Metadata-XML Schema implementation” standard. It is the basis for validation and standardized exchange of metadata files between various systems. The specification is related to a description of the metadata provided by the ISO 19115.

Other Applications of XML Apart from the XML Schema there are many other applications of the XML language. One of the most popular is XHTML (Extensible HyperText Markup Language) commonly used for creating websites. Other examples of XML applications: XSLT (XSL Transformations, Extensible Stylesheet Language Transformations) is part of the XLS language definition and is used to translate documents from one XML format into other XML format, HTML or other file formats. The XSLT was developed by the W3C. SOAP (Simple Object Access Protocol) is a protocol used for remote access to objects, which uses XML to encode requests and HTTP to transfer them. SOAP is a W3C standard. WSDL (Web Services Description Language) is an XML based language used to define web services. WSDL was developed by Microsoft and IBM.

Applications of the XML to Metadata Metadata profiles may use specific metadata entities and metadata elements, for which the description in the XML language is insufficient, because, the XML, for a number of cases, it is too general. In such cases, dedicated applications of the XML should be used, which are the XML adaptations and extensions for particular field of application or scope of data. Theoretically, many applications of XML can be used in metadata profiles extended beyond the ISO 19115 standard. However, the most commonly used is the GML language.

GML GML (Geography Markup Language) is an XML application developed by the OGC (Open Geospatial Consortium) for the purposes of describing spatial (geographical) data. GML is used as a format for data exchange between different geographic information systems (GIS) (Fig. 4.1). GML has more specialized versions, such as GeoSciML (GeoScience Markup Language) used in the development of metadata for Earth Sciences. GeoSciML is

Applications of the XML to Metadata

107

Fig. 4.1 Visualization of Corine Land Cover data stored in GML

a markup language specific to the Earth Sciences (currently mainly in the field of geology), and aims to support the exchange of geographic information. This language was developed by a CGI working group (Commission for the Management and Application of Geoscience Information), which is the commission of IUGS (International Union of Geological Sciences). The language contains a description of: the geological age (stratigraphic table, Fig. 4.2), types of rocks and soils (lithology, genesis, petrography), geological structures, etc. In the future, it should provide a basis for data exchange (including the description of metadata elements) in the field of Earth Sciences within the infrastructures of spatial information – INSPIRE. The GML metadata language is used, when there is a need, to describe in the metadata the geometry of space, geometry of time or geometry of space-time. If in the metadata you need to describe the point, line, polygon, point or range on the time axis, then you should use the GML. It is accomplished by putting into the metadata XML file a section in the GML, using GML structure and appropriate tags. In metadata complying with ISO 19115, the GML is used most often to describe metadata entities of EX_Extent class. EX_Extent data type aggregates metadata elements describing the spatial and temporal extent of the associated metadata entity. EX_Extent entity contains information on the geographical extent (EX_GeographicExtent), temporal extent (EX_TemporalExtent) and vertical extent (EX_VerticalExtent) of the associated entity. EX_GeographicExtent may be specialized as EX_BoundingPolygon, EX_GeographicBoundingBox or EX_GeographicDescription. The combined space-time extent (EX_SpatialTemporalExtent) is an aggregate for EX_GeographicExtent. EX_SpatialTemporalExtent is a subclass of EX_TemporalExtent.

108

4 Metadata Description Languages

Fig. 4.2 Stratigraphic table – an example of the implementation of the GeoSciML language in MEDARD metadata editor

Entity EX_Extent has three optional roles “geographicElement”, “temporalElement” and “verticalElement” and the “description” element. At least one of the four elements listed above should be used [ISO 19115].

Applications of the XML to Metadata

109

The diagram below presents the discussed entity. Elements which require the use of GML are expanded. Abstract classes are not shown.

110

4 Metadata Description Languages

Entities (subclasses): EX_BoundingPolygon, GML_TimeInstant and GML_ TimePeriod are the most frequently described metadata elements in a discussed entity (class). EX_BoundingPolygon defines a boundary containing a set of data, expressed as a closed set of polygon coordinates (x, y) (where the last point is a repetition of the first point). This boundary is described by the metadata element polygon, which is a set of points defining the bounding polygon [ISO 19115]. This way of describing the spatial extent of the resource is used in situations where there is a need to show the complex shape of the area of the resource and/or it is necessary to identify “white spots” in a resource limited by mandatory entity (class) EX_GeographicBoundingBox. Below is an example of the metadata discussed above, described using MEDARD metadata editor – a fragment of XML file containing metadata with elements of GML language:

Classes GML_TimeInstant and GML_TimePeriod are used to describe the temporal extent of resources, mostly date or date with time. Using these classes, one can save the metadata information that the given resource contains data from the years 1976–1978 or from 12:23:59 on 26.09.2008. However, there are cases where you need another method of determining the temporal extent of the resource. This is the case for geological data, for which geological time scale should be used (stratigraphic table). For example, in order to specify the metadata information that the resource contains geological data relating to the time interval from the Cretaceous to the Jurassic period, GeoSciML language should be used. Example of such metadata prepared using the MEDARD metadata editor is presented below – a

Applications of the XML to Metadata

111

fragment of XML metadata file with elements of GML to describe the time and date (TimeInstant) and with elements of GeoSciML language describing the time interval on the scale of geological age (TimePeriod). It should be emphasized that the entity (class) EX_Extent is used in several places of ISO 19115 full profile metadata. Other entities, which elements are described using the GML language, are cornerPoints (165) and CenterPoint (166). CornerPoints is the Earth location (according to ISO 19115) in a coordinate system defined by the Spatial Reference System and the coordinate of the cells’ grid located on opposite ends of the two diagonals of the grid coverage in the spatial dimensions of the grid. There are four corner points in a rectangular grid with

112

4 Metadata Description Languages

a requirement of at least two corner points on one diagonal. The first corner point corresponds to the origin of the grid. CenterPoint is the Earth location in a coordinate system defined by the Spatial Reference System and the grid coordinate of cell lying midway between the opposite ends of the grid in the spatial dimensions. These entities can be found in the section spatialRepresentationInfo of metadata (information about the digital representation of spatial information in the data set), which includes grid representation.

Chapter 5

Applications for Creating and Publishing Geoinformation Metadata

Metadata Editors Metadata Editor is an application dedicated to the preparation of a metadata set according to national and international standards. As such, metadata editor becomes a software tool for the implementation of the EU INSPIRE Directive.

Requirements for Metadata Editor Metadata Editor should ensure compliance with current geoinformation international and national standards, i.e. OGC standards and other relevant international standards (ISO, European CEN Standards, Polish standards – PN). Another essential condition is to meet the requirements of the EU INSPIRE Directive and its relevant implementation provisions – INSPIRE Implementing Rules (IR). Taking into account these requirements and best practices, metadata editor should provide: • Full support for interface descriptions in Polish (GUI). • Support for metadata in accordance with the metadata profiles: INSPIRE profile, and Polish national geoinformation metadata profile. • Creating metadata for data sets, data series, and services. • Validation (validation against the model) of metadata documents. • Possibility of creating and updating metadata in a specific hierarchy, and the possibility of inheritance of the metadata elements. • Automatic generation of metadata document identifier, in accordance with the UUID standard (Universal Unique Identifier), which is specified by IETF (http:// www.ietf.org) and RFC 4122.

L. Litwin and M. Rossa, Geoinformation Metadata in INSPIRE and SDI, Lecture Notes in Geoinformation and Cartography, DOI 10.1007/978-3-642-15862-9_5, # Springer-Verlag Berlin Heidelberg 2011

113

114

5 Applications for Creating and Publishing Geoinformation Metadata

• Saving resource identifiers in accordance with the requirements of INSPIRE. • Generating metadata documents in the XML language according to the implementation schema defined in ISO/TS 19139:2007 (XML Schema) – application schema available at http://standards.iso.org/ittf/PubliclyAvailableStandards/ ISO_19139_Schemas/ • Automatic conversion of temporal reference (to GML standard or its application, such as GeoSciML), as described in ISO/TS 19139:2007 document. • Support for defining the spatial extent of described resource. • Automatic conversion of the values (polygons) to the GML language, which is described in the document ISO 19136 (OGC standard) for defining a spatial extent information for the resource as polygon coordinates (x, y). • Support for metadata document templates. • Support for publishing metadata documents (e.g. catalogs, Web sites). • User interface (GUI) of application fully localized in Polish. • Possibility of printing metadata documents. • Saving created metadata documents to the remote and local repositories of metadata. • Software functionality adapted to the requirements of implementation rules (IR) of the given metadata profile. • Possibility to download and use keywords dictionaries (thesauri) and thematic categories from the relevant databases. • Support for construction of multilingual versions of metadata documents using the symbols from ISO 639-2 – in Polish and English mainly. • Support for GML namespace in the current version (3.2 – required version and 3.1.1 – version provisionally allowed) for defining temporal and spatial coverage. • Support for “reasons for the lack of values” (nil reason) in accordance with the provisions of ISO 19115. • Preview of metadata documents as XML, HTML (XHTML) and PDF. • The capability of co-operation with various databases. • The capability to search metadata at the basic level. • Import of metadata created by other metadata editors in accordance with current ISO standards, OGC standards and implementing rules. • Application help and context-sensitive help. The Metadata Editor should be an application that due to implementation of standards, profiles as well as recommendations and technical specifications of INSPIRE, ensures that user’s documents are created with conformity to all the requirements for the creation of metadata. The Metadata Editor should be developed in a way that makes it easy and intuitive to use, so that the creation of metadata would not require expert skills. This can be achieved through the properly designed application interface (GUI) and context-sensitive help.

Metadata Editors

115

Review and Comparison of Selected Metadata Editors CatMDEdit Editor (Figs. 5.1 and 5.2) http://catmdedit.sourceforge.net/ Current version: 4.5 (05.2010 – last changes: May 2009) License: LGPL – Lesser General Public License v. 2.1 Developed by: Advanced Information System Group of the University of Zaragoza and GeoSpatium-Lab S.L., supported by many European institutions and companies. Operating systems: Windows, Unix. The application requires the Java Runtime Environment (JRE). Characteristics: • • • • • • • • • • •

Supported languages: Czech, English, French, Polish, Portuguese, Spanish Metadata Repositories: the application supports one or more local repositories Supported databases: only local repositories Compliance with the following geostandards: ISO19115: 2003/Cor1: 2006, ISO19139: 2007 Supported metadata profiles: ISO19115, INSPIRE, Dublin Core, WISE (profile for the Water Framework Directive), NEM (profile Nucleo de Espan˜ol Metadatos) Possibility of creating user profiles: yes Inheritance: no Possibility of creating templates of metadata documents : no Validation tools: yes Metadata Preview: HTML Import/Export: XML (ISO19139, CSD-GM US FGDC, SDIGER) and RDF (Dublin Core)

Fig. 5.1 Metadata editor CatMDEdit – the application window

116

5 Applications for Creating and Publishing Geoinformation Metadata

Fig. 5.2 Metadata editor CatMDEdit – preview window of the selected metadata document

• Automatic generation of metadata: Shapefile, DGN, ECW, FICC, GeoTIFF, GIF/GFW, JPG/JGW, PNG/PGW • Additional editing tools: allows reuse of contact information for organizations and individuals – (e.g. name, address, phone, . . .) that must be filled in a number of metadata elements • Automatic generation of metadata for spatial data series • Thesaurus – possibility to fill in some metadata elements using values from connected dictionaries • Possibility to choose the polygon on the map • Possibility of choosing location of data through RSS and GeoRSS • Conversion of coordinates between different coordinate systems and graphic choice of coordinates on maps, allowing users to add new maps to choose from • Tools for editing, control and visualization (possible preview on the map) of elements describing the spatial extent of the resources in the form of polygons. Visualization of data and miniatures in a variety of formats: Shapefile, ECW, GeoTIFF, GIF, JPG, BMP, PDF, HTML • Help available online and as a PDF document

Metadata Editors

117

I.M.E Editor (Figs. 5.3 and 5.4) http://www.crepad.rcanaria.es/metadata/index.htm Current version: 4.1 (Windows released 08.2007), and 4.0 (Linux 09.2006) – as of 05.2010. Licence: the application is available for free under the terms of the author, which must be accepted during installation, Created by: Alberto Amaro (INTA, Spain) Operating systems: Windows, Linux – the application requires the Java Runtime Environment (JRE) Characteristics • • • • •

Supported languages: English, Polish, Spanish Managing metadata: lack of such functionality Supported databases: none Compliance with standards: ISO19115: 2003/Cor1: 2006, ISO19139: 2007 Supported profiles: ISO19115 (with some limitations, mainly through a reduced size of elements of class MD_Identifier in comparison to standard) • Customized metadata profiles: yes • Inheritance: no

Fig. 5.3 Metadata editor IME – application window

118

5 Applications for Creating and Publishing Geoinformation Metadata

Fig. 5.4 Metadata editor IME – application window, preview of MD_Identifier element

• Possibility of creating templates of metadata documents: yes • Tools for validation: yes • Preview of metadata: XML, HTML (direct – automatic generation of files, or indirectly – creating XSLT transformation file), PDF (reports) • Import/Export: XML (ISO19139) • Automatic generation of metadata: no • Additional tools to facilitate the editing of metadata: Identification of links of metadata elements to other standards: ISO19103, ISO10107, ISO19108, ISO19109, ISO19136 (GML)

MEDARD: Metadata Standard Editor (Figs. 5.5 and 5.6) http://medard-opensource.eu/ Current version: 1.2.0.2 released 04.2010 (as of May.2010) License: AGPL – Affero General Public License v.3 Created by: ISPiK (Institute of Spatial and Cadastral Systems S.A. Gliwice, Poland). Operating system: Windows, Linux. Editor tested on: MS Windows: 2000, XP and Vista; Linux: Ubuntu, Fedora and SuSE. The application requires the Java Runtime Environment (JRE). Characteristics: • Supported languages: English and Polish • Metadata repositories: local or remote (network) on the server, multi-user, possibility of applying access restrictions • Supported databases: optional, tested with Oracle

Metadata Editors

119

Fig. 5.5 MEDARD metadata editor – the application window in metadata edit mode

Fig. 5.6 MEDARD metadata editor – graphical editing of polygon limiting the area of spatial data

• Compliance with standards: ISO19115: 2003/Cor1: 2006, ISO19136: 2004, ISO19139: 2007 • Supported profiles: ISO 19115, INSPIRE, Polish National Profile (GUGiK), PGI geological profile • Custom profiles: possible but some programming is required • Inheritance: yes • Possibility of creating templates of metadata documents: yes • Validation tools: yes

120

5 Applications for Creating and Publishing Geoinformation Metadata

• Metadata preview: XML, Dynamic HTML, PDF (print) • Import/Export: XML (ISO 19,139) • Automatic generation of metadata: none (there is a possibility of integration with other applications by ISPiK) • Additional tools to facilitate the editing of metadata: allows reuse of contact information for organizations and individuals – (e.g. name, address, phone, . . .) that must be filled in a number of metadata elements, Contacts editor can import vCard • Thesaurus – possibility to fill in some metadata elements using values from connected dictionaries, including INSPIRE

Cooperation with the Metadata Catalog AQUARIUS (Auto Publication of Metadata Documents in the Repository Catalog) • Tools for editing, control and visualization (possible preview) of elements describing the spatial extent of the resources in the form of polygons • Tools for editing elements (with a possible preview) describing a time range of resources in geological time (stratigraphic table) – implementation of standards: ISO19103, ISO19136 (GML) and GeoSciML • Dedicated Web interface – viewing metadata stored in the repository on the server (XSLT) • Compliance with the INSPIRE regulations and the Implementing Rules • Context help, user manuals and use scenarios, multimedia documentation and assistant Version of MEDARD Metadata Editor prepared for individual practice can be found on the CD enclosed with this book

MEE: Metadata Editor (Figs. 5.7 and 5.8) https://sourceforge.net/projects/metadataeditor/ Current version: 2.0 RC9 released 06.2009 – RC (Release Candidate) indicates that this version can potentially become final product but is not fully tested (as of 05.2010). License: GPL – General Public License v.3. Developed by: Bartosz Kopan´czyk (commissioned by GUGiK – Polish Head Office of Geodesy and Cartography). Operating System: MS Windows NT, 2000, XP, Linux (installation requires software enabling MS Windows applications to work under the control of Linux). Characteristics: • Supported languages: Polish, English • Metadata Repositories: file system (local repository) • Supported databases: not specified

Metadata Editors

121

Fig. 5.7 Metadata editor MEE – application window in metadata document edit mode

Fig. 5.8 Metadata editor MEE – metadata section: spatial representation

• • • • • • • •

Compliance with geostandards: ISO19115: 2003/Cor1: 2006, ISO19139: 2007 Supported profiles: Polish National Profile (GUGiK) Creating custom profiles: no Inheritance: no Possibility of creating templates of metadata documents: no Validation tools: yes Metadata Preview: no Import/Export: XML (ISO19139)

122

5 Applications for Creating and Publishing Geoinformation Metadata

• Automatic generation of metadata: no • Tools for editing the elements that describe the spatial extent of the resources in the form of polygons • Tools for editing elements describing the type of spatial presentation • Help application in the program, the PDF document

Metadata Catalogs Metadata catalogs are used for publishing and viewing metadata documents, which describe spatial data resources. Similarly to the metadata editors, the catalogs should also implement requirements of obligatory standards.

Requirements for Metadata Catalogs Metadata catalog should provide two services required by INSPIRE: metadata searching (Discovery) and browsing (View). These two requirements are to be treated as mandatory when developing, maintaining and extending cataloging services. Both services must comply with obligatory standards and therefore, for searching, the catalog should guarantee: • Implementation of the CSW ISO metadata AP 2.0.2 specification. • Support for the EU official languages (multilingualism), as specified in the recommendations of INSPIRE. • Implementation of data harvesting. • Browsing the found metadata documents within the scope of the information defined in the INSPIRE. • Providing information describing the search service (Get Discovery Service Metadata). • Search linking service, which allows reporting the availability of search services, which are in line with INSPIRE, for the purposes of distributed searching of resources by the Member State’s search services (Link Discovery Service). View service requires: • Implementation of WMS 1.3.0: ISO 19128:2005 (EN) + SOAP. • Providing information describing the view services (Get View Service Metadata). • View linking service, which allows reporting the availability of view services, in line with INSPIRE, for the purposes of distributed resource viewing by an UN Member State’s view services (Link View Service).

Metadata Editors

123

Examples of Metadata Catalogs GeoNetwork Opensource (Figs. 5.9 and 5.10) http://sourceforge.net/projects/geonetwork/ http://www.wodgik.katowice.pl/html/infrastruktura/geonetwork.htm (download of Polish version). GeoNetwork is a joint project of the global organizations: FAO (the Food and Agriculture Organization of the United Nations), WFP (The United Nations World Food Programme) and UNEP (The United Nations Environment Programme) (http://geonetwork-opensource.org/) Version: 2.4.3 (released in April 2010) (as of 05.2010) License: General Public License – GPL Operating systems: MS Windows, Unix, Linux, MAC OS X – application requires the Java Runtime Environment (JRE) Characteristics: • • • • • • • •

Administration, editing and storing metadata geoinformation Search based on criteria Languages: English, French, Spanish, Italian, Chinese, Polish Administration functions and access control for resources and services Built-in editor metadata for ISO19115 and ISO19139 compliant metadata Preview of the main elements of the metadata Preview of ISO19115 compliant metadata XML view

Fig. 5.9 GeoNetwork opensource – website of the project

124

5 Applications for Creating and Publishing Geoinformation Metadata

Fig. 5.10 GeoNetwork opensource – metadata view (FAO project)

• • • • •

Intermap map viewer – supports OGC WMS and ESRI ArcIMS protocol Searching remote catalogs using Z39.50 communication protocol (ISO 23950) Data harvesting service Spatial data access service Extensive documentation

GeoNetwork Opensource delivers much broader functionality than just metadata catalog. It is equipped with advanced administrative functions and sophisticated capabilities of viewing spatial data, thanks to possibility of integration with several map servers including Deegree, MapServer and GeoServer. GeoNetwork metadata catalog does not meet the requirement of INSPIRE.

AQUARIUS: Metadata Standard Catalog (Figs. 5.11 and 5.12) http://aquarius-opensource.eu/ AQUARIUS metadata catalog was developed at the Institute of Spatial and Cadastral Systems S.A., Gliwicw, Poland. The application is being developed in parallel with the evolving INSPIRE technical specifications. The greatest emphasis in developing AQUARIUS catalog was put on meeting current requirements and recommendations of INSPIRE. Version: 1.0 (as of 05.2010) License: Affero General Public License – AGPL v. 3 (Dual Licensing – the catalog client uses commercial license).

Metadata Editors

125

Fig. 5.11 Metadata catalog AQUARIUS – web user interface – advanced search mode

Operating systems: platform independent, application requires an installed Java Runtime Environment (JRE), tested on MS Windows and Linux Characteristics: • Implements OGC standard WMS 2.0.2 • Simple and advanced search based on given criteria • Client application (web) can collaborate with other catalogs complying with the specification • Languages: Polish and English • Administration console • Metadata preview for INSPIRE metadata profile and Polish metadata profile (GUGiK) • XML view

126

5 Applications for Creating and Publishing Geoinformation Metadata

Fig. 5.12 Metadata catalog AQUARIUS – web user interface – search result mode

• Cooperation with the MEDARD metadata editor (functionality outside the AGPL license) • Metadata preview service based on OGC WMS 1.3 (Open Layer viewer) • Data harvesting service • Documentation, usage scenarios, help

Chapter 6

How to Properly Create Metadata

Principles and Good Practices for Creating Metadata Principles and good practices for creating metadata discussed in this chapter have been collected and compiled based on following documents: • ISO 15836:2003, Information and documentation – The Dublin Core metadata element set • ISO 19101: 2002, Geographic information – Reference model • ISO/TS 19103:2005, Geographic information – Conceptual Schema Language • ISO 19106:2004, Geographic information – Profiles • ISO 19107:2003, Geographic information – Spatial Schema • ISO 19108:2002, Geographic information – Temporal Schema • ISO 19109:2005, Geographic information – Rules for application schema • ISO 19110:2005, Geographic information – Methodology for feature cataloguing • ISO 19111:2003, Geographic information – Spatial Referencing by coordinates • ISO 19112:2003, Geographic information – Spatial Referencing by geographic identifiers • ISO 19113:2002, Geographic information – Quality Principles • ISO 19114:2003, Geographic information – Quality evaluation Procedures • ISO 19115:2003, Geographic information – Metadata (published by Polish Committee for Standardization in original, English version as PN-EN ISO 19115) • ISO 19115/Cor.1:2006, Geographic information – Metadata, Technical Corrigendum • ISO 19117:2005, Geographic information – Portrayal • ISO 19119:2005, Geographic information – Services • ISO 19119:2005 PDAM 1, Geographic information – Services • ISO/CD2 19130, Geographic information – Sensor data model for imagery and gridded data ISO/TC 211 N 1772 dated 2005-02-15 • ISO/DIS 19131, Geographic information – Data product specification L. Litwin and M. Rossa, Geoinformation Metadata in INSPIRE and SDI, Lecture Notes in Geoinformation and Cartography, DOI 10.1007/978-3-642-15862-9_6, # Springer-Verlag Berlin Heidelberg 2011

127

128

6 How to Properly Create Metadata

• ISO 19135:2005, Geographic information – Procedures for item registration • ISO/TS 19139:2007 Geographic information – Metadata – XML Schema Implementation • The INSPIRE Directive • Regulations implementing INSPIRE Directive as regards metadata and network services • Technical documents and implementing rules • Head Office of Geodesy and Cartography (GUGiK) guidelines for Polish metadata profile • Document “Polish national metadata profile for geoinformation”s by GUGiK • “Polish geoinformation metadata specification for GEOPORTAL.GOV.PL project”, published in 2007 (first version of national metadata profile) The authors also used their own experiences gained when participating in development of: • • • •

Polish metadata profile MEDARD metadata editor and AQUARIUS metadata catalogue Implementation of GeoSciML for geological metadata Development of geological metadata profile and corresponding implementing rules for Polish Geological Institute • Development of metadata profile within OneGeologyEurope project The rules for implementation of metadata introduced in other countries and related literature, and Polish-language draft translation of the PN-EN ISO 19115 (developed by PKN/KT 297) were also an important source of information in this matter. Moreover, analysis of these documents carried out by the authors in 2007 and 2008 for the national profile of metadata for geoinformation project was also very significant information.

Regulatory Compliance It should be strongly emphasized, that to ensure the interoperability of the metadata in Poland, each institution or individual who wants to share the geoinformation metadata should follow the principles set out by the documents listed above. It is also recommended that any party, dealing with or applying spatial data, works out detailed technical guidelines for the development (implementation) of metadata for spatial data and/or geospatial services. These guidelines, according to GUGiK documents on the creation and use of metadata in line with national profiles, should, apart from the initial part defining their organizational and information context, define and discuss the following topics: • Spatial data resources which are subject to the description • Source of information for creating metadata • Steps to create metadata

Principles and Good Practices for Creating Metadata

• • • • • • • • • • • • • • • • • •

129

General requirements for software creating and updating metadata Rules for naming data sets and series Rules for specifying time information Rules for specifying contact information Rules for specifying keywords Principles of categorizing datasets Rules for creating identifiers of metadata files Principles of specifying general information describing the metadata set Principles of specifying general information describing the data set Principles of specifying restrictions to the use of resources Principles of specifying information on the maintenance of a resource Specifying spatial extent of the data Principles of specifying spatial reference system Principles of specifying information on the distribution of the resource Principles of specifying quality of the resource Principles of specifying information on geoinformation services Rules for the use of special values Rules creating of multi-language version of the metadata

Moreover, these guidelines should describe three main phases of managing collections of metadata: Metadata creation phase – when generating new metadata file in accordance with the accepted standard. The creation of metadata is performed according to the needs of particular participants of spatial data infrastructure and to the relevant EU, national law and industry branch regulations. Metadata update phase – when introducing changes in the existing metadata document. Metadata verification phase – it is a process of verifying the correctness and timeliness of available records in the metadata file. The metadata verification should be conducted periodically according to the needs and specificity of the branch of interest, but at least every 3 years, for all data other than archive data. It is important for users of these guidelines, that the guidelines include examples of metadata developed for actually existing spatial data resources.

What Resources Should Be Described by Metadata ISO 19115 standard defines 16 types of resources, listed on the MD_ScopeCode code list that can be described with metadata. Taking into account possible extensions of ISO 19115, theoretically, any spatial data resource may be described by metadata. However, both the INSPIRE Directive and the Regulation regarding metadata limit the data resources to only three types: spatial data sets, spatial data set series and geoinformation services, and only to resources having digital form.

130

6 How to Properly Create Metadata

This means that INSPIRE does not require creating metadata for traditional, paper maps. When creating metadata, it is mandatory to describe completed data sets as well as collections that are in an advanced stage of development (underdevelopments), which are expected to have broad or particularly important application. Moreover, under the INSPIRE Directive, the metadata must be developed in accordance with the timetable set out therein for all collections, series and geoinformation services regarding 34 data themes listed in three Annexes of the INSPIRE Directive.

Stages of Metadata Creation Phase Metadata should be created in the following stages [Pacho´ł 2008]: 1. 2. 3. 4. 5.

Familiarisation with the relevant documentation on the metadata. Extracting the data sets and grouping them in series. Adopting names for collections and series of spatial data. Preparing spatial extents for data sets, series and services. Collecting information on contact details of all parties associated with the resource (owners, distributors, authors, publishers, point of contact where information about the resource can be obtained) – establish contacts database of parties responsible for the resource. 6. Creating metadata sets in the metadata editor. 7. Validating metadata. 8. Publishing metadata via directory server (metadata catalogue). In the first stage of metadata creation phase, one should not only consult the documents listed at the beginning of this chapter but also identify sources of information for creating metadata. Main sources serving the purpose of creating metadata are: 1. Information contained in the documentation regarding introducing spatial data into spatial data resources. 2. Information contained in the spatial database management systems. 3. Metadata contained in the previous elaborations prepared in line with different standards. 4. Imprints on all kinds of cartographic work. 5. Legends and other descriptions of maps. 6. Regulations defining working hours of contact points, and determining individuals responsible for spatial data resource and contact with clients. 7. Legal acts, regulations and executive orders that define the limitations associated with the availability of spatial data resources and pricing regimes. 8. Other documents allowing to determine the actual parameters of data sets.

Rules for the Use of Special Values

131

For stages 2 through 5 it may be helpful to prepare answers to the following questions [Pacho´ł 2008]: 1. 2. 3. 4.

Is the digital resource in raster, vector, or object form? How is the digital resource divided? Is there a uniform database for a specified area (e.g., municipal area, county)? Is a resource recorded as a single file containing data for each area (sheet, sections, map overlay)? 5. How is a digital resource made available? 6. In how many and in what coordinate systems is the resource maintained? 7. Is a digital resource coherent (independent of scale and other aspects of the source materials)?

Types of Metadata Elements In the metadata profiles, three types of metadata elements are typically distinguished: mandatory, conditional and optional. Mandatory elements – metadata elements that shall be documented, i.e. they must have assigned values. Conditional elements – metadata elements that shall be documented, if specified conditions occur. Optional elements – all the other elements of the metadata that their documentation is not obligatory. In practice (e.g. national profile), in the group of optional items a sub-group of recommended elements is distinguished – these elements need not be documented but it is recommended to assign them the appropriate values.

Rules for the Use of Special Values While creating metadata, one may encounter a problem that some elements can not be completed, due to lack of information, or in some special cases it may turn out that the element is not applicable to the resource to be described. This is particularly important in the case of mandatory and conditional elements which use is obligatory. For the metadata file to be validated, values must be assigned to all mandatory elements. In such a case, special attribute that will provide information about the reasons for not assigning value to the metadata element, should be used. Special attribute should be applied, if value cannot be assigned to mandatory element or conditional element, when it results from the context of other metadata values that it must be completed. However, it is not recommended to use a special attribute for optional elements including recommended elements. If these elements do not have

132

6 How to Properly Create Metadata

Table 6.1 The special attribute values Value Definition Does not apply Does not apply (has no value) in a given context Value of the item is not available to metadata author No data and probably, the correct value may not exist Temporary no data Value of the item will be available later Value of the element is not available to the authors Unknown of metadata, but correct value probably exists Restricted Value of the element is restricted

ISO 19139 value Inapplicable Missing Template Unknown Withheld

values they should not be recorded in the metadata file. Table 6.1 gives summary of the values a special attribute can take.

The Principles of Setting Up a Hierarchy Consisting of Series and Collections When spatial data sets grouped in series inherit some attributes of a series, only those metadata elements that are different for the data set included in a series of spatial data, should be completed on the dataset level. Data sets which form series should be grouped into series for the purposes of maintaining order and to avoid duplication of data descriptions. Name of the hierarchy level should be given only for resources classified as a series or services, and must take the value of “series” and “service” respectively. For resources classified as data sets, this element is not applicable.

Structure of Metadata Set Structure of the metadata set must comply with ISO 19115/Cor 1:2006 and application schema defined in the “Polish national metadata profile for geoinformation”.

Metadata File Format and Application Schema Metadata files should be created in XML format according to the implementation schema (XML Schema) specified in ISO/TS 19139:2007. This schema is available at: http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/. Metadata files should be generated using specialised software to create and update the metadata – metadata editors. Metadata editors should meet certain requirements, which are presented in Chap. 5.

Naming Principles for Data Sets and Series

133

Principles of the Construction of Multilingual Versions of Metadata As the Polish metadata will be available within the EU INSPIRE spatial data infrastructure, it is require that metadata are also developed in English version. To enter the metadata in another language/languages than the primary language (in this case Polish) of the document defined in the metadata language element, the element: “alternate languages” (locale) should be used. “Alternate languages” allows to define the name of the language and standard encoding versions, which were used to record the information. Language name should be expressed as a three-letter language code as defined in ISO 639-2. When introducing values of individual metadata elements in the alternate language, one should indicate which language was used by selecting the corresponding definition in the alternate language element. Information that defines the language in which metadata file is maintained, three-letter language code defined in ISO 639-2 should be used. Also, information about (text) encoding standard used for metadata file should be given. For spatial data created within the Polish spatial data infrastructure, metadata should be recorded in Polish (“pol”) encoded using UTF8 standard.

Naming Principles for Data Sets and Series As the dataset name (title), the formal dataset name is used. Where no formal name exists, possibly unique and short name should be created analogous to the names of similar data sets in the resource. When creating the title one must also be guided by the principle that the title should provide metadata users with basic information about the data set. If a dataset belongs to the series, name of the series should not be duplicated in the name of the set, except for some exceptional circumstances. It should be noted that the name will be interpreted by metadata systems as a composition of series name and dataset name. Name should not include name of municipality or other spatial units, which the dataset relates to, unless it is a formal name of dataset. The area to which dataset relates is defined by other metadata elements and functions of metadata systems. For data sets defined by extent of map sheets, it is recommended to specify the name for a set followed by a colon and the emblem of the map sheet, for example “Orthophotomap: N-34-12-A-b-1”. The name of the data set should not include information that can be derived from other metadata elements such as scale, spatial resolution, etc., unless it is absolutely necessary.

134

6 How to Properly Create Metadata

Specifying Time Information The date in the metadata informs when metadata file was created, modified or when metadata set was verified. Date must be updated after each revision, even if no information contained in the metadata file was updated as a result of the revision. All dates should be recorded in one of the following formats: 1. 2. 3. 4.

Year – YYYY format, e.g. 2005 Month – YYYY-MM format, e.g. 2005-12 Complete date – YYYY-MM-DD format, e.g. 2005-12-25 Date and time – YYYY-MM-DD Thh:mm:ss format, e.g. 2005-12-25 T14:25:17 with maximum possible precision appropriate for given dataset

Temporal coverage of the resource (date) can be expressed in the following ways: 1. Time interval, the interval defined by a starting and ending point in time. 2. Point in time if data is valid for the specified moment. 3. Combinations of a point in time and time interval. The total time coverage for the metadata resource can be expressed as one or more instances of extents defined in point 2 e.g. 1998–2000 and 2005 or 2003–2004 and 2006–2008. This element should be recorded in accordance with the GML standard, as described in ISO/TS 19139:2007. Conversion to this standard, after the user enters appropriate values for points in time, should be done automatically by the mechanisms of the metadata editor. As the date of the resource creation, date/time of completion of the resource is provided. It is recommended to give information to an accuracy of 1 day, if such data is available. The date of creation of the resource shall be recorded, if dates of publication or revision of the resource were not recorded. Date/time when resource became available for use or, for geodetic or cartographic data, date of including into the resource should be recorded as the date of publication, The date is replaced by the date of last revision of the resource, if that occurred. It is recommended to give information to an accuracy of 1 day, if such data is available. Publication date of the resource should be recorded if the date of creation or the date of revision of the resource were not recorded. As the date of revision of the data set, the date/time when the resource was last verified, updated or corrected is to be recorded. This date replaces the date of creation of the resource, if it was recorded in the metadata. It is recommended to provide information to an accuracy of 1 day, if such data is available. Publication date of the resource should be recorded if the date of creation or the date of verification/revision of the resource was not recorded. In the case of data sets series, none of the dates listed above is required. In this case, the mandatory element “date” must occur only once, and it must take special attribute value of “inapplicable”.

Specifying Keywords

135

Data sets for which the update frequency is much higher than the metadata maintenance, the frequency (revision) need not be described by the date of revision. In this case, at least the creation date or publication date of the data set should be recorded. For data sets, where dates mentioned above are difficult or impossible to determine, only the revision date should be indicated. As the value of this element, the date of metadata creation for this dataset should be recorded.

Specifying Contact Information As a point of contact for the metadata, contact information of organization responsible for the creation of and technical assistance for the metadata document shall be provided. When providing information about the organizations affiliated with the data set, it is mandatory to enter the name of the organization and the role that it performs with respect to the resource. E-mail address is a mandatory contact information and may be optionally supplemented with a telephone number and/or website address (URL). It is recommended to provide direct contact to the person in the organisation who can provide information about the resource. Detailed information on how to communicate with the organisation should be provided only if the organisation also serves as a point of contact. Name of the organisation should be formal and given in full. If official abbreviation is in use, it is allowed to provide it in parentheses after the full name e.g. Head Office of Geodesy and Cartography (GUGiK). All names of dependent parties of individual sector services, should be organised in central, open access and documented catalogues and should be recorded in metadata in exactly the same form. Land line numbers should be given in the following format: +4822625963. (“+”, international country code number, area code number, phone number). In the case of mobile phones, skip the area code. It is forbidden to use spaces, dashes, dots and other characters between the digits. Example: Head Office of Geodesy and Cartography (GUGiK) Point of contact +48228273456 john.doe@ gugik.gov.pl http://www.gugik.gov.pl

Specifying Keywords 1. Keywords are applied by users to search for data sets on the catalogue portals. They should therefore be well chosen so that a dataset could be found by the words most frequently applied by users of spatial data.

136

6 How to Properly Create Metadata

2. ISO 19115 standard allows to enter several categories of keywords. Only keywords of “theme” category must be entered. 3. It is recommended to use keywords defined in well documented and publicly available directories. If a keyword is drawn from such directory, the name and publication date of the directory should be recorded in metadata document. 4. It is recommended, that various sectors interested in maintaining the consistency of metadata create lists of keywords for their data sets. 5. Furthermore, it is recommended to use to the maximum extent possible the keywords defined in a multilingual thesaurus GEMET (recommended by the European Environment Agency).

Categorizing Sets 1. Topic category is a general classification scheme that allows for the initial, thematic grouping of spatial resources. It is used as the first and the most general criterion when searching for data sets by users. This category should therefore be chosen so as to fully characterise the described resource. It is obligatory to introduce topic category for data with assigned hierarchy level “dataset” or “series”. 2. When describing data sets, it is recommended that the principles of mapping ISO 19115 topic categories to INSPIRE themes, listed in Annexes I, II and III of the INSPIRE Directive, be used. Those principles are defined in implementation rules regarding metadata. Each of branches and services should develop its own list of spatial data sets together with assigned topic categories.

The Rules for Creating Metadata Files Identifiers 1. To achieve unambiguous identification of metadata sets across the entire spatial data infrastructure, the uniqueness of each metadata file should be assured by catalogue servers, without the need of a centralised identification system. This requirement can be met through the use of metadata file identifiers in accordance with the UUID (Universal Unique Identifier), which is specified by the IETF (http://www.ietf.org) and RFC 4122. Sample ID looks as follows: ee6cd941dbe8-4626-9a56-7cc4e7881b32. 2. Metadata file identifier consistent with the UUID should be generated automatically by the metadata editor.

Principles of Specifying General Information Describing the Data Set

137

Principles of Specifying Information on Metadata Standard Version As a metadata standard “ISO 19115” shall be entered. Standard version is recorded in the form: “2003/cor.1:2006”. Where the metadata are created according to the metadata profile or an extension thereof, the name and version of the profile shall be entered.

Principles of Specifying General Information Describing the Data Set 1. Datasets, depending on the phase of their production and use, should be assigned the appropriate status. Datasets that have been developed in accordance with rules accepted for them and submitted for publication receive the status “completed”. Creation and maintenance of metadata is also allowed for the data sets at an advanced stage of development, for which there are widespread or particularly important applications. In this case, status “underDevelopment” is given. The same status should be given to the data set when it was prepared as one of the stages of developing a target product, but released before the completion of the development of the whole product. For datasets replaced with newer, analogous products, the status “historicalArchive” should be assigned. Data sets that were not replaced with newer sets and are no longer recommended for analytic use, should be assigned the status of “obsolete”. It is not recommended to prepare metadata for data sets at the planning stage or early stage of development. 2. The method of spatial representation is attributed only to datasets (and not to data series). Depending on the specific characteristics of the resource, it is allowed that geographic information is represented in more than one way, e.g. vector and raster. 3. Information on the spatial resolution can be recorded in several ways: • As a scale equivalent to printed maps, often expressed as denominator of the scale (integer value) e.g. “10 000”. • As the base distance between adjacent meshes for raster data and grid nets, usually expressed as a numeric value associated with a unit of length e.g. 25 m. • As the range of scale expressed by the denominator of initial and final scale e.g. 10,000–25,000. • As the interval between the base distance expressed by the denominator of the initial and final distance e.g. 5–10 m. 4. The organization, where comprehensive information about the resource can be obtained as a point of contact for the resource, should be given.

138

6 How to Properly Create Metadata

5. It is recommended to provide information about the unique resource identifier (ID) by means of which the resource is uniquely identified within the national spatial data infrastructure. If the resource identifier was assigned, then its value must be recorded, together with the name (title) and date of publication of generally available and documented catalogue in which the ID was specified. 6. The text of the abstract describing the dataset should be a few hundred characters long and should enable metadata users to understand with what category of data they deal, and to evaluate the usefulness of this dataset for their own purposes. To ensure this, the abstract should include main characteristics of a data set or series. 7. To specify languages in which the resource is maintained, three-letter codes should be used as defined by ISO 639-2. Information about character encoding standard used for particular languages should also be recorded. If the information in the resource is stored in the form of raster, character encoding can not be specified. Therefore, this information does not apply to this type of resource, but as it is mandatory, special value “inapplicable” should be used. 8. It is mandatory to enter information identifying the organization that owns the data and the organizations responsible for the data and ensure maintenance of the resource. If the same organization plays both roles for the resource, it should be recorded in the metadata document twice, once for each role. For example, if the data are included in the state geodetic and cartographic resource, “Treasury” should be recorded as the owner.

Principles of Specifying Restrictions to the Use of Resources 1. Use limitations – this information should be given in the form of “free text” and should enable metadata users to understand, for which purposes the dataset should not be used (because of for example: low precision, incompleteness, level of detail of collected data). Example: “Geometry of parcels was approximated and can not be basis for any legal analysis.” 2. Access constraints – mandatory information about the types of restrictions governing public access to the resource. Lack of such restrictions should be clearly specified in the metadata. This should be done by leaving the item not completed and assigning special attribute with a value of “inapplicable”. Example: license 3. Use constraints – information about the types of restrictions governing the use of a resource such as the publication on the Internet, processing, distribution. Example: copyright 4. Security constraints, classification – mandatory information about the level of constraints imposed on the resource in order to ensure national security or the safety of similar weight. If such restrictions do not exist, the resource is public and attribute value should be set to “unclassified.” Example: secret

Specifying Spatial Coverage of the Data

139

If access or use constraints for the resource do not correspond to the types available from the codelist, “otherRestrictions” value should be used and constraints should be described in the form of free text. For data that can be used for specific purposes after obtaining the formal consent of the data owner in the form of a contract, for example data included in the state geodetic and cartographic resource, it should be indicated that the use (use limitations) of data is governed by a license agreement (formal permission to use) with regard to the principles of copyright and the right to reap the financial benefits and control the dissemination of intangible assets resulting from creativity (intellectual property rights).

Principles of Specifying Information on the Maintenance of a Resource Information on the frequency of updates should be recorded using available values from code lists. In the absence of appropriate value on the code list, the best approximation to the expected value should be assigned. If there is concern that this approximation may be too rough, from the perspective of a metadata user, the value of “irregular” should be specified. If the resource is not updated, give the value of “unplanned”. Metadata authors, if they deem it necessary, may enter additional information detailing the principles of resource maintenance.

Specifying Spatial Coverage of the Data 1. An information on spatial extent of the resource can be defined in several ways (depending on which elements defined in the metadata profile are mandatory): (a) As a bounding box stored in the form of coordinates (west-most, east-most, south-most and north-most) of extent limits, expressed in degrees and tenths of degrees, using ellipsoidal spatial reference system WGS84 (EPSG: 4326). (b) A description in the form of free text, which usually provides additional information to the spatial extent defined as a bounding box, for example: “The data cover the Wyszko´w County and the eastern part of Pułtusk County”. (c) As polygon, expressed as the set of (x,y) coordinates of a boundary enclosing the dataset. This element should be recorded in accordance with the GML standard. Conversion to this standard should be performed automatically through the mechanisms of the metadata editor. (d) As an identifier for geographic objects (object), that have spatial location. The identifier should be drawn from documented and publicly accessible directory service or a gazetteer. It is recommended that the name (title) and date of publication of used gazetteer or a directory be specified.

140

6 How to Properly Create Metadata

2. Accuracy of coordinates should be on the same level as the accuracy of the representation of the position of objects presented in the data set. The precision should be at least two decimals, e.g. “19.25”, while maintaining the condition that the coordinates of all four limits should be introduced with the same accuracy. Defining the spatial extent for the data set should be facilitated by metadata editor.

Principles of Specifying Spatial Reference System 1. When entering information about the spatial reference system, the identifier drawn from generally accessible and well documented catalogue of spatial reference systems should be used. It is recommended to use identifier in accordance with EPSG Geodetic Parameters (http://www.epsg.org), which is specified by the OGP (http://www.ogp.org.uk). Then the identifier code space takes value of “EPSG” and the code of coordinate system is an appropriate identifier in this space, for example, for Polish state coordinate system “1992” it is “EPSG: 2180”. 2. In case of raster resources, for which georeferencing process was not performed, spatial reference system information should not be recorded in metadata. From the viewpoint of information systems, such data sets do not have georeferences.

Principles of Specifying Information on the Distribution of the Resource 1. If the same resources (or their copies) are distributed by the various geodetic and cartographic organisations, information on all these units should be provided. 2. To specify the data format used for distribution, an unambiguous, complete, but possibly a short, recognizable name should be used, together with format version e.g. name: “TIFF” version: “1.0” or name: “Geomedia Warehouse” version: “MS Access 2002, Geomedia 6.0”. 3. Information about the network data source should be completed only for data sets (not data series). Where there is no online access to the resource, Internet address of point of contact, where the information on access to the resource is published, should be provided. 4. Information about fees for using the resource should be presented as free text or, alternatively, refer to network address (URL) where such information is available. It is recommended to provide detailed pricing information, unless, for a specific resource, such information is ambiguous. If the use of the resource is free, value of “no fees” should be used. In the first stage of the creation of

Principles of Specifying Information on Geoinformation Services

141

metadata, instead of using specific prices it is allowed to specify relevant documents on the basis of which specific prices can be determined.

Principles of Specifying Quality of the Resource Information on the quality of the resource may be given in two ways: 1. In the form of a free text, few hundred characters long, in which the creator of the metadata should provide a brief history of the creation of a resource with particular reference to the source data, its quality and methods of processing. 2. In cases when resources were created according to a published standard, information including its title and version (the date of publication or revision), conformance of data with the standard (yes/no) and a brief explanation on the degree of conformance should be provided. Example: “For the territory of Poland, 1:50000 maps were used as primary source. Additionally, ZGW elaborations were used with regard to rail and electricity networks. “Atlas of Polish Lakes”, issued by IMGW, was also used. Current state of legislation on the classification of roads, administrative division and the protection of classified information was taken into account. Some incompleteness of attributes was caused by limited availability of specialised data maintained by some institutions of the sector.”

Principles of Specifying Information on Geoinformation Services 1. Service type – mandatory information on the name of service type and its version. Information on version of the type implemented by the service must be provided if it is available. Example: WMS 1.1.0 2. Methods – information on service methods. Name of the method should be provided along with the type of environment (DCP) in which the method was implemented. Example: GetMap method, DCP – WebServices 3. Coupled data – information about the datasets linked to the service. A name of the service method should be given (must be consistent with the name specified in the method element) and also data identifier, by which data is uniquely identified within the spatial data infrastructure. 4. Connect point – address of online access point to the service, specified as full URL. Example: http://www.geoserver.nrw.de/

142

6 How to Properly Create Metadata

5. Information about coupled data – metadata for spatial data sets associated with the service. Provide reference to a section of information about the identification of the corresponding metadata file that describes the data resource coupled with the service. This reference should be created automatically by the metadata editor.

Principles of Specifying Information for Individual Elements of Metadata About Metadata Article 5 of INSPIRE Directive requires, that metadata are not only created but also are kept up to date. The following information about the metadata must be available: Metadata point of contact: it is a description of the institution responsible for creating and maintaining metadata. This description must contain the name of the institution and e-mail to the contact person. Metadata date stamp: this is the date when metadata record was created or updated. This date must be expressed in accordance with ISO 8601. Metadata language: it is the language in which metadata elements are implemented. The scope of this metadata element is limited to the languages specified in the ISO 639-2 standard.

Principles of Specifying Information for Metadata Elements Identifying the Resource Proper identification of the dataset, data series and services is essential to the full implementation of INSPIRE. It should contain the following metadata elements: Resource Title: characteristic, and often unique, name under which the resource is known. Given the fact that the name can contain basic information about the resource, such as spatial description or thematic element, it is important to identify the resource. The value domain of this metadata element is free text. Abstract: This is a concise summary of the contents of the resource. The value domain of this metadata element is free text. Resource Type: This is the type of resource being described by metadata. The value domain for this element, in accordance with INSPIRE profile, contains three values: dataset, series, service. Resource locator: if the resource is a spatial data set, then resource locator defines the link(s) to the resource, commonly expressed as Uniform Resource Locator (URL), through which more information about the resource and/or one or more geo-information services – when available – can be obtained (visualising, downloading or otherwise transforming the resource). However, if the resource is a

Principles of Specifying Information for Metadata Elements Regarding Keywords

143

geoinformation service, then resource locator defines the link(s) to access related services, commonly expressed as Uniform Resource Locator (URL). Unique Resource Identifier, if the resource is a spatial dataset, then the Unique Resource Identifier corresponds to unique identifiers for spatial objects required by the INSPIRE Directive, in accordance with Article 8-2(a).The value domain of this metadata element is free text. Coupled resource: If the resource is a spatial data service, this metadata element identifies the target spatial data set(s) of the service through their Unique Resource Identifiers. The value domain of this metadata element is free text. Resource language: language(s) used within the resource. The value domain of this metadata element is limited to the languages defined in ISO 639-2.

Principles of Specifying Information for Individual Metadata Elements Regarding Classification of Spatial Data and Services Topic category: a high-level classification scheme to assist in the grouping and topic-based search of available spatial data resources. The classification of spatial data services: this classification assists in the search of available spatial data services. The specific service must be assigned to only one category, unless it is an aggregate service that can perform the operations belonging to more than one category. The value domain of this metadata element is a generic name. Those were presented in ISO 19119 section 8.3 Geographic services taxonomy, divided into the following categories: Geographic human interaction services Geographic model/information management services Geographic workflow/task management services Geographic processing services Geographic processing services – spatial Geographic processing services – thematic Geographic processing services – temporal Geographic processing services – metadata Geographic communication services

Principles of Specifying Information for Metadata Elements Regarding Keywords If the resource is a spatial data set or spatial data set series, then at least one keyword must be used to describe the relevant INSPIRE spatial data theme (according to Annexes I, II or III to INSPIRE Directive) taken from the general

144

6 How to Properly Create Metadata

environmental multilingual thesaurus (GEMET) (http://www.eionet.europa.eu/ gemet). For each keyword, the following metadata elements must be provided: Keyword value: it is a commonly used word, formalised word or phrase used to describe the subject. Due to the fact that the topic category is too coarse for specific queries, keywords help narrowing a full text search and they allow for structured keyword search. Originating controlled vocabulary: if the keyword value originates from a controlled vocabulary (e.g. thesaurus), for example GEMET, the citation of the originating controlled vocabulary must be provided.

Principles of Specifying Information for Individual Metadata Elements Regarding Geographic Location The INSPIRE Directive’s requirements for geographic location [Article 11-2 (e)] must be expressed using the metadata element: geographic bounding box. Geographic bounding box: it is the extent of the resource in the geographic space given as a bounding box. The bounding box must be expressed with westbound and eastbound longitudes of the area, and southbound and northbound latitudes, expressed in decimal degrees, with a precision of at least two decimals.

Principles of Specifying Information for Individual Metadata Elements Regarding Temporal References This metadata element addresses the requirement of INSPIRE regarding the information on the temporal dimension of data [Article 8-2 (d)]. At least one of the metadata elements listed below must be specified. The value domain of those metadata elements is a set of dates. Each date must refer to a temporal reference system and must be expressed in a form compatible with that system. The default reference system is the Gregorian calendar. Dates must be expressed in accordance with ISO 8601. Temporal extent: defines the time period covered by the content of the resource. This time period may be expressed as any of the following: • An individual date • An interval of dates expressed through the starting date and end date of the interval • A combination of individual dates and intervals of dates

Principles of Specifying Information for Individual Metadata Elements

145

Date of publication: date of publication of the resource when available, or the date of entry into force. Date of last revision: date of last revision of the resource, if the resource has been revised. Date of creation: date of creation of the resource, if the resource has not been revised.

Principles of Specifying Information for Individual Items of Metadata Regarding Quality and Validity The INSPIRE Directive requires that the quality and validity of spatial data is documented in the metadata and that search based on these characteristics is possible. This requirement must be met by using the following metadata elements: Lineage: a description of the process history and/or the overall quality of spatial data set. Where appropriate it may include a statement whether the data set has been validated or quality assured, whether it is the official version (if multiple versions exist), and whether it has legal validity. The value domain of this metadata element is free text. Spatial resolution: refers to the level of details of the data set. It is expressed by: • An equivalent scale (typically for maps or map-derived products), generally expressed as an integer value expressing the scale denominator. • A resolution distance for raster data, generally expressed as a numerical value associated with a unit of length. • An interval of equivalent scales expressed through starting scale and end scale of the interval. • An interval of resolution distances expressed through starting distance and end resolution distance of the interval.

Principles of Specifying Information for Individual Metadata Elements Regarding Conformity Conformity refers to the requirements of the INSPIRE Directive [Articles 5-2 (a) and 11-2 (d)] saying that the metadata must include information on the degree of conformity with implementing rules provided in Article 7-1, which refers to interoperability and, where practicable, harmonisation of spatial data sets and

146

6 How to Properly Create Metadata

services. For one spatial data or geoinformation service them there may be assigned more than one specification. Any conformity statement must be expressed through the following metadata elements: Specification: a citation of the product specification with which the resource is compliant. This citation must include at least the title and reference date (date of publication, date of last revision or of creation) of the specification. Degree: degree of conformity of the resource with the relevant specifications. There are three possible degrees of conformity: 1. Conformant 2. Not conformant 3. Not evaluated

Principles of Specifying Information for Metadata Elements Regarding Conditions Applying to Access and Use This metadata element defines the conditions for access and use of spatial data sets and services, and where applicable, corresponding fees as required by Article 5-2(b) and Article 11-2 (f) of INSPIRE Directive. The value domain of this metadata element is free text. The element must have values. If no conditions apply to the access and use of the resource, “no conditions apply” must be used. If conditions are unknown, “unknown conditions” should be used. This element should provide information on any fees required to obtain access to and use of the resource, if available, or refer to the Unified Resource Address (URL) where available such information on fees.

Principles of Specifying Information for Metadata Elements Regarding Limitations on Public Access European Union Member States may limit public access to spatial data and geospatial services, if such access could result in adverse effects mentioned in the Article 13 of INSPIRE Directive. This metadata element must provide information on the limitations (if any) and the reasons for them [Article 5-2 (e)]. The value domain of this metadata element is free text. The element must have value. If there are no restrictions, it must be indicated by “no limitations” value.

Examples of Metadata

147

Principles of Specifying Information for Metadata Elements Regarding Organisations Responsible for the Establishment, Management, Maintenance and Distribution of Spatial Data Sets and Services The INSPIRE Directive requires that information on public authorities responsible for the establishment, management, maintenance and distribution of spatial data sets and services [Article 5-2(d) and 11-2(g)] be provided. To meet this requirement, the following metadata elements must be provided: Responsible party: it is the description of the organisation responsible for the establishment, management, maintenance and distribution of the resource. The description should include the name of the organisation and a contact e-mail address. Responsible party role: the role of the responsible organisation.

Examples of Metadata Example of metadata document: Section - (information about metadata): File identifier (fileIdentifier): 60543df7-E410-11dc-8fa8-005056c00001 UUID - 32 characters Metadata language (language): pol 3-letter ISO 639–2 code Metadata Character Set (characterSet): utf8 Parent identifier (parentIdentifier): 3db66e46-e229-11dc-8fa8-005056c00301 The level of the hierarchy (hierarchyLevel): dataset Contact to the organisation responsible for establishing the metadata (contact): Name of organisation (organisationName): full, formalised name of organization Contact information (contactInfo): Telephones (phone): Phone Number (voice): +48552394971 number with no spaces, dashes etc. Address (address): E-mail (electronicMailAddress): The address of the network resource (onlineResource): URL (linkage): Role (role): resourceProvider Metadata date (dateStamp): 2008-02-28T22:04:04 YYYY-MM-DDThh:mm:ss Metadata standard (metadataStandardName): ISO 19115 Metadata standard version (metadataStandardVersion): 2003/cor.1:2006 Section Identification information (identificationInfo): Point of Contact (pointOfContact): Name of organisation (organisationName): Address and contact information (contactInfo):

148

6 How to Properly Create Metadata

Telephones (phone): Phone number (voice): +48552394971 number with no spaces, dashes etc. Address (address): E-mail (electronicMailAddress): The address of the network resource (onlineResource): URL (linkage): owner, custodian, Function (role): resourceProvider resource provider, publisher Maintenance of the resource (resourceMaintenance): Frequency of updates (maintenanceAndUpdateFrequency): continual, Keywords (descriptiveKeywords): Individual sectors establish dictionaries of keywords Keyword (keyword): Land (etc.: Parcels, Buildings, Use, Ownership, Cadastre) Keyword type (type): theme mandatory keywords of "theme" category Dictionary name (thesaurusName): Special value: template Limitations associated with the data (resourceConstraints): Access constraints (accessConstraints): Special value: Not applicable Use of data (useConstraints): license Use of data (useConstraints): copyright Limitations associated with the data (resourceConstraints): Security classification of the data (classification): unclassified Type of representation of spatial data (spatialRepresentationType): vector only for datasets Spatial resolution (spatialResolution): raster, vector, tin Spatial resolution - equivalent scale (equivalentScale): scale of equivalent map expressed by the scale denominator Scale denominator (denominator): 500 or the resolution distance Resource Language (language): pol Character set (CharacterSet): utf8 Category of data (topicCategory): Extent of data (Extent): Spatial extent (geographicElement): using WGS84 system Westbound longitude (westBoundLongitude): 19.24617447 Eastbound longitude (eastBoundLongitude): 19.58909458 Southbound latitude (southBoundLatitude): 54.03376397 Northbound latitude (northBoundLatitude): 54.28399297 Section Reference system information (referenceSystemInfo): Identifier (referenceSystemIdentifier) recommended that ident. in agreement with www.epsg.org Code (code): 2173 European Petroleum Survey Group Name (code) of catalogue (codeSpace): EPSG 2000/18 - EPSG 2177 Section Distribution information (distributionInfo) Distributor of data (Distributor): 1965/5 - EPSG 2175 Contact to the distributor of data (distributorContact): 1965/1 - EPSG 3120 Name of organisation (organisationName):

Examples of Metadata

149

Address data and contact information (contactInfo): Telephones (phone): Phone Number (voice): +4855239497 Address (address): E-mail (electronicMailAddress): Function (roles): resourceProvider Procedures for ordering (distributionOrderProcess): Fees (fees): Data distribution format (distributorFormat): The format name (name): Microstation DGN complete, short, recognizable name Format version (version): v8 (SWDE v3.2, v2.0 GML) Section Data quality information (dataQualityInfo): The scope of quality information (scope): The level of the hierarchy (level): dataset Data Quality Report (report): Information on conformance to the standard/specification (result): Standard/specification (specification): Title/name (title): Date (date): 2001-03-29 Type of the date (dateType): publication General explanation to the degree of conformance(explanation): conformant Conformant/Not conformant (pass): true Information on conformance to the standard/specification (result): Standard/specification (specification): Title/name (title): Date (date): 2003-11-03 Type the date (dateType): publication General explanation to the degree of conformance(explanation): conformant Conformant/Not conformant(pass): true The history of creation of the resource (lineage): General information about the source data (statement):

.

Chapter 7

Examples of Metadata Documents

The chapter presents samples of metadata files for three different metadata profiles: Example 1 – ISO 19115 base profile (core), including metadata elements, which are mandatory or recommended by the standard Example 2 – INSPIRE profile, including metadata elements which are mandatory or recommended by the EU regulations Example 3 – Polish metadata profile for spatial data (developed by GUGiK) – an open standard

Explanations to the Following Examples Name and Name of Role Name is specified by the label assigned to a metadata entity or metadata element. Metadata entity names begin with a capital letter. The name of the metadata entity may not contain spaces, but a combination of words can be used, where each of the subsequent words begins with a capital letter (example: XnnnYmmm). Metadata entity names are unique within the entire data dictionary of this standard. Names of metadata elements are unique within the metadata entity, but not within the entire data dictionary of this standard. Names of metadata elements become unique within the application by combining the names of metadata entity and metadata element (for example: MD_Metadata.characterSet). The names of roles are used to identify metadata associations from an abstract model and are preceded by the phrase: “Role name:” in order to distinguish them from other metadata elements. The names and role names can be specified in a language other than was used in the standard.

L. Litwin and M. Rossa, Geoinformation Metadata in INSPIRE and SDI, Lecture Notes in Geoinformation and Cartography, DOI 10.1007/978-3-642-15862-9_7, # Springer-Verlag Berlin Heidelberg 2011

151

152

7 Examples of Metadata Documents

Short Names and Domain Code Classes that do not represent CodeList or Enumeration stereotypes are given together with the short name for each element. Short names are unique within the standard and can be used with the Extensible Markup Language (XML) and ISO 8879 (SGML), or using similar implementation techniques. Naming convention used for the construction of short names is similar to that which is used to create full names. Implementation using SGML and XML is not mandatory and other methods of implementation may be used. In the case of Code-List and Enumeration stereotypes, the code is provided for each possible choice. Domain codes are three-digit numbers and are unique within a code list. The first row of each code list or enumeration includes the short name described above, as the first row is a name of code list or enumeration.

Descriptors: Mandatory/Conditional/Optional This descriptor indicates whether the metadata entity or metadata element should always be documented or it may not contain values in some cases. The descriptor may have the following values: M – mandatory C – conditional O – optional

Mandatory (M) Metadata entity or metadata element should be documented.

Conditional (C) Specifies an electronically manageable condition, according to which at least one metadata entity or metadata element is mandatory. The value of “conditional” is used in one of the following three cases: • Having choice between two or more options. At least one option is mandatory and must be documented. • Documenting metadata entity or metadata element if another element has been documented in the metadata.

Descriptors: Mandatory/Conditional/Optional

153

• Documenting metadata element if the specific value was stored in another metadata element. For ease of reading, the specific value is given as a plain text (e.g. table in Section B.2, line 3 (“C / not defined?”). However, in the user interface of metadata editor application a code should be used to verify this condition. If the condition is fulfilled, then the metadata entity or metadata element should be mandatory.

Optional (O) Metadata entity or metadata element may, but need not, be documented. Optional metadata entities and optional metadata elements have been defined to ensure that data can be fully documented. The use of a common set of defined elements will help in promoting collaboration between users and producers (suppliers) of geographic (spatial) data worldwide. If an optional entity is not used, then the elements contained within this entity (including mandatory elements) will also not be used. Optional entities may have mandatory elements, those elements become mandatory only when the optional entity is used.

Maximum Number of Instances Specifies the largest number of instances that a metadata entity or metadata element may have. Individual instances are presented as “1”, multiple instances are represented as “N”. Fixed number of instances other than “1” is also possible. It is represented by the corresponding number (i.e. “2”, “3”, . . . etc.).

Data Type Defines a set of unique values to represent the metadata elements, for example: integer, real, string, DateTime, Boolean. Data type attribute is also used to define metadata entities, stereotypes and metadata associations. (I) Data types are defined in ISO 19118, 8.2.2.

Domain For a metadata entity, a domain indicates the line numbers encompassed by the entity. For a metadata element, a domain specifies allowed values or permits the use

154

7 Examples of Metadata Documents

of any text. The phrase “free text” indicates that there is no restriction imposed on the content of the field. To represent the values for fields that contain lists of codes, integer based codes should be used. • • • •

“þ” sign means the node of the hierarchy of the metadata file. Indentation – specifies the level in the hierarchy of the metadata file. Number e.g. 376 – the number of metadata element according to ISO 19115. Regular text (e.g. language) – the name of the metadata element according to ISO 19115. • The text in brackets, e.g. (Language of metadata) – short explanation of a meaning of a metadata element. • Letter designation in square brackets e.g.[C] – status of the metadata element: – – – –

M – mandatory C – conditional O – optional F – recommended (only for the Polish profile for spatial data – GUGiK profile)

• Bold text, e.g. pol – example of metadata element value. • Italic text e.g. the metadata file identifier . . . – the name and comment for a metadata element.

Example 1: Base Profile (Core), ISO 19115 154 1.Section – (information about metadata): þ 2. fileIdentifier (unique identifier for the metadata file) [O]: 60543df7-E41011dc-8fa8-005056c00001 Unique (world-wide) identification of metadata, it is also the name of the metadata file .This can be any identifier. It is important to meet the condition of uniqueness – for this reason it is recommended to use UUID (Universal Unique Identifier), which is specified by IETF (http://www.ietf.org) and RFC 4122UUID – UUID consists of 32 characters. þ 3. language (language used for documenting metadata) [C]: eng 3-letter code identifying the language in which metadata were developed, it is recommended to use ISO 639-2. þ 4. characterSet (full name of the character coding standard used for metadata set) [C]:utf8 Code specifying the encoding of characters in metadata file – the list of available codes in accordance with ISO 19115 þ 8. contact (party responsible for the metadata) [M]: Identification information and contact to the party responsible for maintaining the metadata. þ 376. organisationName (name of the responsible organisation): Polish Geological Institute (PGI) Full, official name of the organisation. In addition, it is allowed to include official abbreviation of the name of organisation e.g. GUGiK, PODGiK – abbreviations should be given in parentheses.

Example 1: Base Profile (Core), ISO 19115 154

155

þ 379. role (function of the responsible party): pointOfContact code identifying the role performed by the organisation in relation to metadata such as point of contact, originator, custodian, etc – the list of codes defined by ISO 19115 þ 9. dateStamp (creation date of metadata) [M]: 2009-04-30T21: 4:04 Date of creation or last revision of the metadata file. In this example it takes the format YYYYMM-DDThh:mm:ss. It is allowed to specify date without specifying time (hours). þ 10. metadataStandardName (Name of the used metadata standard, together with the profile name) [O]:ISO 19115 The name of standard according to which the metadata were prepared – in this case the International Standard. þ 11. metadataStandardVersion (version of metadata standard, along with the version of the profile) [O]: 2003/cor.1: 2006 Version of the standard, according to which the metadata were prepared – in this case, version of the ISO standard. 13.Section – referenceSystemInfo (information about the system of spatial references) [O]: þ 187. referenceSystemIdentifier (): Identification of spatial reference system – it is recommended to use identifiers according to the EPSG standard – European Petroleum Survey Group (http://www.epsg.org). þ 207. code (): 2173 Number – code value from EPSG catalog. EPSG contains codes for all coordinate systems used in Poland. þ 208.1 codeSpace (name of the codes catalog): EPSG In this case abbreviation of organisation name: European Petroleum Survey Group. 15.Section – identificationInfo (basic information on the resource) [M]: Basic information about the resource(s) to which metadata relate. þ 24. citation () [M]: Data cited for the resource(s). þ 360. title (Title/name) [M]: Sheet 725 – Brzeg Dolny, Formal, unique, short name of the data set.This name does not duplicate the name of the series (composing the appropriate name of the set from series name and short name of the set is a function of metadata catalog), for example the name of the series: “Detailed Geological Map of Poland, scale 1:50 000” and short name of set, “Sheet 725 – Brzeg Dolny” – the name composed by metadata catalog (shown to users in the search results): Detailed Geological Map of Poland, scale 1:50 000 Sheet 725 – Brzeg Dolny þ 362. date () [M]: þ 394. date (): 2003 þ 395. dateType (type of date): creation þ 362. date () [M]: þ 394. date () : 2004 þ 395. dateType (type of date): publication Element date consists of two metadata elements: date and dateType. The first is a date that can be given as: year, year and month, year, month and day or year, month, date and time (given in format: year-month-dayThour:min:sec ¼> YYYYMM-DDThh:mm:ss). In many cases, specifying only the year is sufficient. The second element of date is the type of date specified in the code list of ISO 19115 – these are the dates of: creation, publication and revision of the data set. You can enter all three dates, but it is mandatory to provide at least one of them.

156

7 Examples of Metadata Documents

þ 367. citedResponsibleParty (organisation responsible for the resource) [O]: Identification and contact information for the party responsible for the resource. þ 376. organisationName (name of organisation): Treasury þ 379. role (function): owner þ 367. citedResponsibleParty (organisation responsible for the resource): þ 376. organisationName (name of organisation): Polish Geological Institute þ 379. role (function): originator CitedResponsibleParty element consists of a number of metadata elements. Recording information against these elements is optional, but if they are used, at least the name of the organisation and its role in relation to the resource should be specified. Name – the full, official name of the organisation. In addition, it is allowed to include official abbreviation of the name of organisation e.g. GUGiK, PODGiK – Abbreviations should be given in parentheses. The function is defined by code that describes the role of the organisation in relation to the resource e.g. point of contact, originator, custodian, owner, etc. – the list of codes is defined by ISO 19115. þ 25. abstract (summary) [M]: Map presents the surface geological structure of Poland . . . Summary(abstract) – a brief and concise description of the resource. In summary repetitions should be avoided, i.e. information characterizing the resource, which are described elsewhere in the metadata. þ 37. spatialRepresentationType (type of representation of spatial data) [O]: vector Identification of the method of geometric representation of a resource such as vector, raster, tin, etc. The resource may be represented in several ways. þ 38. spatialResolution (): þ 60. equivalentScale (scale used in elaboration) [O]: þ 57. denominator (denominator of the scale): 500000 þ 61. distance (): 50 m Information on the spatial resolution, defined as the accuracy of the elaboration – can be recorded in several ways: – A scale comparable to hard-copy maps, usually expressed as the denominator of integer type e.g.10,000. – As the base distance between adjacent meshes for raster data and grid nets, usually expressed as a numeric value associated with a unit of length e.g. 25 m. – As the range of scale expressed by the denominator of initial and final scale 10,000–25,000. – As the interval between the base distance expressed by the denominator of the initial and final distance e.g. 5–10 m. þ 39. language (language of the data – resource) [M]: eng 3-letter code identifying the language in which resource was developed, it is recommended to use codes defined by ISO 639–2.

Example 1: Base Profile (Core), ISO 19115 154

157

þ 40. characterSet (Full name of the character coding standard used in a resource) [C]:utf8 Code specifying the character encoding in a resource – a list of codes is specified by ISO 19115 þ 41. topicCategory (Category of data) [M]: geoscientificInformation code identifying the category to which the resource was associated- a list of codes is specified by ISO 19115 þ 45. extent (data range) [C]: Additional information on the extent containing the bounding box, vertical and temporal extent of the data set. þ 336. geographicElement (spatial coverage of the data) [C]: Gives the geographic component of the extent of the referring object. Spatial coverage of the resource specified in the WGS84 coordinate system. Please note that the ISO standard does not specify the minimum number of significant figures. þ 344. westBoundLongitude (west bounding longitude) [M]: 14.00000000 western-most coordinate of the limit of data set range, expressed in longitude in decimal degrees (positive east). 180 <¼ value of the West Bounding Longitude ¼> 180. þ 345. eastBoundLongitude (east bounding longitude) [M]: 24.00000000 easternmost coordinate of the limit of the data set range, expressed in longitude in decimal degrees (positive east). 180 <¼ value of the East Bounding Longitude ¼> 180. þ 346. southBoundLatitude (south bounding latitude) [M]: 49.0000000 southern-most coordinate of the limit of the data set range, expressed in latitude in decimal degrees (positive north). 90 <¼ value of South Bounding Latitude ¼> 90; South Bounding Latitude <¼ value of North Bounding Latitude þ 347. northBoundLatitude (north bounding latitude) [M]: 55.00000000 northern-most coordinate of the limit of data set range, expressed in latitude in decimal degrees (positive north). 90 <¼ value of North Bounding Latitude ¼> 90; value of North Bounding Latitude >¼ value of South Bounding Latitude. 17.Section – distributionInfo (Information on the distribution of data) [O]: Lists information about the distributor and options for obtaining the resource(s). þ 273. transferOption (information about technical means and media by which the resource is acquired from the distributor) [O]: Gives information about technical means and media by which the resource is obtained (purchased) from the distributor. þ 277. onLine (Information on-line) [O]: Information on the web sources, from which the resource can be obtained. þ 397. linkage (URL address) [M]: http://www.pgi.gov.pl Location (address) for web access using the URL network address (Uniform Resource Locator) or a similar addressing scheme. þ 282. distributorFormat (data distribution format) [C]: Gives information on the format used by the distributor. þ 285. name (format name) [M]: Shape Complete, concise, recognizable name that specifies the format used by the distributor. þ 286. version (format version) [M]: ArcGIS 8 Format version (which may include the date, number, etc.). 18.Section – dataQualityInfo (Information about the quality of the resource) [O]: Gives the overall assessment of the quality of the resource(s).

158

7 Examples of Metadata Documents

þ 81. lineage (history of creation of the resource) [C]: Non-quantitative quality information about the lineage of data specified by scope. þ 83. statement (General information on source data) [C]: Detailed method used to create the map . . . General explanation of data producer’s knowledge about the lineage of a data set.

Example 2: INSPIRE Profile 1.Section – (information about metadata): þ 2. fileIdentifier (unique identifier of the metadata file) [O]: 60543df7-E41011dc-8fa8-005056c00001 unique (world-wide) identification of metadata, it is also the name of the metadata file. This can be any identifier, it is important to meet the condition of uniqueness – for this reason it is recommended to use UUID (Universal Unique Identifier), which is specified by IETF (http://www.ietf.org) and RFC 4122UUID – UUID consists of 32 characters. þ 3. language (language used for documenting metadata) [C]: eng 3-letter code identifying the language in which metadata was developed, it is recommended to use ISO 639-2. þ 4. CharacterSet (full name of the character coding standard used for metadata set) [C]: utf8 Code specifying the encoding of characters in metadata file – the list of available codes in accordance with ISO 19115 þ 5. parentIdentifier (): 3db66e46-e229-11dc-8fa8-005056c00301 þ 6. hierarchyLevel () [M]: dataset Scope to which the metadata apply. In the case of INSPIRE profile one of three codes should be used: dataset, series, service. þ 8. contact (Party responsible for the metadata) [M]: Identification information and contact to the party responsible for the metadata information. þ 376. organisationName (name of the responsible organisation): Polish Geological Institute (PGI) Full, official name of the organisation. In addition, it is allowed to include official abbreviation of the name of organisation e.g. GUGiK, PODGiK – Abbreviations should be given in parentheses. þ 378. contactInfo (Address): þ 389. address (): þ386. electronicMailAddress (e-mail address): [email protected] þ379. role (function performed by the responsible party): pointOfContact Code identifying the role played by the organisation in relation to metadata such as point of contact, originator, custodian, etc – the list of codes specified by ISO 19115. þ 9. dateStamp (date of metadata creation) [M]: 2009-04-30T21: 4:04 Date of creation or last update of the metadata file. In this example it takes the format YYYYMM-DDThh:mm:ss. It is allowed to specify date without specifying time (hours). þ 10. metadataStandardName (Name of the used metadata standard, together with the profile name) [O]:ISO 19115 The name of standard according to which the metadata were prepared – in this case the general standard.

Example 2: INSPIRE Profile

159

þ 11. metadataStandardVersion (version of metadata standard, along with the version of the profile) [O]: 2003/cor.1:2006 Version of the standard, according to which the metadata were prepared – in this case, version of the ISO standard. 13.Section – referenceSystemInfo (Information about the system of spatial references) [O]: þ 187. referenceSystemIdentifier (ID): Identification of spatial reference system – it is recommended to use identifiers according to the EPSG standard – European Petroleum Survey Group (http://www.epsg.org). þ 207. code (): 2173 number – value from EPSG catalog. EPSG contains codes for all coordinate systems used in Poland. þ 208.1 codeSpace (name of the codes catalog): EPSG In this case abbreviation of organisation name: European Petroleum Survey Group. 15.Section – identificationInfo (Basic information on the resource) [M]: Basic information about the resource(s) to which metadata relate. þ 24. citation () [M]: Data cited for the resource(s). þ 360. title (title/name) [M]: Sheet 725 – Brzeg Dolny, formal, unique, short name of the data set. The name that does not duplicate the name of the series (composing the appropriate name of the set from series name and short name of the set is a function of metadata catalog), for example the name of the series: “Detailed Geological Map of Poland, scale 1:50 000” and short name of set, “Sheet 725 – Brzeg Dolny” – the name composed by metadata catalog (shown to users in the search results): Detailed Geological Map of Poland, scale 1:50 000 Sheet 725 – Brzeg Dolny þ 362. date () [M]: þ 394. date (): 2003 þ 395. dateType (type of date): creation þ 362. date () [M]: þ 394. date (): 2004 þ 395. dateType (type of date): publication þ 362. date () [M]: þ 394. date (): 2005 þ 395. dateType (type of date): revision Element date consists of two metadata elements: date and dateType. The first is a date that can be given as: year, year and month, year, month and day or year, month, date and time (given in format: year-month-dayThour:min:sec ¼> YYYYMM-DDThh:mm:ss).In many cases, specifying only the year is sufficient. The second element of date is the type of date specified in the code list of ISO 19115 – these are the dates of: creation, publication and revision of the data set. You can enter all three dates, but it is mandatory to provide at least one of them. þ 365. identifier (ID): PGI_SMGP_50k_725 Value that uniquely identifies the object within the namespace. According to the INSPIRE identifiers are to be given by the leading parties (such as state agencies).This element can also contain the URL of the namespace (ID-space).This can be any identifier, but it is important to meet the condition of uniqueness – it can also be a UUID (Universal Unique Identifier), which is specified by IETF (http://www.ietf.org) and RFC 4122UUID – UUID consists of 32 characters.

160

7 Examples of Metadata Documents

þ 367. citedResponsibleParty (Organisation responsible for the resource) [O]: identification information and means of contact with the party responsible for the resource. þ 376. organisationName (name of organisation): Treasury þ 379. role (function): owner þ 367. citedResponsibleParty (Organisation responsible for the resource): þ 376. organisationName (name of organisation): Polish Geological Institute þ 379. role (function): originator CitedResponsibleParty element consists of a number of metadata elements. Recording information against these elements is optional, but if they are used, at least the name of the organisation and its role in relation to the resource should be specified. Name – the full, official name of the organisation. In addition, it is allowed to include official abbreviation of the name of organisation e.g. GUGiK, PODGiK – Abbreviations should be given in parentheses. The function is defined by code that describes the role the organisation in relation to the resource such as point of contact, originator, custodian, owner, etc. – the list of codes in accordance with ISO 19115. þ 25. abstract (summary) [M]: This map shows the surface geological structure of Poland . . . Summary (abstract) – a brief and concise description of the resource. In summary, avoid repetition, i.e. information characterizing the resource, which are described elsewhere in the metadata. þ 29. pointOfContact (Point of contact for the resource): þ 376. organisationName (name of organisation): Polish Geological Institute þ 378. contactInfo (Address): þ 388. phone (telephones): þ 408. voice (Phone number): +48228495351 number with no spaces, dashes etc. þ 389th address (): þ 386. electronicMailAddress (e-mail address): [email protected] þ 390. onlineResource (network resource address): þ 397. linkage (URL) [M]: http://www.pgi.gov.pl Location (address) for web access using the URL network address (Uniform Resource Locator) or a similar addressing scheme. þ 379. role (function): pointOfContact þ 30. resourceMaintenance (information on the maintenance of the resource): þ 143. maintenanceAndUpdateFrequency (frequency of updates): unknown þ 33. descriptiveKeywords () [M]: Information on category keywords, their type and source of reference (dictionary).Individual sectors may create their own specific dictionaries of keywords. According to the INSPIRE requirements, it is mandatory to use GEMET dictionary . þ 53. keyword () [M]: Geology Commonly used word(s) or formalised word(s) or phrase(s) used to describe the subject þ 55. thesaurusName (dictionary name): Name of formally registered dictionary or similar reliable source of keywords. þ 360. title (Title/name) [M]: GEMET In this case, formal, unique, short name of a dictionary of keywords.

Example 2: INSPIRE Profile

161

þ 362. date () [M]: In this case, the date of publication of the dictionary of keywords. þ 394. date () [M]: 2004 þ 395. dateType (type of date) [M]: publication Element date consists of two metadata elements: date and dateType. The first is a date that can be given as: year, year and month, year, month and day or year, month, date and time (given in format: year-month-dayThour:min:sec ¼> YYYYMM-DDThh:mm:ss).In many cases, specifying only the year is sufficient. The second element of date is the type of date specified in the code list provided by ISO 19115 – these are the dates of: creation, publication and revision of the data set. You can enter all three dates, but it is mandatory to provide at least one of them. þ 35. resourceConstraints (restrictions associated with the data) [O]: Provides information on the restrictions that apply to the resource(s). þ 68. useLimitation [O]: Cannot be used for navigation restriction regarding fitness for use of the resource. þ 70. accessConstraints (access to data) [O]: Access restrictions to ensure the protection of privacy or intellectual property, and any additional restrictions or warnings regarding the acquisition of the resource. þ 71. useConstraints (use of data) [O]: license þ 71. useConstraints (use of data) [O]: copyright þ 35. resourceConstraints (restrictions associated with the resource) [O]: Provides information on the restrictions that apply to the resource(s). þ 74. classification (classification of data) [O]: unclassified name of restrictions imposed on the resource. If the resource is not confidential, secret or top secret, it should be reported as unclassified. þ 37. spatialRepresentationType (type of representation of spatial data) [O]: vector Identification of the method of geometric representation of a resource e.g. vector, raster, tin, etc. The resource may be represented in several ways. þ 38. spatialResolution (): þ 60. equivalentScale (scale used in elaboration) [O]: þ 57. denominator (denominator of the scale): 500000 þ 61. distance (): 50 m Information on the spatial resolution, defined as the accuracy of the elaboration – can be recorded in several ways: – As the scale comparable to hard-copy maps, usually expressed as the denominator of integer type e.g. 10,000. – As the base distance between adjacent meshes for raster data and grid nets, usually expressed as a numeric value associated with a unit of length e.g. 25 m. – As the range of scale expressed by the denominator of initial and final scale 10,000–25,000. – As the interval between the base distance expressed by the denominator of the initial and final distance e.g. 5–10 m.

162

7 Examples of Metadata Documents

þ 39. language (language of the data – resource) [M]: eng 3-letter code identifying the language in which resource was developed, it is recommended to use ISO 639-2 standard. þ 40. characterSet (characters encoding standard used in a resource): utf8 þ 41. topicCategory (Data category)[M]: geoscientificInformation code identifying the category to which the resource was associated – a list of codes in accordance with ISO 19115. According to the INSPIRE guidelines, the ISO code is assigned to the relevant spatial data themes contained in the annexes of the INSPIRE directive. þ 45. extent (data range) [C]: Additional information on the extent containing the bounding box, vertical and temporal extent of the data set. þ 336. geographicElement (spatial coverage of the resource) [C]: Provides the geographic component of the extent of the referring object. Spatial coverage of the resource specified in the WGS84 system .Please note that according to the requirements of INSPIRE, values should be given to an accuracy of at least two decimal places. þ 344. westBoundLongitude (west bounding longitude) [M]: 14.13 westernmost coordinate of the limit of data set range, expressed in longitude in decimal degrees (positive east). 180 <¼ value of the West Bounding Longitude ¼> 180. þ 345. eastBoundLongitude (east bounding longitude) [M]: 24.25 eastern-most coordinate of the limit of the data set range, expressed in longitude in decimal degrees (positive east). 180 <¼ value of the East Bounding Longitude ¼> 180. þ 346. southBoundLatitude (south bounding latitude) [M]: 49.32 southern-most coordinate of the limit of the data set range, expressed in latitude in decimal degrees (positive north). 90 <¼ value of South Bounding Latitude ¼> 90; South Bounding Latitude <¼ value of North Bounding Latitude þ 347. northBoundLatitude (north bounding latitude) [M]: 55.45 Northern-most coordinate of the limit of data set range, expressed in latitude in decimal degrees (positive north). 90 <¼ value of North Bounding Latitude ¼> 90; value of North Bounding Latitude >¼ value of South Bounding Latitude. þ 337. temporalElement (temporal extent of the resource) [C]: Specifies temporal component of the extent of the referring object. þ 351. extent[M]: Date and time for the content of the resource. þ 628. TimePeriod (GML Language class) – describes the beginning and end of time interval, which corresponds to the resource. 17.Section – distributionInfo (Information on the distribution of data): þ 272. distributor (Distributor of data): þ 280. distributorContact (means of communication with distributor of data): þ 376. organisationName (name of organisation): Polish Geological Institute þ 378. contactInfo (Address): þ 388. phone (): þ 408. voice (Phone): +48228495351 þ 389. address (): þ 386. electronicMailAddress (e-mail address): [email protected] þ 379. role (function): resourceProvider

Example 2: INSPIRE Profile

163

18.Section – dataQualityInfo (Information about the quality of the resource) [O]: Provides the overall assessment of the quality of the resource(s). þ 79. scope (scope of qualitative information): þ 139. level (hierarchy level): dataset þ 80. report (Data quality report) [C]: Quantitative information on data quality for the specified data scope. þ 107. result (Information on compliance with the standard/specification) [M]: value (or set of values) obtained from applying a data quality measure or the outcome of evaluating the obtained value (or set of values) against a specified acceptable conformance quality level þ 130. specification (standard / specification) [M]: citation of a product specification or user requirement against which data is being evaluated. þ 360. title (title/name) [M]: Regulation – “Instruction of The 1:50,000 Detailed Geological Map of Poland production” The title of the specification. þ 362. date () [M]: Date concerning the specification. þ 394. date () [M]: 2001-03-29 þ 395. dateType (type of date) [M]: publication Element date consists of two metadata elements: date and dateType. The first is a date that can be given as: year, year and month, year, month and day or year, month, date and time (given in format: year-month-dayThour:min:sec ¼> YYYYMM-DDThh:mm:ss).In many cases, specifying only the year is sufficient. The second element of date is the type of date specified in the code list provided by ISO 19115 – these are the dates of: creation, publication and revision of the data set. In this case, date of publication should be provided. þ 131. explanation (general explanation of the degree of conformance) [M]:in conformance with specification Explanation of the meaning of conformance for this result. þ 132. pass (in conformance/ not in conformance) [M] true indication of the conformance result where true¼1 and false ¼ 0 þ 81. lineage (history of creation of the resource) [C]: Non-quantitative quality information about the lineage of data specified by scope. þ 83. statement (General information on source data) [C]: Detailed method used to create the map . . . General explanation of data producer’s knowledge about the history of a data set.

.

About the Authors

Leszek Litwin L.L., Ph.D. in Earth Sciences, was graduated in 1995, from Faculty of Earth Sciences of Silesian University, Katowice, Poland. Dr Litwin also obtained graduations from postgraduated studies in Silesian University of Technology, Gliwice, Poland and from studies in Institute of Development Countries of Warsaw University, Poland, pursuing his particular interest in the domain of GIS. He is a member of the Polish Association of Spatial Information and the Polish Information processing Society. Since 2002, he has been employed by Institute of Spatial and Cadastral Systems Gliwice, Poland, where he carries out research connected with issues of spatial data, metadata, geoinformation standards as well as WebGIS and geoportals. Particularly, he is developing GIS systems complying with requirements of the EU INSPIRE Directive, especially in the systems related to the metadata. He is leading the ISPiK’s project of developing and maintaining the first Polish metadata editor MEDARD and the first Polish metadata catalogue AQUARIUS. In the development of this editor, the Free and Open Source Software (FOSS) and Afero General Public Licence (AGPL) were used. In 2007, by the decision of General Surveyor of Poland he was appointed to the team developing national geoinformation metadata profile (GUGiK profile) for the Head Office of Geodesy and Cartography of Poland. He delivered many presentations on issues related to European Spatial Information Infrastructure at EC GI-GIS (2004) workshops, European INSPIRE conferences (2007, 2008, 2010) and at many other conferences, workshops. He also publicised numerous papers in various GIS related journals including journals listed in ISI Master Journal List. He was invited to give lectures on WebGIS at universities, among them at University of Ljubljana and Chemnitz University of Technology .He provides lectures on WebGiS for students of Computer Science at Silesian University of Technology. He prepared program for and carries out special courses on “Geographic Information Systems, INSPIRE and SDI” program (at postgraduate studies organized by the Institute of Computer Science of Silesian University of Technology). L. Litwin and M. Rossa, Geoinformation Metadata in INSPIRE and SDI, Lecture Notes in Geoinformation and Cartography, DOI 10.1007/978-3-642-15862-9, # Springer-Verlag Berlin Heidelberg 2011

165

166

About the Authors

He is a co-author of the book titled “Geographic Information Systems. Managing spatial data in GIS, SIP, SIT, LIS” published in 2005 in Poland. Maciej Rossa, MSc, graduated from Warsaw University Faculty of Geology and completed postgraduate Ph.D. study. He is a hydro-geologist by education, by profession and passion specialist on geoinformatics, spatial data, metadata and GIS. Member of the Polish Association of Spatial Information. He has worked for many years in Polish Geological Institute (PGI), where he worked on implementation of INSPIRE directive in PGI and in the protection of environment resort, where he is an expert in this domaine. Then he was appointed as the director of Department of Environmental Information, Ecomanagement, Promotion and Information in General Directorate for Environmental Protection. On behalf of Under-Secretary of State Chief National Geologist who represents Polish Ministry of Environment, Mr. Rossa takes part in National Council for Implementation of INSPIRE Directive established at Polish Head Office of Geodesy and Cartography. He also is a member of other groups working on INSPIRE implementation such as INSPIRE Working Group launched by Polish Ministry of Environment and INSPIRE Technical Committee at European Commission where he represents Polish Ministry of Environment. Moreover, he is INSPIRE expert for EuroGeoSurveys (organization of European Geological Surveys) and a member of Polish Metadata Profile Working Group. He gave lectures at Faculty of Geology at Warsaw University. Presently, he provides lectures on metadata in relation to, 3D and 4D GIS and spatial environmental data complying “Geographic Information Systems, INSPIRE and SDI” requirements at postgraduate studies organised by Institute of Computer Science of Silesian University of Technology.

Bibliography

Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) DOUGLAS D. NEBERT (ed.), 2004: The SDI Cookbook; version 2 (www.gsdi.org/docs2004/ Cookbook/cookbookV2.0.pdf) INSPIRE (Architecture and Standards WG) 2002 – INSPIRE Architecture and Standards Position Paper. JRC – Institute for Environment and Sustainability, ISPRA INTEROPERABILITY Program, 2002 – Open GIS Consortium, Wailand, URL: http://www. opengis.org/ogcInterop.htm ISO/TC 211 2002a – ISO/TC 211 Programme of work. Arch. ISO/TC 211, URL: http://www. isotc211.org/pow.htm IWANIAK A., 2006 – Infrastruktura danych przestrzennych inaczej – system metadanych dla PZDGiK. Geodeta, 1 EUROPEAN COMMISION (JRC), 2002 – Welcome to the EC GI & GIS Web Portal. URL: http:// www.ec-gis.org KUBIK T., 2007 – Technologiczne uwarunkowania implementacji serwiso´w metadanych. Materiały posiedzenia Rady ds. Implementacji INSPIRE. GUGiK, Warszawa KUBIK T., 2009 – Serwery metadanych – usługi katalogowe oparte na wolnym oprogramowaniu. Materiały ze szkolenia: Wolne oprogramowanie dla wykonawstwa i administracji geodezyjnej. Materiały woGIS, Wrocław KUHN W., 1997 – Liaison contribution from OGC: Toward Implemented Geoprocessing Standards: Converging Standardization Tracks for ISO/TC 211 and OGC. URL: http://www. isotc211.org/ protdoc/211n418/ GAZ´DZICKI J., 2002 – Standardy krajowe czy mie˛dzynarodowe? Geodeta, 12, 91 GAZ´DZICKI J., 2003 – Kompendium infrastruktury danych przestrzennych. Geodeta, 2, 3, 4, 5 GAZ´DZICKI J., MICHALAK J., 2005 – Internetowy Leksykon Geomatyki. URL: http://www. ptip.org.pl/auto.php?page¼Encyclopedia&enc¼1 MCKEE L., ØSTENSEN O., 1997 – The relationship between ISO/TC 211 and Open GIS Consortium, Inc. – Discussion paper. URL: http://www.isotc211.org/protdoc/211n397/ MICHALAK J., 1997 – OGIS – integracja systemo´w informacji geoprzestrzennej w geologii. Materiały konferencji: INFOBAZY’97, CI TASK, Gdan´sk MICHALAK J., 1998 – OpenGIS – rozproszone obiekty w uje˛ciu praktycznym. Materiały IV Konferencji: GIS w praktyce, Wyd. Centrum Promocji Informatyki, Warszawa MICHALAK J., 2000a – Geomatyka (geoinformatyka) – czy nowa dyscyplina? Prz. Geol., 48, 8: 673–678 MICHALAK J., 2002 – Standardy OpenGIS w realizowanych projektach i planach Unii Europejskiej. Materiały z Seminarium PTIP: Infrastruktura danych przestrzennych na poziomie europejskim i globalnym. Warszawa 167

168

Bibliography

MICHALAK J. 2003 – Standardy ISO 19100 i OpenGIS jako podstawa pan´stwowej infrastruktury geoinformacyjnej w zakresie geologii. Prz.Geol., 51, 4: 311–315 MICHALAK J., 2008 – Inicjatywa OWS-5 – kolejny etap rozwoju i harmonizacji specyfikacji OGC dotycza˛cych geoprzestrzennych usług sieciowych. PTIP ANNALES OF GEOMATICS, 6, 5 OGC, 2002 – Open Geospatial Consortium, Inc. URL: http://www.opengis.org OpenGIS Project Document Archive, 2001 – Open GIS Consortium, Wayland. URL: http:// member.opengis.org/tc/archive/index.htm PACHELSKI W., 1999 – Z´ro´dła europejskiego SIT oraz udział norm europejskich w jego budowie i rozwoju. Prace IGiK, 46, 98 PACHELSKI W., 2002 – Program prac normalizacyjnych w zakresie informacji geograficznej. Dokument Komitetu Technicznego nr 297 ds. Informacji geograficznej. PKN, Warszawa PACHELSKI W., WYSOCKA E. 1999 – Standaryzacja systemo´w informacji przestrzennej: teoria i praktyka. Prace IGiK, 46, 98 ´ Ł P., 2008: Metadane dla pan´stwowego zasobu geodezyjnego i kartograficznego. PACHO Konferencja "INFOOS´RODEK", Ustron´ ROSSA M., LITWIN L., 2008 – Edytory metadanych – poro´wnanie wybranych aplikacji „Open Source”. PTIP Annales of Geomatics, 6, 7 SCHELL D., 1999 – About Open GIS Consortium. W: Open GIS Consortium – Spatial connectivity for a changing world. OGC Press, Wayland SENKLER K., 2006 – Lecture on interoperable metadata catalogues. Materiały seminarium nt. implementacji katalogo´w metadanych. GUGiK, Warszawa SOCZEWSKI P., 2007 – Metadane (http://www.bgwm.pl/artykuly.htm) SPECYFIKACJA metadanych geoinformacyjnych dla Polski na potrzeby projektu GEOPORTAL.GOV.PL, 2007. Warszawa