At CitySDK @ WaagOpenSpace, developers of the API talk about the API and what they plan to do with it. This is my summary of the evening.
Job Spierings: CitySDK introduction
Job Spierings started the introduction by reiterating that open data for the CitySDK is important for transparency; releasing social and commercial value; and participation and engagement. However, many open data users run into the familiar issues: different formats, sometimes proprietary; differing refresh rates in data; potential privacy issues, like cellphone numbers for workers in road works data; and legal issues caused by datasets having many different owners with different interests.
CitySDK aims to solve these issues for developers. In Tim Berners-Lee stars, they aim to be between four and five stars. CitySDK does not just take data from governments, but also uses crowd sourced data, to create what they call: crowd enhanced data.
The project is set up to become a one-stop-shop for developers, with pan-european access. Current cities are Lisbon, Barcelona, Manchester, Amsterdam, Rome, Helsinki, Lamia and Istanbul. The whole project is also open source. Not all datasets are available in all cities. Maps, based on OpenStreetMap, are available in all cities, public transport is available in most.
They’ve built a few demo applications, like ‘now’, which shows departure times at nearby public transport stops. This has been done before, but unique about this app is that it works in cities in various European countries, while using only a single API. They are working on the Open City Dashboard, which can be used by municipalities to communicate about the state of the city to citizens.
Bert Spaan: Meet the City SDK API
Bert Spaan takes us into the CitySDK platform. He’s one of the backend developers of the CitySDK mobility API, and uses the example of Amsterdam Central Station. There are many datasets available today, like OpenStreetMap, the NS realtime departure times, and even Foursquare. But they are all very difficult to link. By using common identifiers, as Tim Berners-Lee intended, data can be linked.
CitySDK takes these identifiers from OpenStreetMap, using it as a geographic base layer. They then map other datasets, like GVB departure times, to these OSM nodes. OSM works well for this, because it’s very complete. Bert recently went to Manchester, and the same principles apply there.
Linking datasets is incredibly hard. There are many different spellings and names. Mapping on geographical proximity is also not sufficient. Some of the processing in CitySDK is automatic, but they still do some handwork. An example for this is the DIVV realtime travel times dataset. This data contains coordinates of the roads for which the speed is measured, but those coordinates do not exactly overlap with OpenStreetMap roads. They’ve developed algorithms to map these quite well.
Bert gives us a demo of the map viewer which is a really nice way to explore CitySDK data. I’m quite impressed: a nice example is linking the OpenStreetMap object of Artis to the ArtsHolland API, so that you can go directly and reliably from the OSM object to the next ‘Knuffelen met kleine dieren’.
Laurens Schuurkamp: CitySDK globe
Laurens is a frontend developer at the Waag Society. A year ago, he built a tool that aggregated all 32 open datasets available for Amsterdam at that time. But the biggest problem was that they could not be combined.
The built a new wonderful visualisation now, the CitySDK globe (requires WebGL). Again, the most impressive part is that most data they can show for Amsterdam, is available for Manchester and other cities as well.
Roel Obdam
Roel is a student that works on combining external datasets with the CitySDK. For example, one could take all tourism nodes from OSM, and then run another query against a different API that adds data about museums – from an API that is not included in CitySDK itself.
They use DBPedia for matching. Unfortunately, it’s not entirely reliable at this time. After querying both datasets, a user can define which attributes should be linked to each other. It’s not specific to CitySDK: It will be able to match any two datasets to each other.
Jonathan Carter: Towards a multimodal API
Jonathan from Glimworm IT talks about “Towards a multimodal API”, a report for the Department of Infrastructure, Traffic and Transportation of the city of Amsterdam, which Glimworm wrote together with myself andBraxwell.
The purpose of the project was to see how possible it currently is to make the perfect multimodal API, which areas need improvement, and what DIVV can do. We focused on route planning and real time monitoring of planned routes. One of the results is a proof of concept, which does multimodal planning with different data sources. For example, you could go from Woerden to the Rijksmuseum by car all the way, bike all the way, OV all the way, or bike to a station and then use OV, or take a car to any of the park and rides and then OV, and so on.
The biggest challenge is prediction. If the planner sends someone to a park and ride, because that’s good for both the traveller and the city, and the park and ride is full, the traveller will be very disappointed, and might never consider this again. This problem extends to pretty
much all data: realtime info focuses on the state right now, but there are no good predictions for the future. This is especially critical when a traveller has to switch between modes of transport.
Rein van Oost: Expected Time of Arrival
Rein presents “Expected Time of Arrival”, their idea for an app on the CitySDK. They’ve been making open data apps since 2008. They were asked to come up with a practical application of the CitySDK data.
Their idea, “Estimated Time of Arrival”, uses the CitySDK mobility data. The concept is to share your current position, direction and destination with others. The app estimates the time of arrival at the destination, so other people don’t have to ask you when you will be home or whether you will be on time.