Udskriftsvenlig | Udskriftsvenlig | |
Referat af møde i Gerda-arbejdsgruppen.Tid og sted:
Mødet blev afholdt på GEUS d. 11. juni 2004
Deltagere:
Esben Auken (EA), Aarhus Universitet,
Afbud fra:
Flemming Effersøe, Hedeselskabet
Dagsorden:
ad 1. Opfølgning på omlægningen af databasen tidligere i år. Har vi fået det hele med?Det er tidligere vedtaget, at alle standardafvigelser skal indberettes og lagres som faktorer i stedet for andele. Alle data, som er indberettet ved brug af GFS's Workbench er formodentlig indberettet som faktorer. Standardafvigelser, der er indberettet som andele, mangler at blive identificeret og omregnet til faktorer. Vedrørende 2D modellerne, så er der nogle få modeller, som ikke er indlæst eller indlæst rigtigt. Da disse er på gammel format vil det sandsynligvis være lettest, hvis data importeres endnu en gang. Tidligere er det vedtaget, at TemDat.RhoA skal være et beregnet felt, det mangler at blive implementeret. Det vil ske inden for kort tid. Ved download af data er der tabeller, der undlades. P.t. vises beskrivelserne af disse tabeller ikke på GERDA's hjemmeside, hvilket er uhensigtsmæssigt og vil blive ændret. Det blev besluttet, at man ved download skal kunne vælge default eller fuld download af dataset og model. Ved en default download er der nogle store datatabeller, der ikke medtages. Det blev besluttet, at hjemmesidens feltbeskrivelsessider trænger til en revision, så xml-element- og -attributnavne udgår, da de ikke bliver brugt. Desuden vil det være hensigtsmæssigt, at det fremgår, hvorvidt et felt er et beregnet felt, som ikke hører med i indberetningen. P.t. kan man kun se om et felt kræves ved indberetning. ad 3 og 7. Ønske om constraints (foreign key og not null) i PCGerda-databaser og Størrelser på datatyper, herunder reals anvendt i alle keys på PCGERDA.EA har konstateret, at PCGERDA databaser, der uploades, er meget tunge at arbejde med, hvilket måske skyldes manglende contraints og/eller at der anvendes datatypen reals for alle nøgler. Yderligere er alle felter gemt i real*8 og ikke real*4 hvilket gør, at databaserne får næsten dobbelt størrelse af hvad der er nødvendigt. Igen giver dette yderligere load på databaserserveren og performance nedsættes. MP vil se på sagen. EA prioriterer højest, at nøglernes datatype ændres til integer. ad 4. Indberetning af PCGerda-databaser på Interbase/Firebird-format.MP vil overveje, hvad der skal gøres for at man vil kunne indberette data på Interbase/Firebird format. ad 6. Håndtering af "dårlige" datasæt, der identificeres under tolkning.Det blev besluttet at ”dårlige” datasæt her og nu indsnævres til ”dårlige” TEM-datasæt, hvor problemet er aktuelt. Det er muligt, når man arbejder med PCGERDA data i GFS's Workbench at vælge at ignorere datasæt og modeller, der er dårlige. Denne mærkning sker kun i brugerens lokale workspace og går tabt, når der laves et nyt PCGerda træk. Det vil derfor være hensigtsmæssigt at denne mærkning af ”dårlige” datasæt kan føres tilbage til GERDA databasen. Det blev besluttet at ”dårlige” TEM data, som er identificeret efter afsluttet indberetning, skal kunne indberettes til GERDA databasen i en database med en enkelt tabel, der i GERDA relateres til TemPos-tabellen.
Tabellen IngorDat oprettes. Et datasæt mærkes som dårligt ved, at der er en post i tabellen for det givne datasæt.
Tabellen IgnorDat vil indeholde følgende felter:
'Dataset' eller 'DsetIdent'?? samt 'Position' og 'Client' vil være nøgle. 'Position' er TEM sonderingens position, som i TemPos.Position 'Client' er den aktør, der har ønsket at få datasættet mærket. Forskellige aktører kan få deres egen mærkning af datasæt. Det betyder, at 'Client'-navnet i IgnorDat-tabellen kan være forskellig fra 'Client'-navnet i Dataset-tabellen. 'Contractor' er den aktør, som faktisk har udført identifikationen af de ”dårlige” data. 'DateTime' er tidspunktet for identifikationen af de ”dårlige” data. 'Note' er en fri tekst med en evt. kommentar til mærkningen.
IgnorDat-tabellen vil blive ignoreret ved normal PCGerda indberetning.
|
