Helsinki is committed to open data and serving developers. Helsinki Region Infoshare provides data, APIs, and feedback forums. The city is piloting an Open311 API to enable citizens to submit service requests and feedback using multiple channels. Developers are asked to provide feedback on features like media upload support, location parameters, and push notifications to improve citizen participation.

1. City Service Development Kit Helsinki
Smart
City
City as a platform
Open interfaces
Open data
Whatever makes developer life easier

2. My background: HelMet bookscanner
• Downloaded HelMet library catalog of 600000
titles (193MB)
• Library locations from Helsinki Service Map
Now API for data, library locations, even
opening hours
HelMet bookscanner

3. Catalog: Helsinki Region Infoshare
www.hri.fi
https://www.facebook.com/helsinkiregioninfoshare

4. Example: Helsinki metropolitan area
service map REST API

5. Helsinki metropolitan area service
map REST API
• 8600 Units / Locations
• 1130 service categories
• 226000 REST requests in
May 2012
http://www.hel.fi/palvelukarttaws/rest/ver2_en.html
http://www.hel.fi/palvelukartta/Default.aspx?language=en&city=91

6. Public transport: ReittiGPS
https://sites.google.com/site/reittigps/

7. HSL developer pages
http://developer.reittiopas.fi/pages/en/home.php

8. Public transport: Mapnificent

9. ParkkiNappi / ParkMan

10. Parking payment machines
Created: Antti Ahola
http://www.arcgis.com/home/item.html?id=368c48e20bb6498d8455f356aaa0fc74

11. Traffic accidents
Suomenkuvalehti: Lauri Vanhala
http://www.hri.fi/fi/sovellukset/helsingin-liikenneonnettomuudet-kartalla/

12. Population density
http://www.hsy.fi/seututieto/kaupunki/paikkatiedot/Sivut/Avoindata.aspx

13. Ihana Helsinki!
Ihana Helsinki!

14. Summary
• Helsinki very committed on openness and
developers
• If you are looking for data, APIs and feedback
=> Go to Helsinki Region Infoshare www.hri.fi
• Tell us how we can serve you better?
– Contact: jaakko.rajaniemi@hel.fi
• Other info from Facebook:
– Helsinki Region Infoshare
https://www.facebook.com/helsinkiregioninfoshare
– CitySDK Helsinki https://www.facebook.com/CitySDKHelsinki
– Finnish Open Data Ecosystem
https://www.facebook.com/groups/fi.okfn/
– AppsFinland https://www.facebook.com/Apps4Finland

15. CitySDK - Helsinki

16. Smart Participation – Lead Pilot in Helsinki
Piloted in the
CitySDK project. Interfaces and processes developed during the
project.
FVH coordinates
Oma kaupunki Palauteydin, ASPA feedback
service feedback core handling system
Sanoma Oyj Helsinki, Titek Helsinki, HKR
Citizen
www.hel.fi Technology, City
software Department B
platforms
Fillarikanava
Processes City
Department C
Facebook
Best practises
Media XY City
Department D

17. Smart Participation – CitySDK Helsinki

18. FixMyStreet - UK

19. Citizens Connect - Boston

20. Street Bump - Boston

21. Public works department
annual feedback
Calls 63920
Offered calls 86038
Answered calls 63920
Customer visits 22 980
Emails 25412
Together 112 312

22. Motivation for Open311
• It is the only standard in this area.
• It is used in several cities in USA.
• It has quite an active community behind.
⇒It’s good enough and has potential to become
globally used standard.
http://www.open311.org/

23. Supported use cases
• Use case 1: Submitting a service request
• Use case 2: Quering individual service request
• Use case 3: Quering service requests
• Use case 4: Listing service request types
• Use case 5: Mobility of user

24. Use case 1: Submitting a service request
• Service request can be submitted with following info:
– Description and title
– Location (not obligatory)
• lat/long (WGS-84), address, City specific data identiying service request object , e.g.
Helsinki Service Map
– Service request type
– Contact information
• Name, e-mail address, phonenumber, Account_id
– Device_id
– Media attachment
• Photo and possibly other document formats
– Web link to external service where service request originates (e.g. Omakaupunki)
– PROPOSED: Priority of the service request, Geometry (e.g. lines, polygons)
• Response includes
– Service request id
– Web link to city’s own web page where service request is published
– PROPOSED: related_service_request_id
Parameters we want but not in Open311 spec.
Parameters proposed but our support still open.

25. Use case 2: Quering individual service
request
• Individual service request can be queried using service
request identification ID. Response includes:
– Description and title
– Location
• lat/long (WGS-84), address, City specific data identiying service request object , e.g.
Helsinki Service Map
– State (open, closed)
• PROPOSED: Option to have more status values
– Response text
– Submission date and time
– Update date and time
– Expected date and time when fixed
– Government agency responsible for the service request
• PROPOSED: Option to have multiple agencies
– Service request type
– URL address of attachment
– PROPOSED: Priority of the service request, Geometry (e.g. lines, polygons)
Parameters we want but not in Open311 spec.
Parameters proposed but our support still open.

26. Use case 3: Quering service requests
• Service requests can be queried
– Submission date and time (start and endtime)
– Location (bounding box and/or lat/long+radius)
– Status (all, closed or open)
– Service request type(s)
– Service request id(s)
• Response includes:
– Description and title
– Location
• lat/long (WGS-84), address, City specific data identiying service request object , e.g.
Helsinki Service Map
– State (open, closed)
• PROPOSED: Option to have more status values
– Response text
– Submission date and time
– Update date and time
– Expected date and time when fixed
– Government agency responsible for the service request
• PROPOSED: Option to have multiple agencies
– Service request type
– URL address of attachments
– PROPOSED: Priority of the service request, Geometry (e.g. lines, polygons)
Parameters we want but not in Open311 spec.
Parameters proposed but our support still open.

27. Use case 4: Listing service request types
• Clients can query list of service request types which are supported by the
city.
– Name of service request type
– Description of service request type
– Group of service request type

28. Use case 5: Mobility of service user
• Users may move between cities (Helsinki, Espoo or Barcelona)
and use application to submit service requests.
• Service requests are routed to the correct city endpoint
without the help of the user.
– No solution yet.
– We try to have solution which is compliant with Open311 standard
– Solution may no have any impact on service request interface

29. Use cases under consideration
• Commenting on service requests
• Editing and removing service requests
• Account handling for users
• Voting for service requests

30. We need your help
• We need your help to make citizen
participation
– easier
– better and more accurate
– activate and excite more citizens
– FUN!

31. We need developer feedback (1/2)
• Media upload
– Support for photos and what else?
– Synchronous Multipart/Form upload
• Types and groups of service requests
– Different types like potholes, traffic signs, trash bins, parks, roads, parking, …
– How to decide types and groups in the best way?
• Status values for service requests
– Open, closed
– New values needed?
• New location parameters
– How to use Service Map unit ids as location parameter?
– service_request_object_type=http://www.hel.fi/palvelukarttaws/rest/ver2.html
– service_request_object_id=12345
– Any use for more complex geomerty like lines and polygons?

32. We need developer feedback (2/2)
• Mobility between cities
– How to detect where the user is and where to send service request?
– Helsinki vs. Espoo vs. Vantaa
• Accurate address parameter
– Manually typed addresses are not accurate
– Lat,lon mapped to accurate address or some other mean to verify the address
• Push notifications on changes
– Currently only pull model supported, enough?
– Pull vs. Push model and how to do push notifications (e.g. Pubsubhubbub)
• How to use user identification parameters?
– Current plan is not to have user accounts on city’s service
– How to use device_id and author_id parameters?

33. Developer testing and usage
• Test interface comes available later this year
– Enable debugging sent data and responses
• API key will be required for posting service
requests
– Some sort of validation needed for API key
– This will be available next year
• Anyone interested to join effort to setup open
source Open311 server for testing?

34. Next steps
• We want to build community around CitySDK
topics => Join us on Facebook, events and
elsewhere!
• The interface specification frozen in June =>
Please give feedback before.
• CitySDK schedule
– Sanoma pilot beta ready in the end of this year
– Test interface ready Q4

35. Contact info
• Jaakko.Rajaniemi@hel.fi ja
Hanna.Niemi-Hugaerts@forumvirium.fi
• Puh: +358 40 516 5931
• Twitter: @jaakko
• Facebook:
https://www.facebook.com/CitySDKHelsinki