Skip to content
LoginRegister
DEENFRIT
Home
Open data platform mobility Switzerland
  2. Cookbook
  3. Bike Parking

Bike Parking

Source: https://pixabay.com

Go to the data

https://opentransportdata.swiss/en/dataset/bike-parking

Change Log

2023-07-12 As a “Beta” or experimental feature, some more details provided by the ROKAS service are added as addtional properties. These include (if available):

  • “type”: the type of the station, currently a German text field
  • “capacity”: number of places available
  • “website”: website for further information.
  • “address_….”: various fields about counry, canton, street address etc.

(!) This is a preliminary, provisional addition. Field names and values may change in the future.

2023-06-28 First publication of this service, with kind permission of the SBB team ELM (Erste & Letzte Meile).

Description

The data feed consists of a file of about 900 kB in size, which is retrieved daily from an SBB database (ROKAS). The feed contains the data of  about 1200 bicycle paring locations with name, geo-coordinates and some optional information.

Data Format

The files are UTF-8 encoded JSON files based on the GeoJSON standard (see https://en.wikipedia.org/wiki/GeoJSON).

The data structure is a GeoJSON “FeatureCollection”, which contains a list (array [ ]) with “features” (the bike parkings).

Each feature (parking facility) mainly contains these fields:

  • “id“: a technical identifier,
  • “type“: “Feature” (required by GeoJSON to define the type),
  • “geometry” a GeoJSON data structure for a point with the WGS 84 coordinates,
  • “properties“: other properties, including:
    • “name“: the name of the bike parking.
    • “stopPlaceUic” and “stopPlaceSloid”: external identifiers (UIC and SLOID),
    • “source”: hints about the source system and its internal id (e.g. ELM / Team Erste & Letzte Meile at SBB)
    • “category”: “parking” and “subCategory”: “bike_parking”: currently, constant fields

In the future, we expect the fields “id”, “type”, “geometry” and “name” to remain unchanged, while other properties may be null or not present, and new properties may be added.

The following code shows an example with one single bike parking for illustration purposes. Ultimately, the data feed itself should be considered for the actual structure and properties.

{
. "type": "FeatureCollection",
. "bbox": [
. . 8.9022774,
. . 47.4885437,
. . 8.9022774,
. . 47.4885437
. ],
. "features": [
. . {
. . . "type": "Feature",
. . . "id": "9a074e29-a611-473d-84ac-4f92ed3bfe34",
. . . "geometry": {
. . . . "type": "Point",
. . . . "coordinates": [
. . . . . 8.9022774,
. . . . . 47.4885437
. . . . ]
. . . },
. . . "properties": {
. . . . "name": "Veloparking Aadorf",
. . . . "stopPlaceUic": 8506013,
. . . . "stopPlaceSloid": null,
. . . . "source": {
. . . . . "name": "elm",
. . . . . "id": "719"
. . . . },
. . . . "category": "parking",
. . . . "subCategory": "bike_parking"
. . . }
. . }
. ]
}

.