Fix nextbike ortenaukreis

[Altonss]

No description provided.

[Altonss]

cc @eskerda
Do you know if all these failing Nextbike tests are "normal"? (The one related to Vélomagg, Montpellier is normal, but isn't related to this PR)

[eskerda]

This workflow checks all instances on the affected modules by the changes. Since this PR changes gbfs and nextbike it's testing both. There may be some failures in there that are unrelated to the PR. You do not need to fix anything that is not related to this PR, even if the workflow is failing, but it's there to help troubleshoot on the majority of the cases

This one is relevant though isn't? https://github.com/eskerda/pybikes/actions/runs/11053693459#user-content-tag-nextbike-ortenaukreis-3.8.18

[Altonss]

This one is relevant though isn't? https://github.com/eskerda/pybikes/actions/runs/11053693459#user-content-tag-nextbike-ortenaukreis-3.8.18

Oh thanks a lot for the hint, didn't see this nice dashboard :)

[Altonss]

Well it's failing because this vehicle type https://static.nextbike.net/app/biketypes/type/97/306/h500.png doesn't have a propulsion_type 😆

[eskerda]

Well it's failing because this vehicule type https://static.nextbike.net/app/biketypes/type/97/306/h500.png doesn't have a propulsion_type 😆

😱 😱 😱 😱 What kind of vehicle is this?

[Altonss]

Well it's failing because this vehicule type https://static.nextbike.net/app/biketypes/type/97/306/h500.png doesn't have a propulsion_type 😆

😱 😱 😱 😱 What kind of vehicle is this?

A bicycle trailer :)

[eskerda]

It seems there's this vehicle type on the gbfs vehicle types response, but no stations are really announcing they have trailers, since there's no warning

The code on parsing vehicle info on gbfs is a bit convoluted. For now I think something like this will do the trick and we can go back later and make it clearer

diff --git a/pybikes/gbfs.py b/pybikes/gbfs.py
index bbcff87..025a740 100644
--- a/pybikes/gbfs.py
+++ b/pybikes/gbfs.py
@@ -86,20 +86,20 @@ class Gbfs(BikeShareSystem):
         # contains pairs of (vehicle query, resolver)
         return [
             (
-                lambda v: v['propulsion_type'] == 'human' and v['form_factor'] == 'bicycle',
+                lambda v: 'propulsion_type' in v and v['propulsion_type'] == 'human' and v['form_factor'] == 'bicycle',
                 update_normal_bikes
             ),
             (
-                lambda v: v['propulsion_type'] in ['electric_assist', 'electric'] and v['form_factor'] == 'bicycle',
+                lambda v: 'propulsion_type' in v and v['propulsion_type'] in ['electric_assist', 'electric'] and v['form_factor'] == 'bicycle',
                 update_ebikes
             ),
             (
-                lambda v: v['propulsion_type'] == 'human' and v['form_factor'] == 'cargo_bicycle',
+                lambda v: 'propulsion_type' in v and v['propulsion_type'] == 'human' and v['form_factor'] == 'cargo_bicycle',
                 update_cargo
             ),

             (
-                lambda v: v['propulsion_type'] == 'electric_assist' and v['form_factor'] == 'cargo_bicycle',
+                lambda v: 'propulsion_type' in v and v['propulsion_type'] == 'electric_assist' and v['form_factor'] == 'cargo_bicycle',
                 update_ecargo
             ),
         ]

[eskerda]

Not so sure I want to break the feeds of nextbike into single gbfs feeds.. Offenbourg information is still available in https://maps.nextbike.net/maps/nextbike-live.xml?domains=eh

In this particular it's ok I guess, because there are many of the cities on the feed that do not have much stations, but I do not really want this to become the norm

[eskerda]

Thanks @Altonss!!