Teknik


Jeg er nyligt flyttet til Amagerbro, og hvad er en bedre måde at få lokalkendskab på end at rende rundt med et kamera og tage en håndfuld billeder et par timer.

Til formålet lånte jeg en bekendts kamera, et Samsung ST1000 med indbygget GPS (og wifi og bluetooth og…). Så hvad kan man få ud af at rende rundt et par timer og fyre nogle billeder af, hvis man gerne vil udleve sin indre nørd anno 2010?

GPS og geotagging

Kameraet har som nævnt GPS indbygget, hvor positionen bliver gemt i billedets EXIF-metadata. Efter at have lagt billederne ind i Picasa, er der et overblik over hvor billederne er taget henne:

Panoramabilleder

Nogle moderne digitalkameraer har indbygget panorama-funktion. Det havde dette kamera ikke, så jeg skulle selv smide en håndfuld billeder taget i cirkel nær Stadsgraven ind i et panorama-program, PTGui, for at danne ét stort billede. Det kom så til at fylde 50 MB og er på 25.000×1.640 pixels! (den fulde udgave af JPEG-billedet kan hentes her, men det fylder som sagt derefter).

Det er oplagt at se et sådan billede i Google Earth, men her trækker det lidt tænder ud at skulle behandle et 50MB-billede på samme tid, så en metode er at få skåret billedet i bidder i forskellige opløsninger, så folk kan zoome lidt frem og tilbage og blot hente relevante dele af billedet. Jeg faldt efter lidt søgen over PhotoOverlayCreator, så jeg skulle slippe for at rode med KML-filer og at kode et billedopdelings-program selv.

Resultatet er dette panorama-billede (skal åbnes i Google Earth).

Næste gang må jeg få lavet en kuppel, så der er mere himmel (og tårne) med.

Collager

PTGui kan også stykke billeder sammen side om side. Mit første resultat med dette faldt dog ikke vildt heldigt ud, men jeg synes stadigvæk at ideen er interessant. Jeg må lege lidt mere med teknikken eller finde andre programmer til formålet, for eksempel open source-værktøjet Hugin.

Google Building Maker

Google har et program til at optegne 3D-bygninger ud fra luftfotos:

Jeg har modelleret nogle bygninger i nærheden, men savnede stadigvæk en bedre tekstur. Google gav mulighed for også at bruge deres gadevisnings-billeder, men perspektivet var lidt forkert i dem – plus at jeg manglede bagsiden af bygningen. Heldigvis er der også mulighed for at indsætte sine egne fotos i Bygningsværktøjet:

Her er den endelige model. Vælg evt. 3D View og drej modellen rundt. Jeg skal stadigvæk have tweaket lidt på den, men det ser godt ud, at der er kommet bedre tekstur på.

OpenStreetMap

Mange af billederne blev taget for at registrere placeringen af butikker og andre POIs til OpenStreetMap. Her hjælper det, at der er koordinater indlejret i billederne, og der i øvrigt også optræder vejskilte og husnumre på mange af billederne, så det er let at placere bygningerne.

Det blev så til et par opdateringer med en masse nye steder lagt ind.

Flere steder fik jeg også taget billeder af åbningstider og tastet dem ind i OpenStreetMap. Det gør så, at man kan lave et dataudtræk og se hvilke steder i området, som har åbent (og som er ved at lukke).

MitKBH

Mange af cafeerne og pizzeriaerne i området er også benævnt på gå-i-byen-guiden MitKBH. Ved at kigge på det store kort i området var det let at finde steder, som manglede et billede af stedet. Her blev der lagt billeder ind for en 20-25 steder.

Wikipedia

Wikipedia-kortet for artikler med manglende billeder var der ikke lige nogen steder i nærheden, der manglede billede. Så må man jo bare tage billede af noget, som der endnu ikke er en artikel om, og så skrive lidt om det… fx Bikuben Kollegiet Ørestad.

… og så løb jeg tør for energi. All in all in a day’s work.

Alle billeder kan i øvrigt ses online, omend Picasa tilsyneladende ikke viser geodata fra dem. Individuelt set er de ikke specielt interessante, og mange af dem er udelukkende taget for at notere hvilke butikker, der ligger hvor, samt at få registreret åbningstider.

Kamera i græsNoget 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…)

Wheel of fortuneFindvej starter normalt i København, hvis der ikke er forudfyldt en adresse, eller den besøgende ikke har valgt en fast start-adresse.

Jeg har nu lavet en kobling til Hostip.info, som er en åben fortegnelse over tilhørsforhold for IP-adresser. Det betyder, at hvis Hostip-databasen ved, hvor ip-adressen normalt hører hjemme, vil kortet starte på det sted. På den måde vil nogle besøgende fra fx Odense se et kort, der tilsvarende starter op i byen.

Fortegnelsen er langt fra komplet, og nogle dele er ikke så hensigtsmæssig. Jeg har dog ryddet lidt op i den og fjernet alle udenlandske adresser, så forvirringen burde være begrænset, hvis fortegnelsen ellers mener, at man fx kommer fra Finland.

Det kan også forekomme, at man starter i en forkert by i Danmark, men som sådan er det jo ikke meget værre, end hvordan verden er i dag – her starter man jo også et vilkårligt sted. Derudover kan faste brugere stadigvæk vælge en fast startadresse, uanset hvor Findvej i øvrigt mener, man kommer fra.

Det er ikke sikkert, at funktionen forbliver – det må erfaringerne vise.

Derudover er der et par mindre opdateringerer: frisk data på Wikipedia-kortet, samt ruteplan-link for et opslag på en by eller en vej uden husnummer.

Garmin Forerunner 305Jeg har ikke været så gadget-fascineret, som man skulle tro. I et tidligere indlæg nævnte jeg min gamle, store mobiltelefon, som jeg næsten altid slæber rundt på, til trods for størrelsen, men ellers har jeg ikke nogen remedier, jeg ikke kan forlade hjemmet uden.

Både Garmin Forerunner og Nokias kommende serie af telefoner med GPS indbygget har dog fascineret mig. Ikke blot fordi enhederne har GPS, men fordi man kan eksportere ens positioner og indtegne ruterne på blandt andet Google Maps.
(mere…)

M.C. Escher: VandfaldKigger man på luftfotos eller satellitfotos over byer, oplever man ofte, at billederne ikke er skudt præcist oppefra.

Det er der ikke noget mærkeligt i; skulle en by være skudt “lige” oppefra, skulle billedet have været taget fra meget, meget lang afstand – og selv det ville ikke være godt nok, idet jorden er rund, hvilket betyder, at bygninger over et større areal, der alle peger op i luften, altså ikke peger i samme retning.

(mere…)

Håndklædet i ringen:

Jeg har længe haft planer om at støtte Findvej op ad de offentlige adresse-webservices for at kunne tjekke helt nye adresser, som ikke eksisterer i mit nuværende datagrundlag. Jeg er imidlertid hverken en haj til SOAP eller WSDL. Jeg ved også, at jeg vil bruge adskillige timer på at bokse med det, bare for at få en helt simpel webservice-forespørgsel til at makke ret.

Derfor er jeg interesseret i at høre kommentarer fra PHP-udviklere, der har et større indblik end mig. Sandsynligvis er der tale om et par enkelte linjers kode for et opslag. Formålet er i første omgang blot at få et resultat tilbage fra en forespørgsel på en adresse + postnummer.

Lidt PHP-kode at starte på:

$soapClient = new SoapClient(‘http://rep.oio.dk/Altforintet_dk/findaddressservice.wsdl’);
$functions = $soapClient->__getFunctions();
$types = $soapClient->__getTypes();

Der er flere informationer på teknik-siden under www.adresse-info.dk.

Det interessante er, at der ikke vil blive opkrævet betaling for brug af de offentlige services. Derfor er der intet i vejen for at få implementeret funktionen på Findvej med en passende caching-mekanisme.

De tilbyder dog ikke bulk-download, men man kan købe et samlet datasæt hos forskellige data-distributører. Dette er også på ønskelisten, men lige nu afventer jeg at ændringerne i forbindelse med kommunalreformen træder igennem.

SafariEn simpel funktion på Findvej har fået Safari til at crashe. Det er en fejl i Safari (ingen side burde kunne få en browser til at crashe). Funktionen, der viser nærmeste station, er nu deaktiveret for Safari-brugere. Jeg er gået i gang med at grave lidt nærmere i den.

Det er en spøjs bug: Jeg har et helt almindeligt array. Outputter jeg det, rummer det [object NodeList] , og arrayNavn.length på arrayet giver også en fin værdi. Men når jeg tilgår arrayNavn[0], crasher Safari helt og holdent:

Exception: EXC_BAD_ACCESS
Codes: KERN_PROTECTION_FAILURE

Det er ikke så hensigtsmæssigt, må man sige. Det betyder dog, at jeg endnu en gang bliver forsinket i udviklingen, fordi tiden skal gå med at lave workarounds, finde ud af, hvad der udløser browser-bugs, isolere de områder og efterfølgende skrive en bugrapport til browserproducenten og håbe at man bliver taget alvorligt. Ikke desto mindre går der nok rigtigt mange måneder, før buggen fundet og fikset i koden, og browseren er opdateret – og ikke mindst blevet så udbredt, at man tør antage, at de fleste Safari-brugere har valgt at opdatere.

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.