HOME   UP   bottom of document  

picture

Diskussion ueber CERA 2.x - fruehere Beitraege


   From Toussaint Tue Aug 12 16:36:36 1997

Hallo CERAnerInnen, die Zusammenstellung der fuer CERA 2.x noch zu erstellenden Werte- tabellen und Module findet sich im Netz unter http://www.pik-potsdam.de/~toussain/COMPUTER/CERA_DEVELOPMENT .
Bitte schreibt doch mal Eure Kommentare, damit wir dann die ersten Listen "verabschieden" koennen. Mitarbeit bei den Modulentwuerfen ist auch willkommen.
Am Fr. 22.8. treffen Michael, Hannes und ich uns in Hamburg, um das weitere Vorgehen zu besprechen. Weitere AktivistInnen sind herzlich willkommen.
Bezueglich der BoundingBoxes hat unsere Anfrage am GFZ ueberwiegend heisse Luft ergeben, d.h. deren Daten sind fuer uns in dieser Form weitgehend nicht verwertbar. Sie haben meist ZentralPositionen und keine Boxes. Ihre Bilder entstehen nicht als Polygone aus Vektoren sondern sind fertige ".gif"s. Wir sind aber selber dabei, fuer geogra- fische Objekte Boxes und VektorBeschreibungen zu erstellen: Alle Kontinente, Laender sowie in Deutschland die Kreise.

   From bmarx@AWI-Bremerhaven.DE Tue Aug 12 16:53:55 1997

ich bin schwer dabei, unser npdd-tool umzubauen und es dem neuen db-schema anzupassen. bei den von dir vorgeschlagenen werten ist mir nichts als problematisch aufgefallen - von mir aus geht das so durch. allerdings hat manfred noch den wunsch, bei location eine 'code_number' einzufuehren, um damit doppel-bezeichnungen bestimmter locations aufloesen zu koennen. das ist wohl gerade fuer die antarktis, wo alle moeglichen verschiedenen interessen aufeinanderstossen und jedes land seine eigenen bezeichnungen fuer jede einzelne eisscholle hat, eine relativ clevere idee.

   From Toussaint@pik-potsdam.de Tue Aug 12 16:58:24 1997

Wie soll die Nr. funktionieren ? Je Objekt, je Bezeichnung ? Eigentlich koennte ein schlaues Programm das an den Koordinaten erkennen, oder ?

   From bmarx@AWI-Bremerhaven.DE Tue Aug 12 18:26:30 1997

denkst du denn, die sind immer eindeutig? also SCAR hat wohl vor, eine liste herauszugeben, die fuer eine location alias-namen zulaesst, die ueber einen location_code eindeutig einer location zugeordnet sind. und manfred meint, dass das mit dem code eine super-idee ist, ja, dass es eigentlich NUR so geht.
Er wollte das eigentlich mit euch abklaeren - er ist der einzige, der weiss, was SCAR da genau vorhat - aber so warten wir mit der diskussion am besten, bis er aus dem urlaub zurueck ist (in 2 1/2 wochen).

   From bmarx@AWI-Bremerhaven.DE Wed Aug 13 11:03:00 1997

sollten wir bei der Format-Tabelle vielleicht ein 'format_acronym' einbauen?

   From Toussaint@pik-potsdam.de Wed Aug 13 11:44:53 1997

Klaro. Ich haette sonst aber gedacht, dass wir sowieso nur die Acronyme eintragen, aber ein Feld mehr ist besser.

   From Toussaint Tue Aug 19 16:48:28 1997

Diskussionsbeitraege haenge ich jetzt auch (ggf. gekuerzt) ins Netz unter http://www.pik-potsdam.de/~toussain/COMPUTER/CERA_DEVELOPMENT/

   From Toussaint Wed Aug 20 10:25:28 1997

Soweit wir gleiche Oberflaechen und/oder DBMS (ORACLE) benutzen, schlage ich vor, sich auch auf gleiche Directory-Strukturen zu einigen. Ingo und ich hatten das schon begonnen. Wenn aber jetzt allerlei umstrukturiert wird, waere es evtl. gut, das gleich nochmal zu "revise"n.

   From Toussaint Fri Aug 29 10:33 1997

ich habe neben dem neuen auch die alten Schemata ins Netz gehaengt. Welcher Teufel hat mich eigentlich geritten vorzuschlagen, location_level als loc_level abzukuerzen, wenn alle anderen Attribute in LOCATION nicht so abgekuerzt werden ?

   From bmarx@AWI-Bremerhaven.DE Fri Aug 29 10:37 1997

stimmt. sieht saubloed aus. wollen wir es rueckgaengig machen?

   From: Toussaint Fri Aug 29 10:45 1997

Subject: machen wir !

   From lautenschlager@dkrz.de Fri Aug 29 13:31:20 1997

BUFR - WMO format for the observational data transmitted over the Global Telecommunications System (GTS) (Aenderung in FORMAT: BUFR statt BUFFR)

   From Toussaint Tue Sep 2 11:10:37 1997

1. Wir sollten uns mal langsam Gedanken darueber machen, welche Feldlaengen und ggf. Datentypen wir fuer die Attribute der Tabellen verwenden. Ich habe dafuer ein kleines Tabellchen auf die CERA-Development-Seite gehaengt ("Attributes"). Die Eintraege sind weitgehend aus dem alten CERA uebernommen (DKRZ Tech. Rep.Nr.9). Neue Felder in Klammern vorschlagsweise dazugetragen.
Aenderungsvorschlaege:
- Enty_name evtl. laenger als char*80 ?
- Size nicht in Byte angeben, sondern wenigstens in KB, sonst MB
2. Da ich selbst nicht sehr im GIF stecke: koennte bitte jemand schauen, ob wir mit dem neuen CERA noch DIF konform sind? Laut Tech.Rep.9 (S.20) soll so etwas wie PARAMETER_GROUP oder _TERM required sein. Das kann ich aber irgendwie schon im alten CERA nicht mehr finden.
3. Die gegenwaertig im DKRZ benutzte TERM-Tabelle (heisst in CERA 2.x TOPIC) haengt zur Diskussion im Netz.

   From Toussaint Tue Sep 2 14:16:49 1997

- Brauchen wir wirklich das Feld "email-type" noch ? Vor 10 Jahren gab's da allerlei, aber ich kenne heute niemanden mehr, dessen Adresse nicht vom Typ "INTERNET" waere.
Aenderungswuensche in TOPICS: - Kryptische Eintragungen sollten in Klartext vorgenommen werden, damit auch Nachbardisziplinen etwas davon haben ("UStar**3").
- Eintragungen informativer: Die Unterscheidung zwischen "U-Velocity" und "u-Velocity" ist etwas mager. Ich denke z.B. an "U-Component of wind speed/water current".
Naechste Abstimmung: Fr., 5.9. in Hamburg.

   From hannes.thiemann@dkrz.de Tue Sep 2 14:29:29 1997

die Topics Tabelle ist urspruenglich mal DIF gewesen. Danach hat Ingo aber an den Inhalten ziemlich rumgemacht.
Meinetwegen koennen wir e-Mail type gerne streichen.

   From bmarx@AWI-Bremerhaven.DE Tue Sep 2 14:39:30 1997

ich kenne die topics von ingo nicht. ich beziehe die topics, mit denen ich die datenbank fuelle, von der GCMD-seite und erlaube weitere eintraege.
ich glaube, ich muss langsam mal anfangen zu schreien, wenn es hier um aenderungen geht (ich habe gerade die letzten vorschlaege von frank verarbeitet und moechte nun wieder daran gehen, das system resp. den prototypen fertigzustellen und zu dokumentieren). ab sofort muss ich bei weiteren aenderungsvorschlaegen auf meinen nachfolger (meine stelle wird wieder besetzt) verweisen. ansonsten gebe ich euch recht: der email-type kann eigentlich weg.

   From Toussaint Tue Sep 2 15:21:16 1997

Weg mit email_type !!
AUWEIA, schon ham' wir 2 TOPIC Listen, die auch beide schon installiert sind... Was passiert nun ??
   Treffen Hamburg, 5./8. September 1997

   From Toussaint Wed Sep 3 15:23:24 1997

die TOPIC-Tabelle im Netz (aus Hamburg von CERA 1.x) stimmt zum ganz ueberwiegenden Teil mit der GCMD Keyword-Liste (unter "http://gcmd.gsfc.nasa.gov/cgi-bin/mduser_dir/earth_sci_keywords") ueberein. 132 ihrer gut 1000 Eintraege sind nicht unter den knapp 1000 Eintraegen des GCMD (siehe Tabelle _TABLES/TOPIC_HH_peculiar.html unter meiner Home-Page). Ausserdem lassen die Duplizitaeten unter diesen 132 vermuten, dass noch andere Eintragungen doppelt sind. Ueber die 132 muessten wir gelegentlich diskutieren.
   Treffen Hamburg, 8./10./15.9.1997

   From Toussaint Wed Sep 17 20:40:05 1997

wir muessen noch die Inhalte von einer der Wertetabellen aendern. Bei ACCESS_TYPE haben wir uns nicht an den FGDC gehalten. Dort lautet die Liste unter 2.5.1.3:
paper, stable-base material, microfiche, microfilm, audiocassette, chart, filmstrip, transparency, videocassette, videodisk, videotape, physical model, computer program, disc, cartridge tape, magnetic tape, online, CD-ROM, electronic bulletin board, electronic mail system. Vereinigt mit unseren Wuenschen ergibt sich die Liste, die ich jetzt ins Netz gehaengt habe ("Wertetabellen").
Ebenfalls im Netz (als .ps) haengt ein Entwurf fuer das Modul "DATA_ORGANISATION" zur Beschreibung der Datenstruktur in den drei Raum- und der Zeitdimension.
   Treffen Hamburg, 23.9.1997

   From Toussaint Tue Sep 30 20:10:17 1997

Da ausser der GebuehrenVO zum UIG offenbar in der scientific (und in der political) community noch keine FEES-Klassen bestehen, werden sich die Werte der Tabelle FEES wohl vorerst auf "none", "unknown" und die genannte VO beschraenken. Damit kann die Tabelle dann auch verabschiedet werden.

   von Hoeck+Toussaint Oct 09 14:10 1997

- Attribut "url" in "CITATION" wird nicht benoetigt, wenn CITATION_TYPE= "book" oder aehnlich. Gleichzeitig fehlt Moeglichkeit, zB ISBN einzutragen. Daher sollte "url" in zB "cit_type_specification" umgetauft werden, die dann wie gehabt die URL enthaelt (bei CITATION_TYPE "web publication"), aber auch ISBN, ISSN etc enthalten kann (bei anderen CITATION_TYPEs).
- Attribut "address_type" fehlt in INSTITUTE (FGDC = Pflicht)
- Attribut "state_or_province" fehlt in INSTITUTE (FGDC = Pflicht)
- Attribut "postal_code" fehlt in INSTITUTE (FGDC = Pflicht)
- size (aus DISTRIBUTION) ist Schluesselwort in ORACLE. Vorschlag: byte_size
   Treffen Hamburg, 20.10.1997
Aenderungen, beschlossen und verkuendet ::::
- CITATION_TYPE, CURRENTNESS_REF, FEES: Wertelisten wie im Netz.
- TOPIC: verabschiedet, ist in Arbeit.
- CITATION/url in CITATION/access_spec(varchar*160) umbenannt
- DISTRIBUTION/size in DISTRIBUTION/data_size umbenannt
- INSTITUTE/street_postal_code (varchar*10) ergaenzt; INSTITUTE/pobox_postal_code (varchar*10) ergaenzt; INSTITUTE/state_or_province (varchar*80) ergaenzt
- LOCATION/ref_date (varchar*10) ergaenzt, damit bei sich aendernden Angaben (BoundingCoords; existence) ein Bezugsdatum festgehalten wird (verschwindende Laender und Kontinente [zB Pangaea]).

   From Toussaint Wed Nov 19 13:33:51 1997

Wir haben leider uebersehen, dass die Form der Datenpraesentation (Pflicht in FGDC) natuerlich nicht nur bei Publikationen eine Rolle spielt, in denen die Daten verwendet werden, sondern auch fuer die Daten selbst. Auch sie gliedern sich in Satellitenfotos, Landkarten, Globen etc. Auf die Wertetabelle PRESENTATION sollte also auch aus dem Bereich der "harten" ENTRY-Informationen verwiesen werden. Dafuer ist wohl die Anfuegung der "presentation_id" in ENTRY am guenstigsten.

   From hoeck@dkrz.de Thu Nov 20 10:31:06 1997

Zu den Beschreibungen der Attribute:
- currentness_ref_descr (Basis, on which the time period of content information (temporal coverage) is determined): Besser finde ich: Type of time coordinate system (i.e. earth real time, ECHAM model time).
- format_descr (Explanation of the format_acronym): lieber: Explanation of the format.
- Ergaenzend zu topic_name: New keywords are allowed.
- entry_type soll required sein.

   Treffen 24.11.97 (ML, FT, HT)

- purpose aus SUMMARY gestrichen
- Eingefuehrt: ref_type_id in REFERENCE, neue Tabelle REF_TYPE mit ref_type_id und ref_type_descr*2000.
- Herausloesen von REFERENCE, REF_TYPE, CITATION, CITATION_TYPE und PRESENTATION aus coreCERA und Behandlung als Modul "PUBLICATION" (bisher Block "PUBLICATION").
- Einige kleinere Aenderungen an Werten der Wertetabellen PROGRESS, PRESENTATION
Damit sind wir bei coreCERA 2.3 und haben unser erstes Modul fertig.

   From Toussaint Wed Dec 10 11:30:46 1997

Unbekannte Monate/Tage in TEMPORAL_COVERAGE sollten als NULL eingegeben werden (im Ggs. z. CITATION.citation_date, wo uns das date-format ja zwingt, gueltige Angaben zu machen, wir uns also auf "1" geeinigt hatten fuer unbekannt).

   Treffen Fr., 19. Dezember, 10:00 Hamburg (ML,MR,HT,FT)

Modul "Publication": bleibt BLOCK, nicht Modul.
weiteres Vorgehen beim Stricken der Module: DATA_ORG Ver.0.4 weiterentwickeln gemaess DKRZ-Anforderungen und CERA 1.x; Gemeinsames Interesse an ACCESS_SPECIFICATION, Tabellen dieser Art existieren schon am AWI; SPACE_REFERENCE: vorl. nur am PIK Interesse: MODEL_INPUT: Interesse aber vertagt.
- CERA Einzeltabellen:
-- LOCATION: Status, Pflege, Umfang: Struktur bleibt, Befuellung lokal, aber mit gegenseitiger Information; Festlegung der ersten Ebenen, dazu Abstimmung mit GCMD und Vorschlag vom AWI (moeglichst bis Anfang Jan); evtl. Aufteilung der oertlichen Schwerpunkte nach Instituten.
-- TOPIC: Raumzeitl. Aggregationen in Extra-Tabelle "Aggregation" (s. Attributes);

   Treffen 9./12. Januar 1998, 15:00 Hamburg (ML,HT,FT)

- Fertigstellung Modul DATA_ORGANIZATION, Version 1.0. Jetzt ist eine detaillierte 4dim Gitterbeschreibung moeglich. Die damit nur umstaendliche Art, irregulaere Punkte zu definieren wird durch eine zusaetzliche Tabelle fuer Punkte umgangen. Praktisch kann jetzt der Datenraum zB auch durch irregulaere Punkte in 2 Dim (zB Messstationen) und ein Gitter in der 3. Dim (zB Hoehe) beschrieben werden.
-- Die Gitter haben noch keine Richtung, da Anfangs- und Endpunkt freischwebend am Connect haengen. Diese Information soll in ein anderes Modul (Beschreibung der Speicherung).
-- Um das Koppeln reiner Relationen im Schema zu vermeiden, kippen wir das Dogma, in coreCERA-Tabellen nur die in coreCERA definierten Attribute zuzulassen. Damit kann die data_org_id in PARAMETER landen, falls das Modul DATA_ORGANIZATION in einer Implementation existiert.

   Treffen 30.1./2.2.98 (FT,ML,HT)

Dimensionierung der Attribut-Felder und Bestueckung der Wertetabelle in Modul DATA_ORG erledigt (siehe .ps-Schema).
Ausserdem in POINT_CONNECT und SCALE_CONNECT ein Feld "sequence_no" eingefuehrt. Damit ist die Ordnung von Punkmengen und Richtung von Skalen in DATA_ORG festgehalten.
Modul DATA_ACCESS: Vorversion ist vorhanden. Modul baut ausser auf coreCERA auch auf DATA_ORG auf. Schema-Grafik folgt.

   Treffen 6.2.98 (FT,ML,SZ)

Abschluss Modul DATA_ACCESS (siehe .ps-Schema).
Vorbesprechung der CERA-Nutzung durch Uni Hamburg, Institut fuer Meereskunde.

   Treffen 16.3.1998, 11:00 Hamburg (ML, FT)

Erstellung der CERA Dokumentation laeuft (ML, FT, MR). Weitere Aktivisten dazu sind willkommen. Erscheinen soll es als DKRZ-Report, aehnlich dem TR9 fuer CERA 1.0.
Parallel erscheint ein PIK-Report ueber die bei uns entwickelte Web-Oberflaeche (JAVA/ORACLE).

   From Toussaint@pik-potsdam.de (Frank Toussaint) Tue Mar 17 16:53:21 1998

ich habe die Webseite jetzt in den Bereichen "_SCHEMES" und "_DDL" so organisiert, dass Datum und Groesse der .ps und .fig-Dateien angezeigt werden. Ein Schema der Blockstruktur ist neu dazugekommen.
Dabei fielen mir noch einige Aenderungsvorschlaege zum Block-Schema, das wir uns ausgedacht haben, ein (Tabellen und Spalten bleiben unveraendert!):
- Im Table "Location" bezieht sich der Begriff auf einen 3D-Raumbereich, der gleiche Begriff als Block-Titel "LOCATION" auf ein raum-zeit- liches 4D-Volumen. Vorschlag: Block "LOCATION" umtaufen in "COVERAGE". Haette auch den Vorteil, dass wir damit FGDC-nahe sind, wie auch bei den Block-Namen "ATTRIBUTE", "CONTACT" und "DISTRIBUTION".
- Tabelle "Spatial_Data_Org" tanzt als einzige grundlos aus der Reihe mit einem Link auf einen anderen Block, der nicht "METADATA ENTRY" ist. Auch inhaltlich bezieht sich die Information auf "ATTRIBUTE". Vorschlag: Die Tabelle von "SPATIAL INFORMATION" nach "ATTRIBUTE" migrieren.
Ich bitte um Rueckmeldung, falls das Umtaufen irgendwo groessere Probleme macht.
Zur Erinnerung: Auf dem Treffen der AG Umweltdaten der Helmholtz-(HGF-) Institute am 4./5.5.98 im PIK werden u.a. WebOberflaechen fuer CERA Thema sein (WebInfo). Auch Nicht-HGFler sind dazu willkommen.


   Treffen 30.3.1998, 11:00 Hamburg (ML, FT)

- Block LOCATION umbenannt in COVERAGE.
- Tabelle "Spatial_Data_Org" bleibt in Block "SPATIAL INFORMATION".
- stop_year in "Temporal_Coverage" wird Pflichtfeld.
- Attribute, die long/lat/alt... heissen, werden in Modul DATA_ORG zu x,y,z.

   From: Hannes Thiemann, Thu Apr 16, 11:43

Bei nicht primary/foreign key Datentypen sollten wir immer auch die Laenge festlegen. Also integer *x, char *x, float *x. Dies sind meine Vorschlaege fuer die bisher nicht festgelegten.
MOMENT: year int*8; month int*1; day int*1; hour int*1; minute int*1; second int*1; utc_diff float*4
POINT_CONNECT: sequence_no int*4
SCALE_CONNECT: sequence_no int*4
Desweiteren haben wir bisher bei nur wenigen columns festgelegt, was required ist und was nicht. Z.B. was tun wenn es zu einem entry keine summary gibt, summary_id in entry dann NULL setzen oder einen dummy-Eintrag in summary einfuehren, der einfach besagt, keine summary vorhanden. Zu jeder column gehoert also eine Kennzeichnung dazu required oder nicht. Hast Du da schon was?


   Treffen Fr, 15.5.1998, 11:00 Hamburg (ML, HT, FT)

Abschliessende Absprache von Datentypen und Feldlaengen: Im gesamten CERA sollten NULL-Eintragungen illegal sein. E rlaubt: xx_id=0 bei Wertetabellen als "not filled". Diese Eintragung sollte ueberall erlaubt sein, ausser bei entry_title und wenigstens einem Keyword. Damit sind alle Felder "required" aber es kann fast ueberall eine neutrale Angabe gemacht werden.
Besprechung: Vorgehen bei Publikation des Technical Reports

   Treffen Fr, 5.6.1998, 14:00 Hamburg (ML, HT, FT)

Redaktionssitzung zur Publikation des CERA-2 Technical Reports

   Treffen Mo, 30.6.1998, 14:00 Hamburg (ML, FT)

Redaktionssitzung: Letzte Korrekturen & Layout; Diskussion des Kapitels "Vergleich: CERA - DIF/CSDGM"

   Treffen Mo/Di, 23./24.11.98 (bei der Sitzung der HGF-AG Umweltdaten)

Die Tabelle SPATIAL_DATA_ORG kommt von Block SPATIAL INFORMATION nach Block ATTRIBUTE.
















Go to top of document.

Pages are optimized for NETSCAPE. For comments and suggestions contact Frank Toussaint.

Last change: Mon Jul 12 20:51:45 NFT 1999