Hvis du har holdt på mer enn noen timer med enkle nettsider, blogger og “lavnivå” webutvikling basert på rimelige webhotell har du sikkert hørt om begrepet LAMP. Dette er en fellesbetegnelse på teknologier som gjør at du kommer langt med å lage deg en nettside; Linux, Apache, MySQL og PHP (eller Perl eller Python).

De aller fleste webhotell tilbyr en LAMP-løsning, og det av flere grunner; det er enkelt å komme i gang med, det fungerer meget bra og det er fri programvare. Dermed slipper man å betale lisensutgifter. Dette gjør også at det er mange som tilbyr den samme tjenesten, og man fokuserer på at ting skal fungere godt sammen.

Vel, jeg har ikke tenkt så mye på LAMP de siste årene. Jeg kjører WordPress på bloggen min her, og slipper å tenke på detaljene. På jobb går det i Java, med web-løsninger via Spring og Tomcat. MySQL er droppet til fordel for Oracle, eller PostgreSQL. Og vi hoster serverene selv, slik at vi kan installere det vi trenger.

Men, når jeg skulle i gang med MineTurer ville jeg ha ting på en egen server, helst på et webhotell. Men, nei. Det finnes få (om ingen) webhotell som tilbyr ferdiginstallasjoner av PostGIS og Geoserver (hvis vi da ser bort fra tjenester som GisCloud). Dermed endte jeg opp med Amazon EC2, der jeg kunne sette opp min egen linux-installasjon. Og så begynnte jeg å tenke, burde det ikke finnes en LAMP for webkart også?

Jo, det synes jeg. Men da må vi ha et catchy akronym: POG! Hva står det for? PostGIS, OpenLayers og Geoserver såklart. Dette er henholdsvis database, server og klientside-programmer som brukes for å lage kartapplikasjoner på nett. De er alle fri programvare, og selv om det finnes alternativer (mySQL med spatial, Mapserver, TileMill¸ Leaflet etc etc) er de definitivt mye brukt.

Vi har jo allerede OpenGeo Suite som kan kalles POG, med noe ekstra, men jeg ser frem til at flere kan levere slike løsninger, slik at det i fremtiden blir enda enklere for folk å sette opp sine egne kartløsninger på nett, uten å måtte ty til Google Maps.

Jeg registrerer at en gammel sak har fått nytt vind i seilene. Jeg husker det var snakk om det da jeg studerte, men nå har man visst fått med seg mediene også. Vi snakker om datastudenter som vil få avlegge eksamen på pc.

Begrunnelsen: man skriver aldri kode på papir, og det er langt unna fremtidige arbeidssituasjoner. Jepp, det er det, men jeg støtter fremdeles ikke kravet. La meg få utdype hvorfor.

Nei, kode skrives ikke på papir, det skrives i en teksteditor, eller et IDE. Dog, ingen skriver egentlig noe som helst for hånd mer. Dermed mener jeg at datafag ikke står i en særstilling. For, slik jeg opplever arbeidslivet, er det ikke en pc som et det viktigste. Det er ressurssene jeg har tilgang til, det jeg har i hue.

Tenk deg følgende; dra ut nettpluggen i maskina di, fjern all eksempelkode og annen kode du har liggende. Er dette normal arbeidssituasjon? Så, fjern alle kollegene dine. Normalt? Plasser så pcen din i en gymsal, sammen med 400 andre du ikke kan snakke med. Begrens så tiden du har til rådighet til 5 timer, og nekt deg selv å reise deg for å strekke på beina, spise lunch eller hente kaffe. Normal arbeidssituasjon? Neppe.

Legg så til det faktum at oppgaven din ikke er å utvikle en løsning, men å implementere Quick Sort, vise hva en linka liste er eller lage et ER-diagram for en kundedatabase.

Ser du poenget mitt? Saken er at en 5-timers eksamen ikke kommer i nærheten av “normal arbeidssituasjon” uansett. Krev heller prosjektoppgaver, kundestyrte prosjekter og hjemmeeksamen, det er mye bedre å bruke penger på dette enn å lære opp ett lass eksamensvakter til å sjekke pcer.

Så er det jo slik at 5-timers eksamen vil bli brukt fortsatt. Og ja, jeg skal innrømme at det er noe drit, men om sensor kicker på et manglende semikolon eller en feilplassert bracket er det noe grunnleggende feil. Jeg skriver selv som ei kråke for hånd, men jeg tyr ofte til papir for å komme frem til løsninger.

Så, for å konkludere; pc på eksamen er feil fokus. Skal du ha “relevant arbeidssituasjon”, kjemp for flere innleveringsoppgaver og gruppearbeider, eller involver deg i et Open Source prosjekt. Dessverre tror jeg denne kampanjen kan medføre at man får pc på eksamen, med dertil hørende problemer, og det resultat at andre områder nedprioriteres.

1. En romlig database
2. En kartserver som støtter OGC-standardene (WMS,WFS etc)
3. Et klient-side-bibliotek for å vise kart i en nettleser

For noen år siden hadde man ikke så mange muligheter på dette feltet som glad amatør. Romlige databaser var synonymt med ArcSDE fra ESRI, kartsevere som støttet OGC-standardene fantes ikke (dog, man hadde jo ArcIMS), og når det kom til klient-side biblioteker kunne man bruke det noe begrensede Google Maps, eller man kunne bruke noe fra ESRI.

Men, fortvil ikke, verden har endret seg. I dag finnes det fri programvare som kan fylle alle hullene:

• PostGIS er en genial extention til PostgreSQL, og gir deg en fullverdig romlig database
• Geoserver og Mapserver er to oppegående kartservere som heller ligger forran enn bak de proprietære løsningene
• OpenLayers er et javascript-rammeverk som gjør alt det Google Maps APIet gjør, pluss mye, mye mer

Men, så var det hvordan man skal lære seg alt dette. Hvordan de forskjellige komponentene brukes, hvvordan de konfigureres og hvordan de spiller sammen. Mye kan såklart løses ved å studere Geomatikk, men det tar ganske mye tid. Mye kan også læres ved å se på tutorials og dokumentasjon på nett. I tillegg er det nesten et krav å beherske følgende:

• SQL – bruk og teori
• Programmering generelt, og kanskje JavaScript spesielt
• Et eller annet slags server-side rammeverk, som f.eks. Java-Spring, Groovy-Grails, Ruby-Rails, JavaScript-Node.js, Python-Pyramid, PHP-whatever
• En viss kjennskap til datumer, projeksjoner, koordinatsystemer, transformasjoner og GIS-operasjoner
• Linux-generell bruk, om du skal kjøre på denne platformen (anbefales)

Men fortvil ikke, man trenger ikke kunne alt med en gang. Man kommer langt med å lære seg noe og bygge på når det trengs. Og nå er vi fremme ved hovedpoenget med denne posten: Det finnes etterhvert en rekke gode bøker som tar for seg OpenSource GIS-verktøy i dybden. Noen anbefalinger er:

• GIS for Web Developers Denne er noen år gammel, og versjonene den dekker er nok litt utdaterte, men den tar for seg både PostGIS og Geoserver, samt filformater, projeksjoner, koordinatsystemer og generelle biblioteker
• PostGIS in Action er en helt ny bok om, du gjettet riktig, PostGIS. Meget god bok, som også tar for seg endel basic geomatikk-emner på en lettfattelig måte.
• OpenLayers 2.10 Beginner’s Guide er også en helt fersk bok, som tar for seg den nyeste versjonen av OpenLayers. Jeg har ikke rukket å lese denne, men ser mange positive omtaler av den.

I tillegg vil jeg varmt anbefale to bøker om JavaScript: JavaScript: The Good Parts og Object-Oriented JavaScript.

Hvis Java er din grunnplatform er du kanskje også interessert i min post om Javascript, GIS, testing, Maven og AJAX. Skal du jobbe med Geoserver vil du nok ha nytte av å kunne litt om Tomcat, da det er java-webcontaineren denne trives best i. Og det å lære seg PostgreSQL i seg selv er nok heller ikke dumt. Kartografi er også et tema som fort kan bli nyttig å kunne noe om, men på disse områdene er jeg litt blankere på gode bokanbefalinger. Så tips meg gjerne her!

Et problem er jo at både PostgreSQL med PostGIS og en Java-container ikke akuratt er standard på webhotell rundt omkring. En mulighet er jo å kjøre sin egen server, en annen mulighet er diverse Cloud-løsninger som popper opp for tiden. Uansett, med noe av kunnskapen her i boks står du godt rustet til både å lage egne netttjenester eller, hvis du er utvikler fra før, å komme deg over i en del av IT-verdenen som er i enorm vekst. Lykke til!

Noen overordnede spørsmål:

1. OpenStreetMap blir ofte trukket frem i denne diskusjonen. Hva er fordelene og ulempene med disse dataene i forhold til “indrefileten” Kartverket (med flere, se under) sitter på?
2. Er det egentlig Kartverket som sitter på alle dataene man ønsker å frigi? Hvilke data vil man ha frigjort når man sier at kartdataene fra kartverket burde være fritt tilgjengelige?

Men, først av alt vil jeg understreke, som vi så både på GeoForum og som Martin Bekkelund har påpekt: avgjørelsen om hvorvidt kartverket skal frigi kartdataene “sine” er en politisk beslutning.

Kvalitet
Hva skiller “kartverkets data” fra dataene til OpenStreetMap? Kvalitet vil mange i “kartbransjen” si. Hva er så kvalitet? ISO 9000 (Wikipedia) definerer kvalitet som:

Helheten av egenskaper en enhet har og som vedrører dens evne til å tilfredsstille uttalte og underforståtte behov.

Vi ser jo fort at kvalitet må tolkes i sammenheng med hva man skal bruke kartdataene til. Men, jeg tror også jeg begynner å skjønne mer hva “kartmenneskene” (i motsetning til det jeg, for enkelhets skyld, vil kalle “datamenneskene” i det vidre) legger i “kvalitet”. De tenker nøyaktighet, alså at du kan sette et tall på hvor nøyaktig f.eks et hus er tegnet inn, hvor en elv går eller hvordan norges kystlinje ser ut.

Et viktig spørsmål er jo hva som er viktig. Er det “bedre kvalitet” å ha et hus med på et kart, men med en unøyaktighet på 3-4 meter? Er det best at en vei er på centimeteren nøyaktig tegnet inn på kartet slik den ble bygget for 10 år siden, eller er det best med en vei basert på et GPS-track fra i går? Jeg tror mye avhenger av brukssituasjonen, og det ser vi jo også i definisjonen på kvalitet fra ISO.

Typer kartdata
I tillegg burde man tenke over følgende: kartdata (som i “det du ser når du tar opp et norgeskart”) består av minst tre-fire-fem ganske distinkte typer data (selv om jeg ikke kan huske å ha sett dette nevnt i noe pensum), here goes:

• “Informasjon om bakken”: Her tenker jeg på informasjon som: elver, bekker, vann, kystlinjer, skoger, høydekurver, kort og godt det som hadde vært der uavhengig om vi mennesker hadde gjort noe med verden (dog, jeg vil vel også inkludere ting som dyrka mark, tettskog, myrer og oppdemte vann etc etc i denne kategorien).
• Infrastruktur. Typisk veier. Og jernbanelinjer, trikkelinjer, gang og sykkelveier, parkeringsplasser, stier, ferjeruter, bygninger og den type ting. Altså ting vi mennesker har lagd, men som tar opp plass i geografien.
• Administrative inndelinger. Det som egentlig ikke finnes i naturen. Eiendomsgrenser, samt kommune-, fylkes- og riksgrenser er vel det beste eksempelet her. Dette er konsepter vi mennesker har kommet opp med og som (så lenge vi ikke markerer med gjerder eller har latt gå langs naturlige skillelinjer som elver) elger og ulver gir pokker i.
• Det vi liker å kalle POIer, altså Points Of Interest. Dette kan være eksempelvis severdigheter, bensinstasjoner, bussholdeplasser, utsiktspunkter eller fotobokser, alt etter hva du finner “interessant”.
• Ortofoto, eller det “vanlige dødelige” kaller flybilder. Dette er jo egentlig ikke kart, og tidligere ble disse dataene nesten bare brukt i prosessen med å lage et kart. Dog, i dag forventer man å finne dette på et nettkart. Her er en kilde norgeibilder.no, som vi jo ser er et samarbeid mellom Kartverket, Skog og Landkap og Statens Vegvesen

Et poeng mange påpeker (med rette) er at OpenStreetMap har mye mer POIer enn kartverkets data. Og POIer er bra. Det er flott at disse samles inn, noe man kan dra nytte av i mange sammenhenger. Spørsmålet er bare om det kan forventes at kartverkets data skal inneholde dette?

Hvilke data har kartverket?
Landdivisjonen i kartverket opererer med en rekke produkter, fra N5000 til FKB. Dette er datasett med varierende generalisering og detaljgrad. I tillegg finnes det jo (som man kanskje ofte glemmer, ihvertfall gjør desverre ofte jeg det), en Sjødivisjon i kartverket. Disse har også en rekke produkter: Offisielle elektroniske sjøkart (ENC-er), Hovedkartserien, Havnekartserien, Kystkartserien, Overseilingskartserien og Fiskerikartserien.

Ser vi på de WMS-tjenestene kartverket tilbyr finner vi en rekke “kartlag” her også, i hovedsak: “Topografisk norgeskart” som baserer seg på N50, N250, N500 og N1000 samt FKB, i tillegg til rasterkart (“scannede papirkart”), sjøkart, dybdatata, administrative grenser, sjøgrenser samt endel “organisatoriske data”.

Hvor kommer “kartverkets” data fra?
Kartverkets data, hvis vi nå tenker på det kartet vi finner på norgeskart.no kommer fra en rekke kilder. Som vi ser nederst i kartet står det en attribution til: Statens kartverk, Geovekst og kommuner.

Statens kartverk er greit: det er jo de som står for kartdataene her i landet? Hva gjør så de to andre der? Geovekst og kommuner? Geovekst er et sammarbeid mellom Statens vegvesen, Energiforsyningen, Kommunene, Statens kartverk, Telenor og Landbruket. Disse arbeider for det formål å:

[..] gjennomføre felles kartleggingsprosjekter, etablere og vedlikeholde et felles sett av geografiske data som tilfredstiller et bredt brukerbehov. Gjennom samfinansiering kan det produseres større mengder data samtidig som det blir rimeligere for hver av partene.

Vi legger merke til at det er 6 (store) kommuner som står utenfor Geovekst, dette er Bærum, Drammen, Stavanger, Bergen og Trondheim samt Oslo. Men Oslo er ikke nevnt vi attribution linken engang: dog, det står på siden: “Dataene for Oslo kommune er ikke like detaljerte som for resten av landet”. Noe som kort og godt betyr at Oslo har valgt å holde seg unna samarbeidet om produktet FKB (Felles KartdataBase, bedre kjent som “de mest detaljerte dataene”).

Så, “kartverkets data” holder ikke helt spør du meg. Ja, kartverket koordinerer mye, men de eier ikke alle dataene. Dette er viktig å ha i bakhodet når man snakker om frislipp av data.

Kan OpenStreetMap måle seg?
Ja! Og nei! Dette er et vanskelig tema, ref spørsmålet om “hva er kvalitet”. På rene adminstrative data kan nok OSM måle seg, gitt at de får tak i de samme dataene som kartverket. På veier er OSM meget gode i mange deler av landet. De er OPPDATERTE! Bygninger har de imponerende mye av, og i konteksten “bakgrunnskart” er de absolutt nøyaktige nok. Stedsnavn er de gode på (folk med lokalkjennskap kan jo legge inn!). Stier, sykkelveger etc er de også gode på. POIer er de særdeles gode på! 3 av 5 av mine kategorier altså. Men hva med de andre to? Flybilder og “bakkedata”? Jeg tror dette er veldig enkelt: dette er data som er vanskelig å samle inn med GPS. Det er sliktsomt å gå eller kjøre langs Mjøsa for å finne den nøyaktige formen på dette, og det å tegne høydekurver, eller finne det nøyaktige elveleiet til Glomma med en GPS høres slitsomt ut. Og, flyfotoene og disse dataene henger nøye sammen. De fleste kartdataene blir nemlig produsert på grunnlag av flyfoto. Dog, i dag blir høydedata mer og mer produsert på grunnlag av laserscanninger, men man kan (og har i mange år fått) dette fra flyfoto også. Jeg tror dermed vi er inne på noe viktig i Vegard Engens kommentar til mitt forrige innlegg om temaet, når han skriver:

Det jeg ønsker meg mest fra Statens Kartverk, er egentlig høydedataene samt markslags-data (skoger, vann, fjell) osv. Dette er ting som er litt vanskelig å samle inn selv.

Her vil jeg gjerne få føye til: nesten umulig å samle inn helt selv uten dyrt og profesjonelt utstyr.

Så, hva burde deles?
Som sagt over: det viktigste er kanskje å dele markslags (eller i vidre forstand det jeg kalte) bakkedata, samt høydekurver og orthofoto. Får man frigitt dette kommer man langt. Da kan mange smarte folk lage smarte tjenester. Men, jeg er litt skeptisk når Engen kommenterer vidre:

Det første jeg ville brukt høydedataene til, var å produsere ortorektifiserte flyfoto over Bergen på dugnadsbasis Dette ville vært en flott kilde å bruke i OSM. Spesielt for bygninger er

Ikke fordi jeg mener at OSM-gjengen ikke ville klart å lage meget gode data basert på dette (og ikke for bare Bergen får vi håpe), men fordi denne jobben sitter det folk som er finansiert (på en eller annen måte) over skatteseddelen min og produserer i dag. Dermed synes jeg disse burde gjøre det, og vi alle burde nyte godt av det! Dog, intill dette blir gjort synes jeg det er flott at noen ildsjeler tar seg bryet med å jobbe med det.

Kilder til kartdata (mer eller mindre frie)
Sånn helt til slutt: Jeg nevnte Skog og Landskap sitt produkt “Kilden til arealinformasjon” i inlegget om GeoForum, men kilden er til mer enn arealinformasjon. Ved å ta en titt på mulige kartlag i klienten her finner vi en rekke offentlige institusjoner som tilbyr data som WMS:

• Kartverket (WMS og cache)
• Skog og Landskap
• SSB (Statistisk Sentralbyrå) (finner ikke WMS, men mye nedlastbart)
• RA (Riksantikvaren) (lukket?)
• DN (Direktoratet for Naturforvalting)
• NVE (Norges vassdrags- og energidirektorat)
• NGU (Norges Geologiske Undersøkelse)
• Artsdatabanken

Og såklart OpenStreetMap

PS: i arbeidet med denne listen aner jeg en oppfølgingspost! Følg med!

Konklusjon
Dette er ikke et enkelt, oversiktlig tema, og jeg har nok ikke vært utdypende i det hele tatt. Håper dog at noen har nytte av å lese gjennom her, og har jeg bomma på detaljer på vær så snill å si fra. Jeg påberoper meg ikke å kunne eller vite alt, så finner du feil si fra. Har du synspunkter, kommentarer eller vil diskutere saken nærmere er kommentarfeltet åpent for alle som makter å føre en diskusjon på sakling nivå. Det pleier ikke å være noe problem her på bloggen, så fyr løs!

T:kort ble satt i gang lenge før AtB, som dukket opp i fjor høst. Allerede da ble det skrytt høyt at de skulle få på plass et sanntidssystem, altså med GPSer i bussene, automatisk opplesning av neste holdeplass på bussen, samt skjermer på holdeplassene med info om når neste buss passerer. Jeg skrev en mail til AtB ved oppstart, der jeg svarte på en generell oppfordring om å komme med tips og ønsker. Det jeg skrev var følgende:

“Kom GJERNE med et åpent API for å eksponere rutetider og det lovede sanntidssystemet
med GPS i busser, slik at smarte folk kan lage applikasjoner til smarttelefoner etc.”

Svaret jeg fikk var meget positivt:

“Vi har en strategi angående dette, og vil komme med info på nettet etter hvert som vi har løsninger tilgjengelige.”

Men, dette med å få lansert var ikke så lett, en smule forsinket kom systemet på lufta i januar 2011, med eneste mulighet for å sjekke når bussen kom var å sende SMS. Bakvandt, gammelt og dyrt. Hva med nettapplikasjon, hva med en app, hva med et API? Jeg hørte med @KollektivtiSTrl om når nettøsninger og API kom 31. januar, dvs dagen systemet ble lansert. Svaret var:

Internett kommer, forhåpentligvis i løpet av dagen, ikke helt sikker når og hvordan. App kommer også etter hvert, men usikker når

Så ble det stille og ingenting skjedde. Ingenting ble lansert. Så leste jeg her om dagen en bloggpost av Ola Nordal, som etterspurte noen som kunne lage en app mot AtBs sanntidsssystem. Jeg kommenterte og klaget min nød over manglende API, noe som førte til twittermasing på AtB fra flere. @Miljøpakken svarte:

AtB vil lage sanntidsapp. Etter dette vil eventuell åpning av data bli vurdert. Mer info? Kontakt AtB

Og KollektiviSTrl melder:

AtB har bekreftet at de for tiden arbeider med utvikling av en eller flere app(s), men det er usikker lanseringsdato.

Den eneste informasjonen #AtB har å gi om #sanntid på internett er at det kommer “i løpet av våren 2011″.

Min spådom? Ja, det kommer til å komme en iPhone app og en dårlig webside. Når det er ferdig ser de på bruksmønsteret og budsjettet sitt og tenker: “nå har vi ikke råd til noe åpent API”, så vi driter i det. Synd, når man vet at man har åpnet for tilgang til slikt i Oslo.

For å ta et lite eksempel: Jeg har brukt et par dager på å snekre sammen denne siden: http://geomatikk.eksplisitt.net/atle/nybuss/. Den viser alle bussholdeplasser på et kart, og når du klikker i kartet for å angi hvor du befinner deg listes de bussholdeplassene som ligger innen en radius av 500 meter fra deg på siden. Her kan du så klikke for å finne bussider fra og til byen fra denne holdeplassen. Desverre får du nå følgende melding når du klikker på en slik knapp:

Siden AtB ikke har noe åpent API mot sanntidssystemet kommer vi ikke lengre. Hvis du vil vite når bussen går må du finne mobilen din og sende “ST 1522″ til 2027. Dette koster deg en krone pr melding. Heia fremtiden!

Dog, jeg har de gyldige kodene på hver holdeplass (etter en helvettes scaping fra ei pdf-fil), så hadde AtB hatt en kjempeenkelt REST-api på plass kunne jeg vist sanntidsinformasjon isteden. Jeg krever ikke annet enn et api der jeg kan sende inn en holdeplasskode og få tilbake den samme teksten som en SMS til 2027 returnerer. Men nei! Det skal vi visst ikke få enda.

Dette synes jeg er en bakstreversk holdning. Tjenester som ruteinformasjon er ikke noe man skal holde på, det er noe som skal ut til folket, så folket tar bussen!

PS:
Når det gjelder selve eksempelapplikasjonen kan jeg komme med noen kommentarer: Løsninga kjører på en kombinasjon av Openstreetmap-kartservice, OpenLayers, Geoserver og PostGIS. Holdeplassdataene stammer fra et prosjekt i samarbeid med Alexander Nossum. For å få oppdatert med de nye holdeplasskodene har jeg gjort endel manuell jobb med å konvertere AtBs Pdf med holdeplassinformasjon til et mer maskinlesbart format. Så har jeg, på navn matchet den med den opprinnelige oversikten vi hadde med holdeplassnavn og koordinater. Med endel manuell matching har jeg fått på plass de fleste holdeplasssene, men oversikten er ikke komplett. Noen som vet om slike data finnes i et fornuftig format?

Hvis du er interessert i en basedump av de scrappede dataene fra pdfen er det bare å si fra, når det gjelder koordinatene er jeg litt mer usikker på hva jussen sier, siden de er skaffet til veie litt via, via folk.. Og, har du bedre koordinater på holdeplasser er det bare å si fra!

(og ja, eksempelsiden min kommer helt uten garantier av noe slag).

Biblioteket som slippes i dag er såklart også lisensiert under en MIT-lisens, og gjør omtrent følgende:

Basert på en katalog med geotaggede bilder på webserveren plasserer den thumbnails av disse på kartet, og åpner en større versjon av dette bildet (via lightbox-aktig funksjonalitet). Dette kan såklart kombineres med GPX-funkjsonaliteten jeg tidligere har vist.

Dermed: en demo på funksjonaliteten finnes på http://kart.atlefren.net/sk_map/ (takk til Magnus Stoveland for bildene her, regner med at det er greit at jeg bruker dem?;)).

Så litt om funksjonaliteten: For å håndtere geotaggede bilder har jeg måttet ta i bruk litt PHP. Kort fortalt er dette en liten modifikasjon på koden fra masteroppgaven min, PHP-scriptet leser ut GPS-informasjon fra bilders EXIF-informasjon og bygger en GeoJSON-streng som så requestes fra OpenLayers scriptet ImageLoader.js. ImageLoader.js tar seg av å transformere koordinatene i GeoJSON stringen til UTM 33N, slik at de kan vises på kartet. I tillegg har jeg implementert LightLightbox.js, en enkel versjon av Lightbox-funksjonaliteten.

For å vise thumbnails av bildene (og store, men ikke fullsize bilder) brukes funksjonaliteten i PHP-klassen Resize_Image, hentet fra http://www.bitrepository.com/resize-an-image-keeping-its-aspect-ratio-using-php-and-gd.html.

Og, kildekoden finner du som en zip-fil på code.atlefren.net/source/sk_map.zip, den skal være å bare pakke ut på egen webserver og ta i bruk. Det eneste kravet er at du har noen GPX filer og/eller geotaggede bilder. Har du GPX-filer, men ikke geotaggede bilder kan du teste f.eks Prune, som jeg ble positivt overrasket over (kjører på alle platformer).

Husk bare et par ting: siden både GPX-filer og bildene er vektorer i kartet kan det bli vel mye for en stakkars JavaScript motor om du kjører på med for mange bilder og/eller GPX-filer (les mer i OpenLayers sin FAQ).

I tillegg er det et par kjente bugs/shortcomings her:

• Når bildelaget er aktivt kan du ikke klikke på GPX-filene for å få en popup
• PHP-classen for å håndtere bilderesizing gjør alt on-the-fly, dette kan føre til ytelsesproblemer ved mye bruk
• LightLightbox.js-koden er, for å si det mildt, elendig utseendemessig.
• Det finnes ingen load-indikatorer på bilder etc

Dog, all den tid jeg har frigjort koden er det bare å ta tak i dette, jeg er ikke noen ekspert på hverken PHP eller CSS, men det burde være greit å endre på slikt. Ellers skal koden være “greit nok” dokumentert, finner du at den ikke er det så si fra!

Og, jeg tar gjerne imot innspill til forbedringer!

Dermed har jeg rydda litt i koden, lagt til muligheten for fargekoding, “klikk-for-info” og lengdeberegning. Jeg har også flyttet all koden ut i en separat JS-klasse, og satt en åpen lisens på denne (MIT for den som lurer).

Du finner et eksempel på http://kart.atlefren.net/gpx2/, som forøvrig viser en fin tur i Sylane, anbefales!

Trykk “view source” for å få med deg oppsettet. Det viktigste er dog å huske å inkludere GpxReader.js. OBS: jeg setter pris på om du IKKE hotlinker til denne, men laster ned og legger på egen server.

Ellers er “magien” for å legge til GPX-filer enkel: et array [] med et objekt {} pr GPX-fil, som inneholder følgende:

• file: filsti til GPX-fil (husk Same origin policy)
• color: hex-representasjon for farge
• width: tykkelse på linje i pixler
• title: Tittel på track, dukker opp i popup
• desc: beskrivelse av track, dukker opp i popup

Se ellers hvordan jeg har satt opp ting i eksempelet. Og, spør gjerne om det er noe, og vis meg gjerne hva du bruker koden til, også om du endrer den!

Dog, uansett om du havner på Google Maps eller OpenLayers (ja, det finnes vel også noe fra ESRI) for å lage kartapplikasjoner som skal kjøre i nettleseren trenger du å forholde deg til Javascript. Mye kan sies om Javascript, og mye av det er feil. Likevel: det er et språk som er misbrukt mer enn PHP. Derfor: skal du gjøre noe fornuftig med Javascript anbefaler jeg deg å se Douglas Crockfords videoforelesning “programming in javascript“. Og også eventuelt lese boka hans “JavaScript: the good parts“. Og kanskje også Stoyan Stefanovs bok: “Object-Oriented JavaScript“.

Dog, det var ikke det denne posten skulle handle om. Jeg tenkte å være enda litt mer spesifikk. Jeg tenkte å skrive litt om hvordan Javascript-utvikling kan integreres i utviklingen av en Java webapp.

Det er mange steder og angripe problemet fra, men vi kan starte med Maven, som jeg er fristet til å si at er et must for javautvikling. Det finnes flere plugins for å håndtere Javascript i Maven. Jeg liker godt maven-javascript-plugin. Jeg tror ikke den vedlikeholdes så godt, men det som finnes fungerer og fyller følgende oppgaver:

• Pakke javascript-biblioteker som “dependencies”
• Komprimering og konkatinering av javascript-filer

I tillegg kan det kjøre tester, men der foretrekker jeg et annet bibliotek: nemlig Jasmine. Jasmine er et rammeverk for drive skrive Behaviour Driven Development av Javascript, i teorien betyr det at du kan skrive unit-tester for javascript. Legg til jasmine-maven-plugin og du får støtte for å kjøre testene via Maven. Javascript kan dermed testes like lett som Java-kode.

Når det gjelder AJAX (eller AJAJ som jeg liker å kalle det), synes jeg DWR (Direct Web Remoting) er brilliant. Lag en Java-klasse, eksponer metoder og kall dem direkte fra Javascriptet ditt. Enklere blir det ikke, dropp å tenke på XMLHttpRequest-oppsett og ståk. Når vi først snakker om å gjøre ting på server-siden må jo også GeoTools nevnes. GeoTools er rammeverket GeoServer baserer seg på, og er kort og godt et GIS-rammeverk for Java. Lese shapefiler, koble seg til romlige databaser som PostGIS og Oracle Spatial, gjør GIS-operasjoner som bufferanalyser og transformer koordinater. Litt dårlig dokumentert, men klarer det meste.

Hva så med Javascript-rammeverk? Det finnes jo flust av dem. Prototype, jQuery, ext, etc etc. Vel, så langt har jeg funnet ut at OpenLayers gir meg støtte for mye av det jeg trenger, og har dermed ikke begynnt å se så mye på Javascript-rammeverk enda. Jeg vet det sikkert finnes endel smarte rammeverk som kan gjøre ting enklere her også.

Til slutt tenkte jeg å nevne log4javascript, som virker som et meget ålreit loggeverktøy for javascript, det mest spennende er kanskje å sende logg til serversiden via AJAX. Hvis du ikke trenger dette vil jeg påstå at Firebug gjør jobben den også. Kombinert med “web developer plugin” gjør den FireFox til den eneste fornuftige browseren å utvikle javascript i (så er det en annen sak at det skal fungere i andre nettlesere også).

Håper denne listen med ressurser kan være til hjelp for noen. Ikke nøl med å kommentere om du ønsker utdyping på noen områder, har spørsmål eller kommentarer. Og, har du flere ressurser å dele så tar jeg gjerne imot dem med takk. Jeg har på ingen måte fasiten, så jeg håper at jeg med denne posten når ut til noen som driver med noe av det samme som meg. Jeg tror ikke vi er så veldig mange?

Dette er delvis et spørsmål, delvis et rop om hjelp, og delvis bare en ide. Svar på den måten du finner formålstjenelig, det beste hadde jo vært om noen hadde en løsning til meg, eller om noen etter å ha lest dette lager en løsning for meg. Hvis ikke du kan noen av delene kan det jo være du kjenner noen som kan kjenne til problemstillingen eller sitter inne med kompetanse og ressursser til å realisere den? Jeg har nemlig ganske stor tro på dette. Så, nok om det, til saken.

Jeg begynner etterhvert å følge ganske mange på Twitter (jeg synes ihvertfall det er en del). Mange av de jeg følger er som meg, de klarer ikke å holde seg til et tema (som jo er en god ting, men det et annet innlegg). I tillegg bruker jeg både Seesmic på telefonen og DestroyTwitter på pcen for å følge med. Dette har fått meg til å innse en mangel med Twitter (eller i det minste de klientene jeg bruker): nemlig mangelen på muligheten til å gruppere tweets.

La meg illustrere: jeg følger, naturlig nok, mange gis/geomatikk-mennesker. Disse kommer med mange intressante inspill og linker som jeg kunne tenkt meg å ta vare på, og eventuelt bruke som grunnlag for å publisere en slags “gis-høydepunkter for siste måned”-post på Terra Incognita. Jeg følger også mange bloggere, som linker til mange interessante bloggposter jeg skulle ha lest (men ikke nå..). Eller, jeg ser en tweet her og der som kan komme godt med i arbeidssituasjonen en gang. Og mange av de intressante tweetene (har vi et norsk ord for dette?) er retweets.

Mangelen er altså en måte å tagge eller gruppere tweets på. Du vil nå kanskje si at dette har vi jo hashtagger til. Eller lister. Men: nei. Ikke alle gis/geomatikk-tweets er tagget med #geomatikk (og jeg orker ikke retweete alle med #geomatikk-taggen). De færreste tweetene har hashtaggen #dennekanatlefåbrukforijobbsammenheng. Derfor er ikke hashtagger løsningen.

Hva så med lister? Der kommer det jeg tidligere nevnte med at folk twitrer om så mye forskjellig. Jeg twitrer for eksempel innimellom noe geomatikk-relatert, men legger du meg inn i en geomatikk-liste får du alle rantene mine om dumme politikere og kulda i Trondheim i tillegg. Det kan jo være du finner spennende (jeg liker ihvertfall slik “uventet” info også), men når du leter etter geomatikk-stoff i twitter-feeden din er dette støy.

Men, kan jeg ikke bare bookmarke de tweetene jeg finner interessante? Nei, jeg bruker jo nesten ikke web-interfacet til Twitter. Dessuten må jeg da bruke nettlererens bokmerkesystem for å lage orden. Det er også en dårlig løsning.

Det jeg ønsker meg er noe slikt som dette: Når jeg i f.eks DestroyTwitter ser en tweet jeg tenker at “denne kan være grei å huske på” kan jeg høyreklikke på den og velge “group as” eller “save to category” eller noe slikt smart. Da sendes denne tweeten til en separat timeline hos meg, som kan hete f.eks “tingatlesyneserverdtåsepåijobbsammenheng”, eller “geomatikkrelatert” eller “intressantebloggposter”. Henger du med? Når jeg så senere vil finne ting i en gitt kategori kan jeg browse denne timelinen, og slippe unna alt som i den sammenhengen er støy.

Do I make myself clear? Hvis ikke, skrik ut, så utdyper jeg gjerne!

Men, jeg kan egentlig ikke forstå at jeg skal være den første som kommer på dette (det er jo så smart at noen andre må ha tenkt på det). Så derfor håper og tror jeg at det finnes en twitter-klient der ute som lar meg gjøre dette? Og som i tillegg kjører på Linux (Adobe Air f.ex?). Noen som kjenner til noe slikt? Eller noen som lager eller kjenner noen som lager twitter-klienter? Tips i vei!

Og til slutt: er det bare jeg som savner noe slikt som dette, eller er det flere? Eller kan jeg løse “problemet” mitt på andre måter? Isåfall setter jeg stor pris på om du forteller meg hvordan du håndterer denne problemstillingen!

På forhånd takk!

Siden sier om seg selv:

Making Your Opinion Count
Amplicate collects similar opinions in one place; making them more likely to be found by people and companies.

Poenget er altså å samle folks meninger om “ting” på ett sted. Hvis du elsker eller hater noe kan du fortelle verden det her. Så beregnes det en Love/Hate score. En slags HotOrNot for nær sagt alle ting altså.

Men, dette er jo ikke så artig. Det som er artig er at siden bruker to store kilder til den kollektive intelligensen: Twitter og Facebook. Ikke vet jeg hvordan de gjør det, men hvis du søker på emner som Flexus, NTNU, Norge eller Linux (et tilfeldig utvalg) så ser du at den plukker opp meldinger fra disse tjenestene.

Dog: den er ikke kjempesmart, ser vi på det ene “Love”-innslaget på Flexus vil vel de fleste tenke: “IRONI” her?

Men, kult konsept. Spørsmålet er jo hvordan dette kunne blitt forbedret, om det har noen faktiske bruksområder, eller om noe du er opptatt av (positivt eller negativt) mangler her?