A partial archive of https://score.community/ as of Monday March 04, 2024.

Working group call on Tuesday 22 may 2018


We’re having a call next week Tuesday 22 may 2018 at 10:00 CEST on how to get started building this tool. The questions that @claus and I have identified now to discuss are the following:


  • Who are you and what is the status of the travel time tool in your organisation?
  • What are the main questions you need answering before moving forward?
  • Amsterdam is planning to use the proprietary iGeolise API as the backend API for getting the travel times in their frontend tool, how do we fit this into the collaboration in SCORE?

If you have any questions to add to this, please tell us here :slight_smile:

The call is at https://global.gotomeeting.com/join/920494285 and we have confirmation of joining from Digipolis: Martine & @pjppauwels, Gent: @JoranVD, Amsterdam: @h.niesing, Chennard


Draft minutes:

Hi all, quick update from the call yesterday. @h.niesing @pjppauwels @JoranVD @HD_Hamburg @HansF @Boris (& Chennard) please let me know if I missed or misrepresented something.

We had a great conversation with Amsterdam, Gent, Digipolis Gent and Hamburg about potentially moving ahead with the time travel tool.

Amsterdam has internal approval to build this anyway and is in a hurry to implent this as soon as possible. The call was to evaluate it’s applicability and replicability through SCORE.

While all parties could see the benefit of the tool (incl proprietary software), there were a few issues that merit further discussion by the larger score community.

The travel time tool frontend that Amsterdam will build relies (for the time being) on a proprietary data set, algorithm and API hosted by a third party. So: mixed data sources get scanned by the proprietary software, it analyses travel time (where I can get to within 30min cycle from indicated point), and outputs the results. Amsterdam wants to build the frontend webpage to allow people to view this on a map.

While the proprietary software could be replaced, it is (according to Amsterdam’s research) the only solution that performs at the required speed and hard to replace with open source software.

The discussion thus focused on: can we build things in SCORE that rely on proprietary software (and thus liscencing costs)? Should we take a pragmatic stance in order to be able to get started with the first solution (and benefits of learnings thereof)?

Next steps

Seeing as this is a fundamental question for SCORE this should be discussed by the wider community.
Amsterdam will develop a short document that makes the case for developing the front end for the thrid party travel time API with SCORE partners. This docuement will outline what they want to develop, what it will cost, how others can participate and reuse the solution, and a business case for evaluating the role/costs proprietary software for reuse by others.

This discussion will hopefully lead to a general framework/principles/consensus to evaluate future solutions/decisions about the solutions we will be developing in SCORE.


Hi @claus !

When is the next Working Group call planned to take place?
I would like to invite Malin Stoldt from Gothenburg City Traffic Office to participate.

Thank you.
Best /Eva


Hi @evdoxia.kouraki !

Here is the working group calls schedule:

  • Flood Risk : on every 2nd Thursdays of the month at 4PM CET (next call: on 13/09)
  • IoT Registry : on every 3rd Thursdays of the month at 2PM CET (next call: on 20/09)
  • Mobility (e.g Events on mobility, Mobility hub, Travel Time etc): on every 4th Thursdays of the month at 3PM CET (next calls: on 23/08, 27/09)

You can invite anyone via the monthly google calendar invite.



Thank you so much Marie!
Have a great weekend :slight_smile: