I dag har det blitt bombet i regjeringskvartalet og skutt på AUFs sommerleir, og alt tyder på at desperate mennesker har vært på fære. Jeg håper de kriminelle som står bak blir funnet og straffet, og at dette blir gjort på et måte som gjør at demokrati, de mistenktes borgerrettigheter og samfunnets anstendighet blir ivaretatt. Jeg frykter dog at moralpanikk vil føre til at våre alles borgerrettigheter og det norske demokratiet blir skadelidende. Vi får se.
Arbeidet med et nettsted som viser frem hva hver enkelt av våre folkevalgte har stemt går sakte fremover. Det har gått to måneder siden jeg skrev om prosjektet. Siden sist har vi fått kontakt med organisasjonen Holder De Ord som holder på med et lignende prosjekt, samt fått tilgang til endel voteringsinformasjon fra Stortinget.
Har fått tilgang til to datasett fra Stortinget. Det ene er en CD med voteringsdetaljer mellom 1990 og 2009, det andre er tilgang til stortingets kommende data-API der en kan hente ut informasjon om representanter, saker og voteringer. Jeg har ikke rukket se nok på noen av dem til å laste dem inn i min prototype, men jeg håper begge datasettene kan brukes.
Det første datasettet er kopiert og publisert på NUUGs filtjener, og består av to filer pr. votering. En fil med tidspunkt og hver enkelt stemme, og en annen med hvem som stemte og hvilket parti og fylke de representerte. Tegnsettet er så vidt jeg kan se Codepage 865, og jeg håper det er enkelt å koble sammen person og stemme. Har ikke rukket forsøke dette ennå. Jeg tror en god strategi her er å parse råfilene fra Stortinget og sammenstille dem med databasen over representanter, og ved hjelp av denne koble de unike ID-ene til representantene med hver enkelt stemme og publisere resultatet i XML-format. Antar det er en par dagers programmering, men har ikke funnet tid til det.
Hvis du vil bidra, ta kontakt med meg på IRC (#nuug på irc.freenode.net) eller bli med på epostlisten aktive@nuug. Det trengs både manne-timer for skraping og finansiering av utviklingstimer for å en norsk portal på plass.
Reading the thingiverse blog, I came across two highlights of interesting parts of the Autodesk and Microsoft Kinect End User License Agreements (EULAs), which illustrates quite well why I stay away from software with EULAs. Whenever I take the time to read their content, the terms are simply unacceptable.
På torsdag lanserte kartverket en ny nett-tjeneste kalt Se Eiendom, der en får innsyn i det norske eiendomsregisteret (Matrikkelen) og kan slå opp grunnleggende informasjon om hver eiendom. En kan slå opp et koordinat og finne ut hvilken eiendom punktet befinner se på og så slå opp eiendommen i matrikkelen og finne ut nøkkelinformasjon om eiendommen.
Det slo meg at dette kan brukes til å gjenskape kommunegrenser, ved å slå opp punkter langs grenselinja og dermed bestemme hvor grenselinjen befinner seg. En kan bestemme den vilkårlig nøyaktig ved å gjøre et geometrisk søk.
Sniffet i kveld på trafikken til tjenesten, og det er i korte trekk tre relevante tjenestekall som returnerer JSON-data.
Først en som konverterer mellom koordinater, som i mitt eksempel konverterer fra UTM sone 33 til UTM sone 32:
% GET 'http://www.seeiendom.no/services/geoport.svc/GetTransformJsonp?nord=6648308.4755859&ost=248316.38085938&fromEpsg=EPSG:32633&toEpsg=EPSG:32632'
{"x":583905.90433579613,"y":6640700.79711847}
%
Koordinatene i UTM sone 32 kan så gis til tjenesten som slår opp eiendom basert på koordinat:
% echo | POST 'http://www.seeiendom.no/services/geoport.svc/PerformPropertySearchFromPolygonCoordinatesJsonp?polygonCoordinatesString=583905.9043357961,6640700.79711847'
{"error":"","wfsTeigInfo":{"TeigId":128010625,"Areal":"6128.7","GardsNr":"300","BruksNr":"2384","FesteNr":"0","SeksjonsNr":"0","MatrikkelNr":"300/2384","HovedTeig":true,"KommuneNavn":"Bærum","Adresses":null,"ArealMerknadsKoder":null,"UregistrertJordsameie":false,"AvklartEiere":false,"TeigMedFlereMatrikkelEnheter":false,"Tvist":false,"KommuneNr":"0219"}}
%
Etter dette kallet har en kommunenavn og kommunenummer, noe som er tilstrekkelig til å gjenskape kommunegrenser. Hvis en ønsker å vite detaljene om eiendommen kan en slå opp i selve matrikkelen, og få ut en HTML-side med informasjon:
% GET 'http://www.seeiendom.no/services/Matrikkel.svc/GetDetailPage?type=property&knr=0219&gnr=300&bnr=2384&fnr=0&snr=0&showpwm=false&customer=kartverket'
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Matrikkel informasjon</title>
[...]
Informasjon om hva en kan hente ut ved hjelp av Matrikkel.svc er dokumentert og tilgjengelig på en egen hjelpeside. Hvis en vil ha XML- eller JSON-formattert informasjon kan GetMatrikkelinfo-funksjonen brukes. Hvis en f.eks. bruker den slik får en masse informasjon om en eiendom:
% echo '{"knr": 1601, "gnr": 27, "bnr": 2, "fnr": 0, "snr": 0, "customer": "kartverket"}' | \
POST -c application/json http://www.seeiendom.no/services/Matrikkel.svc/GetMatrikkelinfo
[...]
%
Dette ser ut som en svært nyttig tjeneste som kan gjøre FiksGataMi mer treffsikker når den skal finne ut hvilken kommune og fylke som skal ha problemrapporter. Da eierinformasjon ikke er tilgjengelig, må vi i så fall bygge opp vår egen database over eiere av eiendommer knyttet til vei for å kunne skille på veinivå om kommune eller vegvesen skal ha beskjed. Har ikke funnet informasjon om hvilke bruksvilkår tjenesten har, så jeg er ennå ikke sikker på om dette er trygt å gjøre. Håper det blir klart etter hvert som tjenesten tar form.
Tillegg 2011-06-24: Har oppdaget at en også kan hente ut geografisk beskrivelse av eiendommen (dvs. et polygon som omkretser eiendommen), ved hjelp av følgende forespørsel.
% echo | POST 'http://www.seeiendom.no/services/geoport.svc/GetPropertyBorderJsonp?kommunenr=1663&gardsnr=4&bruksnr=182&festenr=0&seksjonsnr=0&gateAdresseId=&address=&showPopUp=true' [...] %
Da blir det straks veldig nyttig for å klassifisere eierskap på veier og andre offentlige områder. Det er dog en eller annen feil som gjør at oppslag på store eiendommer (som Nordmarka i Oslo og Finnmarksvidda) ikke fungerer. Vet ikke hva det kommer av.
Oppdaget ved en tilfeldighet via twitter at regjeringen i går annonserte at de planlegger å gjøre offentlighetsloven og innsynsretten mer tannløs. Forslaget ble vedtatt i går av regjeringen uten høring og de planlegger visst å oversende til stortinget uten å be om innspill fra berørte parter i forkant. Personlig ser jeg innsynsretten som en viktig rett som kan bidra til å holde maktpersoner i det offentlige under kontroll. Det er ingen privatsak å jobbe for folket, noe enhver som er ansatt i det offentlige eller valgt inn i posisjoner jo faktisk gjør, og det er viktig at enhver borger har mulighet til å se det offentlige i kortene.
Forslaget bør skytes ned og ethvert forsøk på å gjøre det vanskeligere for innbyggerne å holde et øye med hva som skjer i det offentlige bør skrinlegges.
To britiske tjenester som jeg har veldig stor sans for er TheyWorkForYou og Public Whip, som gir enkel og tilgjengelig oppdatering om hva som skjer i de britiske parlamentene. Jeg har lenge hatt lyst på noe slikt for det norske Stortinget, for å synliggjøre og ansvarliggjøre hver enkelt stortingsrepresentant. Voteringen over datalagringsdirektivet forsterket motivasjonen min tilstrekkelig til at jeg når har gått igang med å få dette på plass, og noen flere har meldt seg på. Utgangspunktet er å lage det som et NUUG-prosjekt på samme måte som med FiksGataMi.
TheyWorkForYou gir en tilgang til informasjon om hver enkelt representant, og lar en f.eks. abonnere via epost på alt en representant har sagt i stortinget. En kan også abonnere via epost på alle som har nevnt ord en er interessert i. Public Whip lar en ser hva enkeltrepresentanter har stemt i voteringer i parlamentene, lar en se hvordan representantene forholder seg til relaterte voteringer, og kan se hvem som er utbrytere og hvilke voteringer som er spesielt kontroversielle (mange utbrytere).
Hovedutfordringen nå er å få tilgang til nødvendig informasjon på strukturert og maskinlesbart format. Bak de to britiske tjenestene er skrapeprosjektet Parlament Parser, og det trengs en tilsvarende tjeneste for Stortinget som kan hente ut referater og informasjon om representanter og saker som er behandlet. På Stortingets nettsted mangler det informasjon om hvem som har stemt hva, så den informasjonen må en be eksplisitt om fra Stortinget. Jeg er i dialog med Stortingets informasjonsseksjon og håper de vil begynne å publisere denne informasjon på sikt. En annen kilde til relevant informasjon er PolSys-databasen til Norsk samfunnsvitenskapelig datatjeneste AS, men bruksvilkårene de har valgt på sine data umuliggjør at enhver kan bruke informasjonen om stortinget til hva som helst og det er et mål for meg at alle skal kunne gjøre hva som helst med datasettene når jeg lager tjenesten.
Første demonstrasjon av konseptet er nå tilgjengelig med de voteringsdata jeg har fått tak i så langt. Jeg regner med å kaste den koden når mer data er på plass, og heller basere tjenesten på lignende prosjekter som de to forannevnte, eller den polske Sejmometr.
Hvis du vil bidra, ta kontakt med meg på IRC (#nuug på irc.freenode.net) eller bli med på epostlisten aktive@nuug. Det trengs både manne-timer for skraping og finansiering av utviklingstimer for å tilpasse eksisterende portal til norsk.
Artikkelen i Aftenposten i dag om de som fikk tauet bort bilen etter å ha trodd på Oslo kommunes oversikt over når ulike gater skulle feies i påsken, fikk meg til å ta en titt på kommunens oversikt, og der ble jeg fascinert over følgende lille gullkorn:
Hvorfor har dere ikke SMS-varsling?
Forsøksordningen i 2005 viste dessverre at SMS-varsling i liten grad reduserte antallet borttauede biler. De som abonnerte på ordningen unngikk naturligvis feilparkeringer, men plassene ble brukt av "fremmede" biler altså av bileiere som ikke abonnerte og dermed ikke ble varslet.
Det gir inntrykk av at kommunen i stedet for å se på SMS-varsling som en tjeneste for innbyggerne, som kunne gjøre at de innbyggerne som benyttet seg av tjenesten slapp å få tauet bilen sin, så på det som en tjeneste for seg selv for å redusere antall tauinger. Forklaringen synes jeg illustrerer veldig godt hvorfor det er så viktig å se på hva som er fokus for tjenester som leveres og hva som er suksesskriteriene. Jeg mistenker at hvis suksesskriteriet for SMS-tjenesten hadde vært hvor fornøyd brukerne av SMS-tjenesten var, så ville den blitt videreført. Eller hvis suksesskriteriet var økt bruk av tjenesten. Jeg vet i hvert fall mange som gjerne vil slippe å både daglig besøke bilen sin der den er parkert i Oslo, og som gjerne vil varsles i stedet for å oppdage at bilen er tauet bort når de trenger den.
Mon tro hvor mange som må bruke en slik tjeneste før andelen bort-tauinger blir redusert? Jeg mistenker den må være godt over 50% av alle med bil i Oslo, før det er større sannsynlighet for at en ledig men risikofylt parkeringsplass blir stående ledig enn at den blir tatt umiddelbart. Det er for stort press på parkeringsplasser i Oslo i dag til å tro at en ledig parkeringsplass blir stående ubrukt med mindre sjåføren vet at det er risikabelt å stå der. Hvis reduksjon i antall bort-tauinger var suksesskriteriet for SMS-tjenesten var en dermed garantert å konkludere med at den feilet, da det er umulig å få så stor bruksprosent i en prøvedrift.
Fokus for FiksGataMi er innbyggeren, og et av suksesskriteriene er at innbyggerne som bruker tjenesten er fornøyde med at rapportene blir synliggjort og levert til relevant offentlig myndighet. Det er naturligvis fint om de som mottar meldingene også har nytte av tjenesten, og at problemene blir fikset, men det viktigste er innbyggernes opplevelse. Innbyggerne skal oppleve tjenesten som enkel og effektiv, slik at vi sikrer at flest mulig klarer å bidra til å forbedre offentlig infrastruktur.
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.
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.
Created by Chronicle v3.7