Peilbuis, of hoe informatie bruikbaar wordt (1)

Gefragmenteerd gegevensbeheer is een bestaand vraagstuk dat niet 1-2-3 opgelost gaat worden. Ieder multidisciplinair object komt in meerdere systemen voor, en systemen praten onvoldoende met elkaar.

Het objecttype Peilbuis wordt als voorbeeld bij de horens gevat.
In dit eerste deel wordt gekeken naar een bruikbare gegevensstructuur en hoe deze geimplementeerd kan worden in een kernregistratie.

De nationale registratie van peilbuizen maakt deel uit van de Basisregistratie Ondergrond (BRO). Deze basisregistratie is nog volop in ontwikkeling. Er komt een informatiemodel IMBRO dat aansluit op de andere sectorale IM* modellen zoals IMGeo, IMWA, IMRO etc.  Meer informatie over de BRO is te vinden op de websites:
Basisregistratie Ondergrond op Pleio
BROinfo

Waterbeheerders zijn zowel afnemer èn leverancier van peilbuisgegevens. Het leveren van informatie via berichtenverkeer en PKI-overheidscertificaten aan de BRO wordt straks (> 2017) lastig en complex. Begin maar vast met inlezen zou ik zeggen. Des te belangrijker om de eigen informatievoorziening tijdig op orde te krijgen.

Peilbuisgegevens worden al jaren in GIS systemen en Excel opgeslagen. Hierbij wordt gebruik gemaakt van een al ouder gegevensmodel:
http://www.aquo.nl/Aquo/lm_aquo/entiteit/GWM.htm

Dan nu aan de slag.

1. Op hoofdlijn
De basisregistratie BRO is vertrekpunt, maar wordt in DEMO sterk vereenvoudigd Alle gegevens moeten wel tussen BRO en DEMO over en weer uitwisselbaar blijven.

Grondwatermonitoringsput  en Monitoringsbuis zijn in DEMO top-level objecttypen, en kennen daardoor standaard al de volgende eigenschappen:

• Unieke identificatie (guid)
• Objectbegintijd
• Objecteindtijd
• Tijdstipregistratie
• Eindregistratie
• Indicatie 'In onderzoek'

Beiden zijn bovendien fysieke objecttypen, waardoor de volgende eigenschappen ook al aanwezig zijn:

• Status
• 'planvorming'
• 'klaar voor gebruik'
• 'in gebruik'
• 'storing'
• 'buiten gebruik'
• 'niet meer aanwezig'
• Ontstaanswijze
• 'mensenwerk'

Deze eigenschappen worden hergebruikt, waarbij definities in DEMO leidend zijn.

2. Intrinsieke eigenschappen

Het is altijd de uitdaging de eigenschappen van een object te beschrijven die er toe doen, en weg te laten wat indirect is of zelfs niet aan de objectbeschrijving bijdraagt. Beschrijf daarom het wat (fysieke kenmerken), en niet het hoe, waarom of waarmee. Daarom:

• geen maaiveldhoogte
• geen informatie over meetplannen, monsternames, meetfrequenties
• geen informatie over watervoerende pakketten
• geen onderhoudsaspecten
• geen algemene 'opmerkingen'

Deze eigenschappen maken deel uit van de eerder genoemde standaarden, maar worden dus niet overgenomen.

Over zelf geplaatste peilbuizen moeten extra gegevens bijgehouden en geleverd worden,  zoals KvK nummers van aannemers en onderhoudsdiensten, de registratiestatus en -geschiedenis, toegepaste technieken en methodieken etc. etc. Al deze metadata wordt in DEMO samengevat in èèn XML veld, wat de gegevensbeheerder veel werk zal schelen.

3. Nieuwe domeinen

In een eerdere blog is al eens uitgelegd hoe domeinen in DEMO werken. Langs die weg worden de noodzakelijke nieuwe BRO domeinen uitgewerkt:

• Nieuwe domeinlijsten en -waarden verzamelen uit BRO documentatie
• Domeinwaarden inlezen in tabel public.domeinwaarden
• Nieuwe datatypen definieren
• bro-id
• kvknummer
• initielefunctie
• typemonitoringsbuis
• materiaalmonitoringsbuis
• Nieuwe check-constraints voor deze datatypen definieren
• KvK nummer eigen organisatie vastleggen (voor beheer eigen peilbuizen conform BRO model)

Voorbeelden:

 --KvK nummer kent 8 cijfers, òf 11 cijfers, en kan een voorloopnul bevatten.
 --https://openkvk.nl/
 --DROP DOMAIN public.kvknummer;
 CREATE DOMAIN public.kvknummer
  AS character varying
  COLLATE pg_catalog."default"
  CONSTRAINT kvknummer CHECK (VALUE ~ '^([0-9]{11}|[0-9]{8})$');
 ALTER DOMAIN public.kvknummer OWNER TO postgres;

 --DROP DOMAIN public.typemateriaal;
 CREATE DOMAIN public.typemateriaal
  AS character varying
  COLLATE pg_catalog."default"
  CONSTRAINT typemateriaal CHECK (VALUE = ANY (get_domainvalues('imbro', 'typemateriaal')));
 ALTER DOMAIN public.typemateriaal OWNER TO postgres;

 --Eigen KvK nummer vastleggen
 INSERT INTO public.kvstore VALUES(DEFAULT, 'nsKvK', '17251019');

3. De nieuwe tabellen

 CREATE TABLE grondwatermonitoringsput
  grondwatermonitoringsput_pk serial PRIMARY KEY,
  BRO_id public.broid,
  naam varchar,
  eigenaar public.kvknummer,
  functie public.initielefunctie,
  metadata xml,
  geometrie geometry(POINT,28992),
  actor varchar,
  CONSTRAINT grondwatermonitoringsput_guid_key UNIQUE (guid)
 ) INHERITS (fysiekobject)
  WITH ( OIDS=FALSE )

 CREATE TABLE monitoringsbuis
 (
  monitoringsbuis_pk serial PRIMARY KEY,
  grondwatermonitoringsput varchar,
  buisnummer numeric(3),
  buistype public.typemonitoringsbuis,
  bovenkant numeric(6,3),
  lengte numeric(6,3),
  filtermateriaal public.typemateriaal,
  filterdiameter numeric(4),
  filterbovenkant numeric(6,3),
  filteronderkant numeric(6,3),
  metadata xml,
  actor varchar,
  CONSTRAINT monitoringsbuis_grondwatermonitoringsput_fkey FOREIGN KEY (grondwatermonitoringsput)
  REFERENCES public.grondwatermonitoringsput (guid) MATCH SIMPLE
  ON UPDATE NO ACTION ON DELETE NO ACTION
 ) INHERITS (fysiekobject)
 WITH ( OIDS=FALSE )

De tabellen zijn zowel in het schema public als in het schema archive gemaakt.

4. De nieuwe triggers
Zoals bij ieder nieuw objecttype zijn INSERT, UPDATE en DELETE triggers gemaakt voor:

• het registreren van nieuwe objecten 
• het vastleggen van het KvK nummer (eigenaar) bij invoeren van nieuwe records
• het bijhouden van historie bij wijzigen en verwijderen van objecten

4. Security

(als voorbeeld alleen de monitoringsbuis)

 CREATE ROLE nsBRO;
 COMMENT ON ROLE nsBRO IS 'Informatiedomein Basisregistratie Ondergrond';

 GRANT nsbro TO "joe@.nl";

 GRANT SELECT ON monitoringsbuis TO PUBLIC;

 -- public schema only
 GRANT INSERT, UPDATE, DELETE ON public.monitoringsbuis TO NSBRO;
 ALTER TABLE public.monitoringsbuis ENABLE ROW LEVEL SECURITY;
 CREATE POLICY user_mod ON public.monitoringsbuis FOR ALL USING (true) WITH CHECK (naamruimte = (SELECT value FROM public.kvstore WHERE key = 'nsBRO')::varchar);
 ALTER TABLE public.monitoringsbuis ENABLE TRIGGER ALL;

Hiermee is het objecttype Peilbuis geimplementeerd in DEMO. Er is inmiddels ook testdata beschikbaar, de volgende keer wordt dit als proof-of-eating-the-pudding ingelezen. Daarna staat alles gereed om eens naar het gegevensbeheer te kijken.