Petter Reinholdtsen

Today, the first draft implementation of an Open311 API for the Norwegian service FiksGataMi started to work. It is only available on the developer server for now, and I have not tested it using any existing Open311 client (I lack the platforms needed to run the clients I have found so far), but it is able to query the database and extract a list of open and closed requests within a given category and reported to a given municipality. I believe that is a good start to create a useful service for those that want to do data mining on the requests submitted so far.

Where is it? Visit http://fiksgatami-dev.nuug.no/open311.cgi/v2/ to have a look. Please send feedback to the fiksgatami (at) nuug.no mailing list.

The last few days I have spent some time trying to add support for the Open311 API in the Norwegian FixMyStreet service. Earlier I believed Open311 would be a useful API to use to submit reports to the municipalities, but when I noticed that the New Zealand version of FixMyStreet had implemented Open311 on the server side, it occurred to me that this was a nice way to allow the public, press and municipalities to do data mining directly in the FixMyStreet service. Thus I went to work implementing the Open311 specification for FixMyStreet. The implementation is not yet ready, but I am starting to get a draft limping along. In the process, I have discovered a few issues with the Open311 specification.

One obvious missing feature is the lack of natural language handling in the specification. The specification seem to assume all reports will be written in English, and do not provide a way for the receiving end to specify which languages are understood there. To be able to use the same client and submit to several Open311 receivers, it would be useful to know which language to use when writing reports. I believe the specification should be extended to allow the receivers of problem reports to specify which language they accept, and the submitter to specify which language the report is written in. Language of a text can also be automatically guessed using statistical methods, but for multi-lingual persons like myself, it is useful to know which language to use when writing a problem report. I suspect some lang=nb,nn kind of attribute would solve it.

A key part of the Open311 API is the list of services provided, which is similar to the categories used by FixMyStreet. One issue I run into is the need to specify both name and unique identifier for each category. The specification do not state that the identifier should be numeric, but all example implementations have used numbers here. In FixMyStreet, there is no number associated with each category. As the specification do not forbid it, I will use the name as the unique identifier for now and see how open311 clients handle it.

The report format in open311 and the report format in FixMyStreet differ in a key part. FixMyStreet have a title and a description, while Open311 only have a description and lack the title. I'm not quite sure how to best handle this yet. When asking for a FixMyStreet report in Open311 format, I just merge title an description into the open311 description, but this is not going to work if the open311 API should be used for submitting new reports to FixMyStreet.

The search feature in Open311 is missing a way to ask for problems near a geographic location. I believe this is important if one is to use Open311 as the query language for mobile units. The specification should be extended to handle this, probably using some new lat=, lon= and range= options.

The final challenge I see is that the FixMyStreet code handle several administrations in one interface, while the Open311 API seem to assume only one administration. For FixMyStreet, this mean a report can be sent to several administrations, and the categories available depend on the location of the problem. Not quite sure how to best handle this. I've noticed SeeClickFix added latitude and longitude options to the services request, but it do not solve the problem of what to return when no location is specified. Will have to investigate this a bit more.

My distaste for web forums have kept me from bringing these issues up with the open311 developer group. I really wish they had a email list available via Gmane to use for discussions instead of only a forum. Oh, well. That will probably resolve itself, one way or another. I've also tried visiting the IRC channel #open311 on FreeNode, but no-one seem to reply to my questions there. This make me wonder if I just fail to understand how the open311 community work. It sure do not work like the free software project communities I am used to.

Det er morsomt å følge med hvordan bruken av FiksGataMi sprer seg over det ganske land. Her er lenkene til fylkesoversikt på kart over de (for tiden) 200 siste problemene. Bruker her GeoRSS-kilden i FiksGataMi og presenterer enten via Google Maps eller en GeoRSS-fremviser jeg fant for OpenStreetmap.

• Østfold [ Google Maps ] | [ OpenStreetmap ]
• Akershus [ Google Maps ] | [ OpenStreetmap ]
• Oslo [ Google Maps ] | [ OpenStreetmap ]
• Hedmark [ Google Maps ] | [ OpenStreetmap ]
• Oppland [ Google Maps ] | [ OpenStreetmap ]
• Buskerud [ Google Maps ] | [ OpenStreetmap ]
• Vestfold [ Google Maps ] | [ OpenStreetmap ]
• Telemark [ Google Maps ] | [ OpenStreetmap ]
• Aust-Agder [ Google Maps ] | [ OpenStreetmap ]
• Vest-Agder [ Google Maps ] | [ OpenStreetmap ]
• Rogaland [ Google Maps ] | [ OpenStreetmap ]
• Hordaland [ Google Maps ] | [ OpenStreetmap ]
• Sogn og Fjordane [ Google Maps ] | [ OpenStreetmap ]
• Møre og Romsdal [ Google Maps ] | [ OpenStreetmap ]
• Sør-Trøndelag [ Google Maps ] | [ OpenStreetmap ]
• Nord-Trøndelag [ Google Maps ] | [ OpenStreetmap ]
• Nordland [ Google Maps ] | [ OpenStreetmap ]
• Troms [ Google Maps ] | [ OpenStreetmap ]
• Finnmark [ Google Maps ] | [ OpenStreetmap ]

Antall problemer returnert i GeoRSS-kildene justeres over tid etter hvert som vi får mer erfaring med hvilken belastning det gir på tjenesten.

Oppdatering 2011-04-27: Endret URL til fylker med mellomrom i navnene fra %20 til %2B, slik at de fungerer i flere nettlesere.

Neste mann ut er Marius Kotsbak, styremedlem i FRISK og mangeårig bidragsyter i Skolelinux-prosjektet.

Hvem er du, og hva driver du med til daglig?

Jeg er en systemutvikler/kybernetiker og jobber med dette til daglig. På fritiden tester jeg ut/bruker mye fri programvare, og bidrar med testing og utvikling når jeg ser stort nok behov for det og jeg har noe å bidra med.

Hvordan kom du i kontakt med Skolelinux-prosjektet?

Hmm, det er lenge siden, så det er nesten så jeg ikke husker. Jeg hadde vel hørt om prosjektet i media før en gjeng i Trondheim startet opp SPIST, Skolelinux-prosjektet i Sør-Trøndelag, hvor vi hjalp noen skoler i nærområdet med å installere Skolelinux og finne brukt IT-utstyr til disse. Det var moro å gjøre noe praktisk for å spre Skolelinux, og å se hvor fort gjort det var å sette opp utrangerte klientmaskiner og få disse opp som tynnklienter på helt nye datasaler på skolene, kun med kostnaden til servere.

Hva er fordelene med Skolelinux slik du ser det?

Det er et system spesielt skreddersydd for drift av et stort antall klienter mot servere, og da spesielt i henhold til skolers behov. Det er enkelt og billig å installere og drifte, og det trenger ikke ny maskinvare for god ytelse.

Hva er ulempene med Skolelinux slik du ser det?

Hardwarestøtten kunne vært bedre og i enda større grad installerbart rett ut av boksen. Distribusjonen har til tider hatt litt gammel programvare pga. at den følger Debian sine utgivelser. Kanskje man skulle vurdert en versjon basert på Ubuntu eller andre distribusjoner i tillegg?

Hvilken fri programvare bruker du til daglig?

Oi, det er ikke lite. Her er det jeg kommer på i farta. Jeg bruker Linux og Ubuntu, og på Ubuntu programene Firefox, Thunderbird, Chromium, Pidgin, Digikam, OpenOffice, Wireshark, git og irssi. Telefonen min er en Android, og der bruker jeg programmene K-9 Mail, OI Shopping list, Shuffle, ZXing, OI Notepad og ADW Desktop. På jobb bruker jeg JBoss, Eclipse, uCLinux for Blackfin, RCF-CPP, Qt, Maven, og boost-bibliotekene for C++.

Hvilken strategi tror du er den rette å bruke for å få skoler til å ta i bruk fri programvare?

En bør fokusere på totalkostnader inkludert driftsbehov, fleksibilitet, åpenhet og ikke låsing til en leverandør framfor sparte lisenskostnader, samt programvarens kvalitet og fortrinn, og at den fritt kan brukes på et ubegrenset antall PC-er, også hjemme hos elevene. En bør også forbedre den fri programvaren ved testing, bugrapportering og kodebidrag om man kan, og ikke anbefale programvare uten at man har forsikret seg at den har tilstrekkelig kvalitet, ellers kan man lett oppnå det motsatte. Tror en bør selge inn konseptet til fylkes-/statsnivå, kanskje med bidrag til utviklingsarbeid fra disse som alle landets skoler kan få glede av.

The Gnash project is still the most promising solution for a Free Software Flash implementation. A few days ago the project announced that it will participate in Google Summer of Code. I hope many students apply, and that some of them succeed in getting AVM2 support into Gnash.

I dag ligger an til å bli en trist dag for Norge. I dag skal etter planen Stortinget stemme over om det skal innføres elektronisk brev- og besøkskontroll for hele folket, og Arbeiderpartiet og Høyre utgjør et flertall som har annonsert at de er enige om at dette skal gjøres. Konsekvensene for journaliststikken, organisasjonslivet, samfunnsikkerheten, personvernet og demokratiet er alvorlige, og jeg er bekymret hvor vi går etter dette.

Både Høyre og Arbeiderpartiet forsøker seg på nytale og forklarer gang på gang å få folk til å tro at dette styrker personvernet, selv etter at datatilsynet som faginstans på området slo fast i januar at innføring av datalagringsdirektivet vil svekke personvernet.

Hva innebærer datalagringsdirektivet i praksis? Jeg kopierer likegodt en tekst fra Martin Bekkelund i sin helhet:

Fordi teknologien er usynlig, abstrakt, komplisert og utformet av mennesker, er det få som reflekterer over at teknologi kan være noe negativt, til tross for at intensjonene kanskje er gode.

Det er mandag morgen, og du skal på jobb. Idet du kommer ut døra treffer du en velkledd mann i sort dress, hvit skjorte og et tynt, sort slips. Du ser på ham og han ser på deg gjennom et par store, mørke solbriller. I den venstre hånden holder han en notisblokk, i den høyre en penn. Han noterer noe på notisblokken og stikker den i lommen.

Når du går nedover veien legger du merke til at mannen følger etter deg, mens han stadig noterer på notisblokken.

Etter en stund har du fått nok og bestemmer deg for å konfrontere mannen med hans oppførsel. Hvorfor følger han etter deg? Og hva er det han noterer i notisblokken sin? Mannen gir deg et ignorant tusenmetersblikk gjennom de mørke solbrillene. Han svarer ikke.

Det du ikke vet er at mannen er fra politiet, og er et ledd i myndighetenes nye satsing for å forhindre terror og alvorlig kriminalitet. De skal overvåke alle mennesker, uansett om de har gjort noe galt eller ei, for å sikre seg beviser i tilfelle du skulle gjøre noe galt.

For oss som bor i et fritt samfunn hvor rettssikkerheten står sterkt høres dette helt usannsynlig ut. Vi ville aldri akseptert menn som følger etter og overvåker oss.

Problemet er at mannen allerede eksisterer. Men det er en liten forskjell på mannen beskrevet i denne historien og mannen som allerede eksisterer. Han er usynlig, og finnes foreløpig kun i EU. Mannen som overvåker oss er ikke en mann av kjøtt og blod, men en usynlig robot som samler inn informasjon om hvordan vi bruker våre elektroniske hjelpemidler. Hver gang du ringer noen er han der og noterer seg hvem du ringer, når du ringer og hvor du befinner deg når samtalen tas. Det samme når du sender SMS, e-post eller bruker internett. Og med en smarttelefon i lomma blir vi gjenstand for kontinuerlig overvåking.

Menn i mørke dresser og solbriller som overvåker oss i gatene er selvfølgelig uakseptabelt. Hvorfor skulle det være mer akseptabelt med samme overvåking bare fordi mannen er usynlig? Det er derfor du skal si nei til Datalagringsdirektivet som Arbeiderpartiet ønsker å innføre i disse dager.

Det har kommet noen nye innspill i debatten de siste dagene. Her er noen aktuelle lenker, både nye og gamle:

• - DLD kan utvides i det stille - artikkel på digi.no der jusprofessor Dag Wiese Schartum forteller at lovforslaget for å innføre datalagringsdirektivet baserer seg på illusjoner og at formuleringen om at det kan utvides med endring i forskrift og ved enkeltvedtak gjør at omfanget av overvåkning kan gjøres i det stille uten offentlige debatt.
• Stopper DLD i Tsjekkia - artikkel på digi.no som forteller at Grunnlovsdomstolen i Tsjekkia har avvist EUs kontroversielle datalagringsarkiv.
• Slik er seks måneders DLD-data i praksis - artikkel på digi.no som forteller om en tysk politiker som har fått visualisert på kart med kommentarer hva slags informasjonen som vil bli samlet inn hvis datalagringsdirektivet innføres i Norge.
• Om å la politimyndigheter avgjøre rettsstatens grenser – ny forskning - bloggpost fra Jon Wessel-Aas om hva som ligger bak forslag som datalagringsdirektivet.
• Styrke personvernet - bloggpost hos Martin Bekkelund som i korte trekk forklarer hvorfor datalagringsdirektivet ikke bedrer personvernet.
• PST argumenterer selv best mot datalagringsdirektivet - bloggpost fra Jon Wessel-Aas om hvordan PST motsier seg selv når de hevder det er en god ide å innføre datalagringdirektivet.
• - Feil at piratjakt er DLD-motiv - artikkel på digi.no der Høyre som svar på observasjon fra Jon Wessel-Aas om at DLD vil bli brukt til å ramme varslere og brudd på opphavsretten er at det ikke er motivasjonen. Motivasjonen til Høyre er her irrelevant når det jo snakkes om konsekvensen.

Here is a small update for my English readers. Most of my blog posts have been in Norwegian the last few weeks, so here is a short update in English.

The kids still keep me too busy to get much free software work done, but I did manage to organise a project to get a Norwegian port of the British service FixMyStreet up and running, and it has been running for a month now. The entire project has been organised by me and two others. Around Christmas we gathered sponsors to fund the development work. In January I drafted a contract with mySociety on what to develop, and in February the development took place. Most of it involved converting the source to use GPS coordinates instead of British easting/northing, and the resulting code should be a lot easier to get running in any country by now. The Norwegian FiksGataMi is using OpenStreetmap as the map source and the source for administrative borders in Norway, and support for this had to be added/fixed.

The Norwegian version went live March 3th, and we spent the weekend polishing the system before we announced it March 7th. The system is running on a KVM instance of Debian/Squeeze, and has seen almost 3000 problem reports in a few weeks. Soon we hope to announce the Android and iPhone versions making it even easier to report problems with the public infrastructure.

Perhaps something to consider for those of you in countries without such service?