Revision to Services: Open311 Discuss: Open311 Lists

I work for a local authority in the UK and we've had a partial Open311 Service
(Services and Service Request) for a few years.

I think that Services would benefit from an optional "service_parent" field, so
that a hierarchy could be created. Items at the top level could be set at "0"
and then items underneath would use the service_code of their parent.

This would enable a hierarchy to be created rather than one flat list, which
can be hard to use if integrated into a front-end and there are many entries in
it.

I'm keen to get others' views on this and to ask, if there's consensus that
this would be an improvement, how do we add this to the spec.

I'm supportive of the concept. I'm not certain of the best technical
implementation though your approach seems reasonable.

Rest of post

That's great, thanks.

Does anyone else have a view on this?

How would we get this additional, optional field added?

Hi Phil,

The Open311 GeoReport v2 spec defines a specific "group" field for this
purpose:
http://wiki.open311.org/GeoReport_v2/#get-service-list

For a live example, check out the Austin endpoint, powered by Connected Bits:
http://311.austintexas.gov/open311/v2/services.json

{
"service_code": "53601cb9844eedb1460001f0",
"service_name": "Street Sweeping",
"description": "Use this service request to report debris/litter on the street
or bike lane that needs to be removed.",
"metadata": true,
"type": "batch",
"group": "Streets & Signs"
}

You can see the API grouping in action on their web form here:
http://311.austintexas.gov/reports/list_services

-Zack

Zack Beatty
SeeClickFix
<email obscured>

Phil,
Zack is correct - we're supporting the "group" field to categorize Services
into issues related to public transportation and issues not related to public
transportation for the OneBusAway open-source transit app
(http://onebusaway.org/) - see this screenshot for how it looks in our Android
app:
https://cloud.githubusercontent.com/assets/928045/20411445/7d7a441c-acef-11e6-9dd9-bf6941345917.png

I agree that this is limiting, though - it only gives you one level of
grouping, and doesn't allow parent/child relationships between services. In
large multi-agency deployments that target different types of government
services having a better hierarchy would definitely improve the UI
presentation of services.

Maybe a "group_parent" is a better way to approach this, given that "group" is
already used for a related purpose?

Sean

Revision to Services

Already a member?

Not a member?