Geo-Metadaten: Unterschied zwischen den Versionen

Aus Geoinformation HSR
Wechseln zu: Navigation, Suche
(Lösungsvorschlag)
(Lösungsvorschlag)
Zeile 24: Zeile 24:
 
== Lösungsvorschlag ==
 
== Lösungsvorschlag ==
  
Generell empfehlen wir Geo-Metadaten schnell zugänglich zu machen!  
+
Generell empfehlen wir '''Geo-Metadaten schnell zugänglich zu machen'''! Das bedingt, dass Metadaten '''intern''' rasch erfasst werden und dass '''Schnittstellen''' für den Austausch '''rasch bereitgestellt''' werden.
  
Wir stellen fest, dass zwei Geo-Metadaten-Modelle benötigt werden: Eines für den Austausch und eines für die 'interne' Verwaltung. ISO 19115/119 (und Profile wie GM03) waren bisher für den gemeinsamen Austausch gedacht. Wir plädieren dafür, dieses als Vorlage für die Verwaltungs-Modelle weiterzuverwenden, welche aber noch ergänzt werden müssen (u.a. durch Geodienste) und z.Zt. noch sehr unterschiedlich sind.
+
Wir wollen darauf hinweisen, dass '''zwei Geo-Metadaten-Modell-Arten''' benötigt werden: Eines für den Austausch und eines für die 'interne' Verwaltung.  
  
 
Folgende Regeln, Aussagen und Massnahmen sind unserer Ansicht nach wichtig:
 
Folgende Regeln, Aussagen und Massnahmen sind unserer Ansicht nach wichtig:
# '''Geo-Metadaten-Verwaltungs-Modell''': Dieses ist das Wichtigste für Daten-Provider. Es kann organisations-intern vereinbart werden. Für die Verwaltung - also das was die Datenerfasser sehen - gibt es ISO 19115/119 (und Profile wie GM03). In einer Phase der Konsolidierung kann später über den vereinfachten, verlustfreien Austausch nachgedacht werden. Wir haben gute Erfahrungen mit vereinfachten Modelle gemacht (vgl. [[GMDB]]).
+
# '''Geo-Metadaten-Verwaltungs-Modell''': Dieses ist das Wichtigste für Daten-Provider. Es kann organisations-intern vereinbart werden. Der Zeitpunkt kann selbst bestimmt werden. Um keine Zeit zu verlieren soll jetzt schon Schnittstellen-SW vorgesehen werden.  
# '''Geo-Metadaten-Austausch-Modell''': Rasch gemeinsam definieren. Dieses ist das wichtigste Modell für die Anwender-Gemeinschaft. Es gilt z.Zt. ISO 19115/119 (und Profile wie GM03-Core). Ein besseres muss schnell definiert werden (vgl. Protokoll unten).
+
# '''Geo-Metadaten-Austausch-Modell''': Dieses ist das wichtigste Modell für die Anwender-Gemeinschaft. Es muss rasch definiert werden, da gemeinsam entschieden werden muss. Es gilt z.Zt. ISO 19115/119 (und Profile wie GM03-Core). Ein besseres muss schnell definiert werden (vgl. unten). # '''Codierung des Geo-Metadaten-Austausch-Modells''': Die Codierung ist in der Schweiz z.Zt. das GM03/XML. Sobald das Geo-Metadaten-Austausch-Modell definiert ist, muss auch die Codierung festgelegt werden.
# '''Codierung des Geo-Metadaten-Austausch-Modells''': Die Codierung (z.B. für Export/Import) ist in der Schweiz z.Zt. das GM03/XML. Sobald das Geo-Metadaten-Austausch-Modell definiert ist, muss auch die Codierung festgelegt werden.
+
# '''Geo-Metadaten-Werkzeuge/-Editoren''': Webapplikationen und GIS-Desktop-spezifische Editoren werden koexistieren. Wichtig ist die Trennung in Software für die Verwaltung von Geo-Metadaten und Suchdienste. Dazwischen gibt es eine Schnittstellen-Software.  
# '''Geo-Metadaten-Werkzeuge/-Editoren''': Webapplikationen und GIS-Desktop-spezifische Editoren werden koexistieren. Unserer Einschätzung nach, sprechen mehr Vorteile für Webapplikationen, die durch Schnittstellen mit Suchdiensten und Quellsystemen verbunden sind (vgl. Abbildung).
+
# '''Geo-Metadaten-Austausch-Protokoll''' (für Suchdienste): Schnittstellen-Software für Export rasch bereitstellen, zunächst mit Dublin Core. Es gibt dafür noch kein in der GIS-Welt anerkanntes Protokoll. CSW erscheint nicht geeignet. Es gibt jedoch Lösungsansätze wie OAI-PMH. Sobald ein Geo-Metadaten-Austausch-Modell definiert ist, kann die Schnittstellen-Software angepasst werden.
# '''Geo-Metadaten-Austausch-Protokoll''' (für Suchdienste): Schnittstellen-Software für Export rasch bereitstellen (zunächst mit Dublin Core). Es gibt noch kein in der GIS-Welt anerkanntes Protokoll. CSW erscheind nicht geeignet. Es gibt jedoch Lösungsansätze wie OAI-PMH. Sobald ein Geo-Metadaten-Austausch-Modell definiert ist, kann die Schnittstellen-Software angepasst werden.
 
  
 
Diskussion:
 
Diskussion:
* Zu 1, Verwaltungs-Modell: Dieses kann selber bestimmt werden, solange die Schnittstellen (3 und 5) erfüllt werden. Erfassung, Verwaltung und Nacherfassung ist umso einfacher, je kleiner das Modell ist.
+
Zu 1 und 2, Verwaltungs- und Austauschmodelle: ISO 19115/119 und Profile wie CH-GM03 waren bisher für die Erfassung wie auch für den gemeinsamen informationsverlustfreien Austausch gedacht. Wir plädieren dafür, dieses als Vorlage für beide Modellarten weiterzuverwenden. Alle müssen sie aber noch verkleinert und ergänzt(!) werden, v.a. durch Beschreibung von Geodiensten (vgl. unten). Vorschläge dazu gibt es unten.
* Zu 2, Austausch-Modell: Es sind Diskussionen im Gange v.a. zum Geo-Metadaten-Austausch-Modell als auch zum Protokoll (= 5). Es gelten bis auf weiteres ISO 19115-Profile wie z.B. GM03-Core in der Schweiz. Metadaten gemäss Austausch-Modell sind grundsätzlich '''freie''' Daten (z.B. mit angepasster LGPL-Lizenz). Man beachte: Geo-Metadaten über Geodaten können Verweise auf Dateien haben, es können aber auch auf Webdienste wie WMS/WFS zeigen! Wir sprechen hier bei WMS/WFS von Data Access Services, die zu den Geodaten-Beschreibung gehören und keine eigenständigen Geo-Webservices sind. Geo-Filterdienste hingegen sind eigenständige Geo-Webdienste, z.B. Webdienste zu Koordinatentransformation, zur Datenkonversion.
+
* Zu 1, Verwaltungs-Modell: Dieses kann selber bestimmt werden, solange die Schnittstellen (3 und 5) erfüllt werden. Für die Verwaltung aus Sicht Datenerfasser sehen gibt es ISO 19115/119 (und Profile wie GM03). In einer Phase der Konsolidierung kann später über den vereinfachten, verlustfreien Austausch nachgedacht werden. Wir haben gute Erfahrungen mit einachten Modellen gemacht (vgl. 'GM03light' mit [[GMDB]]). Erfassung, Verwaltung und Nacherfassung ist um so einfacher, je kleiner das Modell ist. Definitions-Vererbungs-Mechanismen, wie sie in Interlis bekannt sind, kommen nicht zum Tragen wegen dem Baukasten-Ansatz von ISO (mit über 300 optionalen Attributen).
* Zu 3, Codierung: Das soll den Spezialisten überlassen bleiben. Mit UML/Interlis gibt es bereits eine Lösung.
+
* Zu 2, Austausch-Modell: Es gelten bis auf weiteres ISO 19115-Profile wie z.B. GM03-Core in der Schweiz. Metadaten gemäss Austausch-Modell sind grundsätzlich '''freie''' Daten (z.B. mit angepasster LGPL-Lizenz). Man beachte: Geo-Metadaten über Geodaten können Verweise auf Dateien haben, es können aber auch auf Webdienste wie WMS/WFS zeigen! Wir sprechen hier bei WMS/WFS von Data Access Services, die zu der Geodaten-Beschreibung gehören und keine eigenständigen Geo-Webservices sind. Geo-Filterdienste hingegen sind eigenständige Geo-Webdienste, z.B. Webdienste zu Koordinatentransformation, zur Datenkonversion.
* Zu 4 folgendes: Sehr wahrscheinlich werden Webapplikationen und GIS-Desktop-Editoren koexistieren - dank Schnittstellen. Es erscheint z.Zt. am Sinnvollsten, eine Webapplikation anzubieten und allenfalls die vorhandenen Attributwerte von den Geodaten direkt zu holen (Datum, Ausdehnung, Koord.System) und in Feldern URLs zuzulassen, z.B. auf Datenschema-Beschreibungen oder andere Informationen im Web (z.B. Lizenzinformationen). Nachteile/Vorteile dieser Variante:
+
* Zu 3, Codierung: Das soll den Spezialisten überlassen bleiben. Mit UML/Interlis gibt es bereits eine Lösung. Bei Dublin Core gibt es verschiedene Bemühungen.
 +
* Zu 4, Werkzeuge zur Verwaltung: Sehr wahrscheinlich werden Webapplikationen und GIS-Desktop-Editoren koexistieren - dank Schnittstellen. Es erscheint z.Zt. am Sinnvollsten, eine Webapplikation anzubieten und allenfalls die vorhandenen Attributwerte von den Geodaten direkt zu holen (Datum, Ausdehnung, Koord.System) und in Feldern URLs zuzulassen, z.B. auf Datenschema-Beschreibungen oder andere Informationen im Web (z.B. Lizenzinformationen). Unserer Einschätzung nach, sprechen daher mehr Vorteile für Webapplikationen im Gegensatz zu im Desktop-GIS integrierten Editoren. Nachteile/Vorteile Variante Webapplikation:
 
** + Unabhängig von Systemversion und mehrere GIS können in einer Version ko-existieren
 
** + Unabhängig von Systemversion und mehrere GIS können in einer Version ko-existieren
 
** + Metadaten sind im Web sichtbar, Adressen (Abgabestelle/Datenherr) können zentral verwaltet werden.  
 
** + Metadaten sind im Web sichtbar, Adressen (Abgabestelle/Datenherr) können zentral verwaltet werden.  
 
** + Gewünschte Metadaten sind für Google und andere Suchdienste auffindbar.
 
** + Gewünschte Metadaten sind für Google und andere Suchdienste auffindbar.
 
** - Es muss zwischen den Geodaten und der Webapplikation synchronisiert werden.   
 
** - Es muss zwischen den Geodaten und der Webapplikation synchronisiert werden.   
* Zu 5: siehe im vorangehenden Text.
+
* Zu 5, Geo-Metadaten-Austausch-Protokoll und Software:  
 
+
** Das Protokoll soll offen sein für versch. Metadaten-Modelle. Um keine Zeit zu verlieren soll die Software jedoch jetzt schon vorgesehen werden. Diese würde zunächst Dublin Core, dann CH-GM03 und dann noch das zu definierende Metadaten-Austausch-Modells anbieten.
Schnittstellen / Protokolle:
+
** Zwei aufeinander aufbauende Protokolle scheinen vielversprechend:  
* Zwei aufeinander aufbauende Protokolle scheinen vielversprechend:  
+
*** Geo-Metadaten als genormtes GM03/XML ins Web stellen (= 'Published XML'),  
** Geo-Metadaten als genormtes GM03/XML ins Web stellen (= 'Published XML'),  
+
*** Implementation eines 'Geographic Metadata Harvesting'-Protokolls, z.B. OAI-PMH (Google-API!).  
** Implementation eines 'Geographic Metadata Harvesting'-Protokolls, z.B. OAI-PMH (Google-API!).  
+
** Man beachte, dass für beide Protokolle bereits Spezifikationen sowie Implementationen vorhanden sind und sofort eingesetzt werden könnten! Das [http://www.openarchives.org OAI-PMH]-Harvesting-Protokoll, ist seit Jahren in Digitalen Bibliotheken implementiert und wird von Google erkannt!
* Man beachte, dass zu den Punkten 3 und 5 bereits Spezifikationen sowie Implementationen vorhanden und verbreitet sind! Es sind dies zu 3 [http://www.interlis.ch INTERLIS] und zu 5 ist es HTTP und neu das [http://www.openarchives.org OAI-PMH]-Harvesting-Protokoll, welches seit Jahren in Digitalen Bibliotheken implementiert ist und von Google erkannt wird. Da Dublin Core sowie GM03/XML gegeben ist, kann OAI-PMH sofort eingesetzt werden!
 
  
 
== Fragen und Antworten ==
 
== Fragen und Antworten ==

Version vom 3. September 2006, 09:43 Uhr

Stand heute

Metadaten sind der Schlüssel zur Zugänglichkeit und Auffindbarkeit von Daten! Das heisst, dass Geo-Metadaten eine der wichtigsten und ersten Komponenten einer Geodaten-Infrastruktur (GDI) sind.

Heute, 2006, muss festgestellt werden, dass aus Anwender-Sicht ein unbefriedigender Zustand herrscht. Das Hauptproblem ist dabei nicht bei den (Web-)Applikationen zu suchen, sondern bei der fehlenden Benutzersicht sowie beim fehlenden gemeinsamen Verständnis über eine gemeinsame GDI-Architektur, Prozesse, und v.a. den Zusammenhängen von Geodaten, Metadaten, Webservices und Applikationen.

In der Schweiz haben sich schon verschiedene Initiativen und Stellen mit Geo-Metadaten befasst. Es sind dies v.a. KOGIS mit Geocat, das BAFU mit Envirocat, verschiedene Kantone sowie die Initiative e-geo.ch.

Es gibt die Standards ISO 19115 und OGC's CSW 2.0 und die Diskussionen laufen weiter - in Richtung noch komplizierteren und noch umfangreicheren Spezifikationen. Wir raten daher von der Implementation der erwähnten Spezifikationen ISO 19115 Comprehensive und CSW 2.0 ab.

Vision zu Geo-Metadaten und GDI

Hier folgt eine Skizze einer Vision zu Geo-Metadaten und GDI und unten einen Lösungsvorschlag dazu zusammen mit einem Aufruf zur raschen Publizierung von Geo-Metadaten!

  • Die Benutzer benötigen Suchdienste zum einfachen Auffinden von Geoinformationen.
  • Die Geodaten-Provider brauchen ein (internes, umfassendes) Geo-Metadaten-Verwaltungs-Werkzeug mit einem Geo-Metadaten-Verwaltungs-Modell.
  • Geo-Datenherren und Service Provider benötigen
    • ein Geo-Metadaten-Austausch-Modell,
    • ein Encoding (z.B. XML) und ein
    • Protokoll (Basis HTTP) dazu für den Austausch und die Verteilung der Geo-Metadaten.

Zu alledem machen wir nachfolgend einen Lösungsvorschlag:

Lösungsvorschlag

Generell empfehlen wir Geo-Metadaten schnell zugänglich zu machen! Das bedingt, dass Metadaten intern rasch erfasst werden und dass Schnittstellen für den Austausch rasch bereitgestellt werden.

Wir wollen darauf hinweisen, dass zwei Geo-Metadaten-Modell-Arten benötigt werden: Eines für den Austausch und eines für die 'interne' Verwaltung.

Folgende Regeln, Aussagen und Massnahmen sind unserer Ansicht nach wichtig:

  1. Geo-Metadaten-Verwaltungs-Modell: Dieses ist das Wichtigste für Daten-Provider. Es kann organisations-intern vereinbart werden. Der Zeitpunkt kann selbst bestimmt werden. Um keine Zeit zu verlieren soll jetzt schon Schnittstellen-SW vorgesehen werden.
  2. Geo-Metadaten-Austausch-Modell: Dieses ist das wichtigste Modell für die Anwender-Gemeinschaft. Es muss rasch definiert werden, da gemeinsam entschieden werden muss. Es gilt z.Zt. ISO 19115/119 (und Profile wie GM03-Core). Ein besseres muss schnell definiert werden (vgl. unten). # Codierung des Geo-Metadaten-Austausch-Modells: Die Codierung ist in der Schweiz z.Zt. das GM03/XML. Sobald das Geo-Metadaten-Austausch-Modell definiert ist, muss auch die Codierung festgelegt werden.
  3. Geo-Metadaten-Werkzeuge/-Editoren: Webapplikationen und GIS-Desktop-spezifische Editoren werden koexistieren. Wichtig ist die Trennung in Software für die Verwaltung von Geo-Metadaten und Suchdienste. Dazwischen gibt es eine Schnittstellen-Software.
  4. Geo-Metadaten-Austausch-Protokoll (für Suchdienste): Schnittstellen-Software für Export rasch bereitstellen, zunächst mit Dublin Core. Es gibt dafür noch kein in der GIS-Welt anerkanntes Protokoll. CSW erscheint nicht geeignet. Es gibt jedoch Lösungsansätze wie OAI-PMH. Sobald ein Geo-Metadaten-Austausch-Modell definiert ist, kann die Schnittstellen-Software angepasst werden.

Diskussion: Zu 1 und 2, Verwaltungs- und Austauschmodelle: ISO 19115/119 und Profile wie CH-GM03 waren bisher für die Erfassung wie auch für den gemeinsamen informationsverlustfreien Austausch gedacht. Wir plädieren dafür, dieses als Vorlage für beide Modellarten weiterzuverwenden. Alle müssen sie aber noch verkleinert und ergänzt(!) werden, v.a. durch Beschreibung von Geodiensten (vgl. unten). Vorschläge dazu gibt es unten.

  • Zu 1, Verwaltungs-Modell: Dieses kann selber bestimmt werden, solange die Schnittstellen (3 und 5) erfüllt werden. Für die Verwaltung aus Sicht Datenerfasser sehen gibt es ISO 19115/119 (und Profile wie GM03). In einer Phase der Konsolidierung kann später über den vereinfachten, verlustfreien Austausch nachgedacht werden. Wir haben gute Erfahrungen mit einachten Modellen gemacht (vgl. 'GM03light' mit GMDB). Erfassung, Verwaltung und Nacherfassung ist um so einfacher, je kleiner das Modell ist. Definitions-Vererbungs-Mechanismen, wie sie in Interlis bekannt sind, kommen nicht zum Tragen wegen dem Baukasten-Ansatz von ISO (mit über 300 optionalen Attributen).
  • Zu 2, Austausch-Modell: Es gelten bis auf weiteres ISO 19115-Profile wie z.B. GM03-Core in der Schweiz. Metadaten gemäss Austausch-Modell sind grundsätzlich freie Daten (z.B. mit angepasster LGPL-Lizenz). Man beachte: Geo-Metadaten über Geodaten können Verweise auf Dateien haben, es können aber auch auf Webdienste wie WMS/WFS zeigen! Wir sprechen hier bei WMS/WFS von Data Access Services, die zu der Geodaten-Beschreibung gehören und keine eigenständigen Geo-Webservices sind. Geo-Filterdienste hingegen sind eigenständige Geo-Webdienste, z.B. Webdienste zu Koordinatentransformation, zur Datenkonversion.
  • Zu 3, Codierung: Das soll den Spezialisten überlassen bleiben. Mit UML/Interlis gibt es bereits eine Lösung. Bei Dublin Core gibt es verschiedene Bemühungen.
  • Zu 4, Werkzeuge zur Verwaltung: Sehr wahrscheinlich werden Webapplikationen und GIS-Desktop-Editoren koexistieren - dank Schnittstellen. Es erscheint z.Zt. am Sinnvollsten, eine Webapplikation anzubieten und allenfalls die vorhandenen Attributwerte von den Geodaten direkt zu holen (Datum, Ausdehnung, Koord.System) und in Feldern URLs zuzulassen, z.B. auf Datenschema-Beschreibungen oder andere Informationen im Web (z.B. Lizenzinformationen). Unserer Einschätzung nach, sprechen daher mehr Vorteile für Webapplikationen im Gegensatz zu im Desktop-GIS integrierten Editoren. Nachteile/Vorteile Variante Webapplikation:
    • + Unabhängig von Systemversion und mehrere GIS können in einer Version ko-existieren
    • + Metadaten sind im Web sichtbar, Adressen (Abgabestelle/Datenherr) können zentral verwaltet werden.
    • + Gewünschte Metadaten sind für Google und andere Suchdienste auffindbar.
    • - Es muss zwischen den Geodaten und der Webapplikation synchronisiert werden.
  • Zu 5, Geo-Metadaten-Austausch-Protokoll und Software:
    • Das Protokoll soll offen sein für versch. Metadaten-Modelle. Um keine Zeit zu verlieren soll die Software jedoch jetzt schon vorgesehen werden. Diese würde zunächst Dublin Core, dann CH-GM03 und dann noch das zu definierende Metadaten-Austausch-Modells anbieten.
    • Zwei aufeinander aufbauende Protokolle scheinen vielversprechend:
      • Geo-Metadaten als genormtes GM03/XML ins Web stellen (= 'Published XML'),
      • Implementation eines 'Geographic Metadata Harvesting'-Protokolls, z.B. OAI-PMH (Google-API!).
    • Man beachte, dass für beide Protokolle bereits Spezifikationen sowie Implementationen vorhanden sind und sofort eingesetzt werden könnten! Das OAI-PMH-Harvesting-Protokoll, ist seit Jahren in Digitalen Bibliotheken implementiert und wird von Google erkannt!

Fragen und Antworten

Webapplikationen oder integrierte GIS-Desktop-Editoren?
Webapplikation. Siehe "Zu 4)" oben.
Was ist ein Harvesting-Protokoll, z.B. im Vergleich zu einem Query-Protokoll?
Ein Harvesting-Protokoll benötigt keine Query-Funktionen und und verlangt daher weniger Implementationsaufwand. Siehe oben.

Aufruf zur Publizierung von Geo-Metadaten!

Wir empfehlen allen Vertretern allen Geodaten-Besitzern - v.a. den öffentlichen Verwaltungen - dringend Geo-Metadaten zu erfassen und zwar zum Nutzen aller und ganz im Sinne des Öffentlichkeitsprinzips!

Vorgehensvorschlag: Beginnen Sie Metadaten zu erfassen - ohne weitere Verzögerungen!

  1. Internes Metadaten-Verwaltungs-Modell wählen (dokumentierte Datenmodelle sind eine Investition mit Zukunft).
  2. Export (Import) eines einheitlich codierten Geo-Metadaten-Austausch-Modellen nach nationalen Profilen vorsehen/verlangen (CH: GM03 Core/XML)
  3. Geo-Metadaten-Austausch-Protokolle vorsehen/verlangen (vgl. oben).
  4. Geo-Metadaten-Werkzeuge - ob als Webapplikation oder Desktop-Tool - vorzuschreiben ist nicht zwingend notwendig, wenn Schnittstellen und Protokolle sichergestellt sind.
  5. (Interne) Erfassungs-, Aktualisierungs- und Verwaltungs-Richtlinien erstellen.
  6. Schulung berücksichtigen.
  7. Kosten für Software-Anpassungen und Daten-Nacherfassungen vorsehen.

Werkzeuge (Tools) zur Verwaltung von Geo-Metadaten

  • Webapplikationen und Desktop Tools, (potentiell) ISO 19115:
    • GeoKatalog/geocat.ch (kommerziell, gehostet oder kommerziell lizenziert, Java, ORACLE)
    • Geo-Metadatenbank GMDB - Webapplikation, Open Source (PHP, MySQL/PostgreSQL)
    • ArcCatalog GM03-Extension der Fa. axite
    • ArcCatalog (kommerziell)
    • deegree (Open Source, kommerziell, Java)
    • sdi.suite terraCatalog (Open Source, kommerziell)
    • disy Preludio (gratis, Windows, Java)
    • GeoKey (kommerziell)
    • M3CAT, Canada (ASP, kommerziell)
    • InGeo Services (kommerziell, nur Service)
    • MDWEB, France – IRD (PHP, ?)
  • Übrige Produkte:
    • GIMEF (kommerziell)
    • INdicio (kommerziell)
    • RedSpider Catalog (kommerziell)
  • Weitere unklassifiziert:
    • geonetwork, (Open Source, Java) CSW implementation. A tool developed by FAO, UNEP and WFP
    • CorpsMet95 (Windows, eingestellt)
    • Mediator (Windows, frei)
    • Publistar (Windows/Linux, kommerziell/kostenpflichtig)
    • Authentic 2005 (Windows, kommerziell/kostenpflichtig, teil von XMLSpy)
    • CatMDEdit, Spanien TelDE (Unix/Windows, kostenfrei, Java)

Hinweis in eigener Sache

Seit unserem ersten Aufruf an der Konferenz GIS/SIT 2000 für möglichst einfache Geo-Metadaten ist es mittlerweile sechs Jahre her!

Am GISpunkt HSR beschäftigen wir uns seit einiger Zeit mit der vereinfachten Erfassung, Dokumentation und Zugänglichkeit von Geo-Metadaten v.a. mit der Geo-Metadatenbank GMDB und der Suchmaschine Geometa.info.

Wir bieten auch Kurse an, namentlich den BIZGEO-Einzelkurs "Geo-Metadaten- und Internet-Recherche" (siehe Agenda). Wir helfen auf Anfrage (organisations-) interne Geo-Metadaten-Verwaltungs-Modelle zu definieren oder ein Geo-Metadaten-Werkzeug auszuwählen.

Weblinks