Helsingin kaupungin kehittäjätapaaminen CitySDK

517 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
517
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Helsingin kaupungin kehittäjätapaaminen CitySDK

  1. 1. City Service Development Kit Smart Open interfaces Open data City City as a platform “Write app for Helsinki, run it in Amsterdam” Whatever makes developer life easier
  2. 2. CitySDKTransfer of Smart City applications from one city to another is challenging due to lackof: – Unified backend technologies; – Innovative end-user services; and – Unified markets beyond single citiesTo tackle this problem CitySDK aims to create toolkit for developing digital services inthe European cities.Toolkit includes open and interoperable digital service interfaces, processes, guidelinesand usability standardsThe toolkit enables more efficient utilization of the developer community and createsnew business opportunities in the citiesFocus on three domains; participation, mobility and tourism
  3. 3. CitySDKJanuary 2012 – June20143 Pilot domains-Smart Participation-Smart Mobility-Smart Tourism
  4. 4. CitySDK Factsheetunding: CIP ICT-PSPotal budget: 6,8 MEURU-contribution: 3,4 MEURuration: 1.1.2012-30.6.2014 (30 months)oordinator:artners: 23 organizations from 9 countriesorum Virium HelsinkiMarja Mattila,marja.mattila@forumvirium.fitel. +358 40 7440067
  5. 5. CitySDKThe consortium consists of 23 partners in 9 European states. Inaddition to experienced SMEs, large ICT and media companies andresearch partners the consortium includes eight cities, five being theCapital cities/regions. HELSINKI MANCHESTER AMSTERDAM ISTANBUL ROME BARCELONA LISSABON LAMIA
  6. 6. Roadmap 201 2 201• 4 Preparing Lead Pilot • Dissemination of the pilot – Pre pilot results – Interface specification • Packaging CitySDK and – Kick off for developer engagement marketing it• Piloting • Reporting 20 13 • Piloting continues • Developer engagement continues • Apps challenge • Supporting the replication pilots • Working on Helsinki replication pilots in the domains of – Tourism – Mobility
  7. 7. Smart Mobility -Amsterdam ReittiGPS
  8. 8. Smart Tourism- Lissabon Kuva: Susanna Ollila
  9. 9. Smart Participation - Helsinki
  10. 10. FixMyStreet - UK
  11. 11. Citizens Connect - Boston
  12. 12. Washington DC 311
  13. 13. Street Bump - Boston
  14. 14. SeeClickFix - USA
  15. 15. 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, HKRCitizen www.hel.fi Technology, City software Department B platforms Fillarikanava Processes City Department C Facebook Best practises Media XY City Department D
  16. 16. Public works department annual feedback Calls 63920 Offered calls 86038 Answered calls 63920 Customer visits 22 980 Emails 25412 Together 112 312
  17. 17. 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/
  18. 18. 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
  19. 19. 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.
  20. 20. 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.
  21. 21. 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.
  22. 22. 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
  23. 23. 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
  24. 24. Use cases under consideration• Commenting on service requests• Editing and removing service requests• Account handling for users• Voting for service requests
  25. 25. We need your help• We need your help to make citizen participation – easier – better and more accurate – activate and excite more citizens – FUN!
  26. 26. 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?
  27. 27. 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?
  28. 28. 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?
  29. 29. 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
  30. 30. 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

×