QGIS.DK | Spatial is not special (or how I learned to stop worrying and love the database)
610
post-template-default,single,single-post,postid-610,single-format-standard,ajax_fade,page_not_loaded,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-9.5,wpb-js-composer js-comp-ver-4.12,vc_responsive

Spatial is not special (or how I learned to stop worrying and love the database)

Af Bo Victor Thomsen,  AestasGIS

Dette indlæg er det første af en række af blogindlæg på QGIS.DK, som alle vil have et fælles tema: Hvordan man kan benytte spatielle databaser – primært sammen med QGIS, men også med andre GIS systemer. (Øvrige blogindlæg: Monkey see, monkey do – eller hvordan du installer PostgreSQL på din egen pc. )

Digital kortlægning i Danmark havde sine spæde start i sen – 1970’erne, bl.a. ved kortlægningen af det nye naturgas-ledningsnetværk samt forskellige digitaliseringsprojekter i offentlige institutioner.

I 1978 var jeg en temmelig grøn student på DTH – det nuværendes DTU – og havde fået et job som ½ tids programmør i Fredningsstyrelsen (FST). Denne  – i øvrigt ikke særligt kendte – styrelse var en af de første organisationer til at arbejde med digital kortlægning i Danmark.

Vi registrerede fortidsminder, dels til Nationalmuseets brug, dels fordi FST på det tidspunkt havde forpligtelser i forhold til administration af fortidsminde-loven. Fortidsminderne var i sin tid blevet “hånd” – plottet ind på et sæt Atlas-blade (GI 1:40.000 kort fra 1920 – 40). Originalerne var efterhånden så møre og skævvredne, at det var nødvendigt at få overført data til nye kort. Arbejdet bestod i at digitalisere punkter fra kortbladene med brug af en A0 – digitizer koblet direkte til 8-tommers floppy diskettedrev.Tektronix_4014

Filerne med de rå digitaliseringsdata blev overført til RECKU (Regnecentralen for Københavns Universitet) via en 9600 baud telefonlinie. Her blev rådata  tilsidst konverteret vha. et batch-program som dannede positioner samt tematisk informationer – selvfølgelig i et helt privat-obskurt dataformat.  Data blev tilsidst kontrolleret på en grafisk skærm – en Tektronix 4014 – og papirkort blev produceret efter behov på en CalComp A0 tromleplotter udstyret med 4 kuglepenne eller tuchpenne efter behov. Vi var godt kørende dengang i halvfjerdserne!! Som det fremgår af ovenstående benyttede man på den tid for det meste meget primitive programmer til at generere spatiale data med. Mange gange indeholdt data blot et id, en temakode samt de positionelle data. Slutproduktet var oftest nye papirkort med data fra de føromtalte systemer. Og for det meste var det de samme afdelinger og personale med baggrund i papir baseret kartografi, som stod for datafangst samt efterbehandling af data.

Selv om programmerne selvfølgelig blev forbedret voldsomt, gjorde denne produktionsmetode sig gældende i en lang årrække hos producenterne af  GIS data.

Efter min mening skabte arbejdsmetoderne en tradition for at opfatte spatiale data som ”streger” og ”krydser” på et ”elektronisk” kort – evt. forsynet med ”attributter” …  information vedhængt de spatiale data.

Der er løbet rigtigt meget vand i Odense Å siden da, men opfattelsen af spatiale data som ”streger” og ”krydser” på et ”elektronisk kort” hænger faktisk stadigvæk ved i varierende grad ganske mange steder.

Denne opfattelse af spatiale data er totalt og helt igennem forkert!

“Spatial is not special  –  Spatial data processing simply is a branch in computing between many others – and spatial data are too strategic and pervasive to be confined to niche applications

Det ovenstående citat er skrevet af Alessandro Furieri, lead developer af ”spatialite” dataformatet og hentet fra http://www.gaia-gis.it/gaia-sins/

Alessandro har ramt hovedet på sømmet med sætningen. Denne burde tatoveres bag øret hos alle, som er ansvarlige for spatiale data i deres respektive organisationer.

Spatiale data er først og fremmest data, dvs. sæt af sammehørende informationer vedrørende forskellige entiteter, hvor den positionelle del af data blot er én informations-bid blandt mange.

Ikke desto mindre gemmer mange organisationer stadigvæk deres spatiale data i specielle GIS formater såsom shape- og tab-filer – som i bund og grund er filer med tegnedata hægtet nødtørftigt sammen med dbase filer til attributterne.

Dette hæmmer brugen af GIS på flere måder:

  • Man kan kun bruge sine spatiale data via specielle GIS programmer. Dette sætter en naturlig begrænsning for brugen af data, fordi GIS programmerne ofte er dyre at anskaffe, besværlige at benytte og er derfor typisk forbeholdt en mindre antal brugere. (Dette gælder heldigvis ikke for QGIS mht. prisen !!)
  • Hvis man skal sammenstille eller -køre GIS data med andre data i organisationen skal disse data oftest kopieres fra deres eget datamiljø og konverteres til noget GIS programmerne kan forstå. Dette er en process som kan være besværlig og give anledning til gråd og tænders gnislen. (Nu ved jeg jo godt at man i det daglige ikke nødvendigvis har problemer med eksport/import af data, fordi man har sat automatiske processer op til at foretage det nødvendige trummerum – Jeg burde vide det, jeg har selv opsat og/eller programmeret bogstavlig talt hundredevis af den slags procedurer. Det ændrer ikke ved det faktum, at det kan være et risikabelt, fordyrende og i sidste ende et overflødigt mellemled)

 

Men hvordan skal man så oprette, lagre og behandle sine spatiale data ?

De skal selvfølgelig behandles som alle andre vigtige data i en organisation – dvs. placeres i en databaseHerefter benytter man databasens egne værktøjer til at finde og behandle data. Eller evt. benytter et GIS program, som faktisk understøttet brugen af spatiale data i en database som f.eks. QGis.

 

Hvad er en database ? 

Der er mange fordele med at placere sine data spatiale data i en database – og nogle ulemper. Før jeg udpensler disse, er det på sin plads at beskrive hvad en database egentlig er:

  • En database er en samling af strukturerede data – placeret i en eller flere filer i et filsystem
  • Data i databasen er for det meste struktureret efter den relationelle model: Data opdelt i tabeller; tabeller består af rækker / kolonner; hver række indeholder det samme antal felter og den enkelte felt type er den samme fra række til række. Tabellerne er indbyrdes bundet sammen vha. primær/fremmednøgler, dvs. tabeller bindes samen ved at felter i to forskellige tabeller har samme indhold/værdi.
  • Tabellernes struktur er udformet således de opfylder en række normaliseringskrav: Første, anden og tredje normalform (plus et par stykker til af mere eksotisk karakter). Opfyldelsen af disse krav betyder basalt set, at en given enkelt-information optimalt set er lagret et og kun et sted i databasen.
  • Database data, dvs. de aktuelle filer som databasen består af,  læses/skrives kun direkte af et specielt program: Et DBMS (Database management system)
  • Alle brugerprogrammer kan kun bearbejde database data ved at kommunikere med DBMS via forskellige kommunikationsprotokoller (f.eks. ODBC og JDBC). Brugerprogrammerne  arbejder aldrig direkte med databasefilerne, men kun via kommunikation til DBMS programmet.
  • Kommunikationen mellem brugerprogrammer og DBMS foregår oftest ved brug et et specielt kommandosprog kaldet SQL (Structured Query Language)(Hvis du ikke forstod de ovenstående afsnit, er du ikke alene. Det tog mig et semester på DTU i databaseteknologi for at forstå det nogenlunde. Måden at strukturere og normalisere data er et emne, som man sagtens kunne bruge mange blog indlæg på. Det kan være jeg vender tilbage til dette i et senere blogindlæg – nu er du advaret ! Men hvis du her og nu er interesseret i detaljerne, findes der en lang række artikler på internettet, f.eks. denne:https://en.wikipedia.org/wiki/Relational_database)

 

Hvad er fordelene ved en database ?

Nu hvor vi har en idé om hvad en database er, så lad os komme i gang med fordelene:

  • Først og fremmest: Dine spatiale data havner i samme database som dine øvrige data; du kan derfor bearbejde dine spatiale data med samme metoder som alle dine andre data  og gennemføre analyser, der involver alle data – både spatiale og andre data – uden at skulle lave kompleks import/export af data til/fra GIS systemet.
  • Data tilgås på en standardiseret måde via SQL. Stort set alle brugerprogrammer til analyse understøtter disse metoder. Du skal ”kun” lære et sprog (SQL) til at lave ad-hoc data analyser. Og du kan få adgang til og bruge dine spatiale data fra mange forskellige brugerprogrammer – ikke kun GIS programmer (og ikke kun GIS specialister)
  • SQL indeholder de nødvendige geografiske operatorer til at gennemføre mange, almindelige spatiale analyser direkte uden brug af et specielt GIS program.
  • I SQL kan man specificere og opbygge vilkårligt komplekse forespørgsler, som involverer multiple tabeller og meget komplekse søgekriterier. Du skal normalt ikke tage stilling til hvordan data søges frem. DBMS systemet vil selv sørge for at udføre opgaven på den mest hensigtsmæssige måde.
  • Forespørgsler kan ”gemmes” i databasen som et view. Et view er en definition på forespørgsel gemt i databasen under et specifikt navn. Næste gang du ønsker at udføre samme forespørgsel udfører man view’et i stedet. Det er vigtigt at forstå at det er definitionen på en forespørgsel, du gemmer som et view, ikke resultatet af selv forespørgslen.(Denne facilitet fungerer ualmindeligt godt sammen med QGIS, hvor et view kan bruges som en almindelig tabel).
  • Som nævnt før kan du kun få fat i databasedata via DBMS programmet. Dette forhold, som umiddelbart virker som et forsinkende mellemled er rent faktisk en af databasens helt afgørende fordele: Det giver mulighed for at lægge noget ”intelligens” i behandlingen og opbevaringen af data.Nogle få eksempler:
  • Finmasket styring af brugerrettigheder.
    Når dine data er gemt direkte i en fil, kan du essentielt have tre niveauer af rettigheder til filen: Ingen adgang, læseadgang og fuld kontrol. Ved fuld kontrol menes, at du faktisk også har mulighed for at slette filen, nogen gange ved uheld (Har du altid styr på musen når du roder med Stifinder i Windows ?) .  Når din adgang til data styres af DBMS programmet kan man opstille endog meget finkornet adgangskontrol. Dine rettigheder styres af et brugernavn/kodeord, som du altid – på den ene eller anden måde – afleverer til DBMS programmet. Rettighederne kan styres på tabelniveau og helt ned på kolonneniveau. Rettigheder mht. til databehandling splittes op i: ingen adgang, læse, oprette, opdatere, slette. Dertil kommer der er lang række ekstra rettigheder, som bestemmer hvad du i øvrigt kan gøre i databasen, som f.eks. at oprette views, nye tabeller osv.Du kan f.eks. have rettighed til at oprette nye poster i en tabel og opdatere disse, men ikke have lov til at slette dem. Samtidig kan du måske heller ikke rette data i bestemte kolonner. (Og så er det i øvrigt hulens svært at få slettet dine database filer ved et uheld via stifinder: Filerne er netop beskyttet af operativsystemet mod sådanne nogen som dig!!)
  • Finmasket datavalidering før data oprettes eller opdateres i databasen. Vha. af en constraint kan et heltalsfelt f.eks. begrænses til kun at indeholde bestemte værdier (eks. 7, 9 eller 13) i stedet for samtlige heltal. Eller man kan f.eks. begrænse en kolonne af postnumre til kun at indeholde postnumre som allerede befinder sig i en anden opslags tabel vha. en foreign key.
  • Du kan automatisk for/efterbehandle dine data ved oprettelse, opdatering eller sletning i databasen vha. triggers. Dette er programfunktioner baseret på SQL indlagt i selve databasen som udføres umiddelbart før eller efter dine data lægges i databasen. De kan gøre stort set hvad som helst med dine data.Eksempler:
    • Implementere datahistorik, som fungerer uafhængig hvilket bruger program, data kommer fra.
    • Udføre meget komplekse kontrolfunktioner før data indlægges i databasen. F.eks udføre multiple kontrol lookups i andre tabeller kombineret med posteringer a’la et dobbelt bogholderi.
    • Tilføje data til en post, f.eks UUID data eller administrative informationer såsom brugerid og rettelsestidspunkt automatisk .
    • Bearbejde data efter vilkårlig komplekse regler, før de lægges permanent ind i databasen. Jeg har f.eks. programmeret et system, hvor en PostgreSQL – database løbende modtager AIS data (oplysninger om skibspositioner) fra Søfarststyrelsen. Disse data er punktdata. Når de indlægges i databasen behandles de af entrigger funktion som automatisk finder sidste  eksisterende position for samme skib; hægter det sammen med det nye punkt til en vektor; farvelægger og symboliserer vektoren og opretter denne som en ny post i en separat ”sejllinie” – tabel. Slutteligt opdateres det eksisterende punkt i punkt tabellen med data fra den nyeste post.Resultatet er, at systemet automatisk laver en ”sejllinie” farvelagt efter skibets hastighed samtidig med at skibets sidst kendte position findes som et punkt.)
      … Alle de ovenstående eksempler kan selvfølgelig implementeres som funktioner i et specifikt brugerprogram som f.eks. MapInfo. Men hvad sker der med data, når andre tilgår samme datafil med QGis, ArcGis eller et andet programmer, hvor kontrol funktionerne ikke er implementeret ? Hvis alle data ligger i en database og kontrolfunktionerne er implementeret med databasens indbyggede funktioner er det ligegyldigt hvilket brugerprogram, der tilgår data. De vil alle blive underkastet samme kontroller og valideringsmetoder uanset om brugerprogrammer hedder QGIS, MapInfo, sagsbehandler-webgis, MS-Access eller for den sags skyld Excel.
  • Multiredigering – Et databasesystem er fra starten beregnet til at mange brugere kan redigere i samme datatabel på samme tidspunkt. Dette kan kun med vanskelighed lade sig gøre ved redigering i filbaserede data.
  • Robusthed over for hardware fejl  – De forskellige databasesystemer er udviklet kontinuert over en horisont på op til 40 år. Der har været en virkelig seriøs indsats med at gøre DBMS systemerne robuste over for hardwarefejl og utilsigtede nedlukninger. Dette gør brugen af databaser væsentligt mere robust end filbaserede systemer som shape- og tab-filer(Anekdote: Omkring 2002 fik jeg en opgave med at implementere et tablet baseret system til at registrere Natura 2000 områder i danske skovområder. Arbejdet blev udført som en MapInfo baseret applikation som redigerede data både i tab-filer og i en Sqlserver 2000 database placeret lokalt på tablet-pc’en (kun alfanumeriske data – SQL server kunne ikke indeholde spatiale data på det tidspunkt). Vores allerstørste fejlkilde ved registreringen skete, når brugeren af vanvare slukkede for tablet pc-en i felten – f.eks. ved at skifte batterier uden at at lukke ordentligt ned for MapInfo og Windows. Så blev den redigerede tab-fil stort set altid korrumperet og var ubrugelig bagefter. Vi havde rigtig mange og store problemer med dette. Vi havde til gengæld aldrig en eneste fejl med vores lokale databaser på tablet-pc’erne. Ikke en. Og den blev jo udsat for den samme ”behandling” som MapInfo. )
  • Sidst, men ikke mindst: Fil baserede data gennemgår ofte en omstrukturering og kvalitetssikring (det der med normaliseringen… ) før indlæggelse i databasen, således de fungerer optimalt i database miljøet. Dette kunne jo også gøres uden at flytte data til et databasemiljø – det er bare ikke særligt sandsynligt, det bliver gjort.

 

Hvad er så ulemperne ved en database ?

Efter denne hymne til databasens pris må jeg nok også få beskrevet ulemperne ved at bruge en database til sine data – Om ikke andet, så for at få lidt balance i regnskabet:

  • Omkostninger til anskaffelse.
    Databaser kan være dyre at anskaffe. Og spatiel databehandling kræver masser af datakraft i forhold til ”almindelig” databehandling. Det betyder anskaffelse af kraftige servere og – afhængigt af databasesystemet – nogle heftige licenspriser på databasesoftware. Det sidste kan dog undgås ved at bruge PostgreSQL, et Open Source databasesystem, hvor anskaffelsesprisen er 0,- kr.
  • Større administration – Hvis man begynder at benytte nogle af de smarte faciliteter indbygget i databasen, vil det føre til større tidsmæssige omkostninger til administration af databasen. Disse omkostninger dækkes – efter min erfaring – dog meget hurtigt i form af besparelser i form af bedre datakvalitet, bedre analyser, bedre datatilgængelighed, større orden i sine datasamlinger.
  • Dårligere performance – Performance hænger selvfølgelig sammen hvilket isenkram man benytter til at køre sin database. Men det er faktum, at det er tungere at trække data fra en database end direkte fra en fil.(Mine egne erfaringer hælder sjovt nok sjovt nok i en anden retning: På min – godtnok velvoksne, quadcore – pc kan Qgis faktisk vise et ”lokal” postgres baseret lag væsentligt hurtigere end en shape fil. Det skyldes sandsynligvis, at Qgis og Postgres arbejder på hver sin processor og jeg derfor har ”dobbelt” så meget regnekraft til rådighed for indlæsningen)
  • Mindre smidighed ved ændring af datastruktur.
    Ønsker man at løbende at ændre i sin datastruktur kræver det specielle rettigheder i databasen i forhold til alm. skrive/læse rettigheder. Endvidere skal man  – afhængig af database system – også have et vist kendskab til administration af databasesystemet udover det normale kendskab til sit GIS system.
  • Maksimal udnyttelse af databasen kræver kendskab til SQL
    Selv om det er muligt blot at benytte sin database-baserede spatielle data som om de lå i en fil skal brugeren tilegne ny viden om SQL før man kan benytte sig af databasens avancerede muligheder. Denne viden er dog kun absolut nødvendig for ”superbrugeren” – En ad-hoc bruger vil typisk benytte sig af funktioner og views som allerede vil være genereret af  andre. Og SQL er det samme sprog som resten af organisationen benytter sig af for at generere forespørgsler. Der er derfor også hælp at hente andre steder i organisationen end kun i GIS afdelingen.

 

Hvilket database system skal man så vælge ?

Ved ethvert valg af database system til spatiale data er der en række faktorer som skal overvejes før anskaffelse og ibrugtagelse:

Det indlysende svar på det ovenstående spørgsmål er: Bruger din organisation allerede et databasesystem til de øvrige data? Understøtter dette databasesystem brugen af spatiale data? Hvis svaret er ”ja” til begge spørgsmål, så skal du selvfølgelig flytte dine spatiale data over i det eksisterende databasesystem. En grundtanke var jo, at alle organisationens data skulle ligge i samme database system og kunne benyttes sammen uden problemer.

Følgende almindeligt benyttede databasesystemer understøtter spatiale data: MS-SQLServer (2008 R2+), Oracle (8+), Postgres/Postgis (8+), DB2. Der findes andre databasesystemer med understøttelse af spatiale data end disse, men de nævnte systemer dækker omkring 95 % af markedet.

Hvis man skal ud og anskaffe et nyt databasesystem er svaret lidt mere svævende: Er organisationen en 100% ”Microsoft-shop” skal man kigge grundigt på MS-SQLServer. I et sådant miljø vil valg af databasesystem under alle omstændigheder blive målt og vejet mod MS-SQLServer.  Der er sandsynligvis også mange andre tekniske hensyn at overveje end blot det at skulle opbevare spatiale data.

Er man mere frit stillet kan jeg personligt klart anbefale PostgreSQL/PostGIS – også på Windows. Set ud fra spatiale forhold er dette database system det hurtigste og nemmeste at håndtere. Og et de hurtigst kørende. Og anskaffelsesprisen er til at overskue: 0,- kr. inkl. moms.

Nå, det var nok for denne gang – stay tuned – I næste blog gennemgår jeg proceduren til at installere Postgres/Postgis på din egen Windows pc, indlæse dine første data i databasen og som rosinen i pølseenden få vist disse data i QGIS. Som en lille ekstra ”Avec” viser jeg også hvordan man kan gemme sin symbologi direkte i databasen, således laget automatisk får den rette tematisering ved åbning i nye projekter.