Monthly Archives: October 2013

Hvem er vi?

Dette ble skrevet for en god stund siden, sendt inn til Posisjon, men tydligvis glemt. Tenkte at jeg i det minste kan legge det ut her.

Hvem er vi egentlig? Ja, vi, vi er jo geomatikere må vite. Vi jobber med kart. Og verden, eller i det minste Norge da, trenger flere av oss. Jeg ser også det. Jeg mener, det er jo så altfor få utviklere som kan kart. Alle klarer å sette opp en markør i Google Maps på ei nettiside, men hvis du spør dem om å legge inn en WMTS-service fra en tilecache og POSTe tilbake editerte polygoner vha WFS-t til PostGIS ser de dumt på deg! Hæ, ser du også dumt på meg? Men, dette er jo Posisjon, fagbladet for oss geomatikere! Her må jeg vel kunne snakke fag, uten å dumme det ned? Åja, landmåler sa du. Prismer og målinger og totalstasjoner og CPOS, var det det du sa? Snakk litt saktere, jeg skjønner ikke helt. Du gjør hva? Kjører landet rundt og ser inn i en kikkert? Og du er geomatiker??

Vel, jeg skal avslutte der før jeg virkelig avslører hullene i min kunnskap om geomatikkfaget (eller fagområdet?). Poenget mitt tror jeg uansett burde være klart: Vi er en ganske merkelig miks av mennesker vi geomatikere. Fellesnevneren er kart i Norge (ett poeng for selskapsnavn!), eller geodata (enda ett!) eller geomatikk (hat-trick!) da. Vi jobber med så forskjellige ting som oppmåling ute i allslags vær, byggeplasser og fastpunkter utenfor alfarvei til det trygge kontormiljøet. Og hva gjør vi i kontormiljøet? Vel, jeg skriver kode, andre holder rede på SOSI-koder mens atter andre jobber med matrikkelen (høres skummelt ut!). Og hva sier de offisielle kanalene? På utdanning.no skriver UMB følgende: “Hvorfor studere Geomatikk? Et opplagt valg hvis du er interessert i kart, webapplikasjoner, navigasjon (GPS), 3D-spill eller lignende.” 3d-spill, det er kanskje ikke der hodemangelen er størst?

Spør du en hvilkensomhelst ikke-geomatiker om hva geomatikk er jeg tror du får et lite opplysende svar. Kanskje “noe med kart”, hvis du er heldig, eller “GPS og sånn”, som mange i min omgangskrets sier. Eller “fancy geolog”, eller “matematiker som bruker kvarts istedenfor penn og papir”? Vi kan le litt av at folk ikke helt skjønner hva vi driver med, men vi har nå i det minste klart å samle oss bak et felles navn. Men jeg tror også at det innad blant oss er stor spredning i hva vi legger i begrepet. Og det er ikke så rart, vi driver jo med så forskjellige ting. Dette kan til tider være en utfordring. Det å sende inn foredrag til Geomatikkdagene kan være en spennende øvelse: kan jeg vise kode på slidene mine? Kan jeg anta at publikum vet hva HTML er?

På den annen side: denne miksen av fagretninger(?) innenfor faget(?) gjør at det alltid er spennende å møte folk som jobber med det. Du kan nesten alltid forvente å lære noe nytt, vi har en felles referanseramme i bunn (tok du den?) og det er faktisk litt gøy å fortelle folk at du er geomatiker. Når du har ytret dette kan to reaksjoner oppstå: 1. Pinlig stillhet etterfulgt av snakk om været, eller 2. En lengre diskusjon om hvorfor hytta til naboen ikke finnes “på GPSen”. Vokt deg bare vel for å si “Jeg driver med Geomatikk, men det vet sikkert ikke du hva er”. En oppvakt frisør gav meg følgende tilsvar på det utsagnet: “Nei, jeg er jo bare en dum frisør, jeg”.

Ninjatriks i Javascript, del 1

Jeg drister meg frempå med en “del 1”, selv om jeg ikke vet om det blir noen del 2, 3 etc..

Uansett: Jeg skriver jo endel Javascript, og jeg ser endel javascript-kode rundt om kring. En ting som irriterer meg er hvordan folk roter til det globale namespacet, og dermed tenkte jeg å dele noen triks for å holde styr på namespaces etc i Javascript.

Detter er på ingen måte noen fasit, men det er noe som jeg synes fungerer godt selv. Har du inspill eller korreksjoner lærer jeg gjerne av deg!

Hold det globale namespacet ryddig!

Alle funksjoner og variabler du definerer i Javascript legger seg i det “globale namespacet”. Dvs, du kan få trøbbel med at du overskriver variabler eller funksjoner som finnes fra før (hvis disse ikke har vært ryddige). Men, frykt ikke, løsningen er rimelig enkel: namespacing! Hvordan? Vel, Javascript har ikke noe namespace-konsept, men det har objekter (eller, object literals, dvs {}). Disse kan vi bruke som namespace. Si at jeg vil ha et namespace Atlefren. Da kan jeg lage det som følger:


var Atlefren = {};

Da kan jeg, lage funksjonene mine som dette:


Atlefren.myFunc = function () {
    return "foo";
};

Problemet med denne løsningen er ser du hvis du i fil a.js skriver følgende:


var Atlefren = {};
Atlefren.myFunc = function () {
    return "foo";
};

og i fil b.js:


var Atlefren = {};
Atlefren.myOtherFunc = function () {
    return "bar";
};

Hvis du inkluderer a.js og så b.js vil myFunc være “undefined”, fordi “namespacet” Atlefren settes til et tomt objekt i toppen av b.js. Et triks for å omgå dette er følgende:


var Atlefren = window.Atlefren || {};

Her skjer følgende: “namespacet” Atlefren settes lik namespacet Atlefren fra “window” (som er det globale namespacet), og hvis ikke dette finnes lages det et nytt, tomt objekt.

Dermed vil både Atlefren.myFunc og Atlefren.myOtherFunc eksistere etter at a.js og b.js er lastet, og rekkefølgen du laster dem i har heller ikke noe å si.

Selveksekverende funksjoner
Men, vi er ikke helt i mål. Hva med diverse småfunksjoner du ikke vil eksponere ut? ta dette eksempelet:


var Atlefren = window.Atlefren || {};

function someHelpingFunction(string) {
    return string + "!";
}

Atlefren.myFunc = function () {
    return someHelpingFunction("foo");
};

Nå vil Atlefren.myFunc være pent og pyntelig inne i namespacet, mens someHelpingFunction vil ligge i det globale namespacet. Vi kunne såklart lagt someHelpingFunction i Atlefren-namespacet også, men det blir upent. For det første vil det da bli masse, unødvendige funksjoner i Atlefren-namespacet, for det andre må du bruke notasjonen


namespace.funksjonsnavn = function () {};

hver gang du skal lage en ny funksjon. Det er mye skriving. Heldigvis finnes det en løsning, og den inkluderer anonyme funksjoner. Såkalte selv-eksekverende funksjoner. Teorien er sm følger:

Du kan definere en anonym funksjon som følger:


function () {};

Vi vet også at denne kan assignes til en variabel og kjøres:


var func = function () {};
func();

Dette kan også gjøres i en go:


(function () {/*do someting*/}());

Her lager vi en funksjon, og kjører den umiddelbart (det siste () er kallet til funksjonen). Det er “god skikk” å legge et ekstra par parenteser rundt en slik funksjon, for å signalisere at dette er en “selveksekverende funksjon) Denne funksjonen blir kjørt en gang og så har du ikke tilgang til den mer. Det fine her er at funksjoner at et eget scope, variabler og funksjoner definert inne i en funkjsjon legges IKKE i det globale namespacet. Dermed kan vi gjøre følgende:


var Atlefren = window.Atlefren || {}; //definer namespacet
(function () {
    //denne funksjonen finnes kun i scopet til den selv-eksekverende funksjonen
    function someHelpingFunction(string) {
        return string + "!";
    }

    // denne legges på Atlefren-namespacet som før
    Atlefren.myFunc = function () {
        return someHelpingFunction("foo");
    };
}());

Ett lite problem gjenstår: jeg må fortsatt skrive hele namespacet mitt for hver funksjon jeg skal eksponere. Dette kan bli slitsomt hvis jeg har et langt, nøstet namespace (eks org.atlefren.demo.stuff, for Java-fanatikerene), eller om jeg skal endre navnet på namespacet mitt. Heldigvis er jo den selveksekverende funksjonen nettopp en funksjon, og kan dermed ta argumenter. Vi kan dermed sende inn namespacet som et argument og bruke dette (jeg har lagt meg på å kalle parameteret ns, så jeg alltid vet hva jeg jobber med:


var Atlefren = window.Atlefren || {}; //definer namespacet
(function (ns) {
    "use strict";

    //denne funksjonen finnes kun i scopet til den selv-eksekverende funksjonen
    function someHelpingFunction(string) {
        return string + "!";
    }

    // denne legges på Atlefren-namespacet som før
    ns.myFunc = function () {
        return someHelpingFunction("foo");
    };
}(Atlefren));

Sånn, nå har vi et ryddig public namespace, ikke så mye clutter og fint strukturert kode. Hvis du er eksta nøye kan du legge på en “use strict” øverst i den selv-eksekverende funksjonen, for å fortelle javascript-parseren at du skriver “skikkelig” javascript (som jeg har gjort).

SOSI-dotformatet må dø!

I etterkant av foredraget mitt om standarder på FOSS4Gno dreide diskusjonen seg om min påstand om at “SOSI-dotformatet må dø”. Jeg tenkte jeg skulle utdype argumentene som ble “kastet mot meg”, samt gå litt mer i dybden på hvorfor jeg synes det burde avgå ved døden.

Først vil jeg gjennomgå hva vi snakker om her, slik at vi tenker på det samme. SOSI (Samordnet Opplegg for Stedfestet Informasjon) er både en “informasjonsstandard” og et dataformat. Informasjonsstandarden SOSI er noe andre land misunner kart-Norge, all den tid alle kartaktører har en felles måte å beskrive geografisk informasjon med atributter på. Jeg er på ingen måte noen kjenner av SOSI som en informasjonsstandard, men jeg er helt enig med de aller fleste her: det er et gode. SOSI er bra!

Dog, og her kommer poenget jeg også gjorde i foredraget mitt, dataformatet SOSI realiseres i, det såkalte “dotformatet” (.sos) er en helt annen historie. Det er fullt mulig å bruke andre dataformater enn dotformatet til å bære SOSI-data, og det mener jeg absolutt er på overtid å få til.

Det jobbes med å gå over til XML som dataformat for SOSI, men om det er “bedre” eller “riktig” er ikke poenget mitt nå. Poenget mitt er at det eksisterende dotformatet, som sagt, må dø. Det lever på overtid.

Dette vakte jo endel reaksjoner, såpass at det ble påpekt at “å kødde med sosi er som å kødde med sodd, troll og 17.mai” . I hovedsak var argumentene disse (med forbehold om at jeg husker riktig. Jeg husker heller ikke hvem som kom med hvilke innvendinger):

1. “SOSI er et gode. Andre land misunner oss SOSI.”
– Som sagt, SOSI som informasjonsstandard har jeg ikke noen problemer med. Det er dataformatet jeg ikke liker. Ergo ikke et godt argument.

2. “Dotformatet har fungert godt i mange år (siden 1987 ifølge wikipedia) og fungerer godt i dag. Du er ung og uerfaren, når du blir eldre vil du ikke skjønne hvorfor de unge kritiserer GML eller GeoJSON eller hva det nå er du vil ha.”
– “If it ain’t broken, don’t fix it” har aldri tatt verden videre. Jeg mener at det har skjedd såppass mye i IT-verdenen siden jeg var 3 år (ja, jeg er 3 år eldre enn SOSI tydligvis) at det er på tide å oppdatere seg. Til påstanden om at jeg er for ung: jeg håper inderlig at neste generasjon ønsker å gå bort fra de formatene vi bruker i dag. De er på ingen måte perfekte, og jeg håper ikke teknologiutviklingen stopper i 2013.

3. “Er egentlig XML så mye bedre?”
– Jeg vet ikke. Kanskje ikke, men det i seg selv gjør ikke dotformatet bra.

4. “Du skal ikke trenge å lese SOSI manuelt. Syntaksen har ikke noe å si, det finnes programvare for å lese det”.
– “Menigmann” skal ikke trenge å lese SOSI-dotformat, ei heller skrive det. Som utvikler er jeg nødt til det. Bibliotekene som finnes er enten proprietære fra de store selskapene (og koster dermed penger) eller ganske hårete å ta i bruk (OGR må kompileres med FYBA). I tillegg er de eksisterende sosi-dotformat-bibliotekene knytett til gitte programmeringspråk, DLL-filer eller c-bindinger. Hva om jeg vil parse dotformat i nettleseren via JavaScript? På en Android-telefon?

Avslutningsvis vil jeg referere noen svar jeg fikk på Twitter på mitt spørsmål om hva folk synes om dotformatet:

“Generelt ganske forferdelig?!”
“SOSI er helt konge, og treprikksnivå er toppen :)”
“greit men sært.. funker til sitt bruk men ikke mer enn det..”

Dermed: Sosi-dotformatet er et gammelt, særnorsk, format uten støtte i de store programvarepakkene (ja, det finnes norske tillegg og tilpassninger, men ikke out-of-the-box). Det egner seg kanskje til internt bruk i systemer som ikke skal byttes ut, eller for de som har inngående kjennskap til fagfeltet. Derimot, når Kartverket slipper frie data over en lav sko og det første “Petter Smart”-typer som skal lage gode (åpne?) løsninger med disse dataene møter er valget mellom å betale ut av det hvite i øyet for en programpakke for å lese disse åpne dataene, eller må manuelt kompilere FYBA og gdal for å lese dataene kan man lure på hvem dataene er beregnet for.

Dermed er min bønn, sett fortgang i arbeidet med å fase ut dotformatet, tilby alltid alternative formater ved nedlasting av kartdata og innse at selv om du “snakker SOSI i søvne” og synes det er det beste som har skjedd kartnorge: Innse at hvis kartdata skal være noe mer enn en godt bevart hemmelighet menigheten har mulighet til å jobbe med må noe gjøres. Jeg vil tro mange heller laster ned OpenStreetMap-data, banker det inn i PostGIS med osm2pg enn å betale for FME med norske tillegg for å få tak i indrefileten (ja, jeg er klar over at Kartverket tilbyr GeoJSON i tillegg til dotformat, men la meg få være litt dramatisk her.). Forvent heller ikke å kunne spare lisenskostnader ved bruk av “fri programvare” om SOSI inn og ut av løsningen er et absolutt krav: det finnes nemmelig ingen gode løsninger her.

Sånn. Let the flamewar begin!

 

Se forresten også http://labs.kartverket.no/sos/ for en (litt mer teknisk?) gjennomgang av “problemet” med dotformatet.