X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/270b5d6b94f8bda3445affd4a7b19036f7a7462a..28a38686d60047dad1001fafdbe167b3d9df3389:/blog/index.rss diff --git a/blog/index.rss b/blog/index.rss index 0695cb1571..249c1b70ee 100644 --- a/blog/index.rss +++ b/blog/index.rss @@ -6,6 +6,88 @@ http://people.skolelinux.org/pere/blog/ + + Initial notes on adding Open311 server API on FixMyStreet + http://people.skolelinux.org/pere/blog/Initial_notes_on_adding_Open311_server_API_on_FixMyStreet.html + http://people.skolelinux.org/pere/blog/Initial_notes_on_adding_Open311_server_API_on_FixMyStreet.html + Fri, 29 Apr 2011 10:00:00 +0200 + +<p>The last few days I have spent some time trying to add support for +the <ahref="http://www.open311.org/">Open311 API</a> in the +<a href="http://www.fiksgatami.no/">Norwegian FixMyStreet service</a>. +Earlier I believed Open311 would be a useful API to use to submit +reports to the municipalities, but when I noticed that the +<a href="http://fixmystreet.org.nz/">New Zealand version</a> 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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>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 +<a href="http://seeclickfix.com/open311/">SeeClickFix</a> 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.</p> + +<p>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 <a href="http://www.gmane.org/">Gmane</a> to use for +discussions instead of only +<a href="http://lists.open311.org/groups/discuss">a forum<a/>. 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.</p> + + + FiksGataMi - fylkesoversikt på kart http://people.skolelinux.org/pere/blog/FiksGataMi___fylkesoversikt_p___kart.html @@ -622,50 +704,5 @@ gjenbruk av offentlige data.</p> - - 1000 problemer rapportert via FiksGataMi på litt over to dager - http://people.skolelinux.org/pere/blog/1000_problemer_rapportert_via_FiksGataMi_p___litt_over_to_dager.html - http://people.skolelinux.org/pere/blog/1000_problemer_rapportert_via_FiksGataMi_p___litt_over_to_dager.html - Wed, 9 Mar 2011 23:45:00 +0100 - -<p>Etter mandagens lansering av -<a href="http://www.fiksgatami.no/">FiksGataMi</a> har responsen vært -enorm, og de første 1000 problemene er allerede rapportert. Noen -saker er allerede løst, og responstiden til -<a href="http://www.fiksgatami.no/report/490">Bø i Nordland</a> og -<a href="http://www.fiksgatami.no/report/550">Melhus</a> imponerer -stort. Slikt burde gjøre innbyggerne der stolte. :)</p> - -<p>En utfordring for FiksGataMi er håndtering av fylkes- og riksveier -som ikke skal til kommunen men til fylket eller staten. Problemet er -at vi mangler en datakilde som kan brukes til å identifisere hvilket -geografisk område som administreres av fylket og staten (dvs. vei, -grøfter, gjerder og slikt). Det vi trenger er maskinlesbare -georefererte eiendomsgrenser over eiendommene som hører til fylkes- og -riksveier. Når vi har det, kan vi videreutvikle fiksgatami til å -håndtere eiendomsgrenser i tillegg til dagens kommune- og -fylkesgrenser. Så vi trenger datakilder uten bruksbegrensninger og -litt finansiering for å ta dem i bruk.</p> - -<p>Men noen kommuner håndterer denne utfordringen elegant likevel og -til det beste for innsender ved å sende saken videre til riktig -instans og notere dette i FiksGataMi. De første som gjorde dette var -så vidt jeg kan se -<a href=http://www.fiksgatami.no/report/385">Lørenskog</a>. All kudos -til dem!</p> - -<p>I morgen tidlig skal Christer på NRK Østlandssendingen og snakke om -FiksGataMi. Jeg gleder meg til å høre opptaket og se hvilken respons -det fører til på innrapporteringen. Jeg forsøker å holde -<a href="http://www.nuug.no/imedia.shtml">oversikt over omtalen</a> -NUUG og FiksGataMi på NUUGs websider, og responsen så langt har vært -veldig god. De fleste kommunene er veldig positive til tjenesten. De -som hadde lignende løsninger er ikke så fornøyde, noe jeg kan forstå. -På den positive siden får innbyggerne i disse kommunene nå et valg om -hvilken løsning de vil benytte seg av, og konkurranse er en fin ting -for å dyrke frem de beste løsningene. :)</p> - - -