Amsterdam is an easy city to get around as a tourist – even easier if you hire a bike, or perhaps buy the 72 hour transport pass. However, it is also a city where many people live and work – coming in from the suburbs or the wider region. No modern city can function without providing parking and routes for those coming in by car as well – but even if you are a regular in the city, finding a parking space can be difficult and expensive. If we are looking for an issue that has a “smart solution” and which can be beneficial to a large number of people – then some kind of “parking app” is not only to be welcomed, but will increasingly become expected by drivers coming into the city centre. It was no surprise then that when developers got together to look at the open datasets that were available in the recent “Appsterdam” – an open data hackathon in the city – that transport data featured highly. Developers had 48 hours of prototyping and 6 sets of open data had been made available with a very clear and simple instruction: “Take this data and make an App”.
For the developers Glimworm the challenge was not around the data or its usage, but about the need. What could be the “killer app” they could make. The city, by supporting this App challenge, wants people to have a good experience. The Park Shark app was developed at this app challenge – and the aim was to make it simple, easy and fast for customers to use. Parking in the city is not just about availability (and real time data wasn’t easily availability) but about the cost, the location, the length of stay and the method of payment. No use finding a parking space but not having the right payment – or finding somewhere near your meeting but having to leave early because of restrictions on how long you can stay. So having come up with the idea at the Apps challenge, Park Shark went into development. Not only city data was required – but date from CITION, who manage some of the city’s public transport. Also, the city’s transport executive runs a park and ride – and wants to encourage its usage. This data was layered on to Google maps. It’s likely that most applications will need more than one source of data; and may need different types of data – including map data. In Amsterdam, there are parking garages – in private hands – and these might also be something that needs integrating into the ideal data app. In developing Park Shark the data itself wasn’t that difficult to deal with – as the dataset from CITION didn’t change that often. They may upgrade a parking meter to take cards rather than cash, but the actual spaces – and locations – would usually remain the same. However, much more difficult from the developer’s point of view, was applying a useful “business logic” to the data once the app was built. For instance, dividing the city into different sectors so that proximity wasn’t the only criteria (e.g. having to go across the water to north Amsterdam.) Initial data they had used didn’t always match – with different information, such as area codes, location and prices – and “cleaning” the data is always necessary. Also, its far easier if the data is available via an API, so its updated by the supplier of the site, rather than having to be ported into the system on the developer’s server.
For Glimworm, the business model was not to charge for the App, as that was in conflict with its aim – to be easy and simple to use, and be a useful application that could improve people’s parking experience in the city. However the App has acted as a showcase, featured heavily on the iStore and by Dutch Cowboys, a leading tech blog. The publicity generated, as well as the “wow factor” of the App itself has been a driver of other business.
App competitions such as this have proven useful – as a mechanism for driving rapid application development. Developers are happy to have the opportunity to be part of this – but quality data (fewer, better datasets are preferable from a developer point of view), and good documentation, especially around the business logic are vital. This was an interesting point – and one that we’re sure to hear more of. For the data itself only reflects the service from which it has been extracted, and making it easier for developers to make sense of it is vital if we are to encourage more and better apps. What was interesting however was that the developers themselves would like to be part of that dialogue – as their experience of what works and what doesn’t can help cities make the right decisions about what data to put out, and how to ensure it’s useful.
This case study was given at the CitySDK Smart Mobility workshop in Amsterdam in April 2012. By Adrian Slatcher.