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.
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.
Created by Chronicle v3.7