Findvej-blog – features, tanker, ideer, adresser

I dag er det 67 år siden, at danskerne kunne høre Frihedsbudskabet i radioen læst op af Johannes G. Sørensen, hvor det meldes “[..] at de tyske tropper i Holland, Nordvesttyskland og i Danmark har overgivet sig“. Kapitulationen trådte officielt i kraft den 5. maj om morgenen, hvorefter (det meste af) Danmark var befriet.

Rundt omkring på nettet kan man finde forskellige kort, som giver ubehagelige minder.
4. maj-initiativet har for eksempel udarbejdet et kort over faldne på Vesterbro 1943-1945.

Krigen medførte også den første fuldstændige fotografering af Danmark. Her var det dog det tyske luftvåben Luftwaffe, som stod for fotograferingen i 1944. Store dele af kortet er tilvejebragt og kan ses i Flyfotoarkivet, som blandt andet Det Kongelige Bibliotek har bidraget til med arkivmateriale. Der er mange interessante historier bag kortet.

Få dage efter besættelsens ophør blev Danmark igen fotograferet – denne gang af det britiske luftvåben, Royal Air Force. Deres luftfotos kan – til en vis grænse - også ses online.

Noget af det, jeg er mest begejstret for, i min jagt på at kombinere offentlig data, er mulighederne i Wikipedia for at kombinere og strukturere informationer på kryds og tværs – med et mål, som ikke blot er teoretisk interessant, men praktisk brugbart.

Nyeste skud på stammen er en opdatering af Wikipedia-kortet, hvor man kan se artikler med koordinater tilknyttet, som mangler et billede.

Baggrunden var en snak på Wikipedias danske chat-kanal, hvor Thyge havde kommet på en idé om at lave et kort, hvor artikler, som folk savnede billeder til, var prikket ind, så man kunne se, om der var nogen i nærheden af sig selv, samt hvor, der lå klumper af steder og bygninger, der skulle tages billeder af. Målet var at have en struktureret tilgang til at kunne forbedre kvaliteten af den danske udgave af Wikipedia, som var til at tage og føle på.

Én af tankerne var at automatisere så mange processer som muligt, samt at gøre processen transparent for den almindelige Wikipedia-skribent. Formuleret på en anden måde:

Vi skal ikke løse et problem ved at øge kompleksiteten for den almindelige bruger.

Vi skal altså have lavet et værktøj, som kan hjælpe os, så vidt muligt uden at stille nye krav til alle frivillige skribenter. Så vi må tænke kreativt med udgangspunkt i, hvilke muligheder, vi i forvejen har til rådighed.

Du kan læse om de fire dele af processen her:

(mere…)

Torsdag aften afholdt Google releasefest for deres danske kort på maps.google.dk. Det var en hyggelig aften, hvor jeg fik snakket med flere af Googles danske (og norske og tyske) medarbejdere.

Google giver nu mulighed for at man også kan søge efter danske adresser og samarbejder blandt andet med MitKBH om lokalt indhold. Samtidig er Google Maps Mobile også blevet lanceret i en dansk udgave – hvor man altså kan søge efter danske adresser eller virksomheder. Denne funktion har været efterspurgt på Findvej tidligere, og jeg har blandt andet været i dialog med MGMaps-udviklerne om at levere data, men her skulle Googles udgave kunne opfylde de fleste behov.

Nu hvor snakken går på MitKBH, så er det også passende at nævne, at de til deres halvårsfest i aftes samtidig offentliggjorde deres mobilvenlige hjemmeside. Den giver blandt andet mulighed for at søge efter specifikke sider, eller slet og ret bare at indtaste den vej, man står på for at få foreslået nogle populære steder i nærheden.

Slutteligt – hvad betyder Googles tilstedeværelse for Findvej? Det vil tiden vise, men jeg ser meget positivt på Googles tilstedeværelse. Det spændende ved Google er, at de ikke blot går ind på et marked for at kæmpe om markedsandele, men i lige så høj grad at skabe et marked i første omgang. Mange af deres funktioner kommer også udviklere, der benytter Google Maps som fx Findvej til gode. Et eksempel på dette er ruteplanen, som benytter sig af funktioner stillet til rådighed af Google. De giver også mulighed for at finde lokale forretninger (i øvrigt med virksomhedsdata leveret fra Eniro).

Google er altså interesseret i at folk begynder at bruge kort til mere end bare at sætte en prik på et ellers bart kort med “Her bor vi”, og det er netop det ærinde, Findvej også har. Læs for eksempel om baggrunden for Smiley-siden eller prøv for den sags skyld Marauder-kortet inspireret af Harry Potter for et eksempel på at visualisere ruter på en sjovere (omend næppe mere brugbar) måde.

Så der bliver slet og ret endnu flere muligheder, nu hvor Google for alvor har fået øje på Danmark. Derudover er der stadigvæk enkelte punkter, hvor Findvej og Google Maps adskiller sig, blandt andet adressegrundlaget. I skrivende stund kan man fx ikke finde Jagtvej 69 på Google Maps. Jeg vil lade det være op til læseren at vurdere, om det er fordi Googles data netop repræsenterer den virkelige verden

Frem til 31. marts har Innovation Lab givet fri adgang til præsentationerne fra deres GeoWare-konference – vist desværre kun med Internet Explorer. Har du lyst til at se mig underholde i 9½ minut om Mashups, så er jeg at finde blandt det første sæt præsentationer. De øvrige sæt (2, 3, 4) er også værd at kigge forbi.

I forbindelse med konferencen konverterede jeg deltager-listen til en hurtig mashup for at vise den geografiske spredning, samt for at præsentere teknologien for hurtigt at konvertere et adressesæt til punkter på et kort. Ligger man som firma eller forening inde med lister over distributører, outlets, klubber eller deslige, er teknologien der til let at få konverteret store adressesæt til punkter – eventuel med hosting på Findvej.dk.

I andet sæt af præsentationerne snakkede Nokia om deres kommende serier af mobiltelefoner med GPS. Mulighederne her er mægtigt interessante (og naturligvis ikke begrænset til Nokia-produkter). Specielt kombinationen af kamera og GPS, samt at gemme GPS-oplysninger i billedets meta-data, giver vilde muligheder, blandt andet på tjenester som fx Flickr, hvor det er hurtigt at opnå den berømte kritiske masse af indhold, så man kan finde en lang række billeder i bestemte områder, og ikke mindst taget på forskellige tidspunkter, så det er muligt at opleve en række tidsbilleder af et område.

Min gamle, gigantiske 9500 Communicator, som jeg anmeldte for et magasin for over to år siden, har jeg efterhånden nørd-testet til ende, samt brugt i en god del af verden (Sverige, Tyskland, Frankrig, Spanien, USA, Bolivia), men den er stadigvæk lidt for klodset og lidt for sløv og efterhånden lidt for slidt i hængslerne. Jeg er derfor lidt fristet af deres kommende E90 Communicator. Dog blev det nævnt i deres oplæg, at deres software i bl.a. N95′eren, som også har GPS og kamera, og som kan uploade direkte til Flickr, endnu ikke understøttede muligheden at videresende de geografiske koordinater. Dette arbejdede de dog på i de næste par måneder, men jeg vil gerne se et billede taget med én af deres nye mobiler med GPS-informationer indlejret, før jeg er 100 % overbevist.

Når man laver web-applikationer, ender man altid med at bruge hysterisk meget tid på teknologiske shortcomings i forskellige applikationer. Noget, som man burde være foruden.

Findvej var ingen undtagelse. I nogle tilfælde kan man diskutere, hvad browseren skal gøre, men i andre har det blot medført irritation, frustration og masser af tid spildt på af finde frem til en browsers præcise opførsel:

Internet Explorer og highbits i URL’en

På Findvej kan man som bekendt skrive adresser ud i ét, fx http://www.findvej.dk/Ørholmgade. Internet Explorer vælger vist som den eneste browser at sende highbits i URL’en som UTF8, når man selv indtaster adressen. Det gør andre browsere ikke.

Det bliver så mere forvirrende af, at det kun er adressen og ikke querystringen, der sendes utf8-encoded. Går man fx ind på “tæst?tæst=tæst” med IE, requestes der “t%C3%A6st?tæst=tæst” (hvor %C3%A6 så er den urlencodede udgave af utf8-udgaven af “æ”).

Det er ikke en løsning bare at hælde fx strengen igennem utf8_decode(), idet det vil ændre “Ørholmgade” til “?holmgade” for andre browsere. En mulighed er at søge på to highbits i træk og så antage, at det er ét utf8-tegn. Det kan dog give problemer med Svinøøstervej og Påøvej – et problem, der måske er så lille, at det kan accepteres. Jeg har dog i stedet valgt manuelt at søg&erstatte helt bestemte utf8-kombinationer af æ, ø, å, é, m.fl.

På den positive side har ingen browsere problemer med at man indtaster mellemrum i URL’en – den sørger selv for at encode det til %20. Det bør de i øvrigt heller ikke have problemer med, idet det alligevel ikke ville give nogen mening at sende mellemrummet med u-encoded (hvilket blot ville give en 400 Bad Request fra webserveren).

Internet Explorer og highbits i URL’en, take 2

Før jeg overhovedet nåede så langt, og da sitet i udviklingsfasen blot havde adressen findvej.dk og ikke www.findvej.dk, gav Internet Explorer nogle mærkelige problemer. Nogle adresser virkede fint, mens andre blot gav en søgeside i stedet for. Det betyder, at nogle direkte adresser virkede, mens andre ikke gjorde. Øvelsen er at lure hvorfor.

Følgende adresser virkede:

• findvej.dk
• findvej.dk/Nybrogade
• findvej.dk/Øresundsvej 1
• www.findvej.dk/Øresundsvej
• www.findvej.dk/Øresundsvej 1

Følgende adresse virkede derimod ikke:

• findvej.dk/Øresundsvej

Nogle gode bud? Ellers kan jeg fortælle, hvad jeg er nået frem til nu i min jagt på Internet Explorers regler, når man indtaster en adresse. Grundlæggende set forholder det sig på denne måde:

1. Begynder adressen med www.? Så er det en webadresse
2. Hvis ikke, indeholder adressen mellemrum i stien? Så skal specialtegn encodes, og så er det en webadresse.
3. Hvis ikke, er der så highbits (som fx æøå) i stien? Så er det nok ikke en adresse, men en søgning, brugeren har gang i.
4. Hvis ikke, så er det nok en hjemmesideadresse (med forbehold for domænenavnet i øvrigt)

Benytter man ikke IE, kan man dog stadigvæk nøjes med at indtaste adressen uden www – fx findvej.dk/Øresundsvej – uden problemer. Serveren redirecter blot requests på findvej.dk/… videre til www.findvej.dk/…

Denne IE-opførsel tog mildest talt lang tid at gennemskue. Specielt at mellemrummet gjorde forskel bragte blot mere forvirring på banen.

Safari, XML og forskellige tegnsæt

Jeg er ikke glad for Safari og dets XML-håndtering. Jeg hører nogle Safari/KHTML-brugere brokke sig over IE og den manglende mulighed for at sende sider som application/xhtml+xml. Men Safaris XML-håndtering lader nærmest til at være ikke-eksisterende. Rene XML-dokumenter vises ikke struktureret (men tilsyneladende som HTML), og XML-dokumenter, der refererer til et XSL-stylesheet, bliver heller ikke vist korrekt (hvilket IE og Firefox gør, men Opera tilsyneladende ikke gør).

Jeg vil gætte på, at den manglende implementering også er årsag til et andet problem, Safari-brugere oplever: Når der foretages et adresseopslag i baggrunden (vha. Google Maps APIets GDownloadUri-funktion), hentes der et XML-resultatsæt i UTF-8-format. Selve Findvej-hjemmesiden serveres dog i ISO-8859-1. Det burde ikke give nogen problemer (idet indhold altid skal holdes op imod en encoding, og den samme tekststreng, fx “æble”, kan skrives so to forskellige tekststrenge i forskellige encodings – det er stadigvæk den samme streng), men det gør det alligevel i Safari. Teksterne bliver vist “råt”, altså UTF-8-encoded på siden. Med måske for meget selvsikkerhed i stemmen vil jeg påstå, at det er en bug i Safari. Jeg har dog ikke testet om man finder den samme opførsel i Konquerer.

Mine tre bofæller benytter alle Macs, så Safari er ikke ukendt i hjemmet. Derfor prøvede jeg tidligt at rette jeg encodingen i XML-resultatsættet og angav samtidig explicit den anden encoding. Det betød dog, at IE pludselig ikke længere ville læse XML-filen… om det er IE, APIets XML-funktioner eller hvad, der var årsagen til det problem, har jeg ikke gravet dybere i.
Jeg tror, den bedste løsning/workaround er at lade den almindelige side ligeledes overgå til UTF-8. Det ville være en fin øvelse at vænne sig til at benytte UTF-8. Jeg frygter blot at diverse småværktøjer og editors lige hælder unicode-preamble (Byte Order Mark) ind i filerne eller glemmer at encode eller dobbelt-encoder highbits. Jeg benytter en række forskellige editors og værktøjer, og dette ville jeg gerne blive ved med. Jeg har blot en mistanke om at disse applikationer indeholder lige så mange fejl som browserne.

Jeg har overvejet tre muligheder for at formidle flere informationer, alle med deres fordele og ulemper:

1. Custom markers på kortet. Dette er oplagt for fx metro-/s-togs-stationer. Dog, med ca. 100 stationer kan det måske blive tungt eller bare gnidret.
2. Indstillinger, hvor man kan tilvælge “avancerede funktioner”. Jeg er dog ikke begejstret for at adgang til informationer omhandler indstillinger. Det kan også for forskellige oplevelser, alt efter om man lige sidder på en maskine med de rette indstillinger.
3. Opdeling af informationer i tabs i boblen, fx opdelt i “Information” (som omtrent skulle være den nuværende info) og så “Værktøjer” (som skulle være links til hvadsomhelst – eventuelt også Rejseplanen).

Jeg er mest tilhænger af at få smidt nogle markers på stationer, og så begynde at bruge tabs.

Den ekstra information, jeg konkret overvejer at tilføje, er:

• Nærmeste station (fx “Nørreport st.: 600 meter, Kongens Nytorv: 800 meter”)
• Længde/breddegrad-koordinater for folk, der gerne vil vide, hvor deres hus ligger
• Link til en Google Earth-KML-fil, der inkluderer adressen

Så er der både lidt til praktisk brug og lidt til hobbyen.

Jeg har mange ideer til hvad, der kan tilføjes på Findvej – både overordnet på kortet og så på det enkelte søgeresultat. I går tilføjede jeg links til Rejseplanen fra søgeresultatet, og mulighederne for yderligere informationer og links er uendelige. Hvad med forudfyldte links til Kraks ruteplan, til Vurderingsfortegnelsen, til Google Earth, til send-en-blomst-med-Interflora, til Mastedatabasen, til Nærmeste Togstation, til KOB, til DRs licenskontor, til… til… og pludselig var der en million links.

Jeg er glad for at siden content-mæssigt er skåret ind til benet. Siden kan én ting, og det skal den kunne enkelt, hurtigt og godt. Derfor er jeg er ikke udelt begejstret over at have tilføjet Rejseplanen, idet det netop risikerer at være første skridt mod for mange links, der dog alle hver især har sin målgruppe. Jeg tror dog, det er en service for de besøgende (og måske i højere grad for de firmaer, der linker til deres adresse på Findvej og sætter pris på at deres kunder let kan finde transportmuligheder til deres adresse), men alt risikerer bare at blive til “en service” på den konto.

Jeg er om ikke andet overbevist om, at grunden til at folk er blevet glade for Findvej lige så meget handler om lignende øvrige sider på nettet (ingen nævnt, ingen glemt) indeholder alt muligt andet. Det ville være ærgerligt at falde i den grøft.

(lige præcis Interflora regner jeg dog ikke med at linke til – jeg vil ikke være medskyldig i at Findvej-brugere bliver udsat for dårlige oplevelser… det var så dagens kæphest!)

Resultat-boblen indeholder nu også et link til Rejseplanen med den besøgte adresse forudfyldt i “Til”-feltet. Rejseplanen har en fin dokumentation for at linke med felterne forudfyldt.

Flere har i øvrigt efterspurgt muligheden for at finde nærmeste s-togs-station. Jeg overvejer at tilføje stationer som markers på kortet, og/eller tilføje et opslag til at finde de nærmeste par s-togs-stationer for det aktuelle sted.

Eksempel på opslag inklusive Rejseplanen-link: www.findvej.dk/Nybrogade26,1203

En del danske vejnavne kan skrives på forskellige måder. I nogle tilfælde er der overordnede regler, men i andre tilfælde er man på herrens mark.

Er der tale om et vejnavn baseret på en person – fx Peter Faber – vil der altid være mellemrum mellem fornavn og efternavn. Det vil sige Peter Fabers Vej, og aldrig Peterfabers Vej. Desværre varierer det om hvorvidt -vej er i et ord for sig. I Århus findes Hans Egedes Vej og i Vejle findes Hans Egedesvej.

Indeholder vejnavnet forkortelser, bliver det endnu sværere at gætte korrekt. For eksempel hedder en vej på Frederiksberg H.C. Ørsteds Vej. En anden vej i Århus hedder H.C.Ørsteds Vej (uden mellemrum efter sidste punktum) og en tredje vej i Morsø hedder H C Ørstedsvej (uden punktummer eller mellemrum før -vej).

Findvej omgår dette problem ved at se stort på alle mellemrum, punktummer m.m. Det betyder, at det ikke er vigtigt om man indtaster Peterbangsvej, Peter Bangsvej eller det korrekte Peter Bangs Vej.

Derudover kan man, hvis man har meget travlt, nøjes med at indtaste begyndelsen af vejnavnet; Findvej prøver at udfylde resten af vejnavnet. Et par eksempler:

• Søgning på “Folket”
• Søgning på “Hylte10″