Document GeoReport v2 extensions in the wild

[philipashlock]

We've created a new page on the wiki at http://wiki.open311.org/GeoReport_v2/Extensions/ to document where the GeoReport v2 specification is being used in the wild with additional features, fields, parameters, or other customizations that extend the core v2 spec. This issue is simply being used to provide notes about documenting this before adding everything to the page on the wiki. It will also serve as an index to existing issues here on the issue tracker around specific extensions

I think the Extensions page should be organized similarly to the existing GeoReport_v2 page on the wiki around headings for the different GET/POST resources where they've been extended, plus headings for entirely new resources where they've been added. Under each of these headings there should be documentation for the feature in the same format as the main spec documentation and then a list of endpoints and/or providers that implement the extension.

There's already been some good discussion of many of these extension on the mailing list at http://lists.open311.org/groups/discuss/messages/topic/1dIPOwaKyRitCWJ6C6jIlW and here are a few to start off with:

Media Handling (see also #9)

• Bloomington supports a single media upload during POST service request. It's on the to-do list, though, to support multiple media uploads during a single POST service request. See Allow multiple media attachments in a a single POST City-of-Bloomington/uReport#21
• CitySDK issue reporting also shows an possible extension for appending multiple media via the mentioned POST multipart: http://dev.hel.fi/apis/issuereporting#Uploading%20media

Comments (see also #10)

• This has been discussed on the following thread: http://lists.open311.org/groups/discuss/messages/topic/2L05gDVaunVQpQzcqdLDpT
• Comment handling with Accela Open311 is documented at https://github.com/Accela-Inc/accela-open311#get-comments-for-a-service-request

Editing (see also #11)

• Here's mySociety's proposal
• their associated blog post
• and discussion on the mailing list

Others:

• See other parameters noted with the non-standard label provided by endpoints like the Connected Bits service in Chicago: http://dev.cityofchicago.org/docs/api/service_requests
• See other changes in the MySociety FMS customizations: https://github.com/mysociety/FixMyStreet/wiki/Open311-FMS---Proposed-differences-to-Open311

[Jaakko]

In Helsinki, a service request may contain reference to a service object. Service object is typically an item like public toilet and it is referenced by unique service_object_id and service_object_type.

For example a public toilet in city center is referenced (service_object_id=10844, service_object_type=http://www.hel.fi/servicemap/v2). Data for this service object is available from service map database by calling api http://www.hel.fi/palvelukarttaws/rest/v2/unit/10844.