-
Notifications
You must be signed in to change notification settings - Fork 41
GDPR compliant
In the endpoint /operator/available-assets it's possible to list collections of assets (e.g. per type or per station). It's not necessary to add the real assets in these collections, in most cases reporting the number of available assets per collection will do for most scenarios, except for the map-oriented apps.
[
{
"id": "id_x",
"nrAvailable": 29,
"sharedProperties": {"name": "yellow bikes", "colour": "yellow"}
}
,
{
"id": "id_7",
"nrAvailable": 3,
"sharedProperties": {"name": "brown bikes", "colour": "brown"}
}
]
But, if you want to facilitate displaying your assets on a map, you must of course should list assets and their locations. This is non-GDPR compliant if you use every time the same id or name for the same asset.
The solution of GBFS 2.0 is also embraced by the TOMP-API: rotating asset ids. As soon a trip is ended, the asset should get a new id. This way it becomes harder to trace the bikes.
Introduction
- Roadmap
- Semantic versioning
- Use cases
- Changes per version
- Contribution
- Participants
Workflow
- Operator information
- Planning phase
- Booking phase
- Trip execution phase - start
- Trip execution phase - on route
- Trip execution phase - end
- Support
- Payment
Points of attention
- Modalities
- Specifying locations
- GDPR
Eco system
- Relations
Introduction
Scope of the TOMP-API
Versioning and releases
Process Flows
- Authentication
- Operator Information
- Privacy and Registration
- Planning Module
- Booking Module
- Trip Execution Module
- Payment Module
- Support Module
Meta-Information
Reference implementations
To-dos and risks
Technical Specifications
A1 List of terms and definitions
A2 Passenger characteristics dictionary
A3 APIs available on the transportation ecosystem
A4 Overview of the User stories
A5 Authors, Architects, collaborators and stakeholders involved
A6 Adoption and Implementation of the TOMP-API