From: Petter Reinholdtsen Date: Fri, 29 Apr 2011 08:07:08 +0000 (+0000) Subject: Generated. X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/commitdiff_plain/98850b31662fbcc5c316c41a6d33a44b5cc1c427?ds=sidebyside Generated. --- diff --git a/blog/tags/open311/index.html b/blog/tags/open311/index.html new file mode 100644 index 0000000000..a52a1f94a0 --- /dev/null +++ b/blog/tags/open311/index.html @@ -0,0 +1,288 @@ + + + + Petter Reinholdtsen: Entries Tagged open311 + + + + + +
+

+ Petter Reinholdtsen + +

+ +
+ +

Entries tagged "open311".

+ + + + +
+
+ Initial notes on adding Open311 server API on FixMyStreet +
+
+ 2011-04-29 10:00 +
+ +
+ +

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.

+ +
+
+ + + + Tags: english, fiksgatami, open311. + +
+
+
+ +

RSS Feed

+ + + + + + + diff --git a/blog/tags/open311/open311.rss b/blog/tags/open311/open311.rss new file mode 100644 index 0000000000..ac1fcaa414 --- /dev/null +++ b/blog/tags/open311/open311.rss @@ -0,0 +1,92 @@ + + + + Petter Reinholdtsen - Entries tagged open311 + Entries tagged open311 + 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> + + + + +