google med begge ben på jorden

Google med begge ben på jorden

GeoMidt 26. februar 2009

Forfatter Sik Cambon Jensen

Modtagere

Dato 08-04-2023

Version 1.0


Indledning

Google map er kommet oppe fra, udefra, overalt fra og Google har skabt et globalt holdepunkt, som vi alle kan anvende og have glæde af, fordi brugen af Google map er let, og hele tiden bliver lettere. Alle kan med megen lille viden om GIS og kortdata, anvende denne nye måde at kommunikere på, og det bliver derfor mere og mere en forventning, at de offentlige institutioner, herunder også kommunerne, kan og vil kommunikere vha. kort som Google Map.

Der er ingen GIS systemer herhjemme, som på nogen måder kan komme i nærheden af hvad Google kan, når man ser på performance og brugeroplevelse. Selv på datasiden er Google map godt med og kan anvendes ’out of the box’ til mange opgaver, og er dette ikke nok kan man forholdsvist let tilføje egne data, så længe vi ikke snakker om store mængder af data. Dette er dog kun situationen lige nu og man kan kun forvente at dette forbedres over tid.

Så, hvad afholder kommunerne herhjemme, fra at anvende Google Map? Eller, en af de andre globale alternativer som findes derude?

Der er mange årsager, men den største og mest markante er konservatisme. GIS og kort er i kommunerne rodfæstet i de tekniske afdelinger, hvor data og viden om data, har været forbundet med en professionalisme, som igen er udsprunget af akademiske fagdicipliner, som ikke har haft hovedevægten på præsentation og ikke mindst kommunikation. Kartografi, jovel, men med fokus på fagspecifikke tekniske data og fagfolk som målgruppe.

Er det i virkeligheden de forkerte folk i kommunerne, som har ansvaret for kort og brugen af kort? Bemærk at jeg ikke nævnte noget om data i denne sammenhæng. Der ingen tvivl om at data skal have en høj kvalitet, og derfor skal fremstilles og vedligeholdes af fagfolk – når man snakker fagdata. Der er dog store mængder af brugerskabt data, som i lige så høj grad kan/skal skabes og bruges af brugerne – dig og mig.

I det følgende vil jeg gennemgå hvilken udvikling GIS har haft og får i en web 2.0 / 3.0 verden. Jeg vil kikke på hvilke muligheder, der er for kommunerne for at anvende Google map og lignende, og på hvorledes kommunikationen bør varetages i dette setup.

22-02-2009 Side 1/19


1 GIS og kort i en brydningstid

Kikker vi på GIS og kort fra dengang det globale Internet kun var i sin vorden og op til i dag, kan man vel sige, at den største og mest markante infrastrukturændring kommunerne har gennemgået er introduktionen af netværkstanken. GIS folkene sad med de dyre licenser og de allerdyreste maskiner til at drive software og håndtere data – de var toppen af kransekagen når det drejede sig om IT og teknologi i den kommunale forvaltning. Dengang var det svært, og viljen var der måske heller ikke til, at ville dele GIS og data med andre. Skulle man bruge kort, måtte man komme til fagfolkene. Men selv indenfor den tekniske forvaltning var der nøglepersoner, der som de eneste, sad inde med afgørende viden om kommunens GIS data. Originaldata fandtes hos originalerne og blev dårligt delt med andre.

Så kom de interne netværk og intranet tanken spredtes. Deling af data blev lettere, men stadig med mangel på en fælles konsensus for hvorledes data skulle gemmes, administreres og distribueres. Fil baseret data flød rundt på må og få, og det var stadigvæk kun de få, som havde noget der kunne minde om et overblik. Efter mange års filkaos kom gis databaserne, og klienter baseret på disse vandt indpas – man kunne nu håndtere flere brugere, flere versioner af data og replikering begyndte så småt at spøge efterhånden som behovet for dette opstod.

Sideløbende med denne udvikling var Internettet vokset, og antallet af potentielle gis brugere var eksploderet. Behovet så man, og man satte sig ned for at finde ud af hvorledes, man kunne imødekomme kravet om GIS på Internettet. GIS levereandørerne leverede deres bud på en række web baserede klienter, som man tog imod i kommunerne med kyshånd. Pludselig så det ud som om man kunne få GIS og kort i hele kommunen, og ikke mindst ud til alle borgerne. Alle kommuner fik i løbet af få år en webgis løsning, som udstillede mere eller mindre GIS og kort på de kommunale hjemmesider.

Det lyder jo alt sammen meget godt – hvad gik der galt?

Der var en række ting som kørte det hele af sporet:

1. For det første var de internationale GIS leverandører meget fokuserede på at levere webgis løsninger, som på den ene eller anden måde var letvægtsudgaver af deres desktop løsninger. Man ville så at sige løfte hele pakken ud over skranken, og gøre den tilgængelig via Internettet. Når man ikke fokuserer og prioriterer, oplever man ofte at resultatet bliver derefter. Opgaven var for stor og alle funktioner endte med at blive lige ringe.

2. GIS leverandørerne var måske undskyldt i og med, at kunderne (kommunerne og til dels udviklerne) bad om det de fik. Man bad om den fulde pakke, fordi man troede at det var det man havde brug for, hvilket ikke var helt forkert når fokus var stillet skarpt på sagsbehandlerne. Fokus var dog ikke skarpere, end at man holdt GIS for sig og resten for sig. Dvs. sagsbehandlerne fik en eller anden webgis løsning stukket i hænderne, som kontekstmæssigt var afkoblet fra resten af sagsbehandler work flow’et, og som billedlig talt var en schweitzerkniv – alt for megen (og besværlig) funktionalitet, som kun halvt eller slet ikke indfriede de behov som sagsbehandlere efterlyste.

3. Endnu værre blev det da man ville fodre borgerne af med GIS og kort … Man bibeholdt konceptet, som man havde brugt overfor sagsbehandlerne og resten af historien kender vi alle sammen. Hvor mange kommunale GIS hjemmesider har nogensinde tiltrukket borgerne og fået dem til at komme igen og igen? Ingen! Og årsagen er at borgerne ikke har behov for en sagsbehandler look a like platform, som viser tekniske GIS temaer lagindelt med muligheder for udførelse af konfliktanalyser.

22-02-2009 Side 2/19


Hvis ikke Google og hele web 2.0 tanken var kommet, sad vi nok stadig og producerede webgis løsninger med få eller ingen brugere. Hvad er det så der har rystet det hele op med rode, og fået os på andre tanker? Allerførst kan man jo sige at Google har gjort hvad man i GIS branchen ikke i sin vildeste fantasi havde troet var muligt. Man har formået at samle hele verden omkring ét kortværk, én platform og ét dataformat … noget af en bedrift, når man tager i betragtning at Google intet vidste om GIS inden de gik i gang – og det var sikkert meget godt. I stedet vidste de en hel masse om brugere – hvilke behov de har, hvordan varen skal leveres, og ikke mindst hvorledes man videreudvikler på den?

Millioner og atte millioner af brugere kan ikke tage fejl – søgning af information har en geografisk dimmension, som bør og skal udnyttes. Dette er det stik modsatte af hvad kommunernes GIS tanker gik ud på – her var det den geografiske GIS dimmension, som skabte informationerne. En ikke uvæsentlig forskel! Med udgangspunkt i informationerne giver det mening at tilføje kortene, og GIS og kort er geniale til at vise og formidle mange informationer på, på én gang. Når det modsatte er tilfældet er det de færrste, som forstår og magter at genfinde informationerne.

Om Google opfandt web 2.0, er måske så meget sagt, men de har spillet en ikke uvæsentlig rolle i den retning udviklingen har taget. På alle niveauer har web 2.0 tanken grebet ind i den måde data fødes, opbevares og præsenteres og ikke mindst udveksles. Det har betydet at alle faggrupper har været eller vil blive involveret i at transformere web 1.0 om til web 2.0. Det lyder som en stor opgave, og det er det også, men det har den fordel, at man kan starte på alle niveauer uafhængigt af de andre. Typisk vil man starte oppe fra, hvor man tidligere startede nedefra. Man vil begynde med at opbygge sine egne web løsninger ud fra andres web 2.0 komponenter, og først over tid selv være producent af egne web 2.0 komponenter.

Der er vidst brug for et eksempel: Hvor hurtigt og ikke mindst hvordan kan placeringen af 10 børnehaver med tilhørende tekst lægges på nettet med kort og hele molevitten? Meget hurtigt! Med udgangspunkt i børnehavernes adresse, kan man lynhurtigt vha. f.eks Google Spread sheet geokode disse og vha. Google Map få vist disse med tilhørende beskrivelse. Siden med Google Map kortet kan man vha. en knap få returneret som hjemmesidekode, som man igen som web redaktør nemt kan tilføje til kommunens hjemmeside.

Indtast data i Google Spread sheet (eller upload en excell regnearks fil)

22-02-2009 Side 3/19


Overfør adresser via geokoding til Google Map. (Den kvikke læser vil se at kortet kun indeholder 9 børnehaver – der var åbenbart én adresse som ikke kunne geokodes …)

Det der er værd at bemærke her, er hvor smertefrit det var at få lavet kortet og få det publiseret, men endnu mere bemærkelsesværdigt var det, at der på intet tidspunkt i forløbet, var behov for at involvere GIS afdelingen. Institutionsafdelingen kunne selv udfra egne data skabe kortet og få det publiseret.

Behovet og viljen kom oppe fra, men første skridt kunne tages uden at få hjælp nedefra.

På et eller andet tidspunkt, dukker der måske et rigtigt GIS problem op i form af et kort hvor man kan få vist hvilke institutioner, som ligger indenfor en given radius fra en given adresse (forældrenes adresse). Svaret på en sådan løsning, er lidt mere kompliceret, men så alligevel ikke … Det vil næste afsnit diskutere.

22-02-2009 Side 4/19


2 GIS mos - mashups

Et kort med børnehaver på er forholdsvist lige til, men hvad nu hvis enten data bliver mere kompleks eller den dynamiske interaktion med data gøres mere avanceret. Er man så nødt til at vende tilbage til den traditionelle webgis løsning? Ikke nødvendigvis …

En del af web 2.0 tanken består i, at kunne dele og udveksle ikke bare data men også funktionalitet. Vha Mashups har man gjort browser klienten til samlingspunktet for applikationen, og ikke som tidligere via en eller flere servere. Tidligere var det kun serveren, som kunne skaffe data og manipulere data – en given webgis løsning var i konstant kontakt med denne ene server for at kunne udføre den mindste lille handling initieret af en bruger. Dette billede er blevet ændret drastisk i web 2.0 verdenen. Det er stadig serveren / serverne som henter og behandler data, men de hoster ikke nødvendigvis den kaldende applikation. Idet det er browser-klienten, som er bossen, er det den som bestemmer fra hvilken server og med hvilke data en given handling skal eksekveres. Serveren tilbyder ikke længere webgis, men i stedet tilbyder de webgis funktionalitet.

Det er vha såkaldte API’er at en web browser løsning, kan udføre mere eller mindre avancerede funktioner. Værd at bemærke er det, at det kun er et fåtal af disse API’er, som drejer sig om GIS, men hvilken berigelse af GIS’en det er! At man nu kan kombinere GIS med alle disse andre API’er åbner muligheder som var utænkelige tidligere. Igen falder man dog i, og kommer til at tænke GIS’en først og taler om at GIS’en beriges af enorme mængder af anden informationer, men som tidligere nævnt er styrken i GIS’en ikke at vise hvad som helst, men at vise lige netop det som er vigtigt. Med andre ord er det formentlig alle de andre API’er som bliver kolosalt beriget af GIS.

Hvordan bruger man så alle disse web API’er, og hvilke kan jeg med fordel kaste mig over? Set med kommunale briller, har man allerede størsteparten af informationen, nu gælder det om at få den visualiseret, og her er det at Google map API’en (og andre lignende) kommer ind i billedet.

Inden vi kikker på denne, vil jeg dog lige stikke spaden endnu dybere, og appellere til alle med direkte adgang til data om at stille denne til rådighed via web API’er. Det betyder ikke at der bliver fuld adgang til data og at man mister kontrollen – den kan man stadig implementere i en web API, men alle som med rette har adgang og som har behov for data, vil kunne ’webbe’ en løsning lige efter deres hoved og behov.

Google Map API’en er ligesom alle de andre skrevet vha sproget JavaScript, som er den kode som browseren anvender i forbindelse med visning og interaktion med elementer på en hjemmeside. JavaScript kode kan organiseres i separate js filer, som man igen kan lægge offentligt tilgængeligt på en server. Ved at lade andre inkludere disse js filer i deres hjemmesider, beriges disse med ny funktionalitet i form af funktioner og datastrukturer til brug i browser applikationen.

Vil jeg anvende Google Map API’en, skal jeg blot inkludere denne i min HTML side og dernæst i denne tilføje et par linjer JavaScript kode.

Men allerført skal man besøge siden her: http://code.google.com/intl/da-DK/apis/maps/

For at bruge Google Map API’en skal man have en API nøgle – uden denne kan man ikke kalde Google Map fra sin JavsaScript kode.

22-02-2009 Side 5/19

http://code.google.com/intl/da-DK/apis/maps/


Når nøglen er i hus tilføjes følgende i HTML filen:

Og man har et Google kort på sin hjemmeside:

I JavaScript koden kan man interagere med kortet på rigtig mange måder, og det kræver et længere studie af hele Google Map API’en, for at kunne lave en Google Map løsning, som kan andet end blot at vise et kortudsnit. Men det vigtige her er, at det er muligt.

22-02-2009 Side 6/19


For at komme lidt hurtigere i gang kan man kikke en tur forbi Google Map legepladsen. Her kan man se og afprøve en masse API metoder, og se hvorledes de fungerer og selv efterfølgende rette og kopiere koden.

http://code.google.com/apis/ajax/playground/?exp=maps

Udover den omtalte Google Map API findes der en række andre Google API’er, som man også kan lege med ved samme lejlighed.

Jeg afsluttede forrige afsnit med at love at fortælle lidt om hvorledes man kunne gøre Google Map lidt smartere, om end ikke andet så lave en bufferanalyse. Selve bufferanalysen kan Google Map ikke lave (endnu), men hvis man havde adgang til en ande API, som kunne dette givet et punkt og en radius, så kunne resultatet vises i Google Map. Med andre ord er der behov for selv at lave eller få lavet en sådan API service. Anvender man ESRI software og kører man version 9.3.x, vil man kunne definere disse opgaver (tasks) og udstille dem som REST end point. Sidstnævnte er blot et eksempel på endnu en API, som er tilgængelig fra din hjemmeside. Man har med ESRI mulighed for at udstille GIS funktionalitet via API kald.

Før vi går videre, er det vigtigt lige at fange hvad det var der skete her. Google Map er en platform til præsentation af kort og data, men ikke i sig selv en egentlig GIS platform. Google Map kan ikke lave førnævnte bufferanalyse ej heller udføre ’hvad gælder her’ analyser – dette kræver adgang til dessiderede GIS værktøjer. Har man til på den anden side adgang til disse, så er der åbnet muligheder for rigtig mange spændende mash ups.

22-02-2009 Side 7/19

http://code.google.com/apis/ajax/playground/?exp=maps


For at førnævnte medarbejder i institutionsafdelingen på egen hånd, kan gøre brug af Google Maps kombineret med en GIS funktion, bør man få udviklet et værktøj til formålet, som simplificerer processen og gør det lige så let, som at geokode børnehaveadresser.

Apropos geokodning, får jeg lyst til at fortælle om en spændende og noget utraditionel løsning kaldet MapMyPage: http://www.mapmypage.com/

Ved at tilføje en reference til deres js fil kan man få geokodet alle forekomster af stednavne nævnt på den aktuelle side.

Når siden vises, bliver den bag om ryggen støvsuget for stednavne, som alle får tilføjet en ikon med en globus. Ved at klikke på en af disse åbnes et Google Map kort over dette sted. Simpelt og alligevel overraskende kraftfuldt.

Løsningen er baseret på MetaCartasgeotagger og er derfor begrænset tilhvilke steder, den kender.

Men inspireret af denne MapMyPage,kunne man jo sagtens forestille sig enlignende løsning baseret på en hvilkensom helst anden geotagger.

F.eks. kunne en geotagger kende tillokalplansnavne og andre kommunalestednavn og derved gøre alle kommu-nens hjemmesider beriget med kort uden at web redaktørerne skulle gørenoget som helst.

22-02-2009 Side 8/19

http://www.mapmypage.com/


3 Gør det levende

Nu har vi kikket på hvorledes kort kan laves og distribueres, nu vil vi kikke på hvorledes man tilfører liv til kort og data. Med liv menes her, hvorledes data automatisk distribueres og bliver set. I en web 2.0 verden findes, der en række mekanismer til at gøre data tilgængelig, eller med et web 2.0 term – lad os gøre kort data socialt …

Lad os først kikke på kortdata. Data findes i en lang række formater alt afhængig af hvilket GIS system der anvendes til at føde og behandle data. Google har også på dette område leveret et format, som er blevet globalt accepteret, som formatet til udveksling af data på nettet. Formatet hedder KML, og blev sidste år godkendt som en international standard under OGC (The Open Spatial GIS Consortium). Det specielle ved KML er, at det er tekstbaseret og umiddelbart læsbart (også af mennesker ;-). Søgemaskiner som Google og andre søger hovedsagligt på tekstbaseret data, og KML er derfor søgbart via Google. Gør man data tilgængeligt på webben i KML format, vil den kunne blive opdaget af interesserede og anvendt i enten Google Map eller en lang række af andre viewer applikationer.

Kort data har per definiton i mange år været behæftet med copyrights og rettigheder til brug af denne. Data har været dyr at fremstille, og har derfor også været dyr at købe. Dette har også ændret sig i web 2.0 verdenen. Data kan nu fremstilles af alle og bruges af alle. Data er med andre ord blevet billig at lave og billig at bruge. Der findes et Open Source projekt kaldet Open Street Map som er en global organisation baseret på indsamling af GIS data fra alle – og her menes alle. Kvaliteten vil aldrig nå de proffesionelt indsamlede data, men til brug for menigmand, er der her blevet givet adgang til data, som hidtil ellers var udenfor rækkevidde.

Kikker vi på endnu simplere data, såsom de tidligere nævnte geokodede børnehaver, vil små datasæt som disse komme til at betyde rigtig meget, hvis de ikke allerede gør det. Rigtig mange har anvendt muligheden for selv at skabe små og simple datasæt over stort set hvad som helst. Lavet i KML og derfor søgbart og del-bart. Dette er hele ur-essensen af hele det demokratiske Internet – styrken ved Internettet. Vender vi nu blikket mod kommunerne, er spørgsmålet om de er klar til at være med i denne bytte bytte købmand model. Er kommunerne klar til at slippe (dele af) deres data fri til fri afbenyttelse? Børnehaverne fra før er et godt eksempel på data, som kommunen kan fremstille og levere til eget brug, men også til andres brug. I en mashup verden, vil man blive overrasket over hvad og hvor data med et vil kunne bruges, til alles glæde og fordel.

Jeg har tidligere ved blandt andet Kortdage 2008, vist hvorledes grunde til salg data med fordel kunne lægges tilgængeligt for alle. Først og fremmest til kommunernes egen fordel, men på sigt også for alle andre i nationale mashups, som henteer alle grunde til salg i hele landet.

Hvad skal der til og hvor svært er det?

Som tidligere nævnt er KML blevet globalt anerkendt som standarden for udveksling af data på nettet. Det betyder også at alle de etablerede GIS software firmaer har tilføjet KML export (og import) værktøjer til deres applikationer. Har man ikke adgang til disse, findes der en lang række af gratis programmer, som kan konvertere de kendteste GIS data formater til KML.

Lægger man den rå KML data tilgængelig på kommunens hjemmeside, bliver den som nævnt søgbar og forbavsende let brugbar. F.eks kan man i Google Maps skrive url’en til KML’en direkte i søgefeltet, og trylle trylle har man har data vist i Google Map.

22-02-2009 Side 9/19


Til kommunens egen brug kan man i Google Map anvende link værktøjet til at fremstille den kode, der skal til for at web redaktøren kan indsætte kortet på kommunens hjemmeside.

Ønsker man ikke kortet på hjemmesiden kan indsætte link koden i stedet. Og links kan, som vi ved også sendes i en mail, i en chat besked eller på kommunens facebook profil ;-)

22-02-2009 Side 10/19


Afslutningsvis i dette afsnit, vil jeg omtale feeds som er måden hvorpå man gør folk opmærksom på nyheder / ændringer på en hjemmeside. Der findes forskellige feed formater som jeg dog ikke vil komme nærmere ind på her. Fælles for disse er dog at alle feed readers forstår dem. Og hvad er så en reader? En rss reader, som de kaldes er en applikation (det være en stand alone applikartion eller en web baseret løsning) som abbonnerer på førnævnte feeds. Hver gang en feed ændres, vil readeren opdage det, og vise det som en entry i readeres ’inbox’ – ligheden med et mail program er umiddelbar. I stedet for mails, indeholder inbox’en feed entries.

Ovenfor er vist Google reader, som jeg selv bruger.

Så, hvad mangler vi for at gøre cirklen komplet? Geokodning af feeds. Disse hedder GeoRss og den eneste forskel på disse i forhold til almindelige rss feeds, er at de indeholder et GeoTag. Med denne vil en reader kunne placere rss’en geografisk på et kort, og Google Map understøtter naturligvis dette.

I Google Map søgelinjen skrives blot url’en til en GeoRss feed.

22-02-2009 Side 11/19


Inden vi slutter dette afsnit af, vil jeg lige tale lidt mere om Open Source tanken. Open Street Map er som tidligere nævnt en organisation baseret på frivilliges arbejde med at indsamle GIS data (vejnet) for hele verden, og det er utroligt hvad de har kunnet udrette – mængden af data er enorm.

På applikationssiden er der også fremkommet flere Open Source baserede webgis applikationer, blandt andet OpenLayers (som både KRAK og KMS herhjemme har taget til sig).

En anden er GeoCommons, som også kan anvende Open Street Map data, men som endvidere giver alle og enhver mulighed for at uploade egne data til visning sammen med OSM data. Det rigtig smarte her er at man med GeoCommons både kan søge og anvende data, samt online kartografisk redigere dine kort.

22-02-2009 Side 12/19


Når egne date er uploaded og yderligere data fundet (der findes også en del danske data), kan man vha GeoCommons Maker, lave sit eget kort og dele det med alle andre.

Når først kortet er lavet, findes der desværre ingen API, hvorfra man kan interagere med kortet så GeoCommons må ses som værende en smart og hurtig måde at lave kort på, til brug nu og her, og som man smider væk, når de ikke længere er aktuelle.

22-02-2009 Side 13/19


4 Jorden er ikke flad

Google Earth, Microsoft virtual Earth og ESRI ArcExplorer har opdaget det som mange synes at have glemt: jorden er rund. Ikke nok med det – den fysiske verden består af mere end to dimensioner.

Visning af kort på nettet har med diverse plugins taget springet og kommet et skridt nærmere den virkelige verden. Indhold kan gøre meget, men præsentation er nøgleordet, og ikke uden grund har kloder og visning i 3D gjort verden til et sjovere og mere spændende sted at leve (set med web brillerne på). Førnævnte data spises uden videre af ovennævnte produkter når blot ingrediensen er KML.

22-02-2009 Side 14/19


Man kan vel som en tommelfingerregel sige at værdien af et kort er lig med højden gange bredden – ganger man så den 3 dimension på øges værdien derfor mange gange. Så når data tænkes og fremstilles, bør man nok i højere grad en tidligere tænke i 3D.

Tematisering af data gør sig også godt i flere dimensioner. En farveskala er en ting, men hvis man kan sætte en højde på ser man endnu tydligere hvad tematiseringen prøver at illustrere.

For ikke så længe siden inviterede Google folk / organisationer til at levere 3D data til Google Earth. Hvade man data ville Google sørge for at tilføje disse til 3D bygningslaget i GE. En del kommuner herhjemme har betalt for at få udviklet 3D bymodeller og det er synd at de ikke er kommet mere i sving

22-02-2009 Side 15/19


ende de er – i forhold til borgerne mener jeg. Havde kommunerne taget imod Googles tilbud havde vi alle haft adgang til 3D bymodeller i GE. Hagen er selvfølgelig afgivelse af data suverænitet. Når Google tilbyder noget (såsom at vise 3D bumodeller) kan man forvente at data rettighederne skal deles med Google. Og hvad kan det komme til at betyde? Umiddelbart ikke noget, men hvad nu hvis Google vælger at sælge data (og din 3D bymodel er med) hvad så? Jeg vurderer dog at fordelene opvejer ulemperne.

22-02-2009 Side 16/19


5 Konklusion

Visning af kort på kommunernes hjemmesider har indtil nu, været behæftet med tanken om, at data er varige data. Dette synes at have smittet af på de web gis løsninger man har fået lavet. Det virker som om at kort og data puttes i en web gis boks og fastfryses der. Dele kan ikke tages ud og bruges separat og data skal den tunge vej igennem hele systemet for at blive synligt.

Kommunerne skal til at lære at vi lever i køb og smid væk verden – ting er så billige i dag at det nogen gange er billigere at lave en ny dims fremfor at reparere den gamle. Der er i dag mulighed for let at lave et nyt kort, helt fra bunden, hver gang data ændres. Børnehaverne som blev nævnt er et eksempel. Vil man have flere informationer med ud i kortet er det meget hurtigere at lave kortet forfra en at skulle tilrette det eksisterende.

Det samme gælder data. Vælger man at slippe data fri vil man komme til at se at data ikke længere altid er de samme. Gamle versioner vil leve derude længe efter at de burde, men her må man sikre at man for informationer om metadata date med ud i KML filerne og gerne synligt, så alle og enhver visuelt kan se og bedømme datas validitet.

Når dette er sagt så er der ikke andet at gøre end at kridte skoene og starte med at høste de lavthængende frugter, og dernæst få kikket på hvorledes man selv, kan blive en aktiv del i en web 2.0 verden. I den forbindelse kan det blive nødvendigt at gå sammen i kortsamarbejder for at løfte opgaverne, samt i fællesskab være dem, som skubber til leverandører af data, for at få dem web 2.0 opdaterede.

22-02-2009 Side 17/19

google med begge ben på jorden

Technology

er det

der er

det publiseret

google map

med udgangspunkt

en hjemmeside

kommunens

en web 2