A.2.4 GBFS converter implementation

rcavaliere commented 4 years ago

Separate GBFS-Feed for Bolzano and Merano

[x] Analysis of bike sharing data available through ODH API
[x] Compatibility check with GBFS standard
[x] GBFS profile definition (mapping with available data)
[x] Technical analysis of technologies / libraries for the converter implementation
[x] Converter implementation and integration with prototype system architecture
[ ] Testing, documentation and other support activities for the pipeline creation -> this should include also the indication on how to enrich the config file with additional metadata, a task that could be completed by @rcavaliere

The end user story ends with the 2nd prototype version of the end-user client (see #8) using the GBFS-Feed integrated and running in the Open Data Hub architecture

rcavaliere commented 3 years ago

Next steps:

[x] sharing of GBFS profile proposal by @zabuTNT @stemove
[x] review by @rcavaliere
[x] converter finalization, with creation of separate feeds by @zabuTNT and @stemove
[ ] testing, documentation, integration in OTP

zabuTNT commented 3 years ago

This is an example of GBFS files generated by our GBFS service

gbfs-mentor.zip

https://github.com/openmove/odh-mentor-otp/tree/development/gbfs

The GBFS reference version is the 2.0.

rcavaliere commented 3 years ago

Feedback on GBFS-Feed proposal:

GBFS-Feed for Municipality of Merano -> optimal solution would be to use GBFS v2.1 RC (see https://github.com/NABSA/gbfs/pull/219). @zabuTNT has implemented a workaround with GBFS v2.0 in which also stations with very high availability are defined. We have decided to maintain this solution and to implement also the "optimal solution" (could be an additional service for third parties). This activity is part of another user story.
Additional metadata: could be hard-coded in the config-file of the converter

Next steps are updated in the description of the user story.

rcavaliere commented 3 years ago

GBFS-Feed is part of the new version of the client. Additional metadata is going to be part of the version 2.1 (we have to remember to update the metadata part for the GBFS-Feed coupled with the client)

rcavaliere commented 3 years ago

@zabuTNT @stemove @bertolla I have seen that the new client prototype new shows the bikesharing function, but this seems not to work. Bike sharing data are not visualized, and I see something strange in the texts (all $)

zabuTNT commented 3 years ago

hi @rcavaliere, if you go there it seems that in the graph there are no updaters: https://otp.opendatahub.testingmachine.eu/otp/routers/openmove/updaters

We'll support @bertolla if need.

Regarding the texts with $, these are the string that have to be replaced by the translation system, now we'll check it.

rcavaliere commented 3 years ago

@zabuTNT @stemove @bertolla do we have a specific end-point in order to get the whole set of JSON files related to the GBFS Feed, so that I can check their content?

zabuTNT commented 3 years ago

Hi @rcavaliere, they should be these, but now they are down? @bertolla ?

Bozen: https://gbfs.otp.opendatahub.testingmachine.eu/bz/gbfs.json Meran: https://gbfs.otp.opendatahub.testingmachine.eu/me/gbfs.json

here you find the urls of others json as defined in GBFS reference. It is not foreseen by the specification to distribute the entire set via .zip for example, but the data must always be generated on the spot with the most up-to-date data.

I already fixed some issues (missing bikes in meran for example) and create 2 versions.... the v1 (legacy) to use for OTP, and the 2.1 updated with more information. I'll make a pull request as soon as possibile.

noi-techpark / odh-mentor-otp

A.2.4 GBFS converter implementation #5