Parking spots for Free floating operators

[viestat]

whoami

My name is Andrés Viesca and I am a software engineer at Dott, I have been working on implementing and maintaining Dott's GBFS service (gbfs.api.ridedott.com).

What is the issue and why is it an issue?

There is currently no convenient way to share information about designated parking spots for free floating operators.
This is important because some cities require the operators to enforce parking at given locations (i.e. a specific set of coordinates) or at specific areas (i.e. a GeoJson polygon).

The current alternative is to use station_information.json which does not really fit with what it actually is needed.

Please describe some potential solutions you have considered (even if they aren’t related to GBFS).

I think either creating a new endpoint called something like parking_locations.json or extending the current geofencing_zones.json to be able to express this specific kind of region would solve this.

Is your potential solution a breaking change?

• Yes
• No
• Unsure

[josee-sabourin]

Welcome Andrés!

Thanks for opening up this issue.

Have you had a look at #329? It is a proposal to define how a vehicle should be returned at the end of a trip. Perhaps the solution to your issue could be defining those parking spots using is_virtual_station in addition to using the any_station option in return_type suggested in #329.

[kanagy]

Hello! I'd like to learn how big are the Dott's dedicated parking areas? If these are small (say <100x100m) they could be modelled as hybrid systems with virtual stations (a free floating bike that needs to be returned to an unlimited capacity "station" - a single lat/lng rather than area), as Josee suggests.

[viestat]

Hello @josee-sabourin and @kanagy !
Thank you both for your suggestions and for pointing out #329, I had a look into it just now but I have some concerns about it not addressing all of our needs.

While defining parking spots using is_virtual_station seems to definitely be the best way to convey information about them in the spec. There would still not be a way to express that when a user wants to stop the ride within a given zone, it needs to go to a parking space or outside of said zone.

I will try to exemplify this need a bit better:

In a given city, users can start and end rides anywhere within its geofencing zones (free floating model).
There is however a special kind of zone in which a user can only park in designated parking spots (which can be defined as suggested above). So the users need to either go to a designated parking spot (virtual station) or go outside of the zone itself in order to be able to end their trip.

In the current geofencing_zones.json this special kind of zone cannot be expressed or related to any specific parking spot(s).

Summarising (and also hopefully answering @kanagy's question above):

• Defining parking spots using is_virtual_station seems to address the need to express their existence in the spec (our parking spots are generally defined as single lat/long points).
• There is a need to express a special kind of zone that requires users to park at any of the parking spots contained within itself (or outside of it if possible).

[mplsmitch]

@viestat As you said above the parking spots should be defined as virtual stations using either lan/lon or by using station_information.json#station_area ( or both). The parking restriction could then be defined with a geofencing_zones.json clockwise polygon with a rule applied that outlines the parking restriction.

Suppose we define another rule in gefoencing_zones.json like station_parking. This could be used to flag zones where parking at a designated area or station is required within the zone. Making it a Boolean would allow you to be explicit about where it is and is not required within your operating area.

Field Name	Required	Type	Defines
-station_parking	OPTIONAL	Boolean	true Indicates all vehicle types that this rule is applied to MUST only be parked at stations defined in station_information.json within this geofence zone. false Indicates all vehicle types that this rule is applied to MAY be parked outside of stations defined in station_information.json within this geofence zone.

 "properties": {
        "name": "Restricted parking zone 1,
        "start": 1593878400,
        "end": 1593907260,
        "rules": [
          {
            "vehicle_type_id": [
              "Dott-scooter",
              "Dott-ebike"
            ],
            "ride_allowed": true,
            "ride_through_allowed": true,
            "maximum_speed_kph": 10,
            "station_parking": true
            }

Thoughts?

[viestat]

Hello @mplsmitch, thank you for your suggestion!
I think in the proposed approach, the two needs I mentioned above are met (defining the parking spots & expressing station parking).

[ncancelliere]

I like your idea @mplsmitch -- because I am having to try and model similar situations in cities that have designated parking spots. Riders are allowed to park within 100' of the designated spots, and right now there's no good way to express this in GBFS data. We have the larger region denoted {ride_allowed: false, ride_through_allowed: true} since riders can transverse the zone but the they must start and stop at specific locations. I think the combination of virtual parking spots + the station_parking: true attribute would be a way we can then express this type of model in GBFS.

[josee-sabourin]

Closing this due to #349 being opened. Discussion can take place there!

[Giasinit]

@viestat
Hi Andrés,

My name is Yassine and I’m writing to you from Italy to report an issue with the GBFS for Dott scooters.

I’ve noticed that the link https://gbfs.api.ridedott.com/public/v2/Padua/free_bike_status.json returns all the scooters in my city. However, when a user of my app tries to take a scooter, the link that opens in the application, for example, https://go.ridedott.com/vehicles/dcdfc25a-ecca-43f6-be01-1aea46db3e94?platform=ios, only takes the first 5 characters. Since this is a UUID for the vehicle, it prevents the user from quickly accessing the scooter.

Additionally, I’d like to ask what the difference is between the public version and the version with auth bearer.

Finally, I would like to know if it’s possible to integrate the data in order to create a widget with the user’s ride data. What do you think?

Thank you for your attention and I look forward to hearing from you soon.