[NUUG fiksgatami] FixMyStreet integration & v2 spec questions

Philip Ashlock phil at openplans.org
Tue May 3 05:06:54 CEST 2011


I'm still traveling without a regular internet connection, but will be
back in NYC on Wednesday and hope to go through a lot of follow-up on
the state of the v2 spec implementations and open questions. For now,
I wanted to copy some feedback from Petter Reinholdtsen who brought up
some questions he encountered while trying to implement the spec for
FixMyStreet. I'll go through a full response on the issues he raised
in the next few days as I have more time, but for now I mostly wanted
to copy his feedback on to the list.

A few quick notes for now.

Expected language:
Could the preferred language supported by the endpoint just be denoted
by the accept-language http header response of the services list? From
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

"Each language-range MAY be given an associated quality value which
represents an estimate of the user's preference for the languages
specified by that range. The quality value defaults to "q=1". For
example,

       Accept-Language: da, en-gb;q=0.8, en;q=0.7

would mean: "I prefer Danish, but will accept British English and
other types of English." A language-range matches a language-tag if it
exactly equals the tag, or if it exactly equals a prefix of the tag
such that the first tag character following the prefix is "-". The
special range "*", if present in the Accept-Language field, matches
every tag not matched by any other range present in the
Accept-Language field."

Would this approach be inconsistent with they way we're using service
discovery? Would it be better to try to rely on the service discovery
method more exclusively than http headers like this? As far as
standards and RESTful approaches go, accept headers are clearly
established, but i'm not sure if that translates to use in practice
and developers' preference.

---

Multiple Administrations:
The ability to distinguish multiple administrations with one API
endpoint is something that the jurisdiction_id is meant toi be able to
denote. I think the SeeClickFix endpoints are using lat/long for now
on specifying service requests, but I'm not sure that was something
we'd actually included in the spec (not yet at least).

Below are the posts from Petter:
----------------

http://people.skolelinux.org/pere/blog/Experimental_Open311_API_for_the_mySociety_fixmystreet_system.html

Experimental Open311 API for the mySociety fixmystreet system
2011-04-30 17:20
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.

------------------


http://people.skolelinux.org/pere/blog/Initial_notes_on_adding_Open311_server_API_on_FixMyStreet.html

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.

-- 

-- 
Philip Ashlock
Open Government Program Manager | *OpenPlans.org*<http://www.openplans.org/>|
*@philipashlock* <http://www.twitter.com/philipashlock>


More information about the fiksgatami mailing list