the complete manual - geonetwork opensource

The complete manual

By the developers

V 2.4

Copyright © 2007-2009 The Open Source Geospatial Foundation

GeoNetwork opensource V 2.4 ii

Table of Contents

Preface ..................................................................................................................................... viI. User Guide ............................................................................................................................. 1

1. A Geographic Information Management System for all ..................................................... 21.1. Introduction ......................................................................................................... 2

What is GeoNetwork opensource ........................................................................ 2Background and evolution .................................................................................. 2The use of International Standards ..................................................................... 3Harvesting geospatial data in a shared environment ............................................. 3

1.2. GeoNetwork and the Open Source Community Development ................................. 32. Getting Started ............................................................................................................... 5

2.1. Default Search .................................................................................................... 52.2. Searching by Categories ...................................................................................... 62.3. Advanced Search ................................................................................................ 72.4. Analysing Search Results .................................................................................. 102.5. Privileges, roles and user groups ........................................................................ 11

3. Viewing and Analysing the Data .................................................................................... 133.1. Meta Data Description ....................................................................................... 13

Identification Section ......................................................................................... 13Distribution Section ........................................................................................... 16Reference System Section ................................................................................ 16Data Quality Section ......................................................................................... 17Metadata Information Section ............................................................................ 17

4. Adding new Data and Information ................................................................................. 184.1. Creating a New Record using the Metadata Editor on line .................................... 19

The steps in more details ................................................................................. 19Switching Editing Views from Default to Advanced to XML View .......................... 20Using basic commands of the editor .................................................................. 22

4.2. Entering Metadata for your Map ......................................................................... 23Entering Metadata For Your Map ...................................................................... 23Creating a Thumbnail ....................................................................................... 25Linking data for download ................................................................................. 26Assigning Privileges for a Map .......................................................................... 27Assigning Categories for a Map ........................................................................ 29

4.3. Uploading a New Record using the XML Metadata Insert Tool .............................. 295. Metadata in Spatial Data Management .......................................................................... 32

5.1. What is Metadata? ............................................................................................ 325.2. What are Metadata Standards? .......................................................................... 325.3. Why do we need Standardised Metadata? .......................................................... 325.4. Geographic Information Metadata Standard ......................................................... 325.5. Metadata profiles ............................................................................................... 335.6. Transition between metadata standards .............................................................. 33

6. Installing the software ................................................................................................... 346.1. New version - New functionalities ....................................................................... 346.2. Where do I get the installer? .............................................................................. 356.3. System requirements ......................................................................................... 35

Additional Software ........................................................................................... 35Supported browsers ......................................................................................... 35

GeoNetwork opensource V 2.4 iii

6.4. How do I install GeoNetwork opensource? .......................................................... 36On Windows .................................................................................................... 36Installation using the platform independent installer ............................................ 37Command line installation ................................................................................. 37

II. Administrator Guide .............................................................................................................. 397. Basic configuration ....................................................................................................... 40

7.1. System configuration ......................................................................................... 40Site General site parameters. ............................................................................ 42Catalogue services (CSW, Z39.50) .................................................................... 42Proxy configuration ........................................................................................... 43Email & notification ........................................................................................... 43Removed metadata .......................................................................................... 44Authentication .................................................................................................. 44

8. User and Group Administration ..................................................................................... 468.1. Creating new user Groups ................................................................................. 468.2. Creating new Users ........................................................................................... 488.3. User Profiles ..................................................................................................... 49

9. Import facilities ............................................................................................................. 519.1. File import ......................................................................................................... 51

XML file import ................................................................................................. 51MEF file import ................................................................................................ 51XML metadata insert ........................................................................................ 52

9.2. Batch import ...................................................................................................... 52Structured import .............................................................................................. 53

10. Harvesting .................................................................................................................. 5510.1. Introduction ..................................................................................................... 5510.2. Mechanism overview ........................................................................................ 5510.3. Harvesting life cycle ......................................................................................... 5510.4. Multiple harvesting and hierarchies ................................................................... 5610.5. General notes and issues ................................................................................ 56

General ............................................................................................................ 56GeoNetwork harvesting type ............................................................................. 56WebDAV harvesting type .................................................................................. 57CSW harvesting type ........................................................................................ 57OAI-PMH harvesting type ................................................................................. 57OGC service harvesting type ............................................................................ 57

10.6. The main page ................................................................................................ 57Harvesting result tips ........................................................................................ 59

10.7. Adding new nodes ........................................................................................... 60Adding a GeoNetwork node .............................................................................. 61Adding a Web DAV node ................................................................................. 63Adding a CSW node ........................................................................................ 65Adding an OAI-PMH node ................................................................................ 67Adding an OGC Service (ie. WMS, WFS, WCS) ................................................. 69

11. Metadata ownership ................................................................................................... 7111.1. Introduction ..................................................................................................... 7111.2. Access policy .................................................................................................. 71

Visualisation ..................................................................................................... 71Editing ............................................................................................................. 71

11.3. Privileges ........................................................................................................ 71

GeoNetwork opensource V 2.4 iv

11.4. Transfer Ownership ......................................................................................... 7212. Thesaurus .................................................................................................................. 74

12.1. Introduction ..................................................................................................... 7412.2. Thesaurus / SKOS format ................................................................................ 7412.3. Thesaurus administration ................................................................................. 74

Creation of a new thesaurus ............................................................................. 75Import existing thesaurus .................................................................................. 75

12.4. Editing/browsing thesaurus: add/remove/browse keywords ................................. 7612.5. Metadata editing: adding keywords ................................................................... 7612.6. Search criteria: keywords ................................................................................. 77

13. GeoNetwork’s Administrator Survival Tool - GAST ........................................................ 7813.1. What is GAST? ............................................................................................... 7813.2. Starting GAST ................................................................................................. 7813.3. Operating modes ............................................................................................. 7813.4. Tools subdivision ............................................................................................. 7913.5. Server and Account configuration dialogue ........................................................ 79

14. Localisation ................................................................................................................ 8114.1. Localisation of dynamic user interface elements ................................................ 81

15. Import / export tools .................................................................................................... 8315.1. Introduction ..................................................................................................... 8315.2. Import ............................................................................................................. 8315.3. Export ............................................................................................................. 84

III. Server Reference ................................................................................................................ 8516. Software development ................................................................................................ 86

16.1. System Requirements ...................................................................................... 8616.2. Running the software with a servlet engine ....................................................... 8616.3. Development ................................................................................................... 86

Compiling GeoNetwork ..................................................................................... 86Source code documentation .............................................................................. 87Creating the installer ........................................................................................ 87

17. Harvesting .................................................................................................................. 8817.1. Structure ......................................................................................................... 88

JavaScript code ................................................................................................ 88Java code ........................................................................................................ 88XSL stylesheets ............................................................................................... 88

17.2. Data storage ................................................................................................... 8917.3. Guidelines ....................................................................................................... 89

18. Metadata Exchange Format v1.1 ................................................................................. 9118.1. Introduction ..................................................................................................... 9118.2. File format ....................................................................................................... 9118.3. The info.xml file ............................................................................................... 92

Date format ...................................................................................................... 9319. XML Services ............................................................................................................. 95

19.1. Calling specifications ........................................................................................ 95Calling XML services ........................................................................................ 95Exception handling ........................................................................................... 96

19.2. General services .............................................................................................. 98xml.info ............................................................................................................ 98xml.forward ..................................................................................................... 103

19.3. Harvesting services ........................................................................................ 104

GeoNetwork opensource V 2.4 v

Introduction .................................................................................................... 104xml.harvesting.get ........................................................................................... 104xml.harvesting.add .......................................................................................... 107xml.harvesting.update ..................................................................................... 112xml.harvesting.remove/start/stop/run ................................................................ 113

19.4. System configuration ...................................................................................... 114Introduction .................................................................................................... 114xml.config.get ................................................................................................. 114xml.config.update ............................................................................................ 117

19.5. MEF services ................................................................................................. 120Introduction .................................................................................................... 120mef.export ...................................................................................................... 120mef.import ...................................................................................................... 120Metadata ownership ....................................................................................... 121

19.6. Relations ....................................................................................................... 121Introduction .................................................................................................... 121xml.relation.get ............................................................................................... 121

19.7. Schema information ....................................................................................... 123Introduction .................................................................................................... 123xml.schema.info .............................................................................................. 123

20. Settings hierarchy ..................................................................................................... 12620.1. Introduction .................................................................................................... 12620.2. The system hierarchy ..................................................................................... 12620.3. Harvesting nodes ........................................................................................... 127

Nodes of type GeoNetwork ............................................................................. 128Nodes of type geonetwork20 ........................................................................... 129Nodes of type WebDAV .................................................................................. 130Nodes of type CSW ........................................................................................ 130

A. Frequently Asked Questions ............................................................................................... 131B. Glossary of Metadata Fields Description .............................................................................. 134C. ISO Topic Categories ......................................................................................................... 138D. Free and Open Source Software for Geospatial Information Systems .................................... 141

D.1. Web Map Server software ....................................................................................... 141D.2. GIS Desktop software ............................................................................................. 141D.3. Web Map Viewer and Map Server Management ....................................................... 141

Glossary ................................................................................................................................. 142Index ..................................................................................................................................... 146

GeoNetwork opensource V 2.4 vi

PrefaceAbout this Project. This document provides guidelines to install, configure, use and customise theGeoNetwork opensource software. The GeoNetwork project started out as a Spatial Data CatalogueSystem for the Food and Agriculture organisation of the United Nations (FAO)1, the United NationsWorld Food Programme (WFP)2 and the United Nations Environmental Programme (UNEP)3. At presentthe project is widely used as the basis of Spatial Data Infrastructures all around the world. The projectis part of the Open Source Geospatial Foundation (OSGeo) and can be found at http://geonetwork-opensource.org.

License Information. Copyright (c) 2007-2009 Open Source Geospatial Foundation (OSGeo4).

You are free to Share — to copy, distribute and transmit the work. Under the following conditions:

• Attribution. You must attribute the work in the manner specified by the author or licensor (but not inany way that suggests that they endorse you or your use of the work).

• No Derivative Works. You may not alter, transform, or build upon this work.

• For any reuse or distribution, you must make clear to others the license terms of this work. The bestway to do this is with a link to this web page.

• Any of the above conditions can be waived if you get permission from the copyright holder.

• Nothing in this license impairs or restricts the author's moral rights.

You may obtain a copy of the License at Creative Commons5

The document is written in DocBook format for consistency and portability.

Author Information. This framework and documentation was written by the GeoNetworkopensource Developers. If you have questions, found a bug or have enhancements,please contact us through the GeoNetwork opensource Development Mailing list at<[email protected]>

1 http://www.fao.org2 http://vam.wfp.org3 http://www.unep.org4 http://www.osgeo.org5 http://creativecommons.org/licenses/by-nd/3.0/

http://www.fao.org

http://vam.wfp.org

http://vam.wfp.org

http://www.unep.org

http://geonetwork-opensource.org


http://www.osgeo.org

http://creativecommons.org/licenses/by-nd/3.0/

http://www.fao.org

http://vam.wfp.org

http://www.unep.org


http://creativecommons.org/licenses/by-nd/3.0/

Part I. User GuideThis part of the document focusses on the general use of GeoNetwork for visitors and for Spatial DataManagers that want to publish data and metadata.

GeoNetwork opensource V 2.4 2

1. A Geographic Information Management Systemfor all

1.1 Introduction

What is GeoNetwork opensource

GeoNetwork opensource is a standard based and decentralised spatial information managementsystem, designed to enable access to geo-referenced databases and cartographic products from avariety of data providers through descriptive metadata, enhancing the spatial information exchange andsharing between organisations and their audience, using the capacities and the power of the Internet.The system provides a broad community of users with easy and timely access to available spatial dataand thematic maps from multidisciplinary sources, that may in the end support informed decision making.The main goal of the software is to increase collaboration within and between organisations for reducingduplication and enhancing information consistency and quality and to improve the accessibility of a widevariety of geographic information along with the associated information, organised and documented ina standard and consistent way.

Main Features

• Instant search on local and distributed geospatial catalogues

• Uploading and downloading of data, documents, PDF's and any other content

• An interactive Web map viewer that combines Web Map Services from distributed servers aroundthe world

• Online map layout generation and export in PDF format

• Online editing of metadata with a powerful template system

• Scheduled harvesting and synchronisation of metadata between distributed catalogues

• Groups and users management

• Fine grained access control

Background and evolution

The prototype of the GeoNetwork catalogue was developed by the Food and Agriculture organisationof the United Nations (FAO) in 2001 to systematically archive and publish the geographic datasetsproduced within the organisation. The prototype was built on experiences within and outside theorganisation. It used metadata content available from legacy systems that was transformed into whatwas then only a draft metadata standard, the ISO 19115. Later on, another UN agency, the WorldFood Programme (WFP) joined the project and with its contribution the first version of the software wasreleased in 2003 and operational catalogues were established in FAO and WFP. The system was basedon the ISO19115:DIS metadata standard and embedded the Web Map Client InterMap that supportedOpen Geospatial Consortium (OGC) compliant Web Map Services. Distributed searches were possibleusing the standard Z39.50 catalogue protocol. At that moment it was decided to develop the programas a Free and Open Source Software to allow the whole geospatial users community to benefit from thedevelopment results and to contribute to the further advancement of the software.

A Geographic Information Management System for all


Jointly with the UN Environmental Programme (UNEP), FAO developed a second version in 2004. Thenew release allowed users to work with multiple metadata standards (ISO 19115, FGDC and DublinCore) in a transparent manner. It also allowed metadata to be shared between catalogues through acaching mechanism, improving reliability when searching in multiple catalogues.

In 2006, the GeoNetwork team dedicated efforts to develop a DVD containing the GeoNetwork version2.0.3 and the best free and open source software in the field of Geoinformatics. The DVD was producedand distributed in hard copy to over three thousand people and is now also available for download fromthe GeoNetwork Community website1.

GeoNetwork opensource is the result of the collaborative development of many contributors. Theseinclude among others the Food and Agriculture organisation (FAO), the UN Office for the Coordinationof Humanitarian Affairs (UNOCHA), the Consultative Group on International Agricultural Research (CSI-CGIAR), The UN Environmental Programme (UNEP), The European Space Agency (ESA) and manyothers. Support for the metadata standard ISO19115:2003 has been added by using the ISO19139:2007implementation specification schema published in May 2007. The release also serves as the opensource reference implementation of the OGC Catalogue Service for the Web (CSW 2.0.2) specification.Improvements to give users a more responsive and interactive experience have been substantial andinclude a new Web map viewer and a complete revision of search interface.

The use of International Standards

GeoNetwork has been developed following the principles of a Free and Open Source Software (FOSS)and based on International and Open Standards for services and protocols, like the ISO-TC211 and theOpen Geospatial Consortium (OGC) specifications. The architecture is largely compatible with the OGCPortal Reference Architecture, i.e. the OGC guide for implementing standardised geospatial portals.Indeed the structure relies on the same three main modules identified by the OGC Portal ReferenceArchitecture, that are focused on spatial data, metadata and interactive map visualisation. The systemis also fully compliant with the OGC specifications for querying and retrieving information from Webcatalogues (CSW). It supports the most common standards to specifically describe geographic data(ISO19139 and FGDC) and the international standard for general documents (Dublin Core). It usesstandards (OGS WMS) also for visualising maps through the Internet.

Harvesting geospatial data in a shared environment

Within the geographic information environment, the increased collaboration between data providersand their efforts to reduce duplication have stimulated the development of tools and systems tosignificantly improve the information sharing and guarantee an easier and quicker access of data from avariety of sources without undermining the ownership of the information. The harvesting functionality inGeoNetwork is a mechanism of data collection in perfect accordance with both rights to data access anddata ownership protection. Through the harvesting functionality it is possible to collect public informationfrom the different GeoNetwork nodes installed around the world and to copy and store periodically thisinformation locally. In this way a user from a single entry point can get information also from distributedcatalogues. The logo posted on top each harvested record informs the user about the data source.

1.2 GeoNetwork and the Open Source Community Development

The community of users and developers of the GeoNetwork software has increased dramatically sincethe release of version 2.0 in December 2005 and the subsequent releases. At present, the user and

1 http://geonetwork-opensource.org



A Geographic Information Management System for all


developer mailing lists count well over 250 subscriptions each. Subscription to these lists is open toanyone interested. The archive of the mailing lists provides an important resource for users and can befreely browsed online. Members provide feedback within the community and provide translations, newfunctionalities, bug reports, fixes and instructions to the project as a whole. Building a self sustainingcommunity of users and developers is one of the biggest challenges for the project. This community-building process relies on active participation and interaction of its members. It also relies on buildingtrust and operating in a transparent manner, thereby agreeing on the overall objectives, prioritizationand long term direction of the project. A number of actions have been taken by the project team tofacilitate this process.

The foundation for the establishment of a GeoNetwork Advisory Board was laid at the 2006 workshopin Rome and membership criteria were defined.

A work plan is presented and discussed at the yearly GeoNetwork workshop; subsequently, the plan ismaintained and updated throughout the year where needed. The project management team reports backto the advisory board about the reached developments and objectives during the annual workshops.

Two public Websites have been established. One focuses on the users of the software (http://geonetwork-opensource.org), while the other one is dedicated to the developers (http://trac-osgeo.org/geonetwork). Both can be updated and maintained online by trusted members of the community. Theyprovide documentation, bug reporting and tracking, Wiki pages et cetera. A small part of the communityconnects through Internet Relay Chat (IRC) on a public #geonetwork2 channel. But most interactiontakes place on the user3 and the developer4 mailing lists.

During the 2006 workshop, the Project Advisory Board decided to propose the GeoNetwork opensourceproject as an incubator project to the newly founded Open Source Geospatial Foundation (OSGeo)5.This incubation process is currently ongoing but close to conclusions. The project Websites have beenmoved to servers accessible under the umbrella of the OSGeo foundation. Web pages have beenupdated to reflect the OSGeo principles and a source code review performed.

Source code is maintained in a publicly accessible code repository, hosted at an independent serviceprovider, SourceForge.net6 that hosts thousands of FOSS projects. Developers and users have fullaccess to all sections of the source code, while trusted developers can make changes in the repositoryitself. A special mailing list has been established to monitor changes in the code repository. This so-called "commit mailing list" delivers change reports by email to its subscribers.

The documentation is written in DocBook7 format to ensure versioning and support of multiple outputformats (e.g. HTML and PDF).

2 irc://irc.freenode.net/geonetwork3 https://lists.sourceforge.net/mailman/listinfo/geonetwork-users4 https://lists.sourceforge.net/mailman/listinfo/geonetwork-devel5 http://www.osgeo.org6 http://sourceforge.net/projects/geonetwork7 http://www.docbook.org



http://trac-osgeo.org/geonetwork

http://trac-osgeo.org/geonetwork

irc://irc.freenode.net/geonetwork

https://lists.sourceforge.net/mailman/listinfo/geonetwork-users

https://lists.sourceforge.net/mailman/listinfo/geonetwork-devel


http://sourceforge.net/projects/geonetwork

http://www.docbook.org

irc://irc.freenode.net/geonetwork

https://lists.sourceforge.net/mailman/listinfo/geonetwork-users

https://lists.sourceforge.net/mailman/listinfo/geonetwork-devel



http://www.docbook.org


2. Getting Started

Please make sure you have opened the home page of the GeoNetwork based catalogue.1

There are many different ways to search the catalogue for maps and other geographic data. This guidewill introduce you to the most popular search methods: default, advanced and by category. Whicheversearch you choose, remember that you will see results based on your privileges and assigned workgroup (Section 2.5, “Privileges, roles and user groups”).

Note that the term data in this application refers to datasets, maps, tables, documents, etc. that arelinked to the metadata of a specific record.

2.1 Default Search

The default search allows you to search text within the entire record, such as keywords of the metadataand/or geographic location.

Free text search. Type a search term in the What? field. You can type anything here (free text). Youcan use quotes around text to find exact combinations of words.

Text and operators (and, or, not) are not case sensitive. (See Figure 2.1, “The free text field”).

Figure 2.1. The free text field

Geographic search. For the geographic search, two options are available for selecting a particularregion to limit the search:

You can select a region from a predefined list (Figure 2.2, “The region field”);

1If you installed the software on your local machine and started it, the default URL is http://localhost:8080/geonetwork

http://localhost:8080/geonetwork

Getting Started


Figure 2.2. The region field

You can select your own area of interest in a more interactive way. A small global map is shown on thescreen from which you can drag and drop the frame of your location area. Just click on the button onthe upper right of the map screen (Figure 2.3, “Interactive Area Of Interest map”);

Figure 2.3. Interactive Area Of Interest map

Perform search. Both types of search, free text search and geographic search can be combined torestrict the query further.

Click the Search button to proceed and show the results. (Figure 2.4, “The Search button”).

Figure 2.4. The Search button

2.2 Searching by Categories

An additional way to search data within the GeoNetwork database, from the home page, is searchingby Category. A list of categories is provided to the user to identify data at a more generic level:Applications, Audio/Video, Case study and best practises, Conference proceedings, Datasets,Directories, Interactive resources, Maps and graphics, Other information resources, Photo.

To search only for maps, click on Maps and Graphics (Figure 2.5, “Search by Category”). A list of mapswill be displayed from which you may view details of every single map; just clicking on the Metadatabutton of the map you wish to review.

Getting Started


Figure 2.5. Search by Category

2.3 Advanced Search

The advanced search option (Figure 2.6, “Advanced search options”) works similarly to the defaultsearch. However, you can be more specific in your search criteria as it offers different elements to lookfor data, each of them focusing one of the following aspects: What?, Where?, When?

Figure 2.6. Advanced search options

To perform an advanced search , from the home page click Advanced just below the search bottom(see Figure 2.7, “Show advanced search options”).

Figure 2.7. Show advanced search options

In the WHAT? section the elements are all related to the data content. Through them, in addition tosearching only free keywords in the entire metadata content, you can also search directly in the title orabstract fields and add more keywords to customise your search further. You can also specify the levelof accuracy you wish to reach in performing your search (Figure 2.8, “"What" section in the Advancedsearch”).

• To search by Title, Abstract, Free Text, or Keyword(s) type any text into the respective field. Youcan enter information in one or multiple field(s). If you do not want to search by a given field, simplyleave it blank;

• You can choose the accuracy of your search, in terms of spelling words, from Precise = 1 toImprecise = 0.2, through 3 more consecutive steps which are equal to 0.8, 0.6, 0.4.

Getting Started


Figure 2.8. "What" section in the Advanced search

The WHERE? parameters, which are related to the spatial extent, allow you, as in the default search,either to select your own area of interest or to select a predefined region from the drop-down list. In thissection you can also type the geographic coordinates of a specific location that is not available from theabove list. (Figure 2.9, “"Where" section in the Advanced search”)

• To select your own area of interest, drag and drop the frame of your area on the global map usingthe appropriate tool on the bottom left of the map screen;

• To use free coordinates, type the lat-long geographic references in the appropriate fields around themap screen, without any limitation of decimal figures;

• To use the coordinates of a predefined region, select the region from the drop-down list.

Figure 2.9. "Where" section in the Advanced search

Whatever type of geographic search you decide to perform, in the Spatial search type field, you canchoose from different options: is, overlaps, encloses, is fully outside of (Figure 2.9, “"Where" sectionin the Advanced search”). If you use this field, be cautious as this limits your output data as follows:

• If you choose Spatial search type is “Country”, only maps for the selected country will be displayed.In other words, a city map within that country will not show in the output results.

• If you choose Spatial search type overlaps “Country”, all maps with the bounding box overlappingthat country will be displayed in the results, i.e. the neighbouring countries, the continent of which thatcountry is part of and the global maps.

• If you choose Spatial search type encloses “Country” you will get, in the output results, maps of thatcountry first and then all maps within its bounding box.

Getting Started


• Similarly, if you choose Spatial search type is fully outside of a selected region, only maps that followthat exact criteria will show in the output results.

The WHEN? section gives you the possibility to restrict your search in terms of temporal extent,indicating a specific range of time referred to the data creation or publication date (Figure 2.10, “"When"section in the Advanced search”).

• To specify a range of time, click on the date selector button next to From – To fields. Make use of thesymbols > and >> on top of the calendar to select the month and the year first and then click on theexact day; a complete date will be filled in using the following standard order: YY-MM-DD.

• To clean the time fields, simply click on the white cross on their right; the box Any will be automaticallyselected and the search will be performed without any restriction on the time period.

Figure 2.10. "When" section in the Advanced search

Finally, the advanced search allows you to apply further restrictions on the basis of additional parametersas data source, data categories and data format (Figure 2.11, “Other options in the Advanced search”).

• To limit your queries to only one Catalogue out of those made available by the installation throughthe harvesting process, highlight the catalogue of preference or just keep Any selected to search allsites. (See more info about data harvesting in Section 4 Chapter 1 of these guidelines).

• To search for data organised by Category, such as Applications, Datasets, etc., simply highlight thecategory you wish to search in from the related drop-down list, otherwise we suggest to leave thisfield in Any Category.

• You can search for Digital or Hard Copy maps. To search in one or the other, simply check the boxnext to the one you wish to search. If no box is checked, all content will be searched.

At last, you can customise the number of output results per page in the Hits Per Page field. Simplyhighlight the number of records to be displayed or leave the field set on the default number (10).

• Click the Search button.

Figure 2.11. Other options in the Advanced search

Getting Started


2.4 Analysing Search Results

The output of a search provides you a list of the metadata records that should fit your request. Foreach record, the result page shows the title, an abstract and the keywords. According to the privilegesthat have been set for each metadata, a maximum of four sections can be consulted, as shown below.(Figure 2.12, “Search results”)

Figure 2.12. Search results

1. Metadata: The metadata section describes the dataset (e.g.: citation, data owner, temporal/spatial/methodological information) and could contain links to other web sites that could provide furtherinformation about the dataset.

2. Download: Depending on the privileges that have been set for each record, when this button ispresent, the dataset is available and downloadable. The process for retrieving data is simple andquick by just clicking the download button (Figure 2.13, “A single search result”) or by using theproper link in the specific metadata section for distribution info in the full metadata view (Figure 2.14,“Available services related to the resource”).

Figure 2.13. A single search result

Figure 2.14. Available services related to the resource

Getting Started


3. Interactive Map: The map service is also optional. When this button is shown, an interactive mapfor this layer is available and, by default, it will be displayed on the map screen of the simple search.To better visualise the map through the map viewer, click on Open Map Viewer on the bottom leftof the map screen (Figure 2.15, “The interactive map viewer”).

Figure 2.15. The interactive map viewer

4. Graphic Overviews: There are small and large overviews of the map used to properly evaluateusefulness of the data, especially if the interactive map is not available. Simply click on the smallimage to enlarge it. (Figure 2.16, “Large preview image”)

Figure 2.16. Large preview image

2.5 Privileges, roles and user groups

GeoNetwork uses a system of Privileges ,Roles and User groups.

Getting Started


There are no restrictions for users to search and access public information in a GeoNetworkopensource based catalogue. To get access to restricted information or advanced functionality, anaccount to log in is required. This should be provided by the GeoNetwork administrator.

To log in, simply go to the home page and enter your username and password in the dedicated fieldson the top right corner, then click the login button. (See Figure 2.17, “Login”)

Figure 2.17. Login

Privileges. Depending on the privileges set on a metadata record and on your role as an authenticateduser, you will be able to read about a resource and download or interactively browse data related tothat resource.

Roles. Users with an Editor role can create, import and edit metadata records. They can also uploaddata and configure links to interactive map services.

User groups. Every authenticated user is assigned to a particular work group and is able to viewdata within that work group.


3. Viewing and Analysing the Data

Once you have completed your search, you view details of a particular record by clicking on theMetadata button.

The metadata profiles used by GeoNetwork opensource to present and describe geographic data andgeneral documents stored in the catalogue are based on the International Standard ISO 19115:2003,encoded according to the implementation schema 19139:2007, the FGDC and the internationalstandard Dublin Core.

In this guide the ISO 19139 metadata implementation will be described in details since it is alsosuggested as profile for the creation of new metadata records.

3.1 Meta Data Description

The metadata ISO 19139 profile used by GeoNetwork opensource to describe the geographic data andservices is based on the ISO standard 19115:2003 and provides information related to the identification,the maintenance and constraints, the spatial and temporal extent, the spatial representation andreference, the quality and distribution of a geographic dataset.

The metadata profile is organised in sections and the most important, illustrated in Figure 3.1,“Main metadata sections”, are the: Identification Section, Distribution Section, Reference SystemSection, Data Quality Section and Metadata Section. These sections are described here in details.

Figure 3.1. Main metadata sections

Identification Section

This section includes information on the citation of the resource (title, date of creation or publication,edition, presentation form), the abstract, the purpose and the present status of the resource thatcan be defined among the options: completed, historical archive, obsolete, ongoing, planned, requiredor under development. (Figure 3.2, “Identification information”).

Viewing and Analysing the Data


Figure 3.2. Identification information

This section also contains information about the person or organisation responsible for the data andwho is considered to be a point of contact for the resource i.e. the dataset owner, originator, distributor,publisher, etc. and it provides information on data maintenance i.e. annually, monthly, daily, notplanned, as needed, etc. (Figure 3.3, “Point of Contact”)

Figure 3.3. Point of Contact



Elements for keywords and for describing restrictions on data access and use are also included inthis section in addition to spatial representation info like data type (vector, raster, text table, etc.)(Figure 3.4, “Descriptive keywords”).

Figure 3.4. Descriptive keywords

The identification section provides information about the scale, the language and character set usedwithin the resource and the list of ISO categories through which your map could be classified (Figure 3.5,“Scale and other data properties”).

Figure 3.5. Scale and other data properties

Finally, the temporal and spatial extent are also defined in this section. The temporal extent is definedthrough the starting and ending date of data validation (Figure 3.6, “ Temporal extent ”);

Figure 3.6. Temporal extent

The spatial extent of the interested area is defined through geographic coordinates or through theselection of a country or region from a predefined list (Figure 3.7, “ Geographic bounding box ”). Freetext supplemental information can be added to complete the data identification section.



Figure 3.7. Geographic bounding box

Distribution Section

This section provides metadata elements for accessing other useful on-line resources availablethrough the web. The distribution elements allow for on-line access using an URL address or similaraddressing scheme and provide the protocol for the proper connection for accessing geographic dataor any other types of digital documents using the download function. Furthermore, it is possible to linka metadata with a predefined map service through the on line resource and see the map interactively(Figure 3.8, “Distribution information”).

Figure 3.8. Distribution information

Reference System Section

The Spatial Reference System section defines metadata required to describe the spatial referencesystem of a dataset. It contains one element to identify the name of the reference system used(Figure 3.9, “Reference system”). Using elements from the advanced form, this section may bemodified to provide more details on data projection, ellipsoid and datum. Note that if this informationis provided, a reference system identifier is not mandatory.



Figure 3.9. Reference system

Data Quality Section

The Data Quality section provides a general assessment of the quality of the data. It describes thedifferent hierarchical levels of data quality, namely a dataset series, dataset, features, attributes,etc. This section also contains information about sources of the input data, and a general explanationof the production processes (lineage) used for creating the data (Figure 3.10, “Data quality”).

Figure 3.10. Data quality

Metadata Information Section

This section contains information about the metadata itself: the Universally Unique Identifier (UUID)assigned to the record (this is the ‘File identifier’), language and character set used, date of last edit(‘Date stamp’) and the metadata standard and version name of the record. It also contains informationon the metadata author responsible for the metadata record; this person can also be a point of contactfor the resource described. Information on the Metadata author is mandatory (Figure 3.11, “Metadataproperties”).

Figure 3.11. Metadata properties


4. Adding new Data and InformationThis section guides you through the process of adding new records (new data with information) into theGeoNetwork catalogue using either the online metadata editor or the advanced metadata insert tool,based on XML documents. In both cases you will use the template system, add thumbnails, uploaddata, link to services and set access privileges to the metadata and data.

To add or edit data and metadata, you must be registered as an Editor into the work group you wantto add records to. Contact your administrator if you are not a registered editor for your work group.

For the metadata creation using the online editor, GeoNetwork provides a set of simplified metadatatemplates based on the cited standards: ISO, FGDC and DC. The templates for vector and raster basedon the ISO 19139 are the preferred ones since they are devised in a way that hides the complexity ofthe ISO19115 standard in the default view. At the same time those templates are extensible with newelements to fit specialised needs through the advanced view.

To produce a good metadata record, always try to gather as much details as possible on the resourcethat you want to describe taking into account the metadata elements that have been presented in theprevious chapter. The next step is to fill out properly the fields provided by the metadata templates,while at the same time avoiding duplication of information throughout the form.

The most important, mandatory fields that should not be skipped while compiling a standard basedmetadata record are the following:

1. Title

2. Date of Creation or Publication

3. Abstract

4. Language used for documenting data

5. Topic Category

6. Scale

7. Maintenance and Update Frequency

8. Metadata Author

9. Language Used for Documenting Metadata

In addition to the main mandatory fields, we recommend you to fill out these optional but critical fields(if information is available):

1. Purpose

2. Keywords

3. Presentation Form

4. Status

5. Spatial Representation Type

6. Geographic Location

7. Reference System Info

Adding new Data and Information


8. Temporal Extent

9. Data Quality Info

10.Access and Use Constraints

11.Point of Contact

12.Distribution Info: Online Resources

You should also prepare an image of your data that is required to be displayed in search results asthumbnail.

Next section will guide you through the process of metadata creation using the online editor.

4.1 Creating a New Record using the Metadata Editor on line

1. In the home page, click on the Administration Tab.

2. Select New Metadata from the List of the admin page.

3. Select the metadata standard Template, if possible, using the preferred ones (Figure 4.3, “Templateselection”). GeoNetwork opensource comes by default with support for three metadata standards,ISO19139, FGDC and Dublin core. For the ISO standard, two templates have been developed; onefor vector and one for raster data. Both contain a relevant set of elements to describe the respectivetypes of data. More templates can be developed online.

4. Select the Group the metadata will belong to. These are the groups authorised to add metadata toby your administrator.

5. Click on Create.

The steps in more details

1. Enter your username and password and click on the login button (Figure 4.1, “Login”). The systemwill identify you and assign the correct privileges to work with.

Figure 4.1. Login

2. Open the Administration page by clicking the Administration button in the banner and then click onthe New metadata link (Figure 4.2, “Administration panel”).

Figure 4.2. Administration panel



3. From the metadata creation page, select the metadata standard to use from the dropdown list(Figure 4.3, “Template selection”)

Figure 4.3. Template selection

4. After selecting the correct template, you should identify which group of users the metadata will belongto (Figure 4.4, “Group selection”) and finally click on Create.

Figure 4.4. Group selection

A new metadata form based on the selected template will be displayed for you to fill out.

Switching Editing Views from Default to Advanced to XML View

Once you create a new record, you can choose between Default, Advanced or XML View. To switchview, simply click on the view you want to switch to on the left column of the page. The view in bold isthe view you are currently using (Figure 4.5, “Metadata view options”).

Figure 4.5. Metadata view options

In the previous chapter you have analysed the metadata structure as it is presented in the DefaultView. A selection of the main fields from different categories of information is shown in one single view.The minimum set of metadata required to serve the full range of metadata applications (data discovery,determination of data fitness for use, data access, data transfer and use of digital data) is defined here,along with optional metadata elements to allow for a more extensive standard description of geographicdata, if required. However, if should be there a need to add more metadata elements, you can switchto the advanced view at any time while editing.

In the Advanced View, the ISO profile offers the possibility to visualise and edit the entire metadatastructure organised in sections accessible through tabs from the left column. You can use this view towrite more advanced metadata descriptions or templates to fit specialised needs. (Figure 4.6, “Advancedview”)



Figure 4.6. Advanced view

The XML View shows the entire content of the metadata in the original hierarchical structure; differentcolours allow to distinguish between an element's name and its value. The XML structure is composedof tags and to every tag must correspond a closing tag (Figure 4.7, “XML view”). The content is entirelycontained withing the two, i.e.

<gmd:language>

<gco:CharacterString>eng</gco:CharacterString>

</gmd:language>

Figure 4.7. XML view

Nevertheless, the use of the XML view requires some knowledge of the XML language.

Both the Default and the Advanced Views are composed of mandatory, conditional andoptional metadata fields. The meaning of mandatory and optional is fairly intuitive; the mandatory



fields are required, like Title and Abstract for instance, whereas the optional fields can beprovided but are not fundamental, depending on the metadata author. The conditional fields may beconsidered mandatory under certain circumstances: essentially a conditional requirement indicates thatthe presence of a specified data element is dependent on the value or presence of other data elements inthe same section. For instance, the Individual name metadata element of the Point of Contact,which is a conditional element of the Identification section, becomes mandatory if another element ofthe same section, organisation name or Position name is not already defined (Figure 4.8, “Pointof Contact”).

Figure 4.8. Point of Contact

The mandatory fields as well as those highly recommended are flagged with red asterisk [*]. Thestandard definition for each field can be read by passing the mouse on the element name.

The Default View is the preferred view as it provides a selection of the available metadata elements,facilitating both the user and the editor in reading and editing a metadata record, and at the same timeit ensures that a geospatial data can be properly described, through:

• the minimum set of metadata required to serve the full range of metadata applications (data discovery,determination of data fitness for use, data access, data transfer, and use of digital data);

• optional metadata elements - to allow for a more extensive standard description of geographic data,if required;

• a method for extending metadata to fit specialised needs.

Using basic commands of the editor

Fields are either free text fields or drop down lists. Free text means you can type any text into thatfield. Drop down lists allow you to select only one option from the list. You can add multiple fields of the



same kind by clicking on the [+] symbol next to the element. Every new field that you will add in theadvanced view will then be visible in the default view. You can also delete existing fields by clicking onthe [x] symbol next to the element. Clearly, mandatory fields cannot be deleted. One example of theneed to add multiple fields can arise if the content of your dataset has some text written in two differentlanguages (Figure 4.9, “Describing multilingual data”).

Figure 4.9. Describing multilingual data

4.2 Entering Metadata for your Map

As we mentioned in the introduction to this guide, GeoNetwork opensource provides tools to describeany type of geographic data (vector layers, raster, tables, map services, etc.) as well as generaldocument like reports, projects, papers, etc. For the purpose of this Quick Start Guide, an example ofrequired and useful metadata elements to properly describe a thematic map will be provided hereafter.You should gather as much information as possible to identify and understand the map’s resource andcharacteristics you want to describe. Use the default view to start. If necessary, you can always switchto advanced view or come back later and edit the record with the additional information collected.

Entering Metadata For Your Map

Please follow these steps to enter your map's metadata. Note that we will only go through the fieldsthat have been identified as compulsory (i.e. those fields marked with the asterisk [*], mandatory orhighly recommended).

Title *: Under the Identification Info field, give your map a name. There will be a default name of yourdata. Use free text to describe your map here.

Date *: Indicate the exact date of creation, publication or revision on your map.

Presentation Form: Specify the type of presentation, i.e. digital, hard copy, table, etc.

Abstract *: Enter some description of the map.

Purpose: Enter a short summary of the purposes for your map to be developed.

Status: Specify the status of your map within the following options: completed, historical archive,obsolete, ongoing, planned, required, under development.

Point of Contact: Enter all mandatory information and others you have at hand for the contact ofthe person(s) associated with this resources of the map. Note that some fields are only conditionallymandatory, such as organisation Name if Individual Name and Position are not entered.



Maintenance and update frequency *: Specify the frequency with which you expect to make changesand additions to your map after the initial version is completed. If any changes are scheduled you canleave As Needed selected from the drop-down list.

Descriptive Keywords: Enter keywords that describe your map. Also specify the type of keyword youare entering, i.e. place, theme, etc. Remember that you can add another keyword field if you need toadd different types of keywords.

Access Constraints: Enter an access constraint here, such as a copyright, trademark, etc. to assurethe protection of privacy and intellectual property.

User Constraints: Enter a user constraint here to assure the protection of privacy and intellectualproperty.

Other Constraints *: Enter other constraint here to assure the protection of privacy and intellectualproperty. Note that this field is conditionally mandatory if Access and Use constraints are not entered.

Spatial representation type: Select, from the drop-down list the method used to spatially representyour data. The options are: vector, grid, text table, stereo model, video.

Scale Denominator *: Enter the denominator for an equivalent scale of a hard copy of the map.

Language *: Select the language used within your map

Topic category *: Specify the main ISO category/ies through which your map could be classified (seeAnnex for the complete list of ISO topic categories).

Temporal Extent *: Enter the starting and ending date of the validity period.

Geographic Bounding Box *: Enter the longitude and latitude for the map or select a region from thepredefined drop-down list. Make sure you use degrees for the unit of the geographic coordinates asthey are the basis for the geographic searches.

Supplemental Information: Enter any other descriptive information about your map that can help theuser to better understand its content.

Distribution Info: Enter information about the distributor and about options for obtaining your map.

Online Resource: Enter information about online resources for the map, such as where a user maydownload it, etc. This information should include a link, the link type (protocol) and a description of theresource.

Reference System Info: Enter information about the spatial reference system of your map. The defaultview contains one element to provide the alphanumeric value identifying the reference system used.GeoNetwork opensource uses the EPSG codes which are numeric codes associated with coordinatesystem definitions. For instance, EPSG:4326 is Geographic lat-long WGS84, and EPSG:32611 is "UTMzone 11 North, WGS84". Using elements from the advanced view, you may add more details on dataprojection, ellipsoid and datum. Note that if this information is provided, a reference system identifieris not mandatory.

Data Quality: Specify the hierarchal level of the data (dataset series, dataset, features, attributes,etc.) and provide a general explanation on the production processes (lineage) used for creatingthe data. The statement element is mandatory if the hierarchical level element is equal to dataset or



series. Detailed information on completeness, logical consistency and positional, thematic andtemporal accuracy can be directly added into the advanced form.

Metadata Author *: Provide information about the author of the map, including the person’s name,organisation, position, role and any other contact information available.

After completion of this section, you may select the Type of document that you are going to save in thecatalogue. You have three options: Metadata, Template, Sub-template. By default Metadata is set up.

When done, you may click Save or Save and Close to close the editing session.

Creating a Thumbnail

Next, you need to create a graphic overview of your map which will be for a double purpose; as smallthumbnail will be displayed in search results and as large thumbnail with much more details, to allowusers to properly evaluate the data usefulness. As for the latest, the image that you will use as sourceshould be a significant reproduction of the real dataset, possibly inclusive of the legend.

To create a thumbnail, go to the editing menu for your map. If you are no longer in editing mode, retrievethe map from one of the search options then click on Edit. Then follow these simple steps:

• From the editing menu, click on the Thumbnails button on the top or bottom of the page. (Figure 4.10,“The thumbnail wizard button”)

Figure 4.10. The thumbnail wizard button

• You will be taken to the Thumbnail Management wizard (Figure 4.11, “Thumbnail wizard”).

• To create a small or large thumbnail, click on the Browse button next to either one. It is recommendedthat you use 180 pixels for small thumbnails and 800x600 for large thumbnails. Using the ‘Largethumbnail’ option allows you to create both a small and large thumbnail in one go.

• You can use GIF, PNG and JPEG images as input for the thumbnails.

• A pop up window will appear allowing you to browse your files on your computer. Select the file youwish to create a thumbnail with by double-clicking on it.

• Click on Add.

• Your thumbnail will be added and displayed on the following page.



• You can then click on Back to Editing and save your record (Figure 4.12, “Completed thumbnailwizard”).

Figure 4.11. Thumbnail wizard

Figure 4.12. Completed thumbnail wizard

Linking data for download

Finally, you can upload the dataset stored on your local computer and then create a link between dataand related description. Files in whatever format can be uploaded: doc, PDF, images, vector layers,etc. For the latter the distribution in a compressed file is recommended. You can include the vectordata, the legend, any documentation that can help the interpretation of the data, related reports, detaileddescriptions of the data processing, base data used to create the dataset specified and/or other relevantinformation. Follow these guidelines for uploading datasets:



• Make sure the total size of the compressed file is reasonable (less than 50 MB). Should your data bebigger than 50MB, consider a different mechanism to serve this data, e.g. through an FTP or HTTPserver and than link the resource through an online resource ‘Web address (URL)’.

• You can create several smaller files when appropriate and upload them sequentially.

• You add the size of the file at the end of the description field.

To Upload a Dataset, follow these steps (Figure 4.13, “An online resource”):

1. The URL field can be left empty when uploading a file. The system will automatically fill this field out;

2. Select the correct protocol to be used. If you do not see the buttons to browse and upload when Filefor download is selected, save the metadata and return to the upload section. Both buttons shouldappear;

3. Provide a short description of the data;

4. Click the Browse button and navigate to the folder where the file to be released is stored. Consider ifyou want to upload multiple files as one unique zip file or as multiple separate downloads. It is a goodidea to add additional documentation with the datasets that provide the user with information relatedto the data described. Remind: the size of a single file to upload can't exceed 100 Megabytes;

5. Click Upload and then Save.

Figure 4.13. An online resource

Assigning Privileges for a Map

As an important step of entering metadata to your map, you need to assign privileges for each map.This means that you will identify which work groups have which privileges, i.e. view, download, etc. foryour particular map.

For instance, you can define if the information and related services is visible to all (Internet users) orjust to internal users only (Intranet). Privileges are assigned on a per group basis. Depending on theuser profile (Registered User, Editor, Content Reviewer, User Administrator and Administrator) accessto these functions may differ on a per user basis.

To assign privileges for your map, follow these steps:

• Find your map by using the search option. Whether you have multiple or single results from the search,on top of the individual record or next to the record you will always see a row of buttons including aPrivileges button (Figure 4.14, “The editing toolbar with Privileges button”).



Figure 4.14. The editing toolbar with Privileges button

• Click on the Privileges button. This will open the privileges settings window. You can assign certainprivileges to specific groups by selecting or deselecting them from this page. Simply click on the smallbox next to the privilege to place or remove a checkmark. Set All and Clear All buttons allow you toplace and remove the checkmarks all at once (Figure 4.15, “Privileges settings”).

Figure 4.15. Privileges settings

Below is a brief description for each privilege to help you identify which ones you should assign to whichgroup(s).

Publish: Users in the specified group/s are able to see the map, i.e. if searching with matching criteria.

Download: Users in the specified group/s are able to download the map.

Interactive Map: Users in the specified group/s are able to get an interactive map. The interactive maphas to be created separately using a Web Map Server, which is part of the GeoNetwork opensourceapplication.

Featured: When selected, the map is placed in the Features Maps of the home page and it appearsthere randomly.

Editing: When selected, the editors of the group(s) concerned can edit the respective metadata record.

Notify: A notification email is send to the emailaddress of the group, informing that the map has beendownloaded.



Assigning Categories for a Map

As a final step to entering metadata for a map, you should assign categories for it. The assignedcategories will determine the categories the map will display under on the home page. To assigncategories for a map, follow these steps:

• Find your map by using the search option. Whether you have multiple or single results from yoursearch, on top of the individual record or next to the record, you will always see a row of buttonsincluding a Categories button.

• Click on the Categories button. This will open the category selection window. You can assign one ormultiple categories selecting or deselecting them from this page. Simply click on the small box nextto the category to place or remove a checkmark. (Figure 4.16, “Category management”)

Figure 4.16. Category management

4.3 Uploading a New Record using the XML Metadata Insert Tool

A more advanced procedure to upload a new metadata record in the GeoNetwork system is usingan XML document. This procedure is particularly useful for users who already have metadata in XMLformat, for instance created by some GIS application. To this regard, it has to be noted that the metadatamust be in one of the standards used by GeoNetwork: ISO19115, FGDC and Dublin Core.

To start the metadata uploading process through the XML Metadata Insert tool, you should log in (seeStep. 1. in paragraph 7.1.1) and select the appropriate option from the Administration page (Figure 4.17,“Administration panel”).



Figure 4.17. Administration panel

The main part of the page Import XML Formatted Metadata that is displayed (Figure 4.18, “XMLmetadata import tool”) is the Metadata text area, where the user can paste the XML metadata to import.Below this, there is the Type choice, which allows you select the type of record that you are goingto create (Metadata, Template and Subtemplate). Then you can apply a stylesheet to convert yourmetadata input from ArcCatalog8 to ISO1915 or from ISO19115 to ISO19139, if required. Otherwise youcan just leave none selected. The Destination schema list provides you with four options to choosethe final standard layout for your metadata (ISO19115, ISO19139, FGDC and Dublin Core). Finally youshould select the Group as main group in charge of the metadata and the Category that you want toassign to your metadata. By clicking the Insert button the metadata is imported into the system; pleasenote that all links to external files, for instance to thumbnails or data for download, have to be removedfrom the metadata input, to avoid any conflict within the data repository.

Figure 4.18. XML metadata import tool



If your metadata is already in ISO19115 format, the main actions to be performed are the following(Figure 4.19, “XML metadata import 2”):

1. Paste the XML file that contains the metadata information in the Metadata text area;

2. Select Metadata as type of record that you are going to create

3. Select the metadata schema ISO19139 that will be the final destination schema;

4. Select the validate check box if you want your metadata to be validated according to the relatedschema.

5. Select the group in charge of the metadata from the drop down list;

6. Select Maps and Graphics from the list of categories;

7. Click the Insert button and the metadata will be imported into the system.

Figure 4.19. XML metadata import 2


5. Metadata in Spatial Data Management

5.1 What is Metadata?

Metadata, commonly defined as “data about data” or "information about data", is a structured set ofinformation which describes data (including both digital and non-digital datasets) stored in administrativesystems. Metadata may provide a short summary about the content, purpose, quality, location of thedata as well as information related to its creation.

5.2 What are Metadata Standards?

Metadata standards provide data producers with the format and content for properly describing theirdata, allowing users to evaluate the usefulness of the data in addressing their specific needs.

The standards provide a documented, common set of terms and definitions that are presented in astructured format.

5.3 Why do we need Standardised Metadata?

Standardised metadata support users in effectively and efficiently accessing data by using a commonset of terminology and metadata elements that allow for a quick means of data discovery and retrievalfrom metadata clearinghouses. The metadata based on standards ensure information consistency andquality and avoid that important parts of data knowledge are lost.

5.4 Geographic Information Metadata Standard

Geographic data, which can be defined as any data with a geographic component, is often produced byone individual or organisation, and may address the needs of various users, including information systemanalysts, programme planners, developers of geographic information or policy makers. Proper standarddocumentation on geographic data enable different users to better evaluate the appropriateness of datato be used for data production, storage, update.

The metadata standards supported by GeoNetwork opensource are the ISO 19115:2003 - approvedby the international community in April 2003 as a tool to define metadata in the field of geographicinformation - and the FGDC - the metadata standard adopted in the United States by the FederalGeographic Data Committee. In addition, GeoNetwork opensource supports also the internationalstandard Dublin Core for the description of general documents.

This ISO Standard precisely defines how geographic information and related services should bedescribed, providing mandatory and conditional metadata sections, metadata entities and metadataelements. This standard applies to data series, independent datasets, individual geographic featuresand feature properties. Despite ISO 19115:2003 was designed for digital data, its principles can beextended to many other forms of geographic data such as maps, charts, and textual documents as wellas non-geographic data.

The underlying format of an ISO19115:2003 compliant metadata is XML. GeoNetwork uses the ISOTechnical Specification 19139 Geographic information - Metadata - XML schema

implementation for the encoding of this XML.

Metadata in Spatial Data Management


5.5 Metadata profiles

GeoNetwork supports multiple metadata profiles. Profiles can take the form of Templates that you cancreate using the metadata editor. Using the Advanced view of the editor, virtually all of the metadataelements are accessible to the user.

Support for extensions to a metadata standard can also be achieved relatively quick by an experiencedXML/XSL software engineer.

5.6 Transition between metadata standards

With the ISO19115:2003 Metadata standard for Geographic Information now being the preferredcommon standard, many have a need to migrate legacy metadata into the new standard.

GeoNetwork provides import (and export) functionality and has a number of transformers in place. It isan easy process for a system administrator to install custom transformers based on XSLT.


6. Installing the software

6.1 New version - New functionalities

The new GeoNetwork opensource comes with substantial upgrades of different components for amore intuitive and responsive user-system interaction. Web 2.0 technologies have been adopted, inparticular AJAX techniques, to allow for more interactive and faster services in the web interface andfor the integration of the existing web map viewer in the home page. Similar functionalities have beenimplemented in the administrative part of the system, to provide an easier access to the configurationpages related to site settings, catalogue harvesting, scheduling and maintenance.

The search interface has been completely overhauled to provide highly interactive searchingcapabilities. Furthermore, the new version of GeoNetwork embeds GeoServer as map server. Userscan now not only overlay OGC web map services available on the web, but also create their own mapservices for other users to browse without having to download additional plugins. Maps created withweb map services can be now saved as PDF and sent to others.

The metadata catalogue handles the latest ISO19115:2003 geographic metadata format based on theISO19139:2007 schemas, as well as the older ISO19115 final draft format, FGDC and Dublin Core. Themetadata editor is able to handle the majority of these complex standards, providing default, advancedand XML editing online tools.

The new version has a number of different harvesting interfaces allowing users to connect their ownserver to many other catalogues around the world. This is the result of the implementation of the opensource reference for the web catalogue services according to OGC specifications. Harvesting in thenew version is fully compatible with GeoNetwork 2.0 and higher nodes.

We have added advanced online and offline administration functionalities to configure, backup andmigrate the application. We have also added a convenient import and export format "MEF" or MetadataExchange Format, that allows the users to move metadata, previews and even data in a convenientsingle file. GeoNetwork can be easily expanded with plugins to export/import metadata to/from othersoftware supporting MEF.

Figure 6.1. Standard home page of GeoNetwork opensource

Installing the software


6.2 Where do I get the installer?

You can find the software on the Internet at the GeoNetwork opensource Community website1. Thesoftware is also distributed through the SourceForge.net Website at http://sourceforge.net/projects/geonetwork.

Use the platform independent installer (.jar) if you need anything more than a plain Windows installation.

6.3 System requirements

GeoNetwork can run either on MS Windows, Linux or Mac OS X.

Some general system requirements for the software to run without problems are listed below:

Processor: 2 GHz or higher

Memory (RAM): 1 GB or higher

Disk Space: 200 MB minimum. However, it is suggested to have a minimum of 1 GB of free disk space.Additional space is required depending on the amount of spatial data that you expect to upload intothe internal geodatabase.

Other Software requirements: A Java Runtime Environment (JRE 1.5.0). For server installations,Apache Tomcat and a dedicated JDBC compliant DBMS (MySQL, Postgresql, Oracle) can be usedinstead of Jetty and McKoiDB respectively.

Additional Software

The software listed here is not required to run GeoNetwork, but can be used for custom installations.

1. MySQL DBMS v5.5+ (All)2

2. Postgresql DBMS v7+ (All)2

3. Apache Tomcat v5.5+ (All)2

4. Druid v3.8 (All)2 to inspect the database

Supported browsers

GeoNetwork should work normally with the following browsers:

1. Firefox v2+ (All)2

2. Internet Explorer v6+ (Windows)

3. Safari v3+ (Mac OS X Leopard)2

1 http://geonetwork-opensource.org







6.4 How do I install GeoNetwork opensource?

Before running the GeoNetwork installer, make sure that all system requirements are satisfied, and inparticular that the Java Runtime Environment version 1.5.0 is set up on your machine.

On Windows

If you use Windows, the following steps will guide you to complete the installation (other FOSS willfollow):

1. Double click on geonetwork-install-2.4.0.exe to start the GeoNetwork opensource desktop installer

2. Follow the instructions on screen (Figure 6.2, “Installer”). You can choose to install sample data,install the embedded map server (based on GeoServer3 and the CSW 2.0.2 test client. Developersmay be interested in installing the source code and installer building tools. Full source code can befound in the GeoNetwork SubVersion code repository.

3. After completion of the installation process, a 'GeoNetwork desktop' menu will be added to yourWindows Start menu under 'Programs'

4. Click Start > Programs > GeoNetwork desktop > Start server to start the GeoNetwork opensourceWeb server. The first time you do this, the system will require about 1 minute to complete startup.

5. Click Start > Programs > GeoNetwork desktop > Open GeoNetwork opensource to start usingGeoNetwork opensource, or connect your Web browser to http://localhost:8080/geonetwork/

Figure 6.2. Installer

Figure 6.3. Packages to be installed

http://www.geoserver.org

http://localhost:8080/geonetwork/



Installation using the platform independent installer

If you downloaded the platform independent installer (a .jar file), you can in most cases start the installerby simply double clicking on it.

Follow the instructions on screen (see also the section called “On Windows”).

At the end of the installation process you can choose to save the installation script (Figure 6.4, “Savethe installation script for command line installations”).

Figure 6.4. Save the installation script for command line installations

Command line installation

If you downloaded the platform independent installer (a .jar file), you can perform command lineinstallations on computers without a graphical interface. You first need to generate an install script (seeFigure 6.4, “Save the installation script for command line installations”). This install script can be editedin a text editor to change some installation parameters.

To run the installation from the command line, issue the following command in a terminal window andhit enter to start:

java -jar geonetwork-install-2.4.0-0.jar install.xml

[ Starting automated installation ]

[ Starting to unpack ]

[ Processing package: Core (1/3) ]

[ Processing package: Sample metadata (2/3) ]

[ Processing package: GeoServer web map server (3/3) ]

[ Unpacking finished ]

[ Writing the uninstaller data ... ]

[ Automated installation done ]



You can also run the installation with lots of debug output. To do so run the installer with the flag -DTRACE=true:

java -DTRACE=true -jar geonetwork-install-2.4.0-0.jar

Part II. Administrator GuideThis part explains how to configure and administer GeoNetwork based applications using its web anddesktop tools. The tools are subdivided into 2 categories:

1. Web tools: these are directly accessible from the web interface and allow the user to tune almostall aspects of GeoNetwork.

2. The GAST tool: this application provides special functions that cannot be executed while GeoNetworkis running. It also performs special tasks that are better done in a separate tool.


7. Basic configuration

7.1 System configuration

Most of the GeoNetwork system configuration parameters can be changed using the web interface.Those parameters that cannot be changed through the web interface can usually be changed using theGAST application.

Important

Configuration of these parameters is critically important for a proper functioning of theGeoNetwork catalogue in an operational context. Failing to properly change these settingsmay result in a system that does not function as expected. For example, downloads mayfail to be correctly processed, or metadata harvesting from other servers may not work.

To get to the System configuration, you must be logged on as administrator first. Open the Administrationpage and select System configuration (Figure 7.1, “The link to the System configuration page”. The linkis surrounded with a red rectangle).

Important

New installations of GeoNetwork use admin for both username and password. It isimportant to change this from the Administration page once you logged on!

Figure 7.1. The link to the System configuration page

Clicking the page’s link you will get the set of parameters that you can change (Figure 7.2, “Theconfiguration options”). Here follows a detailed description of them:

Basic configuration


Figure 7.2. The configuration options

At the bottom of the page there are some buttons with the following purpose:

Back Simply returns to the main administration page. Save Saves the current options. If some optionsare invalid, the system will show a dialogue with the wrong parameter and will focus its text field on thepage. Once the configuration is saved a success dialogue will be shown. Refresh This button simplyrefreshes the displayed options taking the new values from the server. This can be useful if some optionsget changed dynamically (for example by another user).

Public host and port usage

Up to now, the server’s host and port are used in these cases:

1. During an editing session, when adding data links to a metadata. The host and port will be used tobuild download links to store inside the metadata.

2. During CSW requests. The GetCapabilities operation returns an XML document with HTTP links tothe CSW services. These links are dynamically built using the host and port values.

Basic configuration


Site General site parameters.

Name The name of the GeoNetwork’s installation. This name will be used to identify the node inoperations like the harvesting.

organisation The organisation the node belongs to. Just for informative reasons.

Server Here you have to enter the address of your GeoNetwork’s node. This address is importantbecause it will be used to access the node.

Host The node’s address or IP number. If your node is publicly accessible from the Internet, you haveto use the machine’s domain/address. If your node is hidden into your private network and you have afirewall or web server that redirects incoming calls to the node, you have to enter the public address ofthe firewall or web server. A typical configuration is to have an Apache web server on address A that ispublicly accessible and redirects the requests to a Tomcat server on a private address B. In this caseyou have to enter A in the host parameter.

port The node’s port (usually 80 or 8080). If the node is hidden, you have to enter the port on the publicfirewall or web server.

Intranet A common need for an organisation is to discriminate between internal anonymous users (usersthat access the node from within the organisation) and external ones (users from the Internet). Node’sadministrators can specify different privileges for internal and external anonymous users and, in orderto do so, they have to specify the parameters of the internal network.

Network The internal network’s address in IP form.

Netmask The network’s mask.

Catalogue services (CSW, Z39.50)

OGC CSW configuration

When using Open Geospatial Catalogue Service for the Web (OGC-CSW) service, a client will askfor a description of the service. This description, provided in the form of a GetCapabilities document,describes the main service's properties. The administration section allows configuration of the followingCSW properties:

Enable: This option allows you to start or stop the CSW services. If this option is disabled, othercatalogues cannot connect to the node using CSW protocol.

Contact: The main contact who is defined in the GetCapabilities document of the CSW service. Thiscontact is one user of the catalogue.

Title: The title of your CSW service.

Abstract: The abstract of your CSW service.

Fees

Access constraints

The service description also contains the main keywords of the catalogue. The list of keywords isgenerated by the catalogue based on metadata content.

Basic configuration


Inserted metadata is public: If this setting is selected the metadata inserted using CSW transaction isviewable for all users. This setting is disabled by default.

Z39.50 configuration

Z39.50: GeoNetwork can act as a Z39.50 server, which is an OGC communication protocol to queryand retrieve metadata.

Enable: Check this option to start the Z39.50 submodule. Please, notice that GeoNetwork must berestarted in order to make this change active.

port: This is the port on which GeoNetwork will be listening for incoming Z39.50 requests. Usually, thevalue of 2100 is a standard one, but to have multiple GeoNetwork nodes on the same machine youhave to change this value in order to avoid port conflicts between the different nodes.

Proxy configuration

Proxy: In some occasions (like harvesting) GeoNetwork must be able to connect to remote sites andthis may be denied if an organisation uses proxy servers. In this cases, GeoNetwork must be configuredto use the proxy server in order to route outgoing requests.

Figure 7.3. The proxy configuration options

Host: The proxy’s name or address to use (usually an IP address).

Port: The proxy’s port to use.

Username (optional): a username should be provided if the proxy server requires authentication.

Password (optional): a password should be provided if the proxy server requires authentication.

Email & notification

Feedback GeoNetwork can sometimes send email, for example if a metadata is downloaded or if a userprovides feedback using the online form. You have to configure the mail server GeoNetwork should usein order to enable it to send email.

Figure 7.4. The mail server configuration options

Email: This is the email address that will be used to send the email (the From address).

SMTP host: the mail server address to use when sending email.

SMTP port: the mail server SMTP port (usually 25).

Basic configuration


Removed metadata

Defines the directory used to store a backup of metadata and data after a delete action. This directoryis used as a backup directory to allow system administrators to recover metadata and possibly relateddata after erroneous deletion. By default the removed directory is created under the data folder

Authentication

In this section you define the source against which GeoNetwork will authenticate users and passwords.

Figure 7.5. Authentication configuration options

By default, users are authenticated against info held in the GeoNetwork database. When theGeoNetwork database is used as the authentication source, the user self-registation function can beenabled.

You may choose to authenticate logins against either the GeoNetwork database tables or LDAP (thelightweight directory access protocol) but not both. The next section describes how to authenticateagainst LDAP.

In addition to either of these options, you may also configure other authentication sources. At present,Shibboleth is the only additional authentication source that can be configured. Shibboleth is typicallyused for national access federations such as the Australian Access Federation. Configuring shibbolethauthentication in GeoNetwork to use such a federation would allow not only users from a local databaseor LDAP directory to use your installation, but any user from such a federation.

LDAP Authentication

The section defines how to connect to an LDAP authentication system.

Figure 7.6. The LDAP configuration options

Typically all users must have their details in the LDAP directory to login to GeoNetwork. However if auser is added to the GeoNetwork database with the Administrator profile then they will be able to loginwithout their details being present in the LDAP directory.

Basic configuration


Shibboleth Authentication

When using either the GeoNetwork database or LDAP for authentication, you can also configureshibboleth to allow authentication against access federations.

Figure 7.7. The Shibboleth configuration options

Shibboleth authentication requires interaction with Apache web server. In particular, the apache webserver must be configured to require Shibboleth authentication to access the path entered in theconfiguration. The apache web server configuration will contain the details of the shibboleth server thatworks out where a user is located (sometimes called a 'where are you from' server).

The remainder of the shibboleth login configuration describes how shibboleth authentication attributesare mapped to GeoNetwork user database fields as once a user is authenticated against shibboleth,their details are copied to the local GeoNetwork database.


8. User and Group Administration

GeoNetwork uses the concept of Users, Groups and User Profiles. A User can be part of several Groups.A User also has a User Profile1. The combination of User Profile and Group defines what tasks the Usercan perform on the system or on specific metadata records.

8.1 Creating new user Groups

The administrator can create new groups of users. User groups can correspond to logical units withinan organisation. For example groups for Fisheries, Agriculture, Land and Water, Health etcetera.

To create new groups you should be logged on with an account that has administrative privileges. Tolog in, simply go to the home page and enter your username and password in the top right corner fields,then click on the login button (Figure 8.1, “Login form”).

Important

New installations of GeoNetwork use admin for both username and password. It isimportant to change this from the Administration page once you logged on!

Figure 8.1. Login form

• Select the Administration button in the menu. On the Administration page, select Groupmanagement (Figure 8.2, “Administration page”).

Figure 8.2. Administration page

1. Select Add a new group2;

1A User can only have one User Profile associated.

User and Group Administration


Figure 8.3. Group management

2. Fill out the details. The email address will be used to send feedback on data downloads when theyoccur for resources that are part of the Group.

Figure 8.4. Group edit form

3. Click on Save

Important

The Name should NOT contain spaces! You can use the Localisation functions to providelocalised names for groups.

Access privileges can be set per metadata record. You can define privileges on a per Group basis.Privileges that can be set relate to visibility of the Metadata (Publish), data Download, Interactive Mapaccess and display of the record in the Featured section of the home page.

Editing defines the groups for which editors can edit the metadata record.

Notify defines what groups are notified when a file managed by GeoNetwork is downloaded.

Below is an example of the privileges management table related to a dataset (Figure 8.5, “Privilegesettings”).



Figure 8.5. Privilege settings

8.2 Creating new Users

To add a new user to the GeoNetwork system you do the following:

1. Select User Management from the Administration link in the toolbar (Figure 8.2, “Administrationpage”);

2. Click the button Add a new user (Figure 8.6, “User administration form”);

Figure 8.6. User administration form

3. Provide the information required for the new user (Figure 8.7, “User information form”);



Figure 8.7. User information form

4. Assign the correct profile (Section 8.3, “User Profiles”);

5. Assign the user to a group;

6. Click on Save.

8.3 User Profiles

Users can have different profiles depending on their role in the GeoNetwork system. A profile defineswhat tasks the user can perform.

User profiles are hierarchical and based on inheritance. This means that a user with an Editor profilecan create and modify new metadata records, but can also use all functions a Registered user can use.

Rights associated with the profiles are illustrated in detail in the list below:

1. Administrator Profile

The Administrator has special privileges that give access to all available functions. These include:

• Full rights for creating new groups and new users

• Rights to change users/groups’ profiles

• Full rights for creating/editing/deleting new/old metadata

• Perform system administration and configuration tasks.

2. User Administrator Profile

The User Administrator is the administrator of his/her own group with the following privileges:

• Full rights on creating new users within the own group

• Rights to change users profiles within the own group



• Full rights on creating/editing/ deleting new/old data within the own group

3. Content Reviewer Profile

The content reviewer is the only person allowed to give final clearance on the metadata publicationon the Intranet and/or on the Internet:

• Rights on reviewing metadata content within the own group and authorising its publication

4. Editor Profile

The editor works on metadata with following privileges:

• Full rights on creating/editing/ deleting new/old data within the own group

5. Registered User Profile

The Registered User has more access privileges than non-authenticated Guest users:

• Right to download protected data


9. Import facilities

9.1 File import

The file import facility allows you to import metadata records in XML format or MEF format or copy/pasteXML metadata to insert. In order to use this facility, you have to be logged in as an administrator. Afterthe login step, go to the administration page and select the Metadata insert link.

Clicking the link, you will reach the metadata import file's page as illustrated in Figure 9.1, “ The XMLfile import options ”. You have to specify a set of parameters to make the import working. Dependingon the insert type you will perform:

XML file import

Figure 9.1. The XML file import options

For both, XML and MEF file import, you could choose actions to be performed at import. Import actionsoptions are: No action on import (nothing done during import process), Overwrite metadata withsame UUID (this option will delete existing metadata with the same UUID, and add the new one),Generate UUID for inserted metadata (this option will force a new UUID for each metadata inserted).

Stylesheet option: This is a powerful option because allows you to specify a stylesheet for an XSLtransformation. The drop down control is filled with files taken from the web/xsl/conversion/import folder:all XSL files you put there will be made available. This is a dynamic process so you don’t have to restartGeoNetwork. The purpose of this option is to allow the conversion of a metadata into a suitable formatthat is supported by GeoNetwork. Validate option: This is a simple validation step that you can chooseto perform. The metadata is validated against its schema. Group option: You have to select a groupto associate to the imported metadata. Usually the group is the creator of the metadata set. Categoryoption: You can specify one category to associate to your metadata in order to simplify the search.

MEF file import

Figure 9.2. The MEF file import options

As presented before, only actions options could be selected during a MEF import.

Import facilities


XML metadata insert

Figure 9.3. The XML insert options

Choosing the radio button Copy/Paste, you could perform an XML insert, directly copy/pasting yourmetadata record. Please refer to XML import for options you could use. Note that it is not possible toperform actions during import with this method.

9.2 Batch import

The batch import facility allows you to import a set of metadata into the system all at once. In order to usethis facility, you have to be logged in as an administrator. After the login step, go to the administrationpage and select the batch import’s link (Figure 9.4, “ How to reach the batch import page ”. The link issurrounded with a red rectangle).

Figure 9.4. How to reach the batch import page

Import facilities


Clicking the link, you will reach the batch import’s page as illustrated in Figure 9.5, “ The batch importoptions ”. You have to specify a set of parameters to make the import working. They are:

Directory This is the full path on the server’s file system of the directory to scan. GeoNetwork will look forand try to import all XML files present into this directory. It is important to notice that this is the directoryon the server machine and not on the client of the user that is doing the import. All metadata files presentinto the import directory must have the same schema format. Schema GeoNetwork supports only somemetadata formats so you have to specify the schema of the metadata you want to import. If a metadatadoes not belong to the selected schema, the entire operation will be aborted. Validate This is a simplevalidation step that you can choose to perform. The metadata is validated against its schema. GroupYou have to select a group to associate to the imported metadata. Usually the group is the creator of themetadata set. Category You can specify one category to associate to your metadata in order to simplifythe search. Stylesheet This is a powerful option because allows you to specify a stylesheet for an XSLtransformation. The drop down control is filled with files taken from the web/xsl/conversion/import folder:all XSL files you put there will be made available. This is a dynamic process so you don’t have to restartGeoNetwork. The purpose of this option is to allow the conversion of a metadata into a suitable formatthat is supported by GeoNetwork. Therefore, it is important that the result of the transformation matchesthe schema format selected above.

Below the page, there are the following buttons:

Back Goes back to the administration form. Upload Starts the import process. When the process ends,the total count of imported metadata will be shown. Please notice that the import is transactional: themetadata set will be fully imported or fully discarded (there are no partial imports). Files that starts with’.’ or that do not end with ’.xml’ are ignored.

Figure 9.5. The batch import options

Structured import

An hidden feature of the batch import is the possibility to specify some import parameters in more detail.This feature is triggered when the specified folder contains the import-config.xml file. When this happen,this file is read and the standard import switches to the structured one.

The import-config.xml file has a config root element with the following children:

1. categoryMapping [1]: this element specifies the mapping of directories to categories.

a. mapping [0..n]: This element can appear 0 or more times and maps one directory name to acategory name. It must have a dir attribute that indicates the directory and a to attribute thatindicates the category name.

b. default [1]: This element specifies a default mapping of categories for all directories that do notmatch the other mapping elements. It must have only the to attribute.

Import facilities


2. schemaMapping [1]: this element specifies the mapping of directories to metadata schemas.

a. mapping [0..n]: This element can appear 0 or more times and maps one directory to the schemaname that must be used when importing. The provided schema must match the one used by themetadata contained into the specified directory, which must all have the same schema. It musthave a dir attribute that indicates the directory and a to attribute that indicates the schema name.

b. default [1]: default behaviour to use when all other mapping elements do not match. It must haveonly the to attribute.

Here is an example of the import-config.xml file:

<config>

<categoryMapping>

<mapping dir="1" to="maps" />

<mapping dir="3" to="datasets" />

<mapping dir="6" to="interactiveResources" />

<mapping dir="30" to="photo" />

<default to="maps" />

</categoryMapping>

<schemaMapping>

<mapping dir="3" to="fgdc-std" />

<default to="dublin-core" />

</schemaMapping>

</config>

The import procedure starts by scanning the provided directory. This can contain, beside the import-config.xml file, only subdirectories which name will be ignored but used only as a container. Insideeach directory, there is another level made only by directories that represent a metadata grouping forcategories. Each directory name will be used as the dir attribute in the mapping scheme previouslydescribed.


10. Harvesting

10.1 Introduction

Since the beginning of the project, there has been the need to share metadata among severalGeoNetwork nodes. Usually, each node takes care of a region of interest so it is important to be able toperform a search over all these nodes at the same time. This is called distributed search and exploitsthe Internet connectivity. In our cases, this distributed search can be heavy to perform if there are manymaps with associated thumbnails. Furthermore, GeoNetwork is usually employed in areas (like Africa,Asia) where the connectivity can be limited, making the use of distributed search not feasible.

Harvesting is the process of collecting remote metadata and storing them locally for a faster access.This is a periodic process to do, for example, once a week. Harvesting is not a simple import: local andremote metadata are kept aligned. Using some magic, one GeoNetwork node is capable of discoveringmetadata that have been added, removed or updated in the remote node.

GeoNetwork is able to harvest from the following sources (for more details see below):

1. Another GeoNetwork node (version 2.1 or above).

2. An old GeoNetwork 2.0 node.

3. A WebDAV server.

4. A CSW 2.0.1 or 2.0.2 catalogue server.

5. An OAI-PMH server.

6. An OGC service using its GetCapabilities document. These include WMS, WFS, WPS and WCSservices.

10.2 Mechanism overview

The harvesting mechanism is based on the concept of a universally unique identifier (UUID). This isa special id because it is not only unique locally to the node that generated it but it is unique acrossall the world. It is a combination of the network interface’s MAC address, the current date/time and arandom number. Every time you create a new metadata in GeoNetwork, a new UUID is generated andassigned to it.

Another important concept behind the harvesting is the last change date. Every time you change ametadata, its last change date is updated. Just storing this parameter and comparing it with a new oneallows any system to find out if the metadata has been modified since last update.

These two concepts allow GeoNetwork to fetch a remote metadata, check if it has been updatedand remove it locally if it has been removed remotely. Furthermore, thanks to UUIDs, a hierarchy ofharvesting nodes can be built where B harvests from C and A harvests from B. Even loops can becreated because harvested metadata cannot be modified.

10.3 Harvesting life cycle

When a harvesting node is set, there is no harvested metadata. During the first run, all remote matchingmetadata are retrieved and stored locally. After the first run, only changed metadata are retrieved.Harvested metadata are not editable for the following reasons:

Harvesting


1. The harvesting is periodic so any local change to harvested metadata will be lost during the next run.

2. The change date is used to keep track of changes so if it gets changed outside the originator site,the harvesting mechanism is compromised.

Beside the metadata itself, this implies that users cannot change all other metadata properties (likecategories, privileges etc...).

The harvesting process goes on until one of the following situations arises:

1. An administrator stops (deactivates) the node.

2. An exception arises. In this case the node is automatically stopped.

When a harvesting node is removed, all harvest metadata are removed too.

10.4 Multiple harvesting and hierarchies

Catalogues that provide UUIDs for metadata (for example GeoNetwork and a CSW server) can beharvested several times without having to take care about metadata overlap. This allows the possibilityto perform a thematic search and a metadata belonging to multiple searches is harvested only onceand not duplicated.

This mechanism allows the GeoNetwork harvesting type to be combined with other GeoNetwork nodesto perform hierarchical harvesting. This way a metadata can be harvested from several nodes. Forexample, consider this scenario:

1. Node (A) has created metadata (a)

2. Node (B) harvests (a) from (A)

3. Node (C) harvests (a) from (B)

4. Node (D) harvests from both (A), (B) and (C)

In this scenario, Node (D) will get the same metadata (a) from all 3 nodes (A), (B), (C). The metadatawill flow to (D) following 3 different paths but thanks to its UUID only one copy will be stored. When (a)will be changed in (A), a new version will flow to (D) but, thanks to the change date, the copy in (D) willbe updated with the most recent version.

10.5 General notes and issues

General

1. The harvesting engine does not store harvesting results. This implies that if the server is restartedthe last results are lost.

2. Changes to the harvesting parameters (for example privileges and categories) are taken into accountin the next harvesting run.

GeoNetwork harvesting type

1. During harvesting, site icons are harvested and local copies updated. Icons are propagated to newnodes as soon as these nodes harvest from this one.

2. The metadata UUID is taken from the info.xml file of the MEF bundle. Any UUID stored inside themetadata will be overwritten with this one.

Harvesting


WebDAV harvesting type

1. The same metadata could be harvested several times by different harvesting nodes. Anyway, this isnot a good practise because every copy of the metadata will have a different UUID and the systemwill fill with different copies of the same metadata.

CSW harvesting type

1. If the dct:modified element is missing from the GetRecords response the metadata will be alwaysharvested.

2. Any exception during getRecordById operation is discarded and the metadata skipped.

OAI-PMH harvesting type

1. The id of the remote server must be a UUID. If not, metadata can be harvested but during hierarchicalpropagation id clashes could corrupt harvested metadata.

2. During harvesting, GeoNetwork will try to auto detect the schema of each metadata. If the schemais not supported the metadata is skipped.

OGC service harvesting type

1. Every time the harvester runs, it will remove previously harvested information and create new ones.GeoNetwork will generate the id for all metadata (both service and datasets). Therefor, for datasets, ifthe metadata is created using a remote XML document (ie. if a MetadataUrl tag is in the GetCapabilitydocument), the UUID of the document is used.

2. Thumbnails are generated only for Web Map Service (WMS). The service should also support theWGS84 projection

10.6 The main page

To access the harvesting main page you have to be logged in as an administrator. From theadministration page, click the link shown in Figure 10.1, “How to access the harvesting main page” witha red rectangle.

Figure 10.1. How to access the harvesting main page

Harvesting


Figure 10.2, “The harvesting main page” shows the harvesting main page. The page shows a list ofharvesting nodes that have been created so far. On the bottom side there is a set of buttons to managethese nodes. The meaning of each column is as follows:

1. Select This is just a check box to select one or more nodes. The selected nodes will be affected bythe first row of buttons (start, stop, run, remove). For example, if you select 3 nodes and press theRemove button, these 3 nodes will be removed.

2. Name This is the node’s name provided by the administrator.

3. Type The node’s harvesting type chosen when the node was created (GeoNetwork, web folder etc...).

4. Status This is an icon that reflects the node’s current status. See Table 10.1, “Possible status icons”for all different icons and status description.

5. Errors This column reflects the status of the last harvesting run, which could have succeeded ornot. The result is reflected on this icon and a tool tip will show detailed information. See Table 10.2,“Possible error icons” for all different icons.

6. Every The time (in days, hours, minutes) between two consecutive harvesting from this node.

7. Last run The date, in ISO 8601 format, of the most recent harvesting run.

8. Operation A list of buttons for all possible operations on a node.

9. Selecting Edit will allow you to change the parameters for a node.

Figure 10.2. The harvesting main page

The bottom side of the page contains two rows of buttons. The first row contains buttons that can operateon a set of nodes. You can select the nodes using the check box on the first column and then press theproper button. When the button finishes its action, the check boxes are cleared. Here is the meaningof each button:

1. Activate When a new harvesting node is created, it’s status is inactive. Use this button to make itactive and thus to start harvesting from the remote node.

2. Deactivate Stops harvesting from a node. Please notice that this does not mean that a currentlyrunning harvesting will be stopped but it means that this node will be ignored during future harvesting.

3. Run This button simply tells the harvesting engine to start harvesting immediately. This is useful fortesting during the harvesting setup.

4. Remove Remove all currently selected nodes. A dialogue will ask the user to confirm the action.

Harvesting


The second row contains general purpose buttons. Here is the meaning of each button:

1. Back Simply returns to the main administration page.

2. Add This button allows to create new harvesting nodes.

3. Refresh Refreshes the current list of nodes querying the server. This can be useful to see if theharvesting list has been altered by someone else or if any harvesting process started.

Table 10.1. Possible status icons

Icon Status Description

Inactive The harvesting from this node is stopped.

Active The harvesting engine is waiting for the timeout specified for thisnode. When the timeout is reached, the harvesting starts.

Running The harvesting engine is currently running, fetching metadata fromremote nodes. When the process will be finished, the status will beswitched to active.

Table 10.2. Possible error icons

Icon Description

The harvesting was OK, no errors were found. In this case, a tool tip will show someharvesting results (like the number of harvested metadata etc...).

The harvesting was aborted due to an unexpected condition. In this case, a tool tip willshow some information about the error.

Harvesting result tips

If the harvesting succeeds, a tool tip will show detailed information about the harvesting process. Thisway you can check if the harvester worked as expected or if there is something to fix to the harvestingparameters or somewhere else. The result tip is like a table, where each row refers to

Total This is the total number of metadata found remotely. Metadata with the same id are considered asone. Added Number of metadata added to the system because they were not present locally. RemovedNumber of metadata that have been removed locally because they are not present in the remote serveranymore. Updated Number of metadata that are present locally but that needed to be updated becausetheir last change date was different from the remote one. Unchanged Local metadata left unchanged.Their remote last change date did not change. Unknown schema Number of skipped metadata becausetheir format was not recognised by GeoNetwork. Unretrievable Number of metadata that were readyto be retrieved from the remote server but for some reason there was an exception during the datatransfer process. Bad Format Number of skipped metadata because they did not have a valid XMLrepresentation. Does not validate Number of metadata which did not validate against their schema.These metadata were harvested with success but skipped due to the validation process. Usually, thereis an option to force validation: if you want to harvest these metadata anyway, simply turn it off.

Harvesting


Table 10.3. Result information supported by harvesting types

Result vs harvestingtype

GeoNetwork WebDAV CSW OAI-PMH OGCService

Total x x x x x

Added x x x x x

Removed x x x x x

Updated x x x x

Unchanged x x x x

Unknown schema x x x x x

Unretrievable x x x x x

Bad Format x x

Does Not Validate x x

Thumbnails / Thumbnailsfailed

x

Metadata URL attributeused

x

10.7 Adding new nodes

The Add button in the main page allows you to add new harvesting nodes. It will open the form shownin Figure 10.3, “Adding a new harvesting node”. When creating a new node, you have to choose theharvesting protocol supported by the remote server. The supported protocols are:

1. GeoNetwork 2.1 remote node This is the standard and most powerful harvesting protocol used inGeoNetwork. It is able to log in into the remote node, to perform a standard search using the commonquery fields and to import all matching metadata. Furthermore, the protocol will try to keep bothremote privileges and categories of the harvested metadata if they exist locally. Please notice thatsince GeoNetwork 2.1 the harvesting protocol has been improved. This means that it is not possibleto use this protocol to harvest from version 2.0 or below.

2. Web DAV server This harvesting type uses the web DAV (Distributed Authoring and Versioning)protocol to harvest metadata from a DAV server. It can be useful to users that want to publishtheir metadata through a web server that offers a DAV interface. The protocol allows to retrieve thecontents of a web page (a list of files) with their change date.

3. Catalogue Services for the Web 2.0 The Open Geospatial Consortium Catalogue Services for theWeb and it is a search interface for catalogues developed by the Open Geospatial Consortium.GeoNetwork implements version 2.0 of this protocol.

4. GeoNetwork v2.0 remote node GeoNetwork 2.1 introduced a new powerful harvesting engine which isnot compatible with GeoNetwork version 2.0 based catalogues. Old 2.0 servers can still harvest from2.1 servers but harvesting metadata from a v2.0 server requires this harvesting type. This harvestingtype is deprecated.

Harvesting


5. Z3950 Remote search Not implemented. This is a placeholder.

6. OAI Protocol for Metadata Harvesting 2.0 This is a good harvesting protocol that is widely used amonglibraries. GeoNetwork implements version 2.0 of the protocol.

The drop down list shows all available protocols. Pressing the Add button you will reach an edit pagewhose content depends on the chosen protocol. The Back button will go back to the main page.

Figure 10.3. Adding a new harvesting node

Adding a GeoNetwork node

This type of harvesting allows you to connect to a GeoNetwork node, perform a simple search as in themain page and retrieve all matched metadata. The search is useful because it allows you to focus onlyon metadata of interest. Once you add a node of this type, you will get a page like the one shown inFigure 10.4, “Adding a GeoNetwork node”. The meaning of the options is the following:

Harvesting


Figure 10.4. Adding a GeoNetwork node

Site Here you put information about the GeoNetwork’s node you want to harvest from (host, port andservlet). If you want to search protected metadata you have to specify an account. The name parameteris just a short description that will be shown in the main page beside each node. Search In this sectionyou can specify search parameters: they are the same present in the main page. Before doing that, itis important to remember that the GeoNetwork’s harvesting can be hierarchical so a remote node cancontain both its metadata and metadata harvested from other nodes and sources. At the beginning, theSource drop down is empty and you have to use the Retrieve sources button to fill it. The purpose of

Harvesting


this button is to query GeoNetwork about all sources which it is currently harvesting from. Once youget the drop down filled, you can choose a source name to constrain the search to that source only.Leaving the drop down blank, the search will spread over all metadata (harvested and not). You canadd several search criteria for each site through the Add button: several searches will be performedand results merged. Each search box can be removed pressing the small button on the left of the site’sname. If no search criteria is added, a global unconstrained search will be performed. Options This isjust a container for general options.

Every This is the harvesting period. The smallest value is 1 minute while the greatest value is 100 days.One run only If this option is checked, the harvesting will do only one run after which it will becomeinactive. Privileges Here you decide how to map remote group’s privileges. You can assign a copypolicy to each group. The Intranet group is not considered because it does not make sense to copy itsprivileges. The All group has different policies from all the others:

1. Copy: Privileges are copied.

2. Copy to Intranet: Privileges are copied but to the Intranet group. This way public metadata can bemade protected.

3. Don’t copy: Privileges are not copied and harvested metadata will not be publicly visible.

For all other groups the policies are these:

1. Copy: Privileges are copied only if there is a local group with the same (not localised) name as theremote group.

2. Create and copy: Privileges are copied. If there is no local group with the same name as the remotegroup then it is created.

3. Don’t copy: Privileges are not copied.

On the bottom side of the page there are some buttons:

Back Simply return to the main harvesting page. Save Saves the current node information and returnsto the main harvesting page. When creating a new node, the node will be actually created only whenyou press this button.

Adding a Web DAV node

In this type of harvesting, metadata are retrieved from a remote web page. The available options areshown in Figure 10.5, “Adding a web DAV node” and have the following meaning:

Harvesting


Figure 10.5. Adding a web DAV node

Site Here are the connection information. The available options are:

Name This is a short description of the node. It will be shown in the harvesting main page. URLThe remote URL from which metadata will be harvested. Each file found that ends with .xml willindicate a metadata and will be retrieved, converted into XML and imported. Icon Just an icon to assignto harvested metadata. The icon will be used when showing search results. Use account Accountcredentials for a basic HTTP authentication toward the remote URL. Options General harvesting options:

Every This is the harvesting period. The smallest value is 1 minute while the greatest value is 100 days.One run only If this option is checked, the harvesting will do only one run after which it will becomeinactive. Validate If checked, the metadata will be validate during import. If the validation does not pass,the metadata will be skipped. Recurse When the harvesting engine will find folders, it will recursivelydescend into them. Privileges Here it is possible to assign privileges to imported metadata. The Groupsarea lists all available groups in GeoNetwork. Once one (or more) group has been selected, it can beadded through the Add button (each group can be added only once). For each added group, a rowof privileges is created at the bottom of the list to allow privilege selection. To remove a row simply

Harvesting


press the associated Remove button on its right. Categories Here you can assign local categories toharvested metadata.

At the bottom of the page there are the following buttons:

Back Go back to the main harvesting page. The harvesting is not added. Save Saves node’s datacreating a new harvesting node. Then it will go back to the main harvesting page.

Adding a CSW node

This type of harvesting is capable of connecting to a remote CSW server and retrieving all matchingmetadata. Please, note that in order to be harvested metadata must have one of the schema formathandled by GeoNetwork. Figure 10.6, “Adding a Catalogue Services for the Web harvesting node” showsthe options available, whose meaning is the following:

Harvesting


Figure 10.6. Adding a Catalogue Services for the Web harvesting node

Site Here you have to specify the connection parameters which are similar to the web DAV harvesting.In this case the URL points to the capabilities document of the CSW server. This document is used todiscover the location of the services to call to query and retrieve metadata. Search Using the Add button,you can add several search criteria. You can query only the fields recognised by the CSW protocol.Options General harvesting options:

Every This is the harvesting period. The smallest value is 1 minute while the greatest value is 100 days.One run only If this option is checked, the harvesting will do only one run after which it will becomeinactive. Privileges Please, see web DAV harvesting. Categories Please, see web DAV harvesting.

Harvesting




Adding an OAI-PMH node

An OAI-PMH server implements a harvesting protocol that GeoNetwork, acting as a client, can use toharvest metadata. If you are requesting the oai_dc output format, GeoNetwork will convert it into itsDublin Core format. Other formats can be harvested only if GeoNetwork supports them and is able toautodetect the schema from the metadata. Figure 10.7, “ Adding an OAI-PMH harvesting node ” showsall available options, which are:

Harvesting


Figure 10.7. Adding an OAI-PMH harvesting node

Site All options are the same as web DAV harvesting. The only difference is that the URL parameterhere points to an OAI-PMH server. This is the entry point that GeoNetwork will use to issue all PMHcommands. Search This part allows you to restrict the harvesting to specific metadata subsets. Youcan specify several searches: GeoNetwork will execute them sequentially and results will be mergedto avoid the harvesting of the same metadata. Several searches allow you to specify different searchcriteria. In each search, you can specify the following parameters:

From You can provide a start date here. All metadata whose last change date is equal to or greater

than this date will be harvested. You cannot simply edit this field but you have to use the icon to

Harvesting


popup a calendar and choose the date. This field is optional so if you don’t provide it the start date

constraint is dropped. Use the icon to clear the field. Until Works exactly as the from parameter butadds an end constraint to the last change date. The until date is included in the date range, the checkis: less than or equal to. Set An OAI-PMH server classifies its metadata into hierarchical sets. You canrequest to return metadata that belong to only one set (and its subsets). This narrows the search result.Initially the drop down shows only a blank option that indicate no set. After specifying the connectionURL, you can press the Retrieve Info button, whose purpose is to connect to the remote node, retrieveall supported sets and prefixes and fill the search drop downs. After you have pressed this button, youcan select a remote set from the drop down. Prefix Here prefix means metadata format. The oai_dcprefix is mandatory for any OAI-PMH compliant server, so this entry is always present into the prefixdrop down. To have this drop down filled with all prefixes supported by the remote server, you have toenter a valid URL and press the Retrieve Info button.

You can use the Add button to add one more search to the list. A search can be removed clicking the

icon on its left. Options Most options are common to web DAV harvesting. The validate option, whenchecked, will validate each harvested metadata against GeoNetwork’s schemas. Only valid metadatawill be harvested. Invalid one will be skipped. Privileges Please, see web DAV harvesting. CategoriesPlease, see web DAV harvesting.



Please note that when you edit a previously created node, both the set and prefix drop down lists willbe empty. They will contain only the previously selected entries, plus the default ones if they were notselected. Furthermore, the set name will not be localised but the internal code string will be displayed.You have to press the retrieve info button again to connect to the remote server and retrieve the localisedname and all set and prefix information.

Adding an OGC Service (ie. WMS, WFS, WCS)

An OGC service implements a GetCapabilities operation that GeoNetwork, acting as a client, can use toproduce metadata. The GetCapability document provides information about the service and the layers/feature types/coverages served. GeoNetwork will convert it into ISO19139/119 format. Figure 10.8, “Adding an OGC service harvesting node ” shows all available options, which are:

Harvesting


Figure 10.8. Adding an OGC service harvesting node

Site: Name is the name of the catalogue and will be one of the search criteria. The type of OGC serviceindicates if the harvester has to query for a specific kind of service. Supported type are WMS (1.0.0 and1.1.1), WFS (1.0.0 and 1.1.0, WCS (1.0.0) and WPS (0.4.0 and 1.0.0). The service URL is the URL ofthe service to contact (without parameters like "REQUEST=GetCapabilities", "VERSION=", ...). It hasto be a valid URL like http://your.preferred.ogcservice/type_wms. The metadata language has to bespecified. It will define the language of the metadata. It should be the language used by the web serviceadministrator. The ISO topic category is used to populate the metadata. It is recommended to chooseon as the topic is mandatory for the ISO standard if the hierarchical level is "datasets".

The type of import allows to define if the harvester has to produce only one metadata for the service orif it should loop over datasets served by the service and produce also metadata for each datasets. Foreach dataset the second checkbox allow to generate metadata for the dataset using an XML documentreferenced in the MetadataUrl attribute of the dataset in the GetCapability document. If this documentis loaded but it is not valid (ie. unknown schema, bad XML format), the GetCapability document is used.For WMS, thumbnails could be created during harvesting.

Icons and privileges are defined as in the other harvester types.

Metadata for the harvested service is linked to the category selected for the service (usually "interactiveresources" should be the best category). For each dataset, the "category for datasets" is linked to eachmetadata for datasets.


11. Metadata ownership

11.1 Introduction

Starting from release 2.1.0, GeoNetwork has a new metadata access policy. The old edit and adminprivileges have been removed and the concept of reviewer has been introduced. The purpose of thisnew profile is to control when a metadata can be published outside or not. In previous releases, all usersbelonging to a group with edit privileges could edit the same metadata. Now, a metadata is only visibleto its creator, to a reviewer which has access to the group owner and to an administrator.

11.2 Access policy

A public metadata is a metadata that has the view privilege for the group named all.

Visualisation

An administrator can view any metadata.

A reviewer can view a metadata if:

1. The metadata owner is member of one of the groups assigned to the reviewer.

2. She/he is the metadata owner.

A user administrator or an editor can view:

1. All metadata that has the view privilege selected for one of the groups she/he is member of.

2. All metadata created by her/him.

A registered user can view:

1. All metadata that has the view privilege selected for one of the groups she/he is member of.

Public metadata can be viewed by any user (logged in or not).

Editing

An administrator can edit any metadata.

A reviewer can edit a metadata if:

1. The metadata owner is member of one of the groups assigned to the reviewer.

2. She/he is the metadata owner.

A User Administrator or an Editor can only edit metadata she/he created.

11.3 Privileges

The Privileges administration page is accessible only by:

1. All Administrators

2. All Reviewers that are member of one of the groups assigned to the metadata owner.

Metadata ownership


3. The Owner of the metadata

Privileges for the All and Intranet groups can only be edited by Administrators and Reviewers.

11.4 Transfer Ownership

When metadata ownership needs to be transferred from one user to another for all or specific metadatarecords, the Transfer Ownership option is available. It is located in the Administration page (Figure 11.1,“ How to open the Transfer Ownership page ”) and once selected, leads to the page shown in Figure 11.2,“ The Transfer Ownership page ”.

Figure 11.1. How to open the Transfer Ownership page

Initially, the page shows only a dropdown for a Source editor (the current metadata owner). Thedropdown is filled with all GeoNetwork Users that have the Editor role and own some metadata. Selectingan Editor will select all metadata that is managed by that Editor. An empty dropdown means that thereare no Editors with metadata associated and hence no transfer is possible.

Note The drop down will be filled with all Editors visible to you. If you are not an Administrator, you willview only a subset of all Editors.

Figure 11.2. The Transfer Ownership page

Once a Source Editor has been selected, a set of rows is displayed. Each row refers to the group of theEditor for which there are privileges. The meaning of each column is the following:

1. Source group: This is a group that has privileges in the metadata that belong to the source editor. Putin another way, if one of the editor’s metadata has privileges for one group, that group is listed here.

2. Target group: This is the destination group of the transferring process. All privileges relative to thesource group are transferred to the target group. The target group drop down is filled with all groupsvisible to the logged user (typically an administrator or a user administrator). By default, the Sourcegroup is selected in the target drop down. Privileges to groups All and Intranet are not transferable.

Metadata ownership


3. Target editor: Once a Target group is selected, this drop down is filled with all editors that belongto that Target group.

4. Operation: Currently only the Transfer operation is possible.

By selecting the Transfer operation, if the Source group is different than the Target group, the systemperforms the Transfer of Ownership, shows a brief summary and removes the current row because nowthere are no privileges to transfer anymore.


12. Thesaurus

12.1 Introduction

Thesaurus support in GeoNetwork allows:

• Metadata editing: controlled vocabulary on the metadata editing interface for ISO and Dublin Core

• Administration interface allows import/export/creation/browse thesaurus

• Search interface: a list of keyword is proposed for the keyword criteria

On a node, thesaurus types could be defined as:

• External: When a thesaurus is imported, it is flagged to ”external” which means that users are notallowed to edit the thesaurus. This thesaurus is managed by an external organisation.

• Local: When a thesaurus is created, it is flagged to ”local” which means that users are allowed toedit the thesaurus.

12.2 Thesaurus / SKOS format

The Simple Knowledge Organisation Systems (SKOS) http://www.w3.org/2004/02/skos/ is anarea of work developing specifications and standards to support the use of knowledge organisationsystems (KOS) such as thesauri, classification schemes. This format is used by GeoNetwork to storethesaurus information.

A concept is defined by an identifier, a preferred label, a definition and links with other concepts. Labelsand definitions could be stored in multiple languages (using the xml:lang attributes). Three type of linksbetween concepts have been defined in the SKOS format:

• related terms

• broader terms

• narrower terms

For example, a concept ”ABLETTE” could be defined as follow with a label in French and English, linkedto broader concept:

<skos:Concept rdf:about="http://www.oieau.org/concept#c4fc54576dc00227b82a709287ac3681">

<skos:prefLabel xml:lang="fr">ABLETTE</skos:prefLabel>

<skos:prefLabel xml:lang="en">BLEAK</skos:prefLabel>

<skos:broader rdf:resource="http://www.oieau.org/concept#9f25ece36d04776e09492c66627cccb9"/>

</skos:Concept>

GeoNetwork support multilingual thesaurus (e.g. Agrovoc). Search and edition are made based oncurrent user interface language (i.e. if the interface is in English, when editing metadata, GeoNetworkwill only search for concept in English).

12.3 Thesaurus administration

To reach the thesaurus administration page you have to be logged in as an administrator. From theadministration page, click the link ”Manage thesauri”. Figure 5.3 shows the list of thesaurus available

Thesaurus


in the GeoNetwork node. The page shows a list of thesaurus that have been created or imported. Theupper part of the page allows user to edit/add/modify/consult thesaurus. The lower part allows uploadof thesaurus in SKOS format.

Creation of a new thesaurus

To create a new thesaurus, click the ”+” sign in the category you want your thesaurus to be in. Oncecreated, the thesaurus could be updated through the edit interface. The meaning of each column isas follows:

Type The type allows to classify thesaurus according to its type. First, is defined the type of the thesaurusfollowing ISO category list, then the type indicates if the thesaurus is a local one or an external one.Name This is the thesaurus’s name provided by the administrator on creation or filename on upload.When creating a thesaurus, the name of the thesaurus will be the filename of the thesaurus.

Figure 12.1. Administration interface for thesaurus

For each thesaurus the following buttons are available:

Download Link to the RFD file. Delete Remove thesaurus from the current node. View If type is external,the view button allows to search and view concepts. Edit If type is local, the edit button allows to search,add, remove and view concepts.

Import existing thesaurus

GeoNetwork allows thesaurus import in SKOS format. Once uploaded, an external thesaurus could notbe updated. Select the category, browse for the thesaurus file and click upload. The file is located in /web/xml/codelist/external/thesauri/category/.

Figure 12.2. Upload interface for thesaurus


1. Back: Go back to the main administration page.

Thesaurus


2. Upload: Upload the selected RFD file to the node. Then it will list all thesaurus available on the node.

12.4 Editing/browsing thesaurus: add/remove/browse keywords

From the thesaurus administration interface, click on the edit button for a local thesaurus or the viewbutton for an external thesaurus. This interface allows:

• keywords search

• add/remove keywords for local thesaurus.

Use the textbox and the type of search in order to search for keywords.

Figure 12.3. Browse interface for thesaurus

Figure 12.4. Keyword description

12.5 Metadata editing: adding keywords

When editing metadata in ISO or Dublin core, the keyword fields auto-complete when editor fill the fields.Keywords available in all thesaurus know by the current node are returned. Editor could select one ofthe list or could type any other keywords.

Thesaurus


Figure 12.5. Auto-complete in keywords editor

12.6 Search criteria: keywords

In the advanced search interface, the keyword field will proposed all keywords used in the metadata.These keywords are indexed by Lucene on creation/update of metadata. The number of metadata linkedto all keywords available in the index are display. User could type in the keyword field or click the iconto get the list of keywords available.

Figure 12.6. Thesaurus search interface

Figure 12.7. Auto-complete function in thesaurus search interface


13. GeoNetwork’s Administrator Survival Tool -GAST

13.1 What is GAST?

GAST stands for GeoNetwork’s Administrator Survival Tool and is a standalone applicationwhose purpose is to simplify some low level tasks like change of the servlet, configuration of the JDBCaccount, setup the database and so on. Most of the GAST’s facilities work only for the GeoNetwork’sinstallation where GAST is in. This implies that if you are using a servlet container other than Jetty (likeTomcat) you will not be able to change some options (like the servlet’s name). Other facilities workfor any servlet container but you have to specify the GeoNetwork’s URL into the GAST’s configurationdialogue.

13.2 Starting GAST

GAST belongs to the core components so it is installed by default.

On Windows computers, simply select the Start GAST option under the GeoNetwork opensourceprogram group under Start > Programs > GeoNetwork opensource

Other options to start GAST are either to use a Java command from a terminal window or just clickits jar’s icon. To issue the Java command you have to:

1. change directory to the GeoNetwork installation folder

2. issue the command java -jar gast/gast.jar

GAST will be in current system language if any translation is available. If you want to force GAST GUIlanguage, you could start GAST using the -Duser.language option (e.g. ./gast.sh -Duser.language=fr orjava -Duser.language=fr -jar gast/gast.jar).

You can also try to simply open the GeoNetwork installation folder, go to the gast folder and double clickon the gast.jar file. If you have Java installed, GAST should start in a few seconds.

To run, GAST requires Java 1.5. It will not work on Java 1.4 and it should run on Java 1.6 (this hasnot been tested!).

13.3 Operating modes

When you start GAST, you get an application window like the one in Figure 13.1, “ GAST’s main windowwith a tool selected ”. On the left side you have a panel with the tools you can use. After selecting atool, on the right side you get the tool’s options panel.

GeoNetwork’s Administrator Survival Tool - GAST


Figure 13.1. GAST’s main window with a tool selected

Every function has an operating mode, which defines the condition under which the tool can be used.The tool’s mode is shown with an icon on the right side of the tool’s name. The operating modes, withtheir icons are summarised in the following table:

Mode Icon Description

Restarted The tool can be always used, but GeoNetwork must berestarted in order to make the change effective.

Running The tool can be used only if GeoNetwork is running.

Stopped The tool can be used only if GeoNetwork is stopped. This isimportant because some tools change the database’s accountor create the database from scratch. These are sensitiveoperations that cannot be performed while GeoNetwork isrunning.

13.4 Tools subdivision

All GAST tools present into the left panel are logically subdivided into groups. Each group represents aGeoNetwork’s aspect for which GAST allows you a graphic interface. The groups are:

Configuration You can change some configuration parameters, like the servlet’s name, JDBC accountetc... Management General purpose tools related to the site’s administration. Database Operations thatregard the database. Here you can find tools to create a database from scratch, creating the schemaand filling it with proper data. Migration Tools that allow you to migrate metadata from old installation.

13.5 Server and Account configuration dialogue

Some of the GAST’s tools access a running GeoNetwork application. Usually, GAST connects toGeoNetwork using the connection parameters it finds on the installation folder but you can specify otherparameters in order to connect to other instances. This is required when the GeoNetwork instance is not

GeoNetwork’s Administrator Survival Tool - GAST


running on the embedded Jetty server. In addition to that, some tools require authentication so accountparameters must be provided.

To provide these parameters, you have to use the GAST ’s configuration dialogue. To open the dialogue,select Options >> Config from the menu bar. You will get the dialogue shown in Figure 13.2, “ Theconfiguration dialogue ”.

Figure 13.2. The configuration dialogue

The dialogue is subdivided into 2 areas: Server Tells GAST how to connect to a running GeoNetwork. Ifyou select the embedded option, GAST will get the connection parameters from the installation directory.Alternatively, if you use Tomcat or an external servlet container you have to choose the external optionand provide the connection parameters yourself. Remember that this will work only for tools whichoperating mode is Running. For all the others, GAST will access the parameters from the installationdirectory. Account Some tools require authentication. To authenticate, simply select the Use this accountoption and provide the username and password of a valid account. These parameters will work for boththe embedded instance and for any external instance.


14. Localisation

14.1 Localisation of dynamic user interface elements

The user interface of GeoNetwork can be localised into several languages through XML language files.But beside static text, there is also more dynamic text that can be added and changed interactively. Thistext is stored in the database and is translated using the Localisation form that is part of the administrativefunctions (Figure 14.1, “How to open the Localisation form”).

Figure 14.1. How to open the Localisation form

The form allows you to localise the following entities: Groups, Categories, Operations and Regions. Theform (Figure 14.2, “The Localisation form”) subdivided in a left and a right panel.

The left panel allows you to choose which elements you want to edit. On the top, a dropdown let youchoose which entity to edit. All elements of the selected type are shown in a list.

When you select an element from the list, the right panel will show the text as it will be displayed inthe user interface. The text in the source language is read only while you can update the text in thetarget language field.

Note

You can change the source and target languages to best suit your needs. Some users mayfor instance prefer to translate from French to Spanish, others prefer to work with Englishas the source language.

Use the Save button to store the updated label and move to the next element.

Important

If the user changes a label and chooses another target language without saving, the labelchange is lost.

Localisation


Figure 14.2. The Localisation form


15. Import / export tools

15.1 Introduction

Using GAST, you can import and export metadata at will. It allows you to:

1. Create a backup of the entire metadata set. Each metadata has its own file, including maps andother data files. Once you have the backup, you can decide to import all or only some of them.

2. Move your metadata from one GeoNetwork catalogue to another. This can be done to mirror yourmetadata or to upgrade an old installation. In the last case, you export your metadata from your oldinstallation and then re-import them into the new one.

3. Fill the system with test data. Using the ’skip UUID’ option, you can re-import the same metadataover and over again. This is useful, for example, if you want to perform stress tests.

Metadata are exported using the MEF format.

Ownership

Please, consider that the MEF format version 1.0 does not take into account user andgroup ownership. When exporting metadata, you loose this information. When importingmetadata, the new owner becomes the user that is performing the import while the groupownership is set to null.

15.2 Import

This tool is located under Management tools on the left panel and allows you to import a set of metadatathat have been previously exported using the export facility (see Section 15.3, “Export”). Selecting theImport tool opens the option panel on the right (Figure 15.1, “The metadata import panel”).

Figure 15.1. The metadata import panel

• Input folder. the source folder in your system that GAST will scan to collect metadata to import.GAST will try to import all files with the MEF extension.

Note

Sub-folders are not scanned.

Import / export tools


• Browse button. Navigate through your file system to choose an output location or enter it manuallyinto the text field.

• Import. This will start the process. A progress dialogue will be opened to show the import status.

15.3 Export

This tool is located under the Management tool on the left panel and allows you to export a setof metadata using the MEF format. Selecting the Export tool opens the option panel on the right(Figure 15.2, “The metadata export panel”).

Figure 15.2. The metadata export panel

• Output folder. The target folder in your file system where GAST will put the exported metadata. Youcan either select the Browse button to navigate through your file system to choose a better locationor enter it manually in the text field.

• Format. Here you can specify the metadata’s output format. See the MEF specification for moreinformation.

• Skip UUID. Normally this option is not required (see Warning). If you select it, you will loose themetadata’s unique identifier (UUID) but you will be able to re-import that metadata over and overagain. This is useful to fill the system with test data.

• Search. Allows to specify free text search criteria to limit the set of exported records.

Note

the export result will depend on the metadata visible to the searching user. If you do notauthenticate, you will get only public metadata.

• Export. This will start the export process. A progress dialogue will be opened to show the exportstatus.

Warning

Skipping the UUID on import or export can cause metadata to be duplicated. This shouldnormally always be avoided

Part III. Server ReferenceThis part gives some insights in the internal structure of GeoNetwork opensource. It describes somebasic operations, like compiling and running the software, protocols used, a description of XML servicesand the Settings structure.

If you are a software developer and want to develop, customize or integrate GeoNetwork services, thispart is for you.


16. Software development

16.1 System Requirements

GeoNetwork is a Java application that runs as a servlet so the Java Runtime Environment (JRE) mustbe installed in order to run it. You can get the JRE from the following address http://java.sun.com andyou have to download the Java 5 Standard Edition (SE). GeoNetwork won’t run with Java 1.4 and Java6 has some problems with it so we recommend to use Java 5. Being written in Java, GeoNetwork canrun on any platform that supports Java, so it can run on Windows, Linux and Mac OSX. For the latterone, make sure to use version 10.4 (Tiger) or newer. Version 10.3 (Panther) has only Java 1.4 so itcannot run GeoNetwork.

Next, you need a servlet container. GeoNetwork comes with an embedded one (Jetty) which is fastand well suited for most applications. If you need a stronger one, you can install Tomcat from theApache Software Foundation (http://tomcat.apache.org). It provides load balance, fault tolerance andother corporate needed stuff. If you work for an organisation, it is probable that you already have it upand running. The tested version is 5.5 but GeoNetwork should work with all other versions.

Regarding storage, you need a Database Management System (DBMS) like Oracle, MySQL, Postgresqland so on. GeoNetwork comes with an embedded one (McKoi) which is used by default duringinstallation. This DBMS can be used for small or desktop installations, where the speed is not an issue.You can use this DBMS for several thousands of metadata. If you manage more than 10.000 metadatait is better to use a professional, stand alone DBMS. In this case, using a separate DBMS also freesup some memory for the application.

GeoNetwork does not require a strong machine to run. A good performance can be obtained even with128 Mb of RAM. The suggested amount is 512 Mb. For the hard disk space, you have to consider thespace required for the application itself (about 40 Mb) and the space required for data maps, which canrequire 50 GB or more. A simple disk of 250 GB should be OK. Maybe you can choose a fast one toreduce backup time but GeoNetwork itself does not speed up on a faster disk. You also need somespace for the search index which is located in web/WEB-INF/lucene. Even with a lot of metadata theindex is small so usually 10-20 Mb of space is enough.

16.2 Running the software with a servlet engine

The software is run in different ways depending on the servlet container you are using:

Tomcat You can use the manager web application to start/stop GeoNetwork. You can also use thestartup.* and shutdown.* scripts located into Tomcat’s bin folder (.* means .sh or .bat depending on yourOS) but this way you restart all applications you are running, not only GeoNetwork. After installation andbefore running GeoNetwork you must link it to Tomcat. Jetty If you use the provided container you canuse the scripts into GeoNetwork’s bin folder. The scripts are start-geonetwork.* and stop-geonetwork.*and you must be inside the bin folder to run them. You can use these scripts just after installation.

16.3 Development

Compiling GeoNetwork

To compile GeoNetwork you first need to install the source code during installation. If you do so, youget a build.xml script and a src folder with the full source.

Software development


You also need the Ant tool to run the build script. You can download Ant from http://ant.apache.org.Version 1.6.5 works but any other recent version should be OK. Once installed, you should have theant command in your path (on Windows systems, you have to open a shell to check).

When all is in place, go inside the GeoNetwork’s root folder (the one where the build.xml file is located)and issue the ant command. You should see an output like this one:

gemini:/geonetwork/trunk# ant

Buildfile: build.xml

compile:

[delete] Deleting: /geonetwork/trunk/web/WEB-INF/lib/geonetwork.jar

[delete] Deleting: /geonetwork/trunk/csw/lib/csw-client.jar

[delete] Deleting: /geonetwork/trunk/csw/lib/csw-common.jar

[delete] Deleting: /geonetwork/trunk/gast/gast.jar

[mkdir] Created dir: /geonetwork/trunk/.build

[javac] Compiling 267 source files to /geonetwork/trunk/.build

[javac] Note: Some input files use or override a deprecated API.

[javac] Note: Recompile with -Xlint:deprecation for details.

[javac] Note: Some input files use unchecked or unsafe operations.

[javac] Note: Recompile with -Xlint:unchecked for details.

[copy] Copying 1 file to /geonetwork/trunk/.build

[jar] Building jar: /geonetwork/trunk/web/WEB-INF/lib/geonetwork.jar

[jar] Building jar: /geonetwork/trunk/csw/lib/csw-client.jar

[jar] Building jar: /geonetwork/trunk/csw/lib/csw-common.jar

[jar] Building jar: /geonetwork/trunk/gast/gast.jar

[delete] Deleting directory /geonetwork/trunk/.build

BUILD SUCCESSFUL

Total time: 9 seconds

gemini:/geonetwork/trunk#

The compilation phase, if it has success, puts all jars into the proper place (most of them will becopied into web/geonetwork/WEB-INF/lib and web/intermap/WEB-INF/lib). After this phase, simplyrestart GeoNetwork to see the effects.

Source code documentation

The GeoNetwork Java source code is based on Javadoc. Javadoc is a tool for generating APIdocumentation in HTML format from doc comments in source code. To see documentation generatedby the Javadoc tool, go to:

• GeoNetwork opensource Javadoc1

• InterMap opensource Javadoc2

Creating the installer

You can generate an installer by running the ant command inside the installer directory.

Both platform independent and Windows specific installers are generated by default.

Make sure you update version number and other relevant properties in the installer/build.xml file

You can also create an installer that includes a Java Runtime Environment (JRE) for Windows. Thiswill allow GeoNetwork to run on a compatible, embedded JRE and thus avoid error messages causedby JRE incompatibilities on the PC.

Creating an installer with an embedded JRE requires you to first download and unzip the JRE in a folderjre1.5.0_12 at the project root level. Refer to the installer-config-win-jre.xml file for exactconfiguration.

javadoc/geonetwork/index.html

javadoc/intermap/index.html


17. Harvesting

17.1 Structure

The harvesting capability is built around 3 areas: JavaScript code, Java code and XSL stylesheets (onboth the server and client side).

JavaScript code

This refers to the web interface. The code is located in the web/geonetwork/scripts/harvesting folder.Here, there is a subfolder for each harvesting type plus some classes for the main page. These are:

1. harvester.js: This is an abstract class that must be implemented by harvesting types. It defines someinformation retrieval methods (getType, getLabel, etc...) used to handle the harvesting type, plus onegetUpdateRequest method used to build the XML request to insert or update entries.

2. harvester-model.js: Another abstract class that must be implemented by harvesting types. Whencreating the XML request, the only method substituteCommon takes care of adding commoninformation like privileges and categories taken from the user interface.

3. harvester-view.js: This is an important abstract class that must be implemented by harvesting types.It takes care of many common aspects of the user interface. It provides methods to add group’sprivileges, to select categories, to check data for validity and to set and get common data from theuser interface.

4. harvesting.js: This is the main JavaScript file that takes care of everything. It starts all the submodules,loads XML strings from the server and displays the main page that lists all harvesting nodes.

5. model.js: Performs all XML requests to the server, handles errors and decode responses.

6. view.js: Handles all updates and changes on the main page.

7. util.js: just a couple of utility methods.

Java code

The harvesting package is located in src/org/fao/geonet/kernel/harvest. Here too, there is one subfolderfor each harvesting type. The most important classes for the implementor are:

1. AbstractHarvester: This is the main class that a new harvesting type must extends. It takes care ofall aspects like adding, updating, removing, starting, stopping of harvesting nodes. Some abstractmethods must be implemented to properly tune the behaviour of a particular harvesting type.

2. AbstractParams: All harvesting parameters must be enclosed in a class that extends this abstractone. Doing so, all common parameters can be transparently handled by this abstract class.

All others are small utility classes used by harvesting types.

XSL stylesheets

Stylesheets are spread in some folders and are used by both the JavaScript code and the server. Themain folder is located at web/geonetwork/xsl/harvesting. Here there are some general stylesheets, plusone subfolder for each harvesting type. The general stylesheets are:

Harvesting


1. buttons.xsl: Defines all button present in the main page (activate, deactivate, run, remove, back, add,refresh), buttons present in the "add new harvesting" page (back and add) and at the bottom of theedit page (back and save).

2. client-error-tip.xsl: This stylesheet is used by the browser to build tooltips when an harvesting erroroccurred. It will show the error class, the message and the stacktrace.

3. client-node-row.xsl: This is also used by the browser to add one row to the list of harvesting nodesin the main page.

4. harvesting.xsl: This is the main stylesheet. It generates the HTML page of the main page and includesall panels from all the harvesting nodes.

In each subfolder, there are usually 4 files:

1. xxx.xsl: This is the server stylesheets who builds all panels for editing the parameters. XXX isthe harvesting type. Usually, it has the following panels: site information, search criteria, options,privileges and categories.

2. client-privil-row.xsl: This is used by the JavaScript code to add rows in the group’s privileges panel.

3. client-result-tip.xsl: This is used by the JavaScript code (which inherits from harvester-view.js) toshow the tool tip when the harvesting has been successful.

4. client-search-row.xsl: Used in some harvesting types to generate the HTML for the search criteriapanel.

As you may have guessed, all client side stylesheets (those used by JavaScript code) start with theprefix client-.

Another set of stylesheets are located in web/geonetwork/xsl/xml/harvesting and are used by thexml.harvesting.get service. This service is used by the JavaScript code to retrieve all the nodes thesystem is currently harvesting from. This implies that a stylesheet (one for each harvesting type) mustbe provided to convert from the internal setting structure to an XML structure suitable to clients.

The last file to take into consideration contains all localised strings and is located at web/geonetwork/loc/XX/xml/harvesting.xml (where XX refers to a language code). This file is used by both JavaScriptcode and the server.

17.2 Data storage

Harvesting nodes are stored inside the Settings table. Further useful information can be found in thechapter Harvesting.

The SourceNames table is used to keep track of the uuid/name couple when metadata get migratedto different sites.

17.3 Guidelines

To add a new harvesting type, follow these steps:

1. Add the proper folder in web/scripts/harvesting, maybe copying an already existing one.

2. Edit the harvesting.js file to include the new type (edit both constructor and init methods).

Harvesting


3. Add the proper folder in web/xsl/harvesting (again, it is easy to copy from an already existing one).

4. Edit the stylesheet web/xsl/harvesting/harvesting.xsl and add the new type

5. Add the transformation stylesheet in web/xsl/xml/harvesting. Its name must match the string usedfor the harvesting type.

6. Add the Java code in a package inside org.fao.geonet.kernel.harvest.harvester.

7. Add proper strings in web/geonetwork/loc/XX/xml/harvesting.xml.

Here follows a list of general notes to follow when adding a new harvesting type:

1. Every harvesting node (not type) must generate its UUID. This UUID is used to remove metadatawhen the harvesting node is removed and to check if a metadata (which has another UUID) has beenalready harvested by another node.

2. If a harvesting type supports multiple searches on a remote site, these must be done sequentiallyand results merged.

3. Every harvesting type must save in the folder images/logos a GIF image whose name is the node’sUUID. This image must be deleted when the harvesting node is removed. This is necessary topropagate harvesting information to other GeoNetwork nodes.

4. When a harvesting node is removed, all collected metadata must be removed too.

5. During harvesting, take in mind that a metadata could have been removed just after being added tothe result list. In this case the metadata should be skipped and no exception raised.

6. The only settable privileges are: view, dynamic, featured. It does not make sense to use the others.

7. If a node raises an exception during harvesting, that node will be deactivated.

8. If a metadata already exists (its UUID exists) but belong to another node, it must not be updated evenif it has been changed. This way the harvesting will not conflict with the other one. As a side effect,this prevent locally created metadata from being changed.

9. The harvesting engine does not store results on disk so they will get lost when the server will berestarted.

10.When some harvesting parameters are changed, the new harvesting type must use them during thenext harvesting without requiring to reboot the server.


18. Metadata Exchange Format v1.1

18.1 Introduction

The metadata exchange format (MEF in short) is a special designed file format whose purpose is to allowmetadata exchange between different platforms. A metadata exported into this format can be importedby any platform which is able to understand it. This format has been developed with GeoNetwork in mindso the information it contains is mainly related to it. Nevertheless, it can be used as an interoperabilityformat between any platform.

This format has been designed with these needs in mind:

1. Export a metadata record for backup purposes

2. Import a metadata record from a previous backup

3. Import a metadata record from a different GeoNetwork version to allow a smooth migration from oneversion to another.

All these operations regard the metadata and its related data as well.

In the paragraphs below, some terms should be intended as follows:

1. the term actor is used to indicate any system (application, service etc...) that operates on metadata.

2. the term reader will be used to indicate any actor that can import metadata from a MEF file.

3. the term writer will be used to indicate any actor that can generate a MEF file.

18.2 File format

A MEF file is simply a ZIP file which contains the following files:

1. metadata.xml: this file contains the metadata itself, in XML format. The text encoding of the metadatais that one specified into the XML declaration.

2. info.xml: this is a special XML file which contains information related to the metadata but that cannotbe stored into it. Examples of such information are the creation date, the last change date, privilegeson the metadata and so on. Now this information is related to the GeoNetwork’s architecture.

3. public: this is a directory used to store the metadata thumbnails and other public files. There are norestrictions on the images’ format but it is strongly recommended to use the portable network graphics(PNG), the JPEG or the GIF formats.

4. private: this is a directory used to store all data (maps, shape files etc...) associated to the metadata.Files in this directory are private in the sense that an authorisation is required to access them. Thereare no restrictions on the file types that can be stored into this directory.

Any other file or directory present into the MEF file should be ignored by readers that don’t recognisethem. This allows actors to add custom extensions to the MEF file.

A MEF file can have empty public and private folders depending on the export format, which can be:

1. simple: both public and private are omitted.

2. partial: only public files are provided.

Metadata Exchange Format v1.1


3. full: both public and private files are provided.

It is recommended to use the .mef extension when naming MEF files.

18.3 The info.xml file

This file contains general information about a metadata. It must have an info root element with amandatory version attribute. This attribute must be in the X.Y form, where X represents the major versionand Y the minor one. The purpose of this attribute is to allow future changes of this format maintainingcompatibility with older readers. The policy behind the version is this:

1. A change to Y means a minor change. All existing elements in the previous version must be leftunchanged: only new elements or attributes may be added. A reader capable of reading version X.Yis also capable of reading version X.Y’ with Y’>Y.

2. A change to X means a major change. Usually, a reader of version X.Y is not able to read versionX’.Y with X’>X.

The root element must have the following children:

1. general: a container for general information. It must have the following children:

a. UUID: this is the universally unique identifier assigned to the metadata and must be a validUUID. This element is optional and, when omitted, the reader should generate one. A metadatawithout a UUID can be imported several times into the same system without breaking uniquenessconstraints. When missing, the reader should also generate the siteId value.

b. createDate: This date indicates when the metadata was created.

c. changeDate: This date keeps track of the most recent change to the metadata.

d. siteId: This is an UUID that identifies the actor that created the metadata and must be a valid UUID.When the UUID element is missing, this element should be missing too. If present, it will be ignored.

e. siteName: This is a human readable name for the actor that created the metadata. It must bepresent only if the siteId is present.

f. schema: Indicates the metadata’s schema. The value can be assigned as will but if the schemais one of those describe below, that value must be used:

i. dublin-core: A metadata in the Dublin Core format as described in http://dublincore.org

ii. fgdc-std: A metadata in the Federal Geographic Data Committee.

iii. iso19115: A metadata in the ISO 19115 format

iv. iso19139: A metadata in the ISO 19115/2003 format for which the ISO19139 is the XMLencoding.

g. format: Indicates the MEF export format. The element’s value must belong to the following set:{ simple, partial, full }.

h. localId: This is an optional element. If present, indicates the id used locally by the sourceId actorto store the metadata. Its purpose is just to allow the reuse of the same local id when reimportinga metadata.



i. isTemplate: A boolean field that indicates if this metadata is a template used to create new ones.There is no real distinction between a real metadata and a template but some actors use it to allowfast metadata creation. The value must be: { true, false }.

j. rating: This is an optional element. If present, indicates the users’ rating of the metadata rangingfrom 1 (a bad rating) to 5 (an excellent rating). The special value 0 means that the metadata hasnot been rated yet. Can be used to sort search results.

k. popularity: Another optional value. If present, indicates the popularity of the metadata. The valuemust be positive and high values mean high popularity. The criteria used to set the popularity isleft to the writer. Its main purpose is to provide a metadata ordering during a search.

2. categories: a container for categories associated to this metadata. A category is just a name, like’audio-video’ that classifies the metadata to allow an easy search. Each category is specified by acategory element which must have a name attribute. This attribute is used to store the category’sname. If there are no categories, the categories element will be empty.

3. privileges: a container for privileges associated to this metadata. Privileges are operations that agroup (which represents a set of users) can do on a metadata and are specified by a set of groupelements. Each one of these, has a mandatory name attribute to store the group’s name and a set ofoperation elements used to store the operations allowed on the metadata. Each operation elementmust have a name attribute which value must belong to the following set: { view, download, notify,dynamic, featured }. If there are no groups or the actor does not have the concept of group, theprivileges element will be empty. A group element without any operation element must be ignoredby readers.

4. public: All metadata thumbnails (and any other public file) must be listed here. This container containsa file element for each file. Mandatory attributes of this element are name, which represents the file’sname and changeDate, which contains the date of the latest change to the file. The public elementis optional but, if present, must contain all the files present in the metadata’s public directory and anyreader that imports these files must set the latest change date on these using the provided ones.The purpose of this element is to provide more information in the case the MEF format is used formetadata harvesting.

5. private: This element has the same purpose and structure of the public element but is related to mapsand all other private files.

Any other element or attribute should be ignored by readers that don’t understand them. This allowsactors to add custom attributes or subtrees to the XML.

Figure 18.1, “Example of info file” shows an example of info file.

Date format

Unless differently specified, all dates in this file must be in the ISO/8601 format. The pattern must beYYYY-MM-DDTHH:mm:SS and the timezone should be the local one.



<info version="1.0">

<general>

<UUID>0619abc0-708b-eeda-8202-000d98959033</uuid>

<createDate>2006-12-11T10:33:21</createDate>

<changeDate>2006-12-14T08:44:43</changeDate>

<siteId>0619cc50-708b-11da-8202-000d9335906e</siteId>

<siteName>FAO main site</siteName>

<schema>iso19139</schema>

<format>full</format>

<localId>204</localId>

<isTemplate>false</isTemplate>

</general>

<categories>

<category name="maps"/>

<category name="datasets"/>

</categories>

<privileges>

<group name="editors">

<operation name="view"/>

<operation name="download"/>

</group>

</privileges>

<public>

<file name="small.png" changeDate="2006-10-07T13:44:32"/>

<file name="large.png" changeDate="2006-11-11T09:33:21"/>

</public>

<private>

<file name="map.zip" changeDate="2006-11-12T13:23:01"/>

</private>

</info>

Figure 18.1. Example of info file


19. XML Services

19.1 Calling specifications

Calling XML services

GeoNetwork provides access to several internal structures through the use of XML services. These aremuch like HTML addresses but return XML instead. As an example, consider the xml.info service: youcan use this service to get some system’s information without fancy styles and graphics. In GeoNetwork,XML services have usually the xml. prefix in their address.

Request

Each service accepts a set of parameters, which must be embedded into the request. A service can becalled using different HTTP methods, depending on the structure of its request:

GET The parameters are sent using the URL address. On the server side, these parameters are groupedinto a flat XML document with one root and several simple children. A service can be called this wayonly if the parameters it accepts are not structured. Figure 19.1, “A GET request to a XML service andits request encoding” shows an example of such request and the parameters encoded in XML. POSTThere are 3 variants of this method:

ENCODED The request has one of the following content types: application/x-www-form-urlencoded or multipart/form-data. The first case is very common when sending web formswhile the second one is used to send binary data (usually files) to the server. In these cases, theparameters are not structured so the rules of the GET method applies. Even if the second case couldbe used to send XML documents, this possibility is not considered on the server side.

XML The content type is application/xml. This is the common case when the client is not a browserbut a specialised client. The request is a pure XML document in string form, encoded using the encodingspecified into the prologue of the XML document. Using this form, any type of request can be made(structured or not) so any service can be called.

SOAP The content type is application/soap+xml. SOAP is a simple protocol used to access objectsand services using XML. Clients that use this protocol can embed XML requests into a SOAP structure.On the server side, GeoNetwork will remove the SOAP structure and feed the content to the service.Its response will be embedded again into a SOAP structure and sent back to the caller. It makes senseto use this protocol if it is the only protocol understood by the client.

<request>

<hitsPerPage>10</hitsPerPage>

<any />

</request>

Figure 19.1. A GET request to a XML service and its request encoding

Response

The response of an XML service always has a content type of application/xml (the only exceptionare those services which return binary data). The document encoding is the one specified into thedocument’s prologue. Anyway, all GeoNetwork services return documents in the UTF-8 encoding.

XML Services


On a GET request, the client can force a SOAP response adding the application/soap+xml contenttype to the Accept header parameter.

Exception handling

A response document having an error root element means that the XML service raised an exception.This can happen under several conditions: bad parameters, internal errors et cetera. In this cases thereturned XML document has the following structure:

• error: This is the root element of the document. It has a mandatory id attribute that represents anidentifier of the error from a common set. See Table 19.1, “Summary of error ids” for a list of all idvalues.

• message: A message related to the error. It can be a short description about the error type or it cancontain some other information that completes the id code.

• class: The Java class of the raised error (name without package information).

• stack: The server’s stacktrace up to the point that generated the exception. It contains several atchildren, one for each nested level. Useful for debugging purposes.

• at: Information about a nested level of called code. It has the following mandatory attributes:

class Java class of the called method. method Java called method. line Line, inside the calledmethod’s source code where there the method call of the next nested level. file Source file wherethe class is defined.

• object: An optional container for parameters or other values that caused the exception. In case aparameter is an XML object, this container will contain that object in XML form.

• request: A container for some useful information that can be needed to debug the service.

• language: Language used when the service was called.

• service: Name of the called service.

XML Services


Table 19.1. Summary of error ids

id Meaning of message element Meaning of object element

error General message, humanreadable

bad-format Reason -

bad-parameter Name of the parameter Parameter’s bad value

file-not-found - File’s name

file-upload-too-big - -

missing-parameter Name of the parameter XML container where the parameter shouldhave been present.

object-not-found - Object’s name

operation-aborted Reason of abort If present, the object that caused the abort

operation-not-allowed

- -

resource-not-found - Resource’s name

service-not-allowed - Service’s name

service-not-found - Service’s name

user-login User login failed message User’s name

user-not-found - User’s id or name

metadata-not-found The requested metadata wasnot found

Metadata’s id

Figure 19.2, “An example of generated exception” shows an example of exception generated by themef.export service. The service complains about a missing parameter, as you can see from the contentof the id attribute. The object element contains the xml request with an unknown test parameter whilethe mandatory UUID parameter (as specified by the message element) is missing.

XML Services


<error>

<message>UUID</message>

<class>MissingParameterEx</class>

<stack>

<at class="jeeves.utils.Util" file="Util.java" line="66"

method="getParam"/>

<at class="org.fao.geonet.services.mef.Export" file="Export.java"

line="60" method="exec"/>

<at class="jeeves.server.dispatchers.ServiceInfo" file="ServiceInfo.java"

line="226" method="execService"/>

<at class="jeeves.server.dispatchers.ServiceInfo" file="ServiceInfo.java"

line="129" method="execServices"/>

<at class="jeeves.server.dispatchers.ServiceManager" file="ServiceManager.java"

line="370" method="dispatch"/>

</stack>

<object>

<request>

<asd>ee</asd>

</request>

</object>

<request>

<language>en</language>

<service>mef.export</service>

</request>

</error>

Figure 19.2. An example of generated exception

19.2 General services

xml.info

The xml.info service can be used to query the site about its configuration, services, status and so on.For example, it is used by the harvesting web interface to retrieve information about a remote node.

Request

The XML request should contain at least one type element to indicates the kind of information to retrieve.More type elements can be specified to obtain more information at once. The set of allowed values are:

1. site: Returns general information about the site like its name, id, etc...

2. categories: Returns all site’s categories

3. groups: Returns all site’s groups visible to the requesting user. If the user does not authenticatehimself, only the Intranet and the all groups are visible.

4. operations: Returns all possible operations on metadata

5. regions: Returns all geographical regions usable for queries

6. sources: Returns all GeoNetwork sources that the remote site knows.

The result will contain:

• The remote node’s name and siteId

• All source UUIDs and names that have been discovered through harvesting.

• All source UUIDs and names of metadata that have been imported into the remote node through theMEF format.

XML Services


• Administrators can see all users into the system (normal, other administrators, etc...)

• User administrators can see all users they can administrate and all other user administrators in thesame group set. The group set is defined by all groups visible to the user administration, beside theAll and the Intranet groups.

• An authenticated user can see only himself.

• A guest cannot see any user.

<request>

<type>site</type>

<type>groups</type>

</request>

Figure 19.3. Request example

Response

Each type element produces an XML subtree so the response to the previous request is like this:

<info>

<site>...</site>

<categories>...</categories>

<groups>...</groups>

...

</info>

Figure 19.4. Response example

Here follows the structure of each subtree:

• site: This is the container

• name: Human readable site name

• siteId: Universal unique identifier of the site

• platform: This is just a container to hold the site’s back end

• name: Platform name. For GeoNetwork installations it must be GeoNetwork.

• version: Platform version, given in the X.Y.Z format

• subVersion: Additional version notes, like ’alpha-1’ or ’beta-2’.

Example:

<site>

<name>My site</name>

<organisation>FAO</organization>

<siteId>0619cc50-708b-11da-8202-000d9335906e</siteId>

<platform>

<name>geonetwork</name>

<version>2.2.0</version>

</platform>

</site>

Figure 19.5. Example site information

• categories: This is the container for categories.

XML Services


• category [0..n]: A single GeoNetwork’s category. This element has an id attribute which representsthe local identifier for the category. It can be useful to a client to link back to this category.

• name: Category’s name

• label: The localised labels used to show the category on screen. See Figure 19.6, “Exampleresponse for categories”.

<categories>

<category id="1">

<name>datasets</name>

<label>

<en>Datasets</en>

<fr>Jeux de données</fr>

</label>

</category>

</categories>

Figure 19.6. Example response for categories

• groups: This is the container for groups

• group [2..n]: This is a GeoNetwork group. There are at least the Internet and Intranet groups. Thiselement has an id attribute which represents the local identifier for the group.

• name: Group’s name

• description: Group’s description

• referrer: The user responsible for this group

• email: The email address to notify when a map is downloaded

• label: The localised labels used to show the group on screen. See Figure 19.7, “Exampleresponse for groups”.

<groups>

<group id="1">

<name>editors</name>

<label>

<en>Editors</en>

<fr>Éditeurs</fr>

</label>

</group>

</groups>

Figure 19.7. Example response for groups

• operations: This is the container for the operations

• operation [0..n]: This is a possible operation on metadata. This element has an id attribute whichrepresents the local identifier for the operation.

• name: Short name for the operation.

• reserved: Can be y or n and is used to distinguish between system reserved and user definedoperations.

XML Services


• label: The localised labels used to show the operation on screen. See Figure 19.8, “Exampleresponse for operations”.

<operations>

<operation id="0">

<name>view</name>

<label>

<en>View</en>

<fr>Voir</fr>

</label>

</operation>

</operations>

Figure 19.8. Example response for operations

• regions: This is the container for geographical regions

• region [0..n]: This is a region present into the system. This element has an id attribute whichrepresents the local identifier for the operation.

• north: North coordinate of the bounding box.

• south: South coordinate of the bounding box.

• west: West coordinate of the bounding box.

• east: east coordinate of the bounding box.

• label: The localised labels used to show the region on screen. See Figure 19.9, “Exampleresponse for regions”.

<regions>

<region id="303">

<north>82.99</north>

<south>26.92</south>

<west>-37.32</west>

<east>39.24</east>

<label>

<en>Western Europe</en>

<fr>Western Europe</fr>

</label>

</region>

</regions>

Figure 19.9. Example response for regions

• sources: This is the container.

• source [0..n]: A source known to the remote node.

• name: Source’s name

• UUID: Source’s unique identifier

XML Services


<sources>

<source>

<name>My Host</name>

<UUID>0619cc50-708b-11da-8202-000d9335906e</uuid>

</source>

</sources>

Figure 19.10. Example response for a source

• users: This is the container for user information

• user [0..n]: A user of the system

• id: The local identifier of the user

• username: The login name

• surname: The user’s surname. Used for display purposes.

• name: The user’s name. Used for display purposes.

• profile: User’s profile, like Administrator, Editor, UserAdmin etc...

• address:

• state:

• zip:

• country:

• email:

• organisation:

• kind:

<users>

<user>

<id>3</id>

<username>eddi</username>

<surname>Smith</surname>

<name>John</name>

<profile>Editor</profile>

<address/>

<state/>

<zip/>

<country/>

<email/>

<organisation/>

<kind>gov</kind>

</user>

</users>

Figure 19.11. Example response for a user

XML Services


localised entities

localised entities have a general label element which contains the localised strings in all supportedlanguages. This element has as many children as the supported languages. Each child has a name thatreflect the language code while its content is the localised text. Here is an example of such elements:

<label>

<en>Editors</en>

<fr>Éditeurs</fr>

<es>Editores</es>

</label>

xml.forward

This is just a router service. It is used by JavaScript code to connect to a remote host because aJavaScript program cannot access a machine other than its server. For example, it is used by theharvesting web interface to query a remote host and retrieve the list of site ids.

Request

<request>

<site>

<url>...</url>

<type>...</type>

<account>

<username>...</username>

<password>...</password>

</account>

</site>

<params>...</params>

</request>

Figure 19.12. The service’s request

Where:

1. site: A container for site information where the request will be forwarded.

2. url: Refers to the remote URL to connect to. Usually it points to a GeoNetwork XML service but itcan point to any XML service.

3. type: Its only purpose is to distinguish GeoNetwork nodes which use a different authenticationscheme. The value GeoNetwork refers to these nodes. Any other value, or if the element is missing,refers to a generic node.

4. account: This element is optional. If present, the provided credentials will be used to authenticateto the remote site.

5. params: This is just a container for the request that must be executed remotely.

XML Services


<request>

<site>

<url>http://mynode.org:8080/geonetwork/srv/en/xml.info</url>

</site>

<params>

<request>

<type>site<type>

</request>

</params>

</request>

Figure 19.13. Request for info from a remote server

Please note that this service uses the GeoNetwork’s proxy configuration.

Response

The response is just the response from the remote service.

19.3 Harvesting services

Introduction

This chapter provides a detailed explanation of the GeoNetwork’s harvesting services. These servicesallow a complete control over the harvesting behaviour. They are used by the web interface and canbe used by any other client.

xml.harvesting.get

Retrieves information about one or all configured harvesting nodes.

Request

Called with no parameters returns all nodes. Example:

<request/>

Otherwise, an id parameter can be specified:

<request>

<id>123</id>

</request>

Response

When called with no parameters the service provide its output inside a nodes container. You get asmany node elements as are configured. Figure 19.14, “Example of an xml.harvesting.get response fora GeoNetwork node” shows an example of output.

XML Services


<nodes>

<node id="125" type="geonetwork">

<site>

<name>test 1</name>

<UUID>0619cc50-708b-11da-8202-000d9335aaae</uuid>

<host>localhost</host>

<port>8080</port>

<servlet>geonetwork</servlet>

<account>

<use>false</use>

<username />

<password />

</account>

</site>

<searches>

<search>

<freeText />

<title />

<abstract />

<keywords />

<digital>false</digital>

<hardcopy>false</hardcopy>

<source>

<UUID>0619cc50-708b-11da-8202-000d9335906e</uuid>

<name>Food and Agriculture organisation</name>

</source>

</search>

</searches>

<options>

<every>90</every>

<oneRunOnly>false</oneRunOnly>

<status>inactive</status>

</options>

<info>

<lastRun />

<running>false</running>

</info>

<groupsCopyPolicy>

<group name="all" policy="copy"/>

<group name="mygroup" policy="createAndCopy"/>

</groupsCopyPolicy>

<categories>

<category id="4"/>

</categories>

</node>

</nodes>

Figure 19.14. Example of an xml.harvesting.get response for a GeoNetwork node

If you specify an id, you get a response like that one in Figure 19.15, “Example of an xml.harvesting.getresponse for a WebDAV node” (for a WebDAV node).

XML Services


<node id="165" type="webdav">

<site>

<name>test 1</name>

<UUID>0619cc50-708b-11da-8202-000d9335aaae</uuid>

<url>http://www.mynode.org/metadata</url>

<icon>default.gif</icon>

<account>

<use>true</use>

<username>admin</username>

<password>admin</password>

</account>

</site>

<options>

<every>90</every>


<recurse>false</recurse>

<validate>true</validate>

<status>inactive</status>

</options>

<privileges>

<group id="0">

<operation name="view" />

</group>

<group id="14">

<operation name="download" />

</group>

</privileges>

<categories>

<category id="2"/>

</categories>

<info>

<lastRun />

<running>false</running>

</info>

</node>

Figure 19.15. Example of an xml.harvesting.get response for a WebDAV node

The node’s structure has a common XML format, plus some additional information provided by theharvesting types. In the following structure, each element has a cardinality specified using the [x..y]notation, where x and y denote the minimum and the maximum values. The cardinality [1..1] is omittedfor clarity.

• node: The root element. It has a mandatory id attribute that represents the internal identifier and amandatory type attribute which indicates the harvesting type.

• site: A container for site information.

• name (string): The node’s name used to describe the harvesting.

• UUID (string): This is a system generated unique identifier associated to the harvesting node. Thisis used as the source field into the Metadata table to group all metadata from the remote node.

• account: A container for account information.

• use (boolean): true means that the harvester will use the provided username and password toauthenticate itself. The authentication mechanism depends on the harvesting type.

• username (string): Username on the remote node.

• password (string): Password on the remote node.

XML Services


• options: A container for generic options.

• every (integer): Harvesting interval in minutes.

• oneRunOnly (boolean): After the first run, the entry’s status will be set to inactive.

• status (string): Indicates if the harvesting from this node is stopped (inactive) or if the harvesteris waiting for the timeout (active).

• privileges [0..1]: A container for privileges that must be associated to the harvested metadata. Thisoptional element is present only if the harvesting type supports it.

• group [0..n]: A container for allowed operations associated to this group. It has the id attributewhich value is the identifier of a GeoNetwork group.

• operation [0..n]: Specifies an operation to associate to the containing group. It has a nameattribute which value is one of the supported operation names. The only supported operationsare: view, dynamic, featured.

• categories [0..1]: This is a container for categories to assign to each imported metadata. Thisoptional element is present if the harvesting type supports it.

• category (integer) [0..n]: Represents a local category and the id attribute is its local identifier.

• info: A container for general information.

• lastRun (string): The lastRun element will be filled as soon as the harvester starts harvestingfrom this entry. The value is the

• running (boolean): True if the harvester is currently running.

• error: This element will be present if the harvester encounters an error during harvesting.

• code (string): The error code, in string form.

• message (string): The description of the error.

• object (string): The object that caused the error (if any). This element can be present or notdepending on the case.

Errors

• ObjectNotFoundEx If the id parameter is provided but the node cannot be found.

xml.harvesting.add

Create a new harvesting node. The node can be of any type supported by GeoNetwork (GeoNetworknode, web folder etc...). When a new node is created, its status is set to inactive. A call to thexml.harvesting.start service is required to start harvesting.

Request

The service requires an XML tree with all information the client wants to add. In the following sections,default values are given in parenthesis (after the parameter’s type) and are used when the parameter

XML Services


is omitted. If no default is provided, the parameter is mandatory. If the type is boolean, only the trueand false strings are allowed.

All harvesting nodes share a common XML structure that must be honoured. Please, refer to the previoussection for elements explanation. Each node type can add extra information to that structure. Thecommon structure is here described:

• node: The root container. The type attribute is mandatory and must be one of the supported harvestingtypes.

• site [0..1]

• name (string, ”)

• account [0..1]

• use (boolean, ’false’)

• username (string, ”)

• password (string, ”)

• options [0..1]

• every (integer, ’90’)

• oneRunOnly (boolean, ’false’)

• privileges [0..1]: Can be omitted but doing so the harvested metadata will not be visible. Pleasenote that privileges are taken into account only if the harvesting type supports them.

• group [0..n]: It must have the id attribute which value should be the identifier of a GeoNetworkgroup. If the id is not a valid group id, all contained operations will be discarded.

• operation [0..n]: It must have a name attribute which value must be one of the supportedoperation names.

• categories [0..1]: Please, note that categories will be assigned to metadata only if the harvestingtype supports them.

• category (integer) [0..n]: The mandatory id attribute is the category’s local identifier.

Please note that even if clients can store empty values (”) for many parameters, before starting theharvesting entry those parameters should be properly set in order to avoid errors.

In the following sections, the XML structures described inherit from this one here so the commonelements have been removed for clarity reasons (unless they are containers and contain new children).

Standard GeoNetwork harvesting

To create a node capable of harvesting from another GeoNetwork node, the following XML informationshould be provided:

• node: The type attribute is mandatory and must be GeoNetwork.

• site

XML Services


• host (string, ”): The GeoNetwork node’s host name or IP address.

• port (string, ’80’): The port to connect to.

• servlet (string, ’geonetwork’): The servlet name chosen in the remote site.

• searches [0..1]: A container for search parameters.

• search [0..n]: A container for a single search on a siteID. You can specify 0 or more searches. Ifno search element is provided, an unconstrained search is performed.

• freeText (string, ”) : Free text to search. This and the following parameters are the same usedduring normal search using the web interface.

• title (string, ”): Search the title field.

• abstract (string, ”) : Search the abstract field.

• keywords (string, ”) : Search the keywords fields.

• digital (boolean, ’false’): Search for metadata in digital form.

• hardcopy (boolean, ’false’): Search for metadata in printed form.

• source (string, ”): One of the sources present on the remote node.

• groupsCopyPolicy [0..1]: Container for copy policies of remote groups. This mechanism is used toretain remote metadata privileges.

• group: There is one copy policy for each remote group. This element must have 2 mandatoryattributes: name and policy. The name attribute is the remote group’s name. If the remote groupis renamed, it is not found anymore and the copy policy is skipped. The policy attribute representsthe policy itself and can be: copy, createAndCopy, copyToIntranet. copy means that remoteprivileges are copied locally if there is locally a group with the same name as the name attribute.createAndCopy works like copy but the group is created locally if it does not exist. copyToIntranetworks only for the remote group named all, which represents the public group. This policy copiesprivileges of the remote group named all to the local Intranet group. This is useful to restrictmetadata access.

Figure 19.16, “Example of an xml.harvesting.add request for a GeoNetwork node” shows an exampleof an XML request to create a GeoNetwork node.

XML Services


<node type="geonetwork">

<site>

<name>South Africa</name>

<host>south.africa.org</host>

<port>8080</port>

<servlet>geonetwork</servlet>

<account>

<use>true</use>



</account>

</site>

<searches>

<search>

<freeText />

<title />

<abstract />

<keywords />

<digital>true</digital>

<hardcopy>false</hardcopy>

<source>0619cc50-708b-11da-8202-000d9335906e</source>

</search>

</searches>

<options>

<every>90</every>


</options>

<groupsCopyPolicy>

<group name="all" policy="copy"/>

<group name="mygroup" policy="createAndCopy"/>

</groupsCopyPolicy>

<categories>

<category id="4"/>

</categories>

</node>

Figure 19.16. Example of an xml.harvesting.add request for a GeoNetwork node

WebDAV harvesting

To create a web DAV node, the following XML information should be provided.

• node: The type attribute is mandatory and must be WebDAV.

• site

• url (string, ”): The URL to harvest from. If provided, must be a valid URL starting with ’HTTP://’.

• icon (string, ’default.gif’) : Icon file used to represent this node in the search results. The iconmust be present into the images/harvesting folder.

• options

• recurse (boolean, ’false’): When true, folders are scanned recursively to find metadata.

• validate (boolean, ’false’): When true, GeoNetwork will validate every metadata against itsschema. If the metadata is not valid, it will not be imported.

This type supports both privileges and categories assignment.

Figure 19.17, “Example of an xml.harvesting.add request for a WebDAV node” shows an example ofan XML request to create a web DAV entry.

XML Services


<node type="webdav">

<site>

<name>Asia remote node</name>

<url>http://www.mynode.org/metadata</url>


<account>

<use>true</use>



</account>

</site>

<options>

<every>90</every>




</options>

<privileges>

<group id="0">


</group>

<group id="14">

<operation name="features" />

</group>

</privileges>

<categories>

<category id="4"/>

</categories>

</node>

Figure 19.17. Example of an xml.harvesting.add request for a WebDAV node

CSW harvesting

To create a node to harvest from a CSW capable server, the following XML information should beprovided:

• node: The type attribute is mandatory and must be csw.

• site

• capabilitiesUrl (string): URL of the capabilities file that will be used to retrieve the operationsaddress.

• icon (string, ’default.gif’) : Icon file used to represent this node in the search results. The iconmust be present into the images/harvesting folder.

• searches [0..1]

• search [0..n]: Contains search parameters. If this element is missing, an unconstrained searchwill be performed.

• freeText (string, ”) : Search the entire metadata.

• title (string, ”): Search the dc:title queryable.

• abstract (string, ”): Search the dc:abstract queryable.

• subject (string, ”): Search the dc:subject queryable.

This type supports both privileges and categories assignment.

XML Services


Figure 19.18, “Example of an xml.harvesting.add request for a CSW node” shows an example of anXML request to create a CSW entry.

<node type="csw">

<site>

<name>Minos CSW server</name>

<capabilitiesUrl>http://www.minos.org/csw?request=GetCapabilities

&service=CSW&acceptVersions=2.0.1</capabilitiesUrl>


<account>

<use>true</use>



</account>

</site>

<options>

<every>90</every>




</options>

<privileges>

<group id="0">


</group>

<group id="14">

<operation name="features" />

</group>

</privileges>

<categories>

<category id="4"/>

</categories>

</node>

Figure 19.18. Example of an xml.harvesting.add request for a CSW node

Response

The service’s response is the output of the xml.harvesting.get service of the newly created node.

Summary

The following table:

Table 19.2. Summary of features of the supported harvesting types

Harvesting type Authentication Privileges ? Categories ?

GeoNetwork native through policies yes

Web DAV HTTP digest yes yes

CSW HTTP Basic yes yes

xml.harvesting.update

This service is responsible for changing the node’s parameters. A typical request has a node rootelement and must include the id attribute:

<node id="24">

...

</node>

XML Services


The body of the node element depends on the node’s type. The update policy is this:

• If an element is specified, the associated parameter is updated.

• If an element is not specified, the associated parameter will not be changed.

So, you need to specify only the elements you want to change. However, there are some exceptions:

1. privileges: If this element is omitted, privileges will not be changed. If specified, new privileges willreplace the old ones.

2. categories: Like the previous one.

3. searches: Some harvesting types support multiple searches on the same remote note. Whensupported, the updated behaviour should be like the previous ones.

Note that you cannot change the type of an node once it has been created.

Request

The request is the same as that used to add an entry. Only the id attribute is mandatory.

Response

The response is the same as the xml.harvesting.get called on the updated entry.

xml.harvesting.remove/start/stop/run

These services are put together because they share a common request interface. Their purpose isobviously to remove, start, stop or run a harvesting node. In detail:

1. start: When created, a node is in the inactive state. This operation makes it active, that is thecountdown is started and the harvesting will be performed at the timeout.

2. stop: Makes a node inactive. Inactive nodes are never harvested.

3. run: Just start the harvester now. Used to test the harvesting.

Request

A set of ids to operate on. Example:

<request>

<id>123</id>

<id>456</id>

<id>789</id>

</request>

If the request is empty, nothing is done.

Response

The same as the request but every id has a status attribute indicating the success or failure of theoperation. For example, the response to the previous request could be:

<request>

<id status="ok">123</id>

<id status="not-found">456</id>

<id status="inactive">789</id>

</request>

XML Services


Table 19.3, “Summary of status values” summarises, for each service, the possible status values.

Table 19.3. Summary of status values

Status value remove start stop run

ok + + + +

not-found + + + +

inactive - - - +

already-inactive - - + -

already-active - + - -

already-running - - - +

19.4 System configuration

Introduction

The GeoNetwork’s configuration is made up of a set of parameters that can be changed to accommodateany installation need. These parameters are subdivided into 2 groups:

• parameters that can be easily changed through a web interface.

• parameters not accessible from a web interface and that must be changed when the system is notrunning.

The first group of parameters can be queried or changed through 2 services: xml.config.get andxml.config.update. The second group of parameters can be changed using the GAST tool.

xml.config.get

This service returns the system configuration’s parameters.

Request

No parameters are needed.

Response

The response is an XML tree similar to the system hierarchy into the settings structure. The responsehas the following elements:


• name: Site’s name.

• organisation: Site’s organisation name.

• server: A container for server information.

• host: Name of the host from which the site is reached.

• port: Port number of the previous host.

• Intranet: Information about the Intranet of the organisation.

XML Services


• network: IP address that specifies the network.

• netmask: netmask of the network.

• z3950: Configuration about Z39.50 protocol.

• enable: true means that the server component is running.

• port: Port number to use to listen for incoming Z39.50 requests.

• proxy: Proxy configuration

• use: true means that the proxy is used when connecting to external nodes.

• host: Proxy’s server host.

• port: Proxy’s server port.

• username: Proxy’s credentials.

• password: Proxy’s credentials.

• feedback: A container for feedback information

• email: Administrator’s email address

• mailServer: Email server to use to send feedback

• host: Email’s host address

• port: Email’s port to use in host address

• removedMetadata: A container for removed metadata information

• dir: Folder used to store removed metadata in MEF format

• ldap: A container for LDAP parameters

• use:

• host:

• port:

• defaultProfile:

• login:

• userDN:

• password:

• distinguishedNames:

• base:

• users:

XML Services


• userAttribs:

• name:

• password:

• profile:

Figure 19.19, “Example of xml.config.get response” shows an example of xml.config.get response.

XML Services


<config>

<site>

<name>dummy</name>

<organisation>dummy</organization>

</site>

<server>

<host>localhost</host>

<port>8080</port>

</server>

<Intranet>

<network>127.0.0.1</network>

<netmask>255.255.255.0</netmask>

</intranet>

<z3950>

<enable>true</enable>

<port>2100</port>

</z3950>

<proxy>

<use>false</use>

<host/>

<port/>

<username>proxyuser</username>

<password>proxypass</password>

</proxy>

<feedback>

<email/>

<mailServer>

<host/>

<port>25</port>

</mailServer>

</feedback>

<removedMetadata>

<dir>WEB-INF/removed</dir>

</removedMetadata>

<ldap>

<use>false</use>

<host />

<port />

<defaultProfile>RegisteredUser</defaultProfile>

<login>

<userDN>cn=Manager</userDN>

<password />

</login>

<distinguishedNames>

<base>dc=fao,dc=org</base>

<users>ou=people</users>

</distinguishedNames>

<userAttribs>

<name>cn</name>

<password>userPassword</password>

<profile>profile</profile>

</userAttribs>

</ldap>

</config>

Figure 19.19. Example of xml.config.get response

xml.config.update

This service is used to update the system’s information and so it is restricted to administrators.

XML Services


Request

The request format must have the same structure returned by the xml.config.get service and cancontain only elements that the caller wants to be updated. If an element is not included, it will not beupdated. However, when included some elements require mandatory information (i.e. the value cannotbe empty). Please, refer to Table 19.4, “Mandatory and optional parameters for the xml.config.updateservice”.

XML Services


Table 19.4. Mandatory and optional parameters for the xml.config.update service

Parameter Type Mandatory

site/name string yes

site/organization string -

server/host string yes

server/port integer -

intranet/network string yes

intranet/netmask string yes

z3950/enable bool yes

z3950/port integer -

proxy/use bool yes

proxy/host string -

proxy/port integer -

proxy/username string -

proxy/password string -

feedback/email string -

feedback/mailServer/host string -

feedback/mailServer/port integer -

removedMetadata/dir string yes

ldap/use bool yes

ldap/host string -

ldap/port integer -

ldap/defaultProfile string yes

ldap/login/userDN string yes

ldap/login/password string -

ldap/distinguishedNames/base string yes

ldap/distinguishedNames/users string yes

ldap/userAttribs/name string yes

ldap/userAttribs/password string yes

ldap/userAttribs/profile string -

XML Services


Response

On success, the service returns a response element with the OK text. Example:

<response>ok</response>

Otherwise a proper error element is returned.

19.5 MEF services

Introduction

This chapter describes the services related to the Metadata Exchange Format. These services allow toimport/export metadata using the MEF format.

mef.export

As the name suggests, this service exports a GeoNetwork’s metadata using the MEF file format.

This service is public but metadata access rules apply. For a partial export, the view privilege is enoughbut for a full export the download privilege is also required. Without a login step, only partial exportson public metadata are allowed.

This service uses the system’s temporary directory to build the MEF file. With full exports of big datamaybe it is necessary to change this directory. In this case, use the Java’s -D command line option toset the new directory before running GeoNetwork (if you use Jetty, simply change the script into thebin directory).

Request

This service accepts requests in GET/POST and XML form. The input parameters are:

UUID the universal unique identifier of the metadata

format which format to use. Can be one of: simple, partial, full.

skipUuid If provided, tells the exporter to not export the metadata’s UUID. Without the UUID (which isa unique key inside the database) the metadata can be imported over and over again. Can be one of:true, false. The default value is false.

Response

The service’s response is a MEF file with these characteristics:

• the name of the file is the metadata’s UUID

• the extension of the file is mef

mef.import

This service is reserved to administrators and is used to import a metadata provided in the MEF format.

Request

The service accepts a multipart/form-data POST request with a single mefFile parameter thatmust contain the MEF information.

XML Services


Response

If all goes well, the service returns an OK element containing the local id of the created metadata.Example:

<ok>123</ok>

Metadata ownership

Version 1.0 of the MEF format does not take into account the metadata owner (the creator) and thegroup owner. This implies that this information is not contained into the MEF file. During import, the userthat is performing this operation will become the metadata owner and the group owner will be set to null.

19.6 Relations

Introduction

This chapter describes general services used to get and set relations between metadata records insideGeoNetwork. The association is performed by a Relations table which stores a metadata id and ametadata relatedId fields (see Table 19.5, “Structure of table Relations”).

Table 19.5. Structure of table Relations

Field Datatype Description

id foreign key to Metadata(id) Source metadata whose relation is beingdescribed.

relatedId foreign key to Metadata(id) Metadata related to the source one

xml.relation.get

This service retrieves all relations between metadata.

Request

The request accepts an id and a relation parameters, whose meaning is this:

• id (integer): This is the local GeoNetwork identifier of the metadata whose relations are requested.

• relation (string, ’normal’): This optional parameter identifies the kind of relation that the client wantsto be returned. It can be one of these values:

• normal: The service performs a query into the id field and returns all relatedId records.

• reverse: The service performs a query into the relatedId field and returns all id records.

• full: Includes both normal and reverse queries (duplicated ids are removed).

Here is an example of POST/XML request:

<request>

<id>10</id>

<relation>full</relation>

</request>

XML Services


Response

The response has a response root element with several metadata children depending on the relationsfound. Example:

<response>

<metadata>...</metadata>

<metadata>...</metadata>

...

</response>

Each metadata element has the following structure:

• title: Metadata title

• abstract: A brief explanation of the metadata

• keyword: Keywords found inside the metadata

• image: Information about thumbnails

• link: A link to the source site

• geoBox: coordinates of the bounding box

• geonet:info: A container for GeoNetwork related information

<metadata>

<title>Globally threatened species of the world</title>

<abstract> Contains information on animals.</abstract>

<keyword>biodiversity</keyword>

<keyword>endangered animal species</keyword>

<keyword>endangered plant species</keyword>

<link type="url">http://www.mysite.org</link>

<geoBox>

<westBL>-180.0</westBL>

<eastBL>180.0</eastBL>

<southBL>-90.0</southBL>

<northBL>90.0</northBL>

</geoBox>

<geonet:info>

<id>11</id>

<schema>fgdc-std</schema>

<createDate>2005-03-31T19:13:31</createDate>

<changeDate>2007-03-12T14:52:46</changeDate>

<isTemplate>n</isTemplate>

<title/>

<source>38b75c1b-634b-443e-9c36-a12e89b4c866</source>

<UUID>84b4190b-de43-4bd7-b25f-6ed47eb239ac</uuid>

<isHarvested>n</isHarvested>

<view>true</view>

<admin>false</admin>

<edit>false</edit>

<notify>false</notify>

<download>true</download>

<dynamic>false</dynamic>

<featured>false</featured>

</geonet:info>

</metadata>

Figure 19.20. Example of a metadata record

XML Services


19.7 Schema information

Introduction

GeoNetwork is able to handle several metadata schema formats. Up to now, the supported schemasare:

• ISO-19115 (iso19115): GeoNetwork implements an old version of the draft, which uses short namesfor elements. This is not so standard so this schema is obsolete and will be removed in future releases.

• ISO-19139 (iso19139): This is the XML encoding of the ISO 19115:2007 metadata and ISO 19119service metadata specifications.

• Dublin core (dublin-core): This is a simple metadata schema based on a set of elements capable ofdescribing any metadata.

• FGDC (fgdc-std): It stands for Federal Geographic Data Committee and it is a metadata schema usedin North America.

In parenthesis is indicated the name used by GeoNetwork to refer to that schema. These schemas arehandled through their XML schema files (XSD), which GeoNetwork loads and interprets to allow theeditor to add and remove elements. Beside its internal use, GeoNetwork provides some useful XMLservices to find out some element properties, like label, description and so on.

xml.schema.info

This service returns information about a set of schema elements or codelists. The returned informationconsists of a localised label, a description, conditions that the element must satisfy etc...

Request

Due to its nature, this service accepts only the POST binding with application/XML content type. Therequest can contain several element and codelist elements. Each element indicate the will to retrieveinformation for that element. Here follows the element descriptions:

• element: It must contain a schema and a name attribute. The first one must be one of the supportedschemas (see the section above). The second must be the qualified name of the element whichinformation must be retrieved. The namespace must be declared into this element or into the rootelement of the request.

• codelist: Works like the previous one but returns information about codelists.

<request xmlns:gmd="http://www.isotc211.org/2005/gmd">

<element schema="iso19139" name="gmd:constraintLanguage" />

<codelist schema="iso19115" name="DateTypCd" />

</request>

Note

The returned text is localised depending on the language specified during the service call. A call to /geonetwork/srv/en/xml.schema.info will return text in the English language.

Response

The response’s root element will be populated with information of the elements/codelists specified intothe request. The structure is the following:

XML Services


• element: A container for information about an element. It has a name attribute which contains thequalified name of the element.

• label: The human readable name of the element, localised into the request’s language.

• description: A generic description of the element.

• condition [0..1]: This element is optional and indicates if the element must satisfy a condition, likethe element is always mandatory or is mandatory if another one is missing.

• codelist: A container for information about a codelist. It has a name attribute which contains thequalified name of the codelist.

• entry [1..n]: A container for a codelist entry. There can be many entries.

• code: The entry’s code. This is the value that will be present inside the metadata.

• label: This is a human readable name, used to show the entry into the user interface. It is localised.

• description: A generic localised description of the codelist.

<response>

<element name="gmd:constraintLanguage">

<label>Constraint language</label>

<description>language used in Application Schema</description>

<condition>mandatory</condition>

</element>

<codelist name="DateTypCd">

<entry>

<code>creation</code>

<label>Creation</label>

<description>date when the resource was brought into existence</description>

</entry>

<entry>

<code>publication</code>

<label>Publication</label>

<description>date when the resource was issued</description>

</entry>

<entry>

<code>revision</code>

<label>Revision</label>

<description>date identifies when the resource was examined

or re-examined and improved or amended</description>

</entry>

</codelist>

</response>

Error management

Beside the normal exceptions management, the service can encounter some errors trying to retrievean element/codelist information. In this case, the object is copied verbatim to the response with theaddition of an error attribute that describes the encountered error. The returned errors are describedin Table 19.6, “Possible errors returned by xml.schema.info service”. Here follows an example of suchresponse:

<response>

<element schema="iso19139" name="blablabla" error="not-found"/>

</response>

XML Services


Table 19.6. Possible errors returned by xml.schema.info service

Error code Description

unknown-schema The specified schema is not supported

unknown-namespace The namespace of the specified prefix was not found

not-found The requested element / codelist was not found


20. Settings hierarchy

20.1 Introduction

GeoNetwork stores many options and information inside the Settings table. Information is grouped intohierarchies where each node has a key/value pair and can have many children. Each key is limited to32 characters while each value is limited to 250. The 2 top level hierarchies are system and harvesting.

In the following sections, the indentation is used to show hierarchies. Names in bold represent keyswith the value’s datatype in parenthesis. An italic font is used to indicate basic types (string, integer,boolean) while normal font with a | is used to represent a set of allowed values. Regarding the booleantype, value can be only true or false. A missing datatype means that the value of the node is not used.Square brackets indicate cardinality. If they are missing, a cardinality of [1..1] should be considered.

20.2 The system hierarchy

• site: Contains information about the site

• name (string): Name used to present this site to other sites. Used to fill comboboxes or lists.

• organisation (string): Name of the organization/company/institute that is running GeoNetwork

• siteId (string): A UUID that uniquely identifies the site. It is generated by the installer.

• platform: Contains information about the current version

• version (string): GeoNetwork’s version in the X.Y.Z format

• subVersion (string): A small description about the version, like ’alpha-1’, ’beta’ etc...

• server: Used when it is necessary to build absolute URLs to the GeoNetwork server. This is the case,for example, when creating links inside a metadata or when providing CSW capabilities.

• host (string): Main HTTP server’s address

• port (integer): Main HTTP server’s port (can be empty)

• Intranet: specify the network of the Intranet

• network (string): Network’s address

• netmask (string): Network’s netmask

• z3950: A container for Z39.50 server parameters

• enable (boolean): If true, GeoNetwork will start the Z30.50 server

• port (integer): The port opened by GeoNetwork to listen to Z39.50 requests. Usually is 2100.

• proxy: This container specify proxy configuration to use

• use (boolean): If true, GeoNetwork will use the given proxy for outgoing connections

• host (string): Proxy’s host

• port (integer): Proxy’s port

Settings hierarchy


• username (string): Proxy’s credentials.

• password (string): Proxy’s credentials.

• feedback: Feedback is sent with proper web form or when downloading a resource.

• email (string): email address of a GeoNetwork administrator or someone else

• mailServer: This container represents the mail server that will be used to send email

• host (string): Address of the SMTP server to use

• port (string): SMTP port to use

• removedMetadata: This container contains settings about removed metadata.

• dir: This folder will contain removed metadata in MEF format. It gets populated when the userdeletes a metadata using the web interface.

• LDAP: Parameters for LDAP authentication

• use (boolean)

• host (string)

• port (integer)

• defaultProfile (string): Default GeoNetwork’s profile to use when the profile user attribute does notexist.

• login

• userDN (string)

• password (string)

• distinguishedNames

• base (string)

• users (string)

• userAttribs: A container for user attributes present into the LDAP directory that must be retrievedand used to create the user in GeoNetwork.

• name (string)

• password (string)

• profile (string)

20.3 Harvesting nodes

The second top level hierarchy is harvesting. All nodes added using the web interface are stored here.Each child has node in its key and its value can be GeoNetwork, WebDAV, CSW or another dependingon the node type.

Settings hierarchy


All harvesting nodes share a common setting structure, which is used by the harvesting engine to retrievethese common parameters. This imply that any new harvesting type must honour this structure, whichis the following:


• name (string): Node name as shown in the harvesting list.

• UUID (string): A unique identifier assigned by the system when the harvesting node is created.

• useAccount (boolean): Indicates if the harvester has to authenticate to access the data.

• username (string):

• password (string):

• options:

• every (integer): Timeout, in minutes, between 2 consecutive harvesting.

• oneRunOnly (boolean): If true, the harvester will harvest one time from this node and then it willset the status to inactive.

• status (active|inactive): Indicates if the harvesting from this node is stopped (inactive) or if theharvester is waiting until the timeout comes.

• privileges [0..1]: This is a container for privileges to assign to each imported metadata

• group (integer) [0..n]: Indicate a local group. The node’s value is its local identifier. There can beseveral group nodes each with its set of privileges.

• operation (integer) [0..n]: Privilege to assign to the group. The node’s value is the numeric id ofthe operation like 0=view, 1=download, 2=edit etc...

• categories [0..1]: This is a container for categories to assign to each imported metadata

• category (integer) [0..n]: Indicate a local category and the node’s value is its local identifier.

• info: Just a container for some information about harvesting from this node.

• lastRun (string): If not empty, tells when the harvester harvested from this node. The value is thecurrent time in milliseconds since 1 January, 1970.

Privileges and categories nodes can or cannot be present depending on the harvesting type. In thefollowing structures, this common structure is not shown. Only extra information specific to the harvestingtype is described.

Nodes of type GeoNetwork

This is the native harvesting supported by GeoNetwork 2.1 and above.

• site: Contains host and account information

• host (string)

• port (integer)

Settings hierarchy


• servlet (string)

• search [0..n]: Contains the search parameters. If this element is missing, an unconstrained searchwill be performed.

• freeText (string)

• title (string)

• abstract (string)

• keywords (string)

• digital (boolean)

• hardcopy (boolean)

• source (string)

• groupsCopyPolicy [0..n]: Represents a copy policy for a remote group. It is used to maintain remoteprivileges on harvested metadata.

• name (string): Internal name (not localised) of a remote group.

• policy (string): Copy policy. For the group all, policies are: copy, copyToIntranet. For all othergroups, policies are: copy, createAndCopy. The Intranet group is not considered.

Nodes of type geonetwork20

This type allows harvesting from older GeoNetwork 2.0.x nodes.

• site: Contains host and account information

• host (string)

• port (integer)

• servlet (string)

• search [0..n]: Contains the search parameters. If this element is missing no harvesting will beperformed but the host’s parameters will be used to connect to the remote node.


• title (string)


• keywords (string)

• digital (boolean)

• hardcopy (boolean)

• siteId (string)

Settings hierarchy


Nodes of type WebDAV

This harvesting type is capable of connecting to a web server which is WebDAV enabled.

• Site: Contains the URL to connect to and account information

• URL (string): URL to connect to. Must be well formed, starting with ’http://’, ’file://’ or a supportedprotocol.

• Icon (string): This is the icon that will be used as the metadata source’s logo. The image is takenfrom the images/harvesting folder and copied to the images/logos folder.

• options

• Recurse (boolean): Indicates if the remote folder must be recursively scanned for metadata.

• Validate (boolean): If set, the harvester will validate the metadata against its schema and themetadata will be harvested only if it is valid.

Nodes of type CSW

This type of harvesting is capable of querying a Catalogue Services for the Web (CSW) server andretrieving all found metadata.

• site

• capabUrl (string): URL of the capabilities file that will be used to retrieve the operations address.

• icon (string): This is the icon that will be used as the metadata source’s logo. The image is takenfrom the images/harvesting folder and copied to the images/logos folder.

• search [0..n]: Contains search parameters. If this element is missing, an unconstrained search willbe performed.


• title (string)


• subject (string)


Appendix A. Frequently AskedQuestionsA.1. Users FAQ

A.1.1.Where do I learn more about the use and functionality of the GeoNetwork opensource catalog?

The Quick Start Guide will provide you with an excellent first introduction. The Guide can bedownloaded from the GeoNetwork Community website1

A.2. Administrators FAQ

A.2.1.I want to run GeoNetwork on another port than port 8080. What should I do?

To change the default port 8080, take the following steps:

1. Change the servlet engine configuration. When running on the embedded Jetty, theconfiguration file to change is bin/jetty.xml

2. Search intermap/WEB-INF/config.xml for 8080 and change it to the new port number

3. Change the map service URLs for the local GeoServer layers that GeoNetwork connects to bydefault. The file to change is web/intermap/WEB-INF/mapServers.xml

4. On Windows systems, change the startup script bin/win/start-stdln.html

5. Start the GeoNetwork application and login as Administrator. In the System configuration panelyou will need to change the Server port number

6. If you changed the port number after uploading data in the system while using another port,you may need to start GAST and run the Metadata Sync in order to update the download linksin the metadata.

Other affected, but non-critical files:

• geonetwork/xml/csw/test/csw-Harvest.xml

• geonetwork/xml/schemas/iso19139/process/thumbnails-host-url-relocator.xsl

• geonetwork/xml/validation/csw202_apiso100/csw/2.0.2/examples/wsdl/2.0.2/service.wsdl

• intermap/static/iframepoc.html

A.2.2.I am having difficulty installing multiple instances of GeoNetwork on the same server

To run multiple installation you have to change the ports that GeoNetwork uses in order to avoidconflicts. The ports are:

• Z39.50 listening port. This is the most probable source of conflicts. You can change the portin the System preferences panel under Administrative tools. Use for example 2101 but keepin mind that remote nodes usually use 2100 so your second node will not be reachable. Youcannot use the system configuration web form the first time because if the port conflicts, theserver won't start.


Frequently Asked Questions


• If you are using Jetty.

• Jetty's listening port. This can be modified in the bin/jetty.xml configuration file. Thedefault value is 8080. To run a second installation use a different value, like 8081.

• Jetty's stop port. This is defined into the scripts bin/start-geonetwork.* and bin/stop-geonetwork.* (for both Windows and Linux). The provided value is 8079 as the valueof the STOP.PORT parameter. Use another value for the second installation, like 8078. If youdon't change this value, the stop script will stop all instances.

• If you are using the embedded McKoi DBMS.

• McKoi listening port. This can be easily modified using GAST. The default value is 9157.For other installations you can use 9158, 9159 and so on. The affected files are web/WEB-INF/config.xml and web/WEB-INF/db/db.conf.

A.2.3.What is normally logged when running GeoNetwork opensource?

GeoNetwork has its own internal logging based on log4j Logging services2 (written by defaultto the file jetty/logs/geonetwork.log and jetty/logs/intermap.log for Intermapapplication). Additionaly there are log files generated by the web server (Jetty3 , Apache Tomcat4

etc..) and by the DBMS used (for example by the internal McKoi SQL5 ).

A.2.4.How do I control what is written to the GeoNetwork internal log file?

The logging is configured in the files web/geonetwork/WEB-INF/log4j.cfg and web/intermap/WEB-INF/log4j.cfg. You can change the settings by editing the file in a text editor.

The default configuration uses a DailyRollingFileAppender that writes the daily log to the filelogs/geonetwork.log and at midnight is copied to the file logs/geonetwork.log.yyyy-MM-dd starting in the file logs/geonetwork.log the logging for the new day.

log4j.appender.jeeves =org.apache.log4j.DailyRollingFileAppender

log4j.appender.jeeves.DatePattern='.'yyyy-MM-dd

log4j.appender.jeeves.file = logs/geonetwork.log

The console logging is also configured to show the datetime, the log intensity of the message (seebelow), the category and the logging message.

log4j.appender.console = org.apache.log4j.ConsoleAppender

log4j.appender.console.layout = org.apache.log4j.PatternLayout

log4j.appender.console.layout.ConversionPattern=%d{ISO8601} %-5p [%c] -

%m%n

For operational systems it is suggested to put all log options to OFF or FATAL. The log optionsare, with increasing log intensity:

• OFF - The OFF Level has the highest possible rank and is intended to turn off logging.

• FATAL - The FATAL level designates very severe error events that will presumably lead theapplication to abort.

• ERROR - The ERROR level designates error events that might still allow the application tocontinue running.

http://logging.apache.org/log4j

http://jetty.mortbay.org/jetty

http://tomcat.apache.org/

http://www.mckoi.com/database/

Frequently Asked Questions


• WARN - The WARN level designates potentially harmful situations.

• INFO - The INFO level designates informational messages that highlight the progress of theapplication at coarse-grained level.

• DEBUG - The DEBUG Level designates fine-grained informational events that are most usefulto debug an application.

• ALL - The ALL Level has the lowest possible rank and is intended to turn on all logging.

A.3. Developers FAQ

A.3.1.What is Free and Open Source Software (FOSS) and how can I use, participate and contributeto the GeoNetwork opensource project?

The book "Producing Open Source Software" (shown in Figure A.1, “Producing Open SourceSoftware”) is a highly recommended book for anyone working on open source software projects.It provides insight in all aspects of FOSS development and on how to make a project successful.If you are interested in participating in the GeoNetwork opensource project, please spend sometime reading through this book. It's definitely worth the time and money (so buy the hardcopy ifyou can afford it!).

Producing Open Source Software is a book about the human side of open source development.It describes how successful projects operate, the expectations of users and developers, and theculture of free software.

The book is available in bookstores and from the publisher (O'Reilly Media6), or you can browseor download it from http://producingoss.com/. Producing Open Source Software is released underan open copyright that allows everyone to share and modify the book freely. The latest versionis always available on the website. The online version is the same as the commercially availableprint version ? in other words, you can buy a printed copy and know that it's up-to-date.

Figure A.1. Producing Open Source Software

http://www.oreilly.com/catalog/producingoss/

http://producingoss.com/


Appendix B. Glossary of MetadataFields DescriptionThis glossary provides you with brief descriptions of the minimum set of metadata fields required toproperly describe a geographical data as well as some optional elements highly suggested for a moreextensive standard description.

Access constraints. Access constraints applied to assure the protection of privacy or intellectualproperty, and any special restrictions or limitations on obtaining the resource

Abstract. Brief narrative summary of the content of the resource(s)

Administrative area. State, province of the location

* Temporal extent - Begin date. Formatted as 2007-09-12T15:00:00 (YYYY-MM-DDTHH:mm:ss)

Character set. Full name of the character coding standard used for the metadata set

Grid spatial representation - Cell geometry. Identification of grid data as point or cell

City. City of the location

Reference System Info - Code. Alphanumeric value identifying an instance in the namespace

Country. Country of the physical address

Data quality info. Provides overall assessment of quality of a resource(s)

Date. Reference date and event used to describe it (YYYY-MM-DD)

Date stamp. Date that the metadata was created (YYYY-MM-DDThh:mm:ss)

Date type. Event used for reference date

Delivery point. Address line for the location (as described in ISO 11180, annex A)

Equivalent scale - Denominator. The number below the line in a vulgar fraction

Data Quality - Description. Description of the event, including related parameters or tolerances

OnLine resource - Description. Detailed text description of what the online resource is/does

Descriptive keywords. Provides category keywords, their type, and reference source

Grid spatial representation - Dimension name. Name of the axis i.e. row, column

Grid spatial representation - Dimension size. Number of elements along the axis

Dimension size Resolution. Number of elements along the axis

Distribution info. Provides information about the distributor of and options for obtaining theresource(s)

Geographic bounding box - East bound longitude. Eastern-most coordinate of the limit of thedataset extent, expressed in longitude in decimal degrees (positive east)

Glossary of Metadata Fields Description


Edition. Version of the cited resource

Electronic mail address. Address of the electronic mailbox of the responsible organisation orindividual

Temporal extent - End date. Formatted as 2007-09-12T15:00:00 (YYYY-MM-DDTHH:mm:ss)

Equivalent scale. Level of detail expressed as the scale of a comparable hardcopy map or chart

Extent. Information about spatial, vertical, and temporal extent

Facsimile. Telephone number of a facsimile machine for the responsible organisation or individual

File identifier. Unique identifier for this metadata file

Vector spatial representation - Geometric object type. Name of point and vector spatial objectsused to locate zero-, one-and two-dimensional spatial locations in the dataset

Vector spatial representation - Geometric object count. Total number of the point or vector objecttype occurring in the dataset

Geographic bounding box. Geographic position of the dataset

Grid spatial representation. Information about grid spatial objects in the dataset

Grid spatial representation - Resolution value. Degree of detail in the grid dataset

Grid spatial representation - Transformation parameter availability. Indication of whether or notparameters for transformation exists

Data Quality - Hierarchy level. Hierarchical level of the data specified by the scope

Identification info. Basic information about the resource(s) to which the metadata applies

Point of Contact - Individual name. Name of the responsible person- surname, given name, titleseparated by a delimiter

Keyword. Commonly used word(s) or formalised word(s) or phrase(s) used to describe the subject

Data Language. Language used for documenting data

Metadata - Language. Language used for documenting metadata

Data Quality - Lineage. Non-quantitative quality information about the lineage of the data specifiedby the scope. Mandatory if report not provided

OnLine resource - Linkage. Location (address) for on-line access using a Uniform Resource Locatoraddress or similar addressing scheme such as http://www.statkart.no/isotc211

Maintenance and update frequency. Frequency with which changes and additions are made to theresource after the initial resource is completed

Metadata author. Party responsible for the metadata information

Metadata standard name. Name of the metadata standard (including profile name) used

Metadata standard version. Version (profile) of the metadata standard used



OnLine resource - Name. Name of the online resource

Geographic bounding box - North bound latitude. Northern-most, coordinate of the limit of thedataset extent expressed in latitude in decimal degrees (positive north)

Grid spatial representation - Number of dimensions. Number of independent spatial-temporalaxes

Distribution Info - OnLine resource. Information about online sources from which the resource canbe obtained

Point of Contact - Organisation name. Name of the responsible organisation

Other constraints. Other restrictions and legal prerequisites for accessing and using the resource

Point of contact. Identification of, and means of communication with, person(s) and organisations(s)associated with the resource(s)

Point of contact - Position name. Role or position of the responsible person

Postal code. ZIP or other postal code

Presentation form. Mode in which the resource is represented

OnLine resource - Protocol. Connection protocol to be used

Purpose. Summary of the intentions with which the resource(s) was developed

Reference system info. Description of the spatial and temporal reference systems used in thedatasetData

Data Quality - Report. Quantitative quality information for the data specified by the scope. Mandatoryif lineage not provided

Grid spatial representation - Resolution value. Degree of detail in the grid dataset

Point of contact - Role. Function performed by the responsible party

Geographic bounding box - South bound latitude. Southern-most coordinate of the limit of thedataset extent, expressed in latitude in decimal degrees (positive north)

Spatial representation info. Digital representation of spatial information in the dataset

Spatial representation type. Method used to spatially represent geographic information

Data Quality - Statement. General explanation of the data producer's knowledge about the lineageof a dataset

Status. Status of the resource(s)

Supplemental Information. Any other descriptive information about the dataset

Temporal Extent. Time period covered by the content of the dataset

Title. Name by which the cited resource is known

Topic category code. High-level geographic data thematic classification to assist in the groupingand 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 useris encouraged to select the one most appropriate.

Grid spatial representation - Transformation parameter availability. Indication of whether or notparameters for transformation exists

Vector spatial representation - Topology level. Code which identifies the degree of complexity ofthe spatial relationships

Type. Subject matter used to group similar keywords

URL. Unified Resource Locator

Use constraints. Constraints applied to assure the protection of privacy or intellectual property, andany special restrictions or limitations or warnings on using the resource

Vector spatial representation. Information about the vector spatial objects in the dataset

Voice. Telephone number by which individuals can speak to the responsible organisation or individual

Geographic bounding box - West bound longitude. Western-most coordinate of the limit of thedataset extent, expressed in longitude in decimal degrees (positive east)


Appendix C. ISO Topic CategoriesIso Topic Categories and Keywords

ISO Topic Categories



Appendix D. Free and Open SourceSoftware for Geospatial InformationSystemsA range of related software packages can be used in addition to GeoNetwork opensource to deploya full Spatial Data Infrastructure. These include Web Map Server software, GIS desktop applicationsand Web Map Viewers.

Below you will find some examples of open source software available for each categories.

D.1 Web Map Server software

• GeoServer (All)1 http://www.geoserver.org

• MapServer (All) http://www.mapserver.org/

• MapGuide Open Source (Windows & Linux) http://www.osgeo.org/mapguide

• Deegree (All) http://www.osgeo.org/deegree

D.2 GIS Desktop software

• GRASS (All) http://www.osgeo.org/grass

• gvSIG (All) http://www.gvsig.gva.es/

• uDig (All) http://udig.refractions.net

• Quantum GIS (All) http://www.osgeo.org/qgis

• OSSIM (Windows & OSX) http://www.osgeo.org/ossim

D.3 Web Map Viewer and Map Server Management

• OpenLayers (All) http://www.osgeo.org/openlayers

• MapBender (All) http://www.osgeo.org/mapbender

http://www.geoserver.org

http://www.mapserver.org/

http://www.osgeo.org/mapguide

http://www.osgeo.org/deegree

http://www.osgeo.org/grass

http://www.gvsig.gva.es/

http://udig.refractions.net

http://www.osgeo.org/qgis

http://www.osgeo.org/ossim

http://www.osgeo.org/openlayers

http://www.osgeo.org/mapbender


GlossaryCSW Catalog Service for the Web. The OGC Catalog Service defines

common interfaces to discover, browse, and query metadata aboutdata, services, and other potential resources.See Also OGC.

ISO International Standards Organisation is an international-standard-setting body composed of representatives from various nationalstandards organizations. http://www.iso.org.See Also ISO TC211.

ISO TC211 ISO/TC 211 is a standard technical committee formed within ISO,tasked with covering the areas of digital geographic information (suchas used by geographic information systems) and geomatics. It isresponsible for preparation of a series of International Standards andTechnical Specifications numbered in the range starting at 19101.

GeoNetwork GeoNetwork opensource is a standards based, Free and Open Sourcecatalog application to manage spatially referenced resources throughthe web.http://geonetwork-opensource.org

GN See GeoNetwork.

XML Extensible Markup Language is a general-purpose specification forcreating custom markup languages.

XSD XML Schema, published as a W3C recommendation in May 2001, isone of several XML schema languages. http://en.wikipedia.org/wiki/XSD

DB (or DBMS) A database management system (DBMS) is computer software thatmanages databases. DBMSes may use any of a variety of databasemodels, such as the network model or relational model. In largesystems, a DBMS allows users and other software to store and retrievedata in a structured way.

SOA Service Oriented Architecture provides methods for systemsdevelopment and integration where systems package functionalityas interoperable services. A SOA infrastructure allows differentapplications to exchange data with one another.

FGDC The Federal Geographic Data Committee (FGDC) is an interagencycommittee that promotes the coordinated development, use, sharing,and dissemination of geospatial data on a national basis in the USA.See http://www.fgdc.gov

SOAP Simple Object Access Protocol is a protocol specification forexchanging structured information in the implementation of WebServices in computer networks.

OGC Open Geospatial Consortium. A standards organization for geospatialinformation systems http://www.opengeospatial.org

http://www.iso.org


http://en.wikipedia.org/wiki/XSD

http://en.wikipedia.org/wiki/XSD

http://www.fgdc.gov

http://www.opengeospatial.org

Glossary


OSGeo The Open Source Geospatial Foundation (OSGeo), is a non-profit non-governmental organization whose mission is to support and promotethe collaborative development of open geospatial technologies anddata. http://www.osgeo.org

FAO Food and Agriculture Organisation of the United Nations is aspecialised agency of the United Nations that leads international effortsto defeat hunger. http://www.fao.org

WFP World Food Programme of the United Nations is the food aid branch ofthe United Nations, and the world's largest humanitarian organization.http://www.wfp.org

UNEP The UN Environment Programme (UNEP) coordinates UnitedNations environmental activities, assisting developing countriesin implementing environmentally sound policies and encouragessustainable development through sound environmental practices.http://www.unep.org

OCHA United Nations Office for the Coordination of Humanitarian Affairs isdesigned to strengthen the UN's response to complex emergenciesand natural disasters. http://ochaonline.un.org/

URL A Uniform Resource Locator specifies where an identified resource isavailable and the mechanism for retrieving it.

GAST GeoNetwork Administrator Survival Tool. A desktop application thatallows administrators of a GeoNetwork catalog to perform a range ofadmin operations.

WebDAV Web-based Distributed Authoring and Versioning. WebDAV is a set ofextensions to the Hypertext Transfer Protocol (HTTP) that allows usersto edit and manage files collaboratively on remote World Wide Webservers.

OAI-PMH Open Archive Initiative Protocol for Metadata Harvesting. It is aprotocol developed by the Open Archives Initiative. It is used to harvest(or collect) the metadata descriptions of the records in an archive sothat services can be built using metadata from many archives.

WMS Web Map Service is a standard protocol for serving georeferenced mapimages over the Internet that are generated by a map server usingdata from a GIS database. The specification was developed and firstpublished by the Open Geospatial Consortium in 1999.See Also OGC.

WFS Web Feature Service provides an interface allowing requests forgeographical features across the web using platform-independentcalls. One can think of geographical features as the "source code"behind a map.See Also OGC.


http://www.fao.org

http://www.wfp.org

http://www.unep.org

http://ochaonline.un.org/

Glossary


WCS Web Coverage Service provides an interface allowing requests forgeographical coverages across the web using platform-independentcalls. The coverages are objects (or images) in a geographical areaSee Also OGC.

WPS Web Processing Service is designed to standardize the way that GIScalculations are made available to the Internet. WPS can describe anycalculation (i.e. process) including all of its inputs and outputs, andtrigger its execution as a Web Service.See Also OGC.

UUID A Universally Unique Identifier (UUID) is an identifier standard used insoftware construction, standardized by the Open Software Foundation(OSF) as part of the Distributed Computing Environment (DCE).

MAC address Media Access Control address (MAC address) is a unique identifierassigned to most network adapters or network interface cards (NICs)by the manufacturer for identification, and used in the Media AccessControl protocol sublayer. See also MAC address2 on Wikipedia

MEF Metadata Exchange Format. An export format developed by theGeoNetwork community. More details can be found in this manual inChapter Metadata Exchange Format.

SKOS The Simple Knowledge Organisation Systems (SKOS) http://www.w3.org/2004/02/skos/ is an area of work developingspecifications and standards to support the use of knowledgeorganisation systems (KOS) such as thesauri, classification schemes.

Z39.50 protocol Z39.50 is a client-server protocol for searching and retrievinginformation from remote computer databases. It is covered by ANSI/NISO standard Z39.50, and ISO standard 23950. The standard'smaintenance agency is the Library of Congress.

SMTP Simple Mail Transfer Protocol is an Internet standard for electronic mail(e-mail) transmission across Internet Protocol (IP) networks.

LDAP Lightweight Directory Access Protocol is an application protocol forquerying and modifying directory services running over TCP/IP.

Shibboleth The Shibboleth System is a standards based, open source softwarepackage for web single sign-on across or within organisationalboundaries. It allows sites to make informed authorisation decisions forindividual access of protected online resources in a privacy-preservingmanner.

DC The Dublin Core metadata element set is a standard for cross-domaininformation resource description. It provides a simple and standardisedset of conventions for describing things online in ways that make themeasier to find.

ESA European Space Agency is an intergovernmental organisationdedicated to the exploration of space. http://www.esa.int

http://en.wikipedia.org/wiki/MAC_address

http://www.w3.org/2004/02/skos/

http://www.w3.org/2004/02/skos/

http://www.esa.int

Glossary


FOSS Free and Open Source Software, also F/OSS, FOSS, or FLOSS (free/libre/open source software) is software which is liberally licensed togrant the right of users to study, change, and improve its designthrough the availability of its source code. http://en.wikipedia.org/wiki/FOSS

JDBC The Java Database Connectivity (JDBC) API is the industry standardfor database-independent connectivity between the Java programminglanguage and a wide range of databases – SQL databases and othertabular data sources, such as spreadsheets or flat files. The JDBC APIprovides a call-level API for SQL-based database access.

JDBC technology allows you to use the Java programming languageto exploit "Write Once, Run Anywhere" capabilities for applications thatrequire access to enterprise data. With a JDBC technology-enableddriver, you can connect all corporate data even in a heterogeneousenvironment.

http://en.wikipedia.org/wiki/FOSS

http://en.wikipedia.org/wiki/FOSS


IndexAabstract, 23access constraints, 24

Ddata quality, 24date, 23descriptive keywords, 24distribution info, 24

Ggeographic bounding box, 24

Llanguage, 24login,

Mmaintenance and update frequency, 24metadata, Metadata

Dublin Core, 32FGDC, 32ISO19115, 32ISO19139, 32migrating, 33profiles, 33standards, 32transforming, 33

metadata author, 25

Oonline resource, 24other constraints, 24

Ppoint of contact, 23presentation form, 23purpose, 23

Rreference system info, 24

Sscale denominator, 24

securityaccess restrictions, 11privileges, 11roles, 11user groups, 11

spatial representation type, 24status, 23supplemental information, 24

Ttemporal extent, 24title, 23topic category, 24

Uuser constraints, 24

the complete manual - geonetwork opensource

Documents