PostGIS som navet i dataforvaltningen ved Skog og landskap

PostGIS som navet i dataforvaltningen ved Skog og landskap muligheter, utfordringer og erfaringer Ingvild Nystuen, Lars Opsahl, Teknologiforum, 12.11.2014

Skog og landskap Den store verden Data kopieres 1 gang i uka eller ved behov Produsertedata legges inn etterhvert Brannmur ProduksjonsDB 1 Oracle2Postgres Egne applikasjoner og nettsider. Standardiserte nettjenester Oracle Enterprise Edition ArcSDE Postgres2Postgres ProduksjonsDB 2 Postgres/Postgis Internett-DB Postgres/Postgis

DB synkronisering Felles for begge løsninger Java, ingen database triggere, bruker mange parallelle tråder, hibernate-spatial Tidligere Oracle2Postgres: Fungert stabilt siste 5 år. Lite generisk kode. Ingen automatisk håndtering av relasjoner mellom tabeller Manuelle tilpassninger for nye tabeller og endringer av tabeller. Brukte mye båndbredde for å sammenligne data. Ny Postgres2Postgres: Satt i produksjon for 1 uke siden. Mye auto generert kode ved å hibernate tools Minimalt med båndbredde for å sammenligne data ved å bruke MD5 (6d9113f82f22a5fd1899fbe46f12779e pr. 5000 rad) Rask (ar5, ca. 2 minutter for sammenligning over 50.000 rader pr. sekund for ar5) Automatisk håndtering av relasjoner mellom tabeller. Støtter transaksjoner på tvers flere tabeller. Basis koden brukes også i automatisk uttak av shape filer, kan også brukes til json, gml osv

Hvorfor ikke bruke koden fra Geosynkronserings prosjektet? Ikke støtte for transaksjoner på tabell nivå eller over flere tabeller. Gml applikasjons skjema gjør det komplisert å bruke. Bruk av endrings logg legger sterke føringer på database synkronisering med flere kilder. Ønsker minst mulig installasjon av 3. parts kode som triggere osv. i databasene. Slipper XML overhead. XML gir ingen med verdi når man synker data på dette nivået. Ingen full skala implementasjon som er testet med AR5 pr. dags dato. Uklarheter i forhold til hvordan håndtere relasjoner mellom tabeller. Uklarheter i forhold til topologi.

Fase 0 : Innholdsbasert rutenett generes ut fra Ar5 innhold.

Fase 0 : AR5 input data fra QMS som linjer og punkter Input for å bygge topologi for AR5 20449285 delevis overlappende linestrings med 12 attributter 7983029 points som representer flatene med 15 attributter Innholdsbasert rutenett lages ved en psql funksjon unc_grid.sl_make_contert_based_grid(array['org_ar5.ar5_linje geo'] Maks 10000 rader og min. bredde 5000 l meter Generes 6637 ruter Minste rute 25000 dekar Største rute 555295872 dekar

Fase 0: Få linjer store ruter. Mange linjer små ruter : det betyr at arbeid pr rute blir mye mer likt.

Fase 1 : Ar5 linje bytter ut simple feature geo kollonen Postgis/Topology CREATE TABLE sde_ar5_topo_attributtes.ar5_line(..,noyaktighet NUMERIC(5),...) SELECT topology.addtopogeometrycolumn('sde_ar5_topo_data', 'sde_ar5_topo_attributtes', 'ar5_line', 'geo', 'LINESTRING') As new_layer_id; INSERT INTO sde_ar5_topo_attributtes.ar5_line (objtype, aravgrtype, noyaktighet, synbarhet, verifiseringsdato, datafangstdato, kartid, kjoringsident, arkartstd, opphav, sl_sdeid,informasjon,registreringsversjon, geo) SELECT objtype, aravgrtype, noyaktighet, synbarhet, verifiseringsdato, datafangstdato, kartid, kjoringsident, arkartstd, opphav, sl_sdeid,informasjon,registreringsversjon, topology.totopogeom(geo, 'sde_ar5_topo_data', 1, 0.0000000001) as geo from org_ar5.ar5_linje arl,... where ST_Contains(cell.geo, ST_PointN(arl.geo, 1)) and ST_Covers(cell.geo, arl.geo) and...

Fase 1 : Jobber kun med linjer innenfor rutene : det betyr at serveren kan jobbe effektivt i mange tråder og utnytte hardware optimalt og være sikker på at man ikke for noen låsing i databasen.

Fase 1 : Ingen polygoner på utsiden av rutene, ikke alle linjer er brukt

Fase 1 : Behandler kun linjer som er fullstendige innenfor valgt rute. Vi bruker snapto med 0.0000000001, dvs. under en millimeter hvis ikke har vi linjer som ikke henger sammen. Vi kunne nok brukt snapto grid, men den har vi ikke testet så mye på ennå. Alle operasjoner skjer i databasen enkle sql kommandoer. CPU krevende stor fordel å få kjøre ting i parallell. Behandler 20034002 av totalt 20492371 linjer i fase 1 (98 %) Bruker 2071m55.896s på en server med 4 dual core cpu. ( med 16 hadde det gått på under ca 12 timer). Bruker GNU parallell og psql prosedyrer. Dette gjøres bare en gang og det er når man flytter data over fra QMS til Postgisi/Topologi. Så om dette tar noe tid er ikke dette kritisk. Blir laget face for polygoner som er fullstendig dekket av hver rute når linjene legges inn.

Fase 2 : Noen tomme områder etter alle rutene er ferdig, fordi noen av linjene krysser linjene i rutenettet.

Fase 2 : Behandle linjer som krysser linjene i rutenett men som er innen for et utvalg med ruter.

Fase 2 : Områder som ikke er dekket av utvalget blir ikke behandlet, utvalget utvides derfor ved hver iterasjon.

Fase 2 : Behandler her kun linjer som krysser linjene i rutenett, men de vil være forbundet med linjer lageret i fase 1 når face bygges opp. Før fase 1 mangler det 458369 linjer, skal nå kun jobbe med linjer som ikke er behandlet fra før i fase 1. Finner disse linjene ved å slå sammen et sett med nærliggende ruter til større ruter, men vi beholder linjene fra det originale rutenettet. I fase 2 kjører slår vi sammen 25 ruter (1-25, 25-50, osv) og finner 333845 nye linjer er da ferdig med 20367847 av totalt 20492371 linjer og har da dekket over 99 % av linjene. Det tok 370m39.551s å kjøre jobben. Øker gradevis antall ruter man slår sammen inntil helle landet er dekket av en rute. Med 50 ruter i slengen tar det 56m40.045s og finner 40822 nye rader har funnet totalt 20408669 rader. Neste kjøring bruker vi 200 ruter og 83702 linjer til og det tar 77m11.351s. Neste step er 400 ruter tar 43m50.318s vi er ferdig med alle 20492371 linjer uten en eneste topologi feil.

Fase 3 : Ar5 flate lages ved å bruke face bygget opp fase 1 og 2, sammen med rep. punktene for flatene og tilhørende attributter. CREATE TABLE sde_ar5_topo_attributtes.ar5_flate( objtype VARCHAR(40), artype int4 CONSTRAINT artype_between_0_100 CHECK (artype 0 and artype < 100),...) SELECT topology.addtopogeometrycolumn('sde_ar5_topo_data', 'sde_ar5_topo_attributtes', 'ar5_flate', 'geo', 'POLYGON') As new_layer_id; INSERT INTO sde_ar5_topo_attributtes.ar5_flate (objtype.., geo) SELECT objtype, artype, arskogbon, artreslag,argrunnf, areal, maalemetode, noyaktighet, synbarhet, verifiseringsdato, datafangstdato,kartid,kjoringsident,arkartstd,opphav, sl_sdeid, topology.createtopogeom('sde_ar5_topo_data',3,2,topoelementarray ) as geo ST_GetFaceGeometry('sde_ar5_topo_data',l.face_id) as geo, topology.topoelementarray_agg(array[l.face_id,3]) as topoelementarray

Fase 3 : Behandler polygoner innenfor hver rute, dvs. som ikke krysser linjer i rutenettet. Dette er raskere siden face er ferdig bygd i fase 1 og 2. Tar det ca. 60 minutter og vi bygger da 7556998 av 7981480 dvs. ca 95 % flatene. Vi kjører da i 7 parallelle tråder. Det blir da ikke lagt inn noen nye linjer så her trenger vi ikke å bruke snapto. Enkelt å kjøre jobber i parallell når man jobber innenfor hver rute. Bruker face data for finne riktig data for valgt rute, deretter setter vi sammen face til polygoner. Henter attributt verdier fra punktene i punkt tabellen.

Fase 4 : Behandler polygoner på tvers av ruter dvs. krysser linjer i rute nettet. Jobber da bare med punkter som ikke er behandlet fra før. Jobber med face som ligger på linjene i rute nettet. Kjøres for et sett av ruter som slåes sammen. Vi starter da med å slå sammen 10 og 10 ruter det tar 9m19.609s og vi har behandlet 7776188 punkter. Med interasjon 2 så bruker 20 ruter og det tar 11m38.391s og vi har behandlet 7826089. Så slår vi sammen 100 ruter og det tar 41m4.397s og for da 7900102. Med 400 ruter så tar det 200m45.692s og vi er ferdig med 7930306 dvs. ca 99% Nå står testen og går med 500 ruter om gangen, men den testen er forsatt ikke ferdig. (I den orginale punkt tabellen er 7983029 punkter, men det er bare 7981480 flater i kontroll tabellen som jeg skal sjekke mot, så det er noe inkonsistens i dataene jeg har utgangs punkt i ved denne test casen.)

Intergrasjon med andre systemer som qgis, geoserver, mapserver osv. VI er usikker hvor bra slik verktøy støtter topologi i Postgis. Dette er uansett ikke noe problem det er veldig enkel overgang til simple feature. Ved bruke standard casting i postgres CREATE VIEW sde_ar5_topo_attributtes.ar5_flate_v AS select sl_sdeid, geo::geometry(multipolygon,4258) as geo from sde_ar5_topo_attributtes.ar5_flate ;

Ytelse for Topologi i Postgis. Skaper dette problemer for oss? Ser ut til å være mye tregere enn vanlig simple feature. Et eksempel : finne areal for 1438 polygoner toucher en rute ved å bruke geografisk søk. Postgis topology : 29544 ms. Simple feature : 1023 ms. Postgis topolog /matrialiserte views : 162 ms. Så bruk av Postgis topologi vil ikke skape problemer i forhold til våre kart tjenester. I forhold oppdatering av sentral database med Postgis/Topology tror vil heller ikke de vil skape problemer. Bruker nå 1 til 2 ms. pr polygon i snitt når vi jobber rett topologi data for å bygge opp et polygon fra et face når id'en er kjent.

Hvorfor Postgis/Topologi når man har QMS? Her har jeg ikke godt nok oversikt over QMS til gi et godt svar, men Postgis/Topologi virker veldig lovende rent funksjonelt og det har struktur som gjør at overgangen fra simple feature til topology er enkel å forstå og bruke.

Kunnsk ap for miljø og verdiska ping Takk for oss!

Sammendrag (1) Hvorfor sa du egentlig «JA» til at vi skulle begynne å jobbe med PostGIS? Vi hadde jo andre verktøy vi brukte, og de var greie nok, var de ikke? Sterkt ønske fra utviklerne Trengte en oppgradering fra den løsningen vi hadde den klarte ikke lenger jobben verken knyttet til økt bruk på Internettjenester eller behov for analyser og komplekse beregninger Fri programvare var fristende Hvorfor har det bare fortsatt med mer PostGIS? Gode resultater Utviklerne fornøyde får til mer raskere Enorm fleksibilitet, god ytelse og stabilitet. Ingen lisensproblematikk ved oppskalering. Virker bra sammen med mye ulik programvare (GIS, statistikkverktøo og programmeringsspråk) ikke bare det GIS-verktøyet det er laget for å virke med 11/13/14

Sammendrag (2) Kan du si litt om hva vi bruker det til nå? Det aller meste: forvaltning, distribusjon, beregninger, analyser. Både på servere og «tallknusere». Både mange små beregninger og store beregninger. Rutegeregning med Pgrouting. Begynt å se litt på topologi. Har dere hatt noen spesielle utfordringer? Småting som dårligere funksjonalitet på materielle views i Postgres i tidligere versjoner enn i Oracle Ytelse på vmware var lenge en utfordring har byttet til fysiske servere med ssd-disker. Hot standby base for sikkerhet og lesing. Hva tenker du har vært ekstra viktig rent teknisk for å lykkes? Fleksibilitet, ytelse Rask og enkel kopiering av data mellom baser uten nedetid i en transaksjon (sikrer konsistens): Lars forteller med egen presentasjon. 11/13/14

Sammendrag (3). Hva tenker du om framtiden for PostGIS i Skog og landskap? Hvis PostGIS holder samme kurs som i dag, tror jeg den blir lang og omfattende. Så langt ser det ut til at vi får til det vi ønsker å få til. Ting vi har savnet en god løsning på, har kommet til (f.eks materialiserte view). Topologi er viktig fordi det gir oss nye muligheter til å lage systemer for enklere oppdatering av data : Lars forteller med egen presentasjon. Teste enkel web basert oppdatering av kart. Integrasjon med GeoGig for full historikk 11/13/14