ARBEJDSGRUPPEN Referat af møde i Gerda-arbejdsgruppen. Tid og sted: Mødet blev afholdt hos Hedeselskabet, Viby J, d. 17. januar 2005 Deltagere: Anders Edsen (AE), Hedeselskabet, Peter Duch (PD), WaterTech, Uffe Nielsen (UN), Rambøll, Brian Sørensen (BS), Århus Amt Esben Auken (EA), Aarhus Universitet, Torben Bach, Aarhus Universitet Jørgen Tulstrup (JTu), GEUS Ingelise Møller (ILM) (referent), GEUS Orlov: Mikael Pedersen (MP), GEUS Dagsorden: 1. Logs. AE har udsendt materiale fra Log-gruppen. 2. SKYTEM. EA har et oplæg med. 3. HEM. EA har et oplæg med. 4. Opdateringer i GERDA. 5. Status og diskussion af opgaver på listen fra Brugergruppemødet 2. december 2004 (indsat sidst i referatet). ad 1. Logs: AE orienterede om log-gruppens notat - en sammenstilling af input fra hele loggruppen. Nogle punkter i papiret blev diskuteret: (Omtalte Bilag 1, er indsat sidst i dette dokument). LAS-2 format contra LAS-3 format. LAS-3 har bedre syntaks. JTu foretrækker, at man fortsætter med at anvende LAS-2 formatet, da der allerede er lavet et indlæsningsprogram til LAS-2 formatet. Der findes rutiner til tjek af LAS-2 filer, hvor der testes, om filen overholder syntaksen. Som en del af kvalitetssikringen (KS), skal boringsudbygningen medtages i indberetningen. I forbindelse med etablering af nye indvindingsboringer logges der ofte i arbejdsrør, der er en
midlertidig foring, som fjernes, inden stammer med filtre sættes i boringen og udbygningen af boringen færdiggøres. Det er den færdige boringsudbygning, der vil være indberettet til Jupiter. Kalibreringsparametre skal ikke indberettes til GERDA. Der medtages i rapporten til kunden, at en kalibrering er udført. Fra dette punkt udsprang en diskussion om lovpligtig indberetning af rapporter - se længere nede i referatet. Kommentarer til 1. del af bilag 1: bruttolisten over KS parametre, med parametre generelt for et datasæt: Firma, medtages ikke men erstattes af Projekt-Ident og Dataset-Ident. Projekt-Ident, er en del af Projekt identifikationen i GERDAs stamdatadel, der skal oprettes inden datasæt indberettes. Projekt-Ident og Dataset-Ident skal overholde vedtaget nomenklatur. Sted - et navn der identificerer boringen i logkampagnen? Boring (alternativ navn) - fritekstfelt Filterrør ændres til Stammenr, som skal være linket til stammeid i Jupiter. Det skal dog være muligt at kunne vælge "et åbent hul". Borehulsvæske - fra valgliste. Udbygning - her skal de forskellige udbygningsparametre indberettes i en form, der gør, at der kan søges i disse parametre og de automatisk kan tegnes op på en skitse. Samme format som Jupiter må foretrækkes. I forbindelse med diskussion af referencepunkt og identifikation af stammer, orienterede JTu og BS om, at der i et andet regi er en arbejdsgruppe, der arbejder med en forbedret lokalisering af boringer, mærkning af referencepunkt og stammer. Disse mærker vil sandsynligvis først påsættes efter afslutningen af en boring, hvorved de ikke kan bruges ved logging under etablering af en boring. JTu har dog checket med Martin Hansen (GEUS) efter mødet. Han siger at det er meningen, at brøndborerne fremover skal sætte mærkater på boringer (DGUnummer) og stammer så snart disse er sat. Hvis der logges i en boring efter rørene er etableret, bør man altså kunne se hvilke numre de har. Datastrukturen for logs giver, at forholdet Dataset - LAS-fil er 1:1. Der kan være flere Dataset i samme boring. ILM nævnte, at der ikke er den sammenhæng mellem dataniveauer i GERDA datamodellen og loggingproceduren, som bilag 1 indikerer. En log kørsel (med sonde med flere tools) svarer ikke til LogRun niveauet i GERDA og tilsvarende for LogData. LogRun-tabellen i GERDA er beregnet til parametre vedrørende hver enkelt log i LAS filen. PD nævnte, at der måske er behov for et ekstra niveau i datamodellen. Det vil det fremtidige arbejde belyse. Det blev besluttet, at man ikke skulle gennemgå resten af punkterne på listen, da der nu er et grundlag for et videre arbejde. Punktet afsluttedes med en beslutning om, at arbejdet nu går tilbage i Log-gruppen, som laver en uddybning af bilag 1 med beskrivelse af parametrene mht. om disse skal være obligatoriske felter, hvilken felttype og -længde feltet skal have, en tekstlig beskrivelse af feltet samt beskrivelse af evt. valgliste knyttet til feltet.
Dette arbejde tages op på et log-gruppemøde i København, hvor JTu også er inviteret. ad 2. SKYTEM: EA startede med kort at forklare SKYTEMs måleprincip og instrumentopbygningen. Systemet består af en senderramme og modtagerspole, som er placeret lidt over senderrammen, samt navigationsinstrumenter til bestemmelse af senderrammens position samt højde over jorden. Disse instrumenter er p.t. 2 GPS'er (GP med sampling 1/sec), 1 vinkelmåler (AN med sampling 1/sec), 2 lasere til højdemåling (AL sampling 10/sec). Dertil er der overvågning af sender (Tx sampling 1/sec for strøm og en lang række andre parametre). Data ligger i 2 softwarekanaler, hvor der er 30 gates med sampling 1/sec). Rådata er asynkrone data; måledata og navigationsdata knyttes sammen i processeringen via GMT tid fra GPS. Der opstod en diskussion af hvad et SKYTEM Dataset skal være, da det er meget forskelligt fra datatype til datatype. Målemetodikken lægger op til at det, som for PACES, er hele kortlægninger, der er et Dataset. Er det hensigtsmæssigt? Dog blev der foreslået at man skifter til et nyt Dataset, hvis der ændres i målekonfigurationen. Det blev besluttet, at EA formulerer en definition for et dataset. EA gennemgik diagrammet med den foreslåede datamodel. Enkelte småjusteringer blev umiddelbart foretaget. Det blev besluttet at EA udarbejder regneark/database med tabel og feltbeskrivelser, som sendes til JTu sammen med diagrammet. JTu gennemgår derefter datamodellen, inden en endelig fastlæggelse af datamodellen. Det blev besluttet, at PCGerda tabel- og feltnavne ikke længere skal begrænses til hhv. 8 og 10 karakterer, da der ikke er behov for at kunne understøtte databaseformater med disse restriktioner. Nye tabel- og feltnavne må være op til 20 karakterer lange, hvilket sikrer en bedre læsbarhed af tabel og feltnavne. ad 3. HEM data: EA gennemgik et udkast til en datamodel for processerede HEM data, som EA har lavet for Vejle Amt i forbindelse med BurVal projektet. Denne model vil danne grundlaget for en datamodel i GERDA. Der blev umiddelbart lavet enkelte justeringer. EA sender diagram samt regneark/database med tabel- og feltbeskrivelser til GEUS, hvor Thorkild Rasmussen inddrages, da han har stort kendskab til HEM data. ad 4. Opdateringer i GERDA: Skal man kunne opdatere data. Det har været en gammel politik, at hvis der skal rettes i data, skal hele datasættet slettes og indberettes på ny. Men er det hensigtsmæssigt i alle sammenhæng? Diskussionen hænger sammen med en opdatering af koter. Dette medførte en diskussion af, i hvor høj grad data i GERDA ikke er kotesat. Der var uklarhed om, hvorvidt der er andre data end gamle PACES data, der er indberettet uden koter. Der blev diskuteret, om der er behov for at oprette et felt med GEUS_kote - et nyt beregnet felt. Det er
vigtigt, at man kan se, at koten tilføjet på et senere tidspunkt, da koten kan være ændret i forhold måletidspunktet pga. f.eks. grusgravning eller byudvikling. GEUS vil lave en søgning af dataset, position for at kortlægge, hvor mange dataset der mangler koter. Der skulle afdække, om der er et behov for at oprette et felt med GEUS koter. ad 5. Status og diskussion af liste med opgaver: JTu orienterede om, at punkterne øverst på listen planlagt til marts-kvartalet forventes udført inden for tidsplanen. PD spurgte til hvad " Markering af dårlige datasæt (i første omgang TEM)" dækker over. Det er forklaret og beskrevet i Referatet fra arbejdsgruppemødet 11. juni 2004. JTu modtager gerne kommentarer til den foreslåede struktur. Ekstra punkt: JTu orienterede om, at ifølge vandforsyningsloven skal rapporter over undersøgelser, som er udført med vandindvinding for øje, indberettes. Det er der sandsynligvis ikke mange der er klar over. Det er også uklart, om det er rekvirent eller rådgiver, der skal foretage indberetningen. Rapporter med geofysiske data på pdf-format bør kunne indberettes til GERDA og linkes til databasen. Der skal oprettes et felt/tabel i GERDA til dette. EA foreslog, at rapporter lægges direkte i databasen i et blob-felt, så vil de følge med ved udtræk. JTu sluttede mødet med at takke log-gruppen for dens grundige arbejde. Mødet sluttede kl 15. Listen med opgaver:
Bilag 1 Bruttoliste over KS parametre ved indlægning af logging data i GERDA
Generelt for et datasæt Firma Sted Boring (DGU nr) Boring (alternativt navn) Filterrør (der kan være flere filtre i samme boring) Dato Borehulsvæske Dybde til grundvandspejl (fra referencepunkt) Udbygning (Casing, filtersat) o Casing dybde o Filterrør logget o Casing/filter materiale o Borerør til hvilken dybde Dybde iflg. Boreformand Boreværktøj/Bitsize Dybde iflg. Log Logget af (person initialer) Referencepunkt (terræn, top forerør, kelly bushing,...) Kote for referencepunkt Kilde til kote for reference punkt Boremudderets elektriske modstand (målt i poolen) Formål med logging (tilstandsvurdering, filtersætning,...) Generelt for en kørsel (LogRun ): Datatype (nat.gamma, normallog, guardlog, induktionslog, caliperlog,...) Rådata filnavn Sonde ID, serie nr. Start dybde? Slut dybde? Reference til de anvendte sonder. Flere sonder med forskelligt SN kan være koblet sammen i én kørsel. Log retning (ned, op, timemode) Log hastighed Status (rå, dybdekorrigeret, filtreret,...) Beskrivelse Korrektion for målehjulsfejl på spil. Forskydning (forskydning af data i forhold til dybdeangivelsen, <0 opad,> 0 nedad) Generelt for en log (LogDATA): Hvilken kørsel kommer den fra (Log Run (Filnavn)) Log Type (gamma, R8,...) Log Name (XXX) Enhed (cm, ohmm, ohm,...)
? på Log Run niveau. Kompenseres for under processering. Forskydning (forskydning af data i forhold til dybdeangivelsen, <0 opad,> 0 nedad) Sampleinterval Ydelse ved flowlog; niveau for pumpe; grundvandsspejl underpumpning Log rapporteret/benyttet. (Hvis det besluttes at alle indsamlede log i en boring skal indberettes, f.eks. naturlig gamma logs fra alle benyttede sonder)