Coordination of geographic information and geographic information systems Metadata

Coordination of geographic information and geographic information systems

Metadata

May 03COGIS Slide 2

www.e-geo.ch

May 03COGIS Slide 3

NSDI

Easy availableOptimal offer

Favorable pricesTransparency

ImpactPolitical economical profit

added value for:• public sector (Federal, Cantons, Communes)• organizations (private sector, science etc.)• General public

wider use

National Spatial Data Infrastructure (NSDI)

e-geo.chNetwork

Technicalinfrastructure

Standards Legalbases

Strategy for distri-bution and pricing

MetadataBasic Geo-information

EducationTrainingResearch

Basic Geo-services

May 03COGIS Slide 4

National Spatial Data Infrastructure (NSDI)

e-geo.chNetwork

Technicalinfrastructure

Standards Legalbases

Strategy for distri-bution and pricing

MetadataBasic Geo-information

EducationTraining

Research

Basic Geo-services

Metadata is a part of the NSDI

May 03COGIS Slide 5

• geocat.ch– Concept– Timetable– Pilot application

• The metadata model for Switzerland– GeoMeta, the swiss profile of ISO 19115– Our model-based approach– Our experiences with the implementation

• Catalog gateway protocol– Goals– Overview– Query language

Outline

May 03COGIS Slide 6

geocat.ch concept (1)

• The geocat.ch project wants to set up a metadata catalogue for GI

• Geocat.ch will permit to add, edit, manage and to search for metadata on the Internet

• It will be realised as a framework of distributed metadata and applications in a federated and heterogeneous infrastructure.

Service de découverte geocat.ch

May 03COGIS Slide 7

geocat.ch concept (2)User Interface /

Discovery Service

CatalogGateway

Directory ofServers

(Registriy)

Metadata Spatial Data

catalogadministrator gateway

manager

useruses

maintains

complies

managesmanages

has reference to

posts a query to

searches multiple

deliever entries of

CatalogServer(s)

metadatacontributor

Source: GSDI Cookbook, Version 1.1

May 03COGIS Slide 8

geocat.ch concept (3)

2 type of database are connected:– One central database: the geocat.ch database, which is accessible

to the geocat.ch search application – Distributed databases, which are connected to the Catalog

Gateway of the geocat.ch search application

3 partnership possibilities exist for the producer of data:– Partner A: they manage their metadata directly in the central

database – Partner B: they manage their metadata in their own database. To

make their metadata accessible to the geocat.ch search application, they use the import/export tool to put them in the central database.

– Partner C: they manage their metadata in their own database. The metadata is accessible, because the database is connected to the Catalog Gateway

May 03COGIS Slide 9

Schedule of geocat.ch

Model ApplicationJune to December 2001

Study of ISO 19115 and proposal of a profile for Switzerland

January to march 2002

Elicitation to 120 organisations, cantons and offices, 53 Reponses

April 2002 Workshop: presentation of the results of the elicitation

March to august 2002

A requirements specification is made with a group of 20 people (cantons, offices, organisation)

November 2002 Collaboration with EurogeographicsDecember 2002 Choice of the producer and begin of the

application developmentMay 2003 Pilot application is availableMay 2003 A new draft of a ISO 19115 profile

for SwitzerlandJune 2003 to ? Begin of a RFC (request for

comments) and the standardisation process

September 2003 Catalog Gateway protocol will be definedDecember 2003 Final application will be available

May 03COGIS Slide 10

Pilot application geocat.ch





Outline


GeoMeta the Swiss profile

• Based on ISO 19115• Additional requirements were derived from an analysis of

existing data catalogs (SIK-GIS and CDS)• ISO Standard covered most of these requirements• Swiss profile as presented at the workshop on May 22, 2002 in

Bangkok:– legal information is an additional metadata component– Multilingual support is essential (should be normative in

ISO 19115)– Several components and classes are not needed

• Since Bangkok workshop:– Model revised with the results from the elicitation and the

FDIS version


Experience with implementation of GeoMeta (I)

ISO approach of Profiles– Profiles are reductions of a

general model– This approach proved to be not

feasible in our case– Local models are not necessary

based on common model

Swiss approach– Comprehensive Swiss profile is an

extension of the core profile– All additional models are derived

from the same base model

Comprehensive

Core Localmetadatamodel

Core

Comprehensive

Localmetadatamodel

Localmetadatamodel

Localmetadatamodel


Experience with implementation of GeoMeta (II)

Responsible party can not be modeled as data type.– A specific party is responsible for several datasets– It can have different roles– Should only be stored and maintained once

Streetmap: MD_Identification

Rivermap: MD_Identification

Basemap-Metadata: MD_MetadataBasemap: MD_Identification

John: CI_ResponsibleParty

Individual Name: John DavisOrganisation Name: SwissTopo

Mary: CI_ResponsibleParty

Individual Name: Mary MillerOrganisation Name: Navtec

role: pointOfContactrole: custodian

role: distributerContact

role: owner

role: owner


From UML to XML-Schema

• External classes were moved into 19115 package• All other packages were deleted• Multiplicity removed from attribute name and defined as a

tagged value• Data types reviewed and stereotype changed where needed to

fit the semantics predefined by UML• Export from Rational Rose to XMI• Import into UML/INTERLIS-Editor• Additional data type definitions• Export to XML-Schema


Additional data type definition: Example





Outline


Goals of the protocol

• A catalog gateway protocol needs to be defined :– to manage a connection between the gateway application

(client) and an external server;– to be able to send a query from the client to the server;– for the client to be able to receive query results from the server.

• This query mechanism must be :– independent of the platform/system/vendor of both the client and

the server;– independent of the programming language used on either side;– independent of the network protocol used between the client and

the server;• The protocol must support multiple languages and spatial query

criteria • The protocol must be relatively cheap to implement


Overview of the protocol

geocat.ch Server

OverviewQuery

OverviewAnswer

DetailQuery

DetailAnswer

• The OpenGIS Catalog Service and the Z39.50 protocols were considered to be too general for a cost effective implementation.

• SOAP (Simple Object Access Protocol) was chosen. It’s an XML based wrapping structure, like the postal services which use an envelope for letters that contain questions and answers.


The query language of the protocol

Query language Description Price of the implementation

XQuery new and still unstable specification for the query of XML structures

too expensive for relational databases

SQL Standard query language for relational databases (suggested by the OpenGIS Catalog Service specifications)

too expensive for XML structures

geocat.ch solution

Only the needed functions existThe query attributes are predefined

Cheap for the relational databases and the XML structures


The geocat.ch query language solution example


• The ISO 19115 standard covered most of our requirements

• A model-based approach : Comprehensive Swiss profile is an extension of the core profile

• To realise a framework of distributed metadata and applications in a federated and heterogeneous infrastructure, a catalog gateway protocol is necessary

Conclusion

Documents

Coordination of geographic information and geographic information systems Metadata