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.
