The last few days I have spent some time trying to add support for
+the
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.
+