Options for Travel Time Calculations

Dear colleagues, an update:

We are looking into how we are going to build the Travel Time Tool application.

I am currently trying to get the information about the project, which is under development internally.
My focus is on understanding the level of openness, the development and utilisation costs involved in the current project that is running in Amsterdam.

The current plan is to develop the Travel Time Tool based on the (proprietary) API of iGeolise that can calculate the time to travel from any point using multiple modes of transport.

The costs of using the API from iGeolise is still unclear, it will likely be per calculation. Until now it is not jet clear, but we will keep you updated.

Gr Hugo

Hi Hugo, in regards to T3.7 Definition of requirement specifications and 4.2 Assessment of generic building blocks for solutions, can we justify in this particular project we chose to build on top of iGeolise?

Eg. I don’t think Interreg is eager to pay license for proprietary software in a project that emphasises on using open data and open source?

Well maybe they will if we can validate why this is necessary.
I see three options you can push forward:

1. You hook up to something out-of-the-box and inject your data. Eg. iGeolise.
   Pro: fastest option here, least overhead for cities.
   Con: not really open, still a lot of dependencies.

2. You set it up yourself using open source tools like http://www.opentripplanner.org/
   Pro: You control and own it, everything could be open source and modular for your open source community to build upon.
   Con: A lot of overhead (gathering own public transport and other mobility data per city, this might be too much for this project)

3. (and this would maybe be my go-to solution) You procure a company that builds open source as a service to handle it for you.

Eg. Plannerstack http://www.plannerstack.com/ a Dutch company or https://www.navitia.io/ (French) can setup open API’s based on open trip planner for the consortium to use for mobility solutions, including isochronic mapping like you suggest here.
Pro: you do not have to the grunt work yourself, but even after the contract is done, you can host it yourself, make the code open,…
Cons: Red tape procurement wise.

If we chose option 1, we should be able to explain why we’re not doing the other two.

This is my personal opinion, would love some feedback from @claus, @Boris, @HansF, @thimo.thoeye, @Amsterdatamas and @JoranVD

Would be fine by Interreg

@h.niesing any preference from Amsterdam’s side on the options Pieter-Jan suggested?

Just had a discussion with our internal team. And we would love to have a discussion on the level of openness with at least Amsterdam, but other project partners as well when given the opportunity.

Do we want to have just the front-end open, or the back-end as well? And what with the connected systems? I want to do this on an abstract level.

In same meeting @HansF was eager to see how far we need to go as a city to also make the back-end open source and whether this has been done before by a city or government. I’ll try and help him with this assessment.

Dear colleagues,

Last Wednesday 2nd May I had a meeting with Chennard Testing from Amsterdam municipality.
He is leading the progress on the implementation of the Travel Time Tool (TTT) in Amsterdam.
This process is on the go, next week he is negotiating with the company about the conditions, costs for the different users.

These will mainly be different housing agencies, the expat service for Amsterdam and other organisations and businesses where issues as:

• ‘travel time between work and living’ or
• ‘demonstration that living near Amsterdam can be a better alternative than inside the city is important. At least for the municipality of Amsterdam these issues are important to keep the pressure on the city acceptable.

Chennard explained me that the TTT is open to a high degree, not fully.
The interaction between the sources and the iGeolise algorithms box is open, as well as the results display.
In parallel a open version of the calculation algorithms could be developed, to be discussed.
Amsterdam needs TTT and the first system version will be up and running in June (is the plan).

I would like to propose a Telco after next week (week 14-18 May) when Chennard has more information and we can decide about the SCORE developments of the TTT.

Kind regards,

Hugo

Hi @h.niesing thanks for the update! Sounds promising.

I think the suggestion for a call is a great idea. Here’s a doodle - @pjppauwels & @HansF. Anyone else to invite to the call?

On Ghent side, definitely Martine, Bart Rosseau and @JoranVD. Joran can you check for Bart?

On it!

Hello Claus,

Yes @Boris and Chennard Testing (shall I ask him?).
Greets

Hugo

Call fixed for 22nd at 10am. Look forward to discussing with you all then.