Velopark: A Linked Open Data Platform
for Bicycle Parkings

Introduction

Bicycles have played a main role in the urban transportation evolution of the last decade [1]. Motivated by its positive side-effects (e.g., on traffic congestion, CO2 emissions and public health), public authorities around the world implement strategies that promote cycling as a main mode of transportation [2, 3]. Countries such as Denmark, Germany and The Netherlands, stand among the most successful in this regard [4], due to effective pro-cycling policies combined with adequate infrastructure provision (e.g., parking facilities) [5, 6].

Sufficient infrastructure coverage and capacity is necessary to increase bicycle usage, but infrastructure alone is not enough. Effective information channels that let cyclists know where and how to access and use such infrastructure are also a necessity. Lack of clear communication may lead to increased inappropriate (sometimes illegal) street parking and higher bicycle theft levels. These are already major issues in the aforementioned countries, ultimately having negative effects on cycling promotion [7, 8].

Nowadays cyclists struggle to find reliable and useful information. Authoritative data about bicycle-related infrastructure such as parkings, is usually managed by multiple organizations that either own or operate these facilities. The Web is typically the preferred medium used by these organizations to make information available to the public via their websites. However, having to visit several websites is impractical to find the desired information, e.g., to know where to securely park a bike or if there is enough room to do so in a particular location.

Applications that facilitate information access are difficult to build due to highly heterogeneous or unavailable data. Providing users with all mobility-related information they need, is one of the goals behind MaaS (Mobility as a Service)¹ solutions. Building MaaS applications requires data to be available in machine-readable formats, which is frequently not the case for bicycle-related infrastructure. Acknowledging this gap and motivated by Open Data initiatives, some bicycle infrastructure managers publish their data using machine-readable formats through ad-hoc Web APIs. Although they fulfill their purpose of making data available, developers still struggle on reusing the data due to the high heterogeneity found across APIs in terms of data structure and information detail.

In this paper we present the results of the Velopark project². This project was carried out in Belgium with the support of local governments, public transport operators and pro-cycling organizations. The main results of the project are (i) a semantic data model, namely the Open Velopark Vocabulary³ to effectively describe bicycle parking facilities; (ii) the implementation of a data publishing platform that supports organizations with limited resources to manage and self-publish their data, while fostering interoperability of bicycle parking data; and (iii) an Open Data charter⁴ signed by the cities of Antwerp, Ghent, Leuven, Pelt and other organizations, expressing a commitment to provide timely and high quality information about their bicycle parkings as interoperable Open Data to stimulate daily bicycle use. At the time of writing, 31 Belgian municipalities and 4 bicycle parking related organizations actively engaged into the Velopark platform, publishing 1599 bicycle parking facilities.

The rest of this paper is organized as follows: Section 2 presents an overview of related work regarding data models and approaches for Open Data publishing on the Web. Section 3 describes the Open Velopark vocabulary. Section 4 presents the reference architecture of the Velopark platform. Finally in Section 5, we present our conclusions and vision for future work.

Related Work

In this section we present an overview of related data models that up to different degrees, describe bicycle-related infrastructure. We also describe different approaches that are currently followed to publish bicycle-related information as Open Data.

Modeling Bicycle Infrastructure Data

Providing cyclists with useful information about related infrastructure such as parkings, requires models able to capture and describe all their relevant characteristics and features. Definitions of entities and properties related to cycling infrastructure can be found in general purpose vocabularies like Schema.org⁵. For example schema:ParkingFacility or schema:openingHours represent two concepts directly related to the modeling bicycle parkings. However, Schema.org does not consider many domain-specific aspects, needed for giving detailed and useful information to cyclists. This occurs because Schema.org is meant to provide descriptions for a core of common topics, relying on extensions to cover more in-depth topic’s details [9].

This creators of MobiVoc⁶ followed the same rationale. MobiVoc defines a vocabulary for mobility-related concepts that extends Schema.org classes by establishing subclass relations with Schema.org classes. Such relations are established by means of the rdfs:subClassOf predicate. Even though MobiVoc specializes on mobility and further defines domain related concepts, it still lacks coverage for cyclic infrastructure specific entities. For example, it does not give definitions for parking security features, which often are important criteria for cyclist looking for parking places.

Other related work includes the Parking Ontology⁷, the General Bikeshare Feed Specification (GBFS)⁸ and the Mobility Data Specification⁹ (MDS). The Parking Ontology focuses on describing car parking areas and does not consider bicycle-related domain knowledge. GBFS defines a JSON-based specification for real-time and read-only data about status of bike sharing stations. MDS defines a set of APIs to facilitate information exchange between public authorities and dockless mobility service providers (e.g, e-scooters, mopeds, bicycles). Both GBFS and MDS are mostly focused on describing operational aspects of mobility services and lack formal semantics on their data models.

Bicycle Infrastructure as Open Data

Open and machine-readable data is fundamental for the creation of applications that provide useful and reliable information to cyclists. Infrastructure managers commonly publish their data in the form of data dumps or via HTTP APIs. For instance, the data portal of the city of Ghent, Belgium publishes their bicycle parking data¹⁰ using both approaches.

OpenStreetMap (OSM) can also be considered as an open data source for bicycle infrastructure information [10]. It also provides data dumps and can be queried via the Overpass API¹¹. Given their high server cost, open HTTP APIs often impose request limits (as is the case for Ghent and Overpass endpoints) or expect to handle simple queries only [11]. Data dumps on the other hand, can be seen as a mirror of the original data source and are outdated since the moment of their creation, which becomes an issue, specially when publishing live data [12].

Another popular alternative, motivated by SEO (Search Engine Optimization) guidelines is the embedding of structured data into HTML using Schema.org as a data model, and JSON-LD or RDFa as serialization formats. This helps search engines to better classify and index websites, but it is hard to reuse by applications due to discoverability and even legal issues when scraping websites.

Open Velopark Vocabulary

Motivated by the need of having a common data model capable of capturing all the complexity inherent to bicycle parkings, we created the Open Velopark Vocabulary (OVV). We incorporated the input of several bicycle parking managers, which includes public authorities, public transport operators and pro-cycling organizations, all having the goal of bringing reliable and useful information to bicycle users. For the vocabulary creation we followed the guidelines established by the Best Practices for publishing Linked Data document¹², emphasizing on reusing standard and existing vocabularies.

The core of OVV is based on MobiVoc, which is in its turn based on the Schema.org data model. OVV thus extends both MobiVoc and Schema.org to define a set of concepts and properties that are not originally considered by these vocabularies and are deemed important for providing useful information for cyclists (see Figure 1). The main focus of OVV extensions lies in providing definitions for bicycle parking associated services and features and more detailed descriptions of operational and physical properties of bicycle parking facilities (see Table 1).

OVV defines a core-independent list of terms¹³ that provides definitions to domain-specific entities such as types of parking facilities (e.g., bicycle stand, resident parking, etc), types of bicycles (e.g., electric bikes, cargo bikes, etc) and types of features (e.g., parking services and security characteristics). These entities were defined through an iterative process that involved domain experts from the different organizations involved in the Velopark project. Additionally, they were also reviewed and refined by members of the VeiligStallen.nl¹⁴ technical team. VeiligStallen.nl is a bicycle parking platform from the Netherlands, that has provided an information hub over the last 10 years and was an inspiration of the Velopark initiative.

Reference Architecture

The system architecture of the Velopark platform was designed to support two different strategies of bicycle parking data publishing: (i) decentralized (Parking Manager A in Figure 2) and; (ii) centralized (Parking Manager B in Figure 2) publishing.

The first strategy enables a decentralized data management process. Bicycle Parking Managers (BPMs) are able to use Velopark’s Snippet Generator tool to describe their facilities following the OVV data model, and then opt for publish the resulting data on their own servers. Every BPM decides on how to publish the data, requiring only to make the parking facility URIs dereferenceable and set the appropriate HTTP headers for enabling CORS (Cross-Domain Resource Sharing). Some alternatives to publish the data are (i) embedding JSON-LD snippets in BPMs website HTML; (ii) using HTTP content-negotiation to give both machine- and human-oriented views of the data; or (iii) serving the data as plain RDF files. Figure 2 represents scenario iii through Parking Manager A.

The centralized strategy focuses on supporting organizations with limited resources to self-host and manage the data about their parking facilities. These organizations can also use Velopark’s Snippet Generator tool to create a data description of their facilities using the OVV model, but unlike the decentralized strategy, data is published and maintained on Velopark servers as plain RDF (JSON-LD) files. Parking Manager B is an example of this scenario in Figure 2.

Regardless of the data publishing strategy (either centralized or decentralized), the Velopark platform remains a central and authoritative data entry point. This is achieved by maintaining a DCAT¹⁵ catalog linking to all available parking facility URIs, which are in turn dereferenceable and contain the parkings data.

Snippet Generator

This Web application (available at https:/​/​admin.velopark.be) is designed to enable BPMs describing their parking facilities following the OVV model. Additionally, BPMs have the possibility to manage their facilities by updating them and deciding if they are referenced in Velopark’s data catalog. BPMs publishing parking data on Velopark’s platform are required to follow these steps:

1. Registration: BPMs can be either public authorities representing a certain municipality or company representatives. They first request access to the platform which is granted by Fietsberaad Vlaanderen.
2. Parking Description: Once registered, BPMs can describe their facilities by entering the data in a wizard-based form, which ensures that all basic and required properties are entered.
3. Data Publishing: When the description of a parking facility has been completed, BPMs have the option to either self-host the data or rely on Velopark’s servers to host it. In case self-hosting is chosen, BPMs need to provide the URL where the parking data will be made available. The application will generate a JSON-LD snippet (see listing 1) containing all the parking data that has to be published under the chosen URL. Otherwise, the application will generate a URI (belonging to Velopark’s domain) for the parking facility and will proceed to make the data available there.

{
    "@context": { ... },
    "@id": "https://velopark.ilabt.imec.be/data/
        De-Fietsambassade-Gent_Korenmarkt",
    "@type": "mv:BicycleParkingStation",
    "dateModified": "2020-02-10T22:20:45.814Z",
    "identifier": "Korenmarkt",
    "name": [
        { "@value": "Korenmarkt", "@language": "nl" },
        { "@value": "Korenmarkt", "@language": "en" }
    ],
    "temporarilyClosed": false,
    "address": {
        "@type": "schema:PostalAddress",
        "postalCode": "9000",
        "streetAddress": "Pakhuisstraat",
        "country": "Belgium"
    }
    ...
}

Velopark DCAT catalog

Velopark’s data catalog (available at https:/​/​velopark.ilabt.imec.be/data/catalog) is the result of the work done by BPMs on describing their parking facilities. It references all the parkings that have been approved by the BPMs to be made public, regardless of where the data is hosted (either on BPM or Velopark servers), bridging both centralized and decentralized data publishing strategies. The catalog follows the DCAT specification, defining a unique dcat:Catalog entity that contains multiple parkings. Each parking is represented as a dcat:Distribution, which data can accessed as defined by its dcat:accessURL property (see listing 2).

{
    "@context": { ... },
    "@id": "http://velopark.ilabt.imec.be/data/catalog",
    "@type": "dcat:Catalog",
    "dcat:dataset": {
        "@type": "dcat:Dataset",
        "dcat:distribution": [
            {
                "@type": "dcat:Distribution",
                "dcat:accessURL": [
                  "https://velopark.ilabt.imec.be/data/Cyclopark_AL01"
                ],
                "dcat:mediaType": "application/ld+json",
                "dct:issued": "2020-02-04T17:12:27.035Z",
                "dct:modified": "2020-02-04T17:12:27.035Z"
            },
            ...
        ]
    }
}

Velopark User Interface

This is Web application targeted at cyclists (available at https:/​/​velopark.be) and built by the Velopark team. It presents a map-based view containing all the available parking facilities of a certain region. It also creates human-oriented visualizations on top of parkings data, showing all the parking characteristics. Cyclists can filter the facilities by their properties such as features, services and physical characteristics. This application stands as an example of how Velopark’s data can be discovered (via the catalog) and be directly consumed from their sources.

Another important feature of this application is the possibility for cyclists to provide feedback. If something is incorrect on the data of a particular parking facility or if some parkings are missing, cyclists can report this through the application. These reports will reach the corresponding public authority representatives responsible for the parking or the municipality mentioned in the report, which in turn can proceed to update the data where necessary.

Handling Live Data

One of the most important aspects for cyclists is to be informed about the live occupancy of a certain parking facility. Unfortunately these particular type of data is unavailable for most facilities. In the case of Velopark’s BPMs, only three BPMs had an available API where this data could be found: the city of Ghent (for 2 parkings), Parko (for 1 parking in Kortrijk) and Blue-Bike (for 1 parking in Vilvoorde). We took the data available on these APIs and republished it using the OVV data model. The process to republish the live data is as follows:

1. Data Modeling: OVV already considers a class for representing live capacity values. The mv:RealTimeCapacity class defined by MobiVoc has precisely this purpose, which we reused.
2. Linked Data Generation: Since the original data comes through ad-hoc APIs that lack formal semantic definitions, we used RML (RDF Mapping Language)[13] to define the rules that describe how the data of each API should be annotated to follow the OVV data model. We created these mappings using the YARRRML [14] syntax.
3. Live Data Publishing: We published these particular parkings following the principles defined in [12] and using the Linked Time-Series Server [15]. We extended this implementation to support RML mapping rules, by just providing the mapping files as part of the server’s configuration.

An example of the republished data containing the latest available observations for the city of Ghent, can be found at https:/​/​velopark.ilabt.imec.be/data/live/gent/. Furthermore, historic data can be accessed at https:/​/​velopark.ilabt.imec.be/data/live/gent/fragments and can be traversed by following the links defined by the hydra:previous predicate.

Conclusion and Future Work

The Velopark initiative brought together bicycle infrastructure experts from multiple organizations, all having overlapping interests. Promoting cycling as a main way of transportation and delivering relevant and reliable information to cyclists is a common denominator for these organizations. So far, 31 Belgian municipalities and 4 different BPMs have actively engaged into the Velopark platform, publishing data about 1599 parking facilities. To the best of our knowledge, this represents the most complete and open bicycle parking dataset in Belgium to this date. Furthermore, a third-party application, namely Hopper is already reusing Velopark’s data. Hopper is a route planning application designed to give route advise to electric bicycle users, in combination with public transport. Hopper uses data from Velopark to display which train stations have bicycle parkings.

Another important achievement from this project is the definition of a common data model for Bicycle parkings. By extending existing vocabularies such as Schema.org and MobiVoc, OVV aims for higher interoperability for bicycle parking data. In addition to follow the recommended best practices for publishing Linked Data on the Web, extending Schema.org was also motivated by achieving higher visibility of the data on search engines. Unfortunately, search engines like Google do not recognize external extensions to Schema.org out of the box. This requires first OVV to go through the official extension recognition process of Schema.org, which is part of our future work.

Between the two different strategies to publish data supported by the Velopark platform, we found that organizations with no resources to publish and manage data on their own, were more receptive and have demonstrated higher interest in making their data visible through the platform. Organizations in charge of a high number of facilities were more interested on having automatic processes capable of mapping their data to the OVV model. This is understandable, since manually describing hundreds of facilities can be time consuming.

Another interesting finding is related to the bicycle parking data owned by public transport companies. We found that both NMBS (Belgian railway company) and De Lijn (Flemish public transport), had extensive and in some cases very detailed data about their facilities, although not open. It is notable considering that both companies had already implemented Open Data platforms on their own. However it is worth mentioning that both companies were cooperative and worked together with the Velopark team to openly publish their data.

One common behavior across all the, so far, involved BPMs has been the reluctance to self-host the data created through the Velopark platform. Even organizations with Open Data platforms and websites about their facilities preferred to rely on the Velopark hosting to publish their data. One of the concerns that were raised by the BPMs to for example, embed JSON-LD snippets into their websites, was keeping it updated. If the data was updated BPMs needed to either manually update this script or develop a connection between the content of these scripts, the data displayed in the website and their back-end systems. Currently this is one of the main issues of decentralized data managing.

On future work, we will aim on extending OVV to cover other types of cycling infrastructure such as, bicycle sharing systems and exclusive cycling lanes.

Acknowledgements

The authors would like to thank the Federal government of Belgium for funding this project. Also extend our gratitude to all the organizations that cooperated and made this project possible.