Geospatial anarchy

It’s not that long ago since I started my PhD, but it feels like more time than a mere 2.5 months since.

But, what have I been doing? Well, one thing is that I’m taking classes, so some time has been spent attending lectures and examns (had my first examn in 8 years today, strange feeling). I’ve also started my literature review, so I’ve done a lot of reading.

But, to not derail too much: the title of this blog post is “Geospatial Anarchy”, which was the title of a talk I gave at the danish mapping conference “Kortdage” a week ago (see abstract here). The talk was in Norwegian (but understandable by danes, I hope). There is not much of a point in sharing my slides, as they are kinda devoid of meaning without me talking.

But, even better, the conference also asked if I could write an article covering the topic of the talk. Given the rather short deadline I opted out of the peer-review-process, but submitted a non-reviewed article.

I’ll post the abstract here, and if you want to read the whole article it’s available here.

OpenStreetMap (OSM) is the largest and best-known example of geospatial data creation using Volunteered Geographic Information (VGI). A large group of non-specialists joins their efforts online to create an open, worldwide map of the world. The project differs from traditional management of geospatial data on several accounts: both the underlying technology (Open Source components) and the mindset (schema-less structures using tags and changesets). We review how traditional organizations are currently using the OSM technology to meet their needs and how the mindset of OSM could be employed to traditional management of spatial datasets as well.

Student igjen!

Nei, jeg har ikke tenkt å innlede alle poster med en forklaring på hvorfor det er så lenge siden forrige, men nå er det jo forferdelig lenge siden sist jeg har skrevet noe. Blogg er kanskje litt ut, men jeg har nå tenkt å ta det opp igjen. Hvorfor? Les vidre og bli klokere.

Så sitter jeg på Gløshaugen igjen, 7 år etter at jeg leverte inn masteroppgaven min og trodde jeg var ferdig. Hva har skjedd? Ble det oppdaget en feil som gjorde at jeg må ta opp fag? Er jeg lei livet som geomatiker og skal begynne å studere fluidmekanikk?

Nei. Livet har det med å presentere muligheter man igrunn ikke kan takke nei til. For min del begynnte det for snart 2 år siden, da jeg søkte jobb hos Norkart og havna i et kjempemiljø av likesinnede kart-nerder (hei Alex). Dog, det forklarer ikke helt hvorfor jeg nå er student igjen? Løsningen ligger ikke så langt unna, i våres fikk jeg en telefon fra Terje Midtbø med spørsmål om jeg var interessert i å ta en doktorgrad. Jeg svarte “jo, men det er vel noe som må avklares med Norkart”, hvorpå Terje svarte: “Jeg har vært i kontakt med Norkart, de er positive til en nærings-ph.d!”.

Etter en ukes tenking (og konsultasjoner med B) konkluderte jeg med at dette er en mulighet jeg ikke kan la gå fra meg. Muligheten til å fordype meg i et emne jeg synes er spennende, over lang tid, samtidig som jeg jobber for Norkart med det miljøet som finnes der, med lønn? Kjør på!

Men, hva er så emnet? Det ligger til grunn for en nærings-ph.d at temaet skal være relevant for bedriften såvel som kandidaten. Etter litt tenking og konsultasjoner landet jeg (vi?) på forvaltining og analyse av geografiske datasett, med fokus på åpne datasett. Den foreløpige tittelen er “Geospatial data management in the future – Combining data management techniques from opensource communities and governmental bodies to enable cross-data-exploration and sensemaking”, ikke småtteri.

Kortformen på norsk er “Håndtering av romlige datasett i fremtiden”, og en populærvitenskapelig fremstilling av oppgaven er som følger.

Romlige data, eller kartdata, er datene som ligger bak alle kart og lokasjonstjenester vi bruker i det daglige. I tillegg er dette data det offentlige bruker i en rekke områder av forvaltningen: Matrikkeldata (eiendomsdata), forvaltning av naturvernområder, veiutbygging er noen få eksempler.
PC-, og senere smarttelefon-revolusjonen, har økt både tilgangen på og bruken av kartdata. Ved bruk av GPS-mottakere kan man enkelt finne og dele sin egen posisjon. Et resultat av denne revolusjonen er en Wikipedia-lignende tjeneste der alle kan legge til og endre kartdata for hele verden, OpenStreetMap.

Både bruken og produksjonen av romlige datasett har økt og vil fortsette å øke nærmest eksponentielt, og det finnes en rekke formater, utvalg av kartlagte objekter og store forskjeller i kvalitet og nøyaktighet på disse dataene. Dette reiser en rekke interessante problemstillinger og spørsmål; hvordan kan vi best mulig kombinere kartdata fra en rekke ulike kilder? Hvordan kan vi effektivt lagre og oppdatere store menger kartdata? Hvordan kan vi sammenstille data fra ulike kilder og analysere dem for å finne nye sammenhenger?

Så, dette skal jeg altså vie 75% av arbeidsdagen (+++++) min til de neste 4 årene. Jeg håper å kunne komme med bidrag som mange finner interessante, både i form av de påkrevde vitenskapelige artikler, foredrag, kode (åpen) og ikke minst oppdateringer her på bloggen. Det betyr nok at det meste av innholdet fremover kommer til å være ganske snevert, men denne bloggen har vel aldri vært så veldig bred..

Rent praktisk har jeg Terje Midtbø som hovedveileder og Alexander Nossum som med-veileder, jeg har kontorplass både på NTNU (Lerkendalsbygget) og Norkarts tronddheimskontor. Jeg har ingen undervisningsplikt, men klarer nok ikke å ikke involvere meg i studentprosjekter allikevel.

Og ja, jeg gleder meg stort til å komme i gang. Formelt sett er jeg i gang fra 1. september, men ting tar tid og jeg prøver nå å sette meg inn i litteratur og forfine oppgaven min. Følg med her, eller møt meg over en øl for flere detaljer!

Verktøyene dine former deg

Ja, “our tools shapes us” er ikke noe nytt utsagn, og det er en lite orginal påstand. Men, må merker jeg effektene av dette så på kroppen at jeg har tid til å blogge litt, så da gjør jeg jo det.

Ok, tools, verktøy. Det er så klart snakk om utviklingsverktøy her. Jeg har lenge jobbet med språk som JavaScript og Python (og gjør det fortsatt), men har i den senere tid begynnt å jobbe en del i .NET-verdenen. Og jeg merker forskjeller. MANGE forskjeller. En ting er språkene, det er forskjell på utypa, ukompilerte språk som JavaScript og komplierte, typa, objektorienterte språk som C#. Absolutt. Men, C# er igrunn ikke så værst som språk, jeg synes det er mer fornuftig enn Java (selv om det er noen år siden jeg drev med det), og Linq er ganske stilig.

Men, det var ikke språket som verktøy jeg tenkte mest på, det var verktøyene rundt.

  • Editor eller IDE
  • Pakkehåndteringssystem
  • Kildekontrollsystem

Jeg tenkte på.

Først av alt Visual Studio. En mastodont uten like som prøver å gjøre ALT. Det første som møter deg er en innlogging til noe Microsoft-fjas. Så må du ha ReSharper (fordi Visual Studio ikke klarer å gjøre alt).

Visual studio er tungt, veldig tungt. Jeg vet ikke hva jeg gjør, men jeg har gjerne 4-5 instanser oppe samtidig fordi jeg jobber med mye. Da skjer det gjerne 1-2 ganger om dagen at VS tryner, og 7-8 ganger at det er “unresponsive” i 1-2 minutter. Frustrerende. Så henger drit seg opp, og du må restarte. Dette er bortkasta tid. Det fører ofte til at jeg ikke tester like ofte, det er ikke bare å endre ei linje, trykke crtl+s, alt+tab, ctrl+r. Neida, det er “begynn å endre linje, få beskjed om ikke lov”, så klikke på rød firkant, så endre, så lagre så grønn play, så vente 20 sek, så alt+tab så ctrl-r. Jeg utsetter, eller dropper å perfeksjonere ting fordi verktøyet mitt jobber mot meg. Verktøyet mitt gjør meg til en lat utvikler.

En annen ting er feedback-loopen. Om du lager en webapp med MVC må du starte og stoppe debug-instansen hver gang du gjør en endring. Pain. Much pain. Ok, så er det noen fine sider med dette også: debugging-verktøyene er gode, og det å kunne navigere rundt i koden uten å søke er fint. Men hvis du skal søke: ja da er du fucked. Min løsning er å ha prosjektet mitt åpent i Sublime Text også, for å enkelt kunne søke i det.

Så har vi pakkesystemet, nuGet. Æsj. For det første har det kommandoer på formen “Update-Package”, hvorfor ikke bare “update”, hva ellers oppdaterer du i et pakkesystem? Så klarer ikke nuGet å søke i flere pakkekilder samtidig, så du må huske å velge dette i en dropdown over “terminalen” hver gang du skal gjøre noe. Samme med target-prosjekt, jeg vet ikke hvor mange ganger jeg har lagt til ei pakke i feil prosjekt og tenkt: “jaja, det tok meg 4 minutter, jeg orker ikke å gjøre noe med det”. Det blir rot, men verktøyet mitt gjør at jeg ikke orker å rydde. Verktøyet mitt gjør meg sløv.

Og kildekontroll da. TFS. Ikke TFS med Git, men TFS med TFS. Ja, jeg vet du kan få TFS med Git og jeg skulle ønske jeg hadde det, men det har jeg ikke enda. Og da sitter jeg der med TFS i visual studio da. Og høyreklikker og høyreklikker og excluder packages (har du prøvd å .tfsignore packages/??) skriver commit-meldinger og ser at det tar 30 jævla sekunder å sjekke inn 4 linjer endra i 2 filer. Fytti! Og alle checkins går såklart rett til serveren. Hva gjør jeg da? Jo jeg blir lat. Jeg har en commit om dagen med meldinga “lots of stuff, cannot remember” etterfulgt av en ny en “add missing files, FFS TFS”!. Igjen, verktøyet mitt gjør at jeg fraviker best practices. Jeg committer ikke ofte, jeg brancher aldri og å stashe noe har jeg aldri turt å prøve på.

Og så begynner jeg å lure: Liker folk dette? Er det jeg som ikke skjønner hvordan jeg bruker disse verktøyene? Ser jeg ut som en eskimo som har forvilla seg inn blant Aboriginere? Gjør jeg alt feil? Eller stiller jeg feil krav?

Jeg vil ikke tro det er slik. Jeg har jobbet med prosjekter der jeg brukte Java, IntelliJ Idea, Maven og SVN, jeg har brukt Mercurial på samme stacken. Jeg har jobbet med JavaScript i både Ideda, Webstorm, Sublime text og såvidt Emacs. Jeg har brukt Git, og begynnt å elske git. Jeg har forholdt meg til Bower og NPM. Jeg har skrevet Python-kode og forholdt meg til pip, jeg kjører ubuntu og bruker apt. Kildekontroll, editorer og pakkesystemer er ikke noe nytt for meg. Jeg klarer bare ikke å forholde meg til dem slik Microsoft mener jeg skal.

Jeg vil ikke ha et IDE som gjør alt. I editoren min vil jeg editere kode. Kode er tekst. Litt shortcuts er fint, code-completion og intellisense er ikke dumt, og å kunne navigere seg rundt i koden og få vist testdekning og sånne ting er fine tanker. MEN NÅR ALT ER JÆVLA SIRUP blir det for mye. Jeg vil ikke ha kildekontrollsystemet mitt innbakt i IDEet, jeg vil ha det på kommandolinja. Jeg vil ikke ha et eget vindu (som plutselig er på øvre del av VS, plutselig på nedre) for å installere pakker. Med unntak av Maven (og XML-helvete) har alle andre pakkesystemer jeg har brukt fungert fint fra kommandolinja (en skikkelig kommandolinja altså. Ikke en boks i visual studio, ikke en link til “Visual Studio Developer Console”, ikke fuckings CMS eller PowerShell).

Jeg vil komme i flytsonen, jeg kommer ikke i flytsonen hvis jeg tester noe, støter på en obskur feil, kjører “Update-package” og rekker å skrive en rant på godt over 1000 ord før det forbanna systemet er ferdig med å oppdatere 20 pakker. Selv NPM som laster ned hele jævla internett 5 ganger ved update går raskere enn dette her. Dette er tregere enn å kjøre pip install scipy ffs! Og jeg tror ikke nuGet komplierer Fortran-kode!

Og så er det alle disse småtingene: “Build Action”, og jeg veit ikke hva. Ånei, fila mi ble ikke deploya nei, greit. Eller at visual studio ikke har forstått at det filsystem holder rede på filer, at man ikke trenger ei forbanna XML-fil for dette og en “show all files”-knapp.

Jeg ber ikke om mye: jeg vil ha raske verktøy som gjør det de skal, som ikke henger seg, som ikke har flere knapper enn en brusautomat i USA, som ikke skal gjøre alt samtidig. Emacs er raskt, men du kan spille tetris der. Visual studio føles som å svømme i sirup selv uten teris.

Og der var faenmen nuGet ferdig med oppdateringa si.. Trykke grønn knapp, og så launcha du enda et nytt nettleservindu på en obskur port jeg aldri husker ja, fint! Takk.

“Cannot resolve symbol” ja, jeg ba deg oppdatere pakker, ikke knekke alt!

Jaja, sånn går nå dagene. Jeg skriver i det minste Enterprise-ready-kode da! Det er rock solid og fungerer mye bedre enn tullespråk som JavaScript.

Ok, ikke blogge mens du krangler med verktøyene dine. Hadde dette verktøyet vært fysisk tror jeg det hadde hatt massevis av skader etter å ha blitt slått. Hardt.

Uanset: poenget er at verktøyene, selv de digitale, former oss.

Testing Geospatial claims using Qgis, CartoDB and Cesium.js

andersnatten
This summer I hiked to Andersnatten, a rather small mountain in the southeast of Norway. On the start of the trail there was a sign, that among other things, said that you can see 7 parishes from the top. When we reached the top we had a great view, but I couldn’t see any parishes.. That is, I have no idea where the parishes are, so I couldn’t refute or confirm the claim.

Beeing a geospatial geek I thought that this should be possible to remedy. I just needed the Parishes as polygons, and then I could do some analysis. Well, turns out that I couldn’t find any georeferenced parishes. The closes I got was these scanned paper maps. I couldn’t let this stop me, so I opened Qgis and set to work. Luckily the parish borders resembles modern day municipality borders rather close, so with the georeferenced paper maps, and some other Qgis magic (perhaps more on this in a later blog post) I managed to digitize all the 315 parishes from 1801.

I then loaded these digitized parish polygons into cartodb, and colored the ones around Sigdal, the parish where Andersnatten is. The map turned out like this:

With this in place it was rather certain that 7 was a reasonable amount, there are 6 parishes sharing a border with Sigdal, these should be see-able. According to this article “Dust, water vapour and pollution in the air will rarely let you see more than 20 kilometres (12 miles), even on a clear day.”

Ok, 20 km, lets see how close the 7 nearest parishes are to Andersnatten, using a PostGIS query in Cartodb:

SELECT 
	name,
	ST_Distance(
      the_geom::geography,
      ST_SetSRID(
        ST_MakePoint(9.41677103, 60.11744509),
        4326
      )::geography) / 1000 as dist
FROM prestegjeld
ORDER BY dist
LIMIT 7

This gives

Sigdal      0
Rolloug     5.818130882558
Flesberg    13.510679336426
Modum       19.686924594812
Næss        20.103683955646
Nordrehoug  22.199498534301
Tind        24.804343832136

Ok, so the farthest parish of the seven are 24 kms away, give us some leeway since we are on a 733 m high peak. Interestingly, the closes ones doesn’t overlap with neighboring parishes.

Ok, but, line of sight? What if there are other mountains blocking the view? Since I’m already working on a Cesium.js project I decided to add the CartoDB map to a 3d Model and do some visual tests.

View North
View North

View Southeast
View Southeast

View South
View South

View West
View West

Oh, that’s a suprise. Ok, Cesium does not add “dust, water vapour or air pollution”, and the height model might be a bit off, but nonetheless: 13 (possibly 14) parishes can be seen in this model! That is double the number stated on the sign! Guess they have backing for their claim after all!

Oh, by the way: the digitized parishes are available at GitHub

Ølkart på #hack4no

Jeg var med på #hack4no hos Kartverket på Hønefoss i helga. Da jeg satt på toget til Drammen fikk jeg en Twitter-melding:

Det viste seg at mitt bidrag: Ølkart, vant i kategorien “Beste løsning med geografiske data”, noe som jo er veldig gøy! Jeg tenkte jeg her skulle gå litt igjennom løsningen, hvordan den er blitt til og litt tanker videre.

Men, først av alt: Løsningen finner du på http://beermap.atlefren.net. Det er, som jeg skriver på siden, en: “Visualisering og søk i norske bryggerier, barer og polutsalg.” Koden ligger (så klart) på GitHub

Jeg meldte meg på hack4no mest fordi jeg tenkte det var et bra sted å møte kjente i #geomatikk-miljøet, samt at Kulturdirektoratet, som jeg jobber for for tiden er med på organisator-siden.

Jeg holdt et foredrag på formiddagen fredag om prosjektet jeg gjør for kulturrådet, med fokus på koden du finner på GitHub. Jeg hadde igrunn tenkt at jeg skulle bruke mye av tiden min på å hjelpe andre med å bruke Norvegiana-data, samt å bruke API-wrapper-prosjektet vårt, og hadde tenkt fint lite på selve konkurransen. Folk spurte meg om hva jeg skulle jobbe med, og jeg svarte at “jeg må vel gjøre noe med øl”, mest på spøk.

Dog, jeg satt meg ned i fem minutter, og tenkte litt og kom opp med en tankeskisse som inneholdt følgende: https://github.com/atlefren/norwegian-breweries. Det var vel igrunn det eneste som sto på lista da jeg gikk i gang. Så det første jeg gjorde var jo å lage et kart som viste disse bryggeriene. Ikke veldig spennende, ei heller noe vinneroppskrift. Så fant jeg ut at jeg kunne legge inn mer, Vinmonopolet har jo et “API” med butikkene sine, riktignok på et CSV-format fra helvette, men det fungerte, og jeg fikk også disse inn i kartet. Så hentet jeg puber fra OSM, jeg prøvde først med overpass APIet, men det var så komplekst at jeg valgte å bruke en nedlastet shapefil fra geofabrik, der jeg filtrerte ut puber.

Dette tok vel en god del av ettermiddagen fredag, ispedd en del spørsmål om KNreise og mye CSS-dilling. Etterhvert innså jeg at jeg burde kanskje få inn noe offentlige data ut over bakgrunnskart fra Kartverket, og bestemte meg for å legge inn addresesøket til Kartverket, noe som igrunn var en smal sak. Dette kom på plass i kartet, og jeg funderte litt på hva jeg skulle gjøre videre. Svaret ble å fokusere på lokasjon, dvs å finne nærmeste pol/pub/bryggeri. Geolocation i HTML5, kombinert med addressesøk, ble svaret her, og jeg hadde etterhvert en fin visning av 10 nærmeste. En utfordring var at jeg ikke hadde noen database i bak-kant, alle dataene ble lest inn i minnet i flask/Python-appen min fra GeoJSON. Dog, det finnes bibliotek for Haversine-avstandsberegning.

Det neste ble veldig naturlig å ruteberegne fra din posisjon til bryggeriene, og jeg lurte litt på om jeg skulle bruke Norkarts ruteberegner Ferd, Mapbox sin, eller kanskje Google sin. Jeg snakket med noen som nevnte at Vegvesenet stilte sin ruteberegner til disposisjon under hacket, noe jeg tenkte at var mest i ånden å bruke da. Denne hadde dog sine utfordringer: Mangel på CORS-støtte, krøkkete autentisering, kun UTM33, samt Esri JSON-format. Alt lot seg løse, men det hadde vært penere med GeoJSON i latLon!

Da denne biten var på plass hadde klokka nærmet seg ett på natta, men jeg var inne i en god flyt. Jeg brukte noe tid på å refaktorere det som hadde blitt ei jQuery-suppe, men gav fort opp det. Så ble det brukt noe tid på stiling av kart og markører, men heller ikke dette er noe jeg synes er dritgøy.

Dermed fant jeg ut at jeg måtte ha inn PostGIS, så jeg brukte noe tid på å få på plass dette. Det gikk overaskende smertefritt, men tok jo noe tid. En naturlig følge av å ha en romlig database var jo å kjøre noe spørringer, så jeg fikk inn kommunepolygoner og begynnte å aggregere. Da fant jeg fort ut at jeg skulle lære meg litt D3, så jeg fant en tutorial og gikk i gang. Fikk etter relativt kort tid spytta ut noe grafer, og sa meg fornøyd.

Jeg følte fortsatt at det var litt lite geohipster-preg over løsninga mi, men da klokka nærma seg seks på mårran og jeg innså at det nok ikke ble noe søvn, kom jeg på at Alex hadde blogga om hexagoner i POstGIS, heldigvis med kode. Litt tweaking senere hadde jeg et hexmap! Det gir kanskje ikke så mye innsikt, men det er kult!. Innen dette var på plass nærma det seg frokost, samt at jeg var ute en gåtur i drittværet for å bunkre snus. Timene etterpå ble brukt til å snekre sammen en presentasjon, samt å være litt i koma. Etter presentasjonen min fant jeg ut at grafene mine kunne bli bedre hvis jeg fikk inn befolkningsdata, og jeg rota meg inn på SSB sine sider. Mye data, men mye tullete formater, og mer CSV-krangling med Python. Vel, fikk det jo dataene på plass etterhvert, men det ble mye jobb.

Da grafene mine begynte å bli presentable la jeg ut et screenshot av dem på en ølnerdeside på Facebook, og fikk litt tilbakemelding på at bryggerilista jeg baserte meg på var rimelig utdatert. Det førte til at jeg innså at jeg måtte ha en funksjon for å opprette, endre og slette bryggerier. Dette tok en del tid, og ikke før i halv-fire-tida hadde jeg i det minste oppretting på plass. Det betød at jeg hadde en halvtime på meg for å lage en presentasjon eller “Pitch”. Heldigvis er Big veldig raskt å lage presentasjoner i, og jeg fikk bare 3 minutter.

Klokka fire var det tid for presentasjon, og jeg var førstemann ut. Det gikk rimelig greit synes jeg, men etter å ha sett alle de andre gruppene presentere (jeg var tydeligvis den eneste som jobbet alene), tenkte jeg at “dette vinner jeg ikke, jeg er for useriøs”. Jeg sjekket togtider til Drammen, og så at det gikk et tog 18.00, og neste 21.00. Foreldrene mine fristet med øl og spekemat, så det ble 18.00-toget! Dermed fikk jeg ikke med meg kåringen, men fikk beskjed via Twitter. Kjempekult! Jeg hadde omtrent ikke fått med meg hva premien var, og hadde nesten ikke tenkt å presentere noe, så det var kult.

Ikke bare var det kult å vinne, men det var kult å være med også! Mye flinke folk, mye gode inspill og mye spørsmål. Jeg hjalp folk med alt fra Python-kode til KNreise-apier, og fikk innspill på både datasett, løsninger og rammeverk. I tillegg fikk jeg snakket med mye folk, og ikke minst fikk jeg sitti i nærmere 24 timer og skrevet kode! Knall helg, knall arrangement. Jeg blir gjerne med til neste år.

Men, hva har jeg lært etter mitt første hackaton? Jeg kan vel ikke påstå at jeg har noen fasit, men min oppskrift på seier var vel følgende:

  • Jobb med noe du kan fra før, hvis ikke bruker du mye tid på elementære ting (ref D3)
  • Jobb med noe du synes er gøy
  • Drit i å tenke: Gjør noe!
  • Aksepter at du kommer til å lage spaghetti-kode!
  • YAGNI for alle penga
  • Lag en god presentasjon/pitch.
  • Fokuser på å ha det gøy, ikke på seier
  • For meg funka det bra å jobbe aleine, mye koordinering man slipper
  • Bruk open source bibliotek der du kan, det sparer mye tid
  • Snakk med folk, få innspill