Support for carsharing

[josee-sabourin]

Carsharing has become increasingly popular, especially in Europe. With the adoption of dockless bikes and scooters into GBFS, the specification is now able to handle free floating micro mobility services. The fields that exist for dockless micro mobility offer a solid foundation to model carsharing, however they lack the added specificity that a carsharing service would need. This PR aims to model carsharing services by extending vehicle_types.json, station_information.json and system_pricing_plans.json (in addition to already proposed extension of system_pricing_plans.json on PR #252. A google doc of the proposal can be found here.

Some open questions we'd like feedback on (in addition to feedback on the proposal in general):

• Are the enum values (and their definitions) in car_type are representative of the car typology everywhere? If not, how can we make these more all-encompassing
• Should share_type be in vehicle_types.json or system_information.json? The larger question here would be are there services that have more than just one share_type?
• Are we missing any propulsion types?
• Should we add license plate information or a passenger facing vehicle name, and if so, how do we mitigate the threat to traveller safety?
• Should we include an access_methods field in station_information.json that describes how to access a vehicle in instances where payment (i.e. rental_methods) and access are completed separately?

Please let us know what you think! We are very excited about the prospect of expanding to support carshare, however as you can see we still have a lot of questions and we would love to hear from you!

[mplsmitch]

• share_type should go in system_information.json since it refers to the sharing platform, not the individual vehicle. I'm not aware of systems with more than one share type but that doesn't mean we won't see them.
• license plate information or a passenger facing vehicle name should only be used in A-to-A/roundtrip scenarios. Publishing these in free floating schemes would allow the recreation of trips like we saw with bike_id
• rental_methods is problematic because although it's currently defined as "Payment methods accepted at this station" what's listed are a mix of payment methods and fare media. For example when you rent a Bixi you may use an RFID key, or an app on your phone, but with either of these the method of payment is a credit card. I think we need to look at separating the method of payment from the fare media or access method so I would support that addition of a field but it should go in system_information since it would apply to both station based and free floating schemes.
• on propulsion types suggest adding hydrogen fuel cell

[matt-wirtz]

Hello!

Looks like the GBFS should become the silver bullet for all mobility services regarding information.

My concerns so far are of general nature. I think it's perfectly ok to think about opening up a standard in order to incorporate similar products, services or processes. So in the case of the GBFS it looks like the data needs for Apps informing about bike-sharing systems are very similar to scooter-sharing systems. So killing two birds with just one stone and having just one standard API sounds like a good option. And changing the name for the standard to e.g. MMFS (micro mobility feed specification) in order to reflect that change of focus should be taken for granted.

But carsharing includes products with different processes and services. At least in Europe the long standing and mature type of carsharing is the station based carsharing. It's booking functionality where booking targets are reserved for a specific time frame in the future comes with completely different requirements regarding information. Not only the current availability status is of importance but rather the availability in the next weeks or months is important. I don't know what the situation looks like in Asia or America.

So I wonder if it's wise to bloat the specification in order to just incorporate a specific type of carsharing: free floating carsharing. For carsharing software systems that would mean to support at least two different standards just for information - unless they only offer free floating carsharing. Having in mind that there are already standards available covering all types of carsharing like e.g. IXSI.

[Empty2k12]

Lots of great additions. I am reviewing as a provider of GBFS feeds for E-Scooters and station-based e-bikes.

I think some fields are too car-specific and can easily be remodelled, so they can be used by every GBFS feed, not just car-rental fields.

[Empty2k12]

I think this might better be min_range_meters. Together with max_range_meters these values can be calculated by consumers, just like battery / tank percentage can be calculated with max_range_meters and current_range_meters.

[Empty2k12]

I'm not sure if we're too specific about cars here, again. To future-proof, I think it would be ideal to have just hybrid and combustion here and then create a fuel-type enum (diesel, electric, gasoline, LPT, E10, ...)?

[Empty2k12]

This is useful, but should include some more restrictions like

• must be served over https
• CORS * header should be set
• etc

[Empty2k12]

Not to sure if this is too specific about cars again, I could image extending our own scooter and bike feeds with this field, specifying for example if the vehicle has a bell, how many brakes, bicycle basket, etc. Maybe this should just be part of the vehicle_desc field instead?

[Empty2k12]

This should be renamed to rider_capacity, so other feed types (scooters / bikes / vespas) can take advantage of the field.

[josee-sabourin]

Thanks for the suggestion! I made this change in 76097c!

[Empty2k12]

Can this be merged with form_factor? I feel setting form_factor: "car" and car_type: "full_size" a bit duplicated. The fields could be renamed to car_* and then be used like this: form_factor: "car_full_size" or form_factor: "car_suv".

[josee-sabourin]

Hi all! With the input and support of the French CarSharing Association (AAA). Some changes have been made to the PR, notably the added modification of free_bike_status.json in addition to the files mentioned above.

Please let us now what you think!

If you are a carsharing provider : is this proposal able to model your system?

[Miryad3108]

Comment de Vincent SZALENIEC, île-de-France Mobilités:

Changer en obligatoire les champs suivants qui sont importants pour l’utilisateur

· Seating capacity

· Wheelchair accesibility (peut être même réglementaire de l’afficher, à vérifier)

· Step free access

· Service type

· Charging capacity

· Station_type

· Current range

· Vehicle plate

[NicolasFrasie]

From the carsharing point of view (as a producer), and based on comments on the Google Doc, I suggest :

vehicle_type.json

• Add Plug-in hybrid, Liguidgas (Liquefied Petroleum Gas (LPG)) and Naturalgas (Compressed Natural Gas (CNG)) in the propulsion types
• Replace vehicle_desc text field by another field to specify the brand and model of the vehicle.
• As far as I know, Use_conditions should only include age and driving license conditions. Is it possible to make it easier to handle for consumer than a text field ?
• Delete min_fuel_level which don't look necessary for carsharing, considering that fuel is included.
• Add one or two fields to such as Euro_norm and gCO2/km to give the opportunity to consumer to inform when a vehicle can or cannot be used because of air pollution restictions or downtown restictions.
• Add a share_type field as mention in Better clarification of vehicle rental dropoff restrictions requiring station-only dropoffs #270.

station_information.json

• Add a contact_phone of the station (if commercial parking lot or underground parking) to let end users have the opportunity to be helped out if the vehicle cannot be found (customer experience of commercial parking lot isn't designed for people who didn't initially park one's vehicle).
• Add a share_type field as mention in Better clarification of vehicle rental dropoff restrictions requiring station-only dropoffs #270.

free_bike_status.json

• Add a share_type field as mention in Better clarification of vehicle rental dropoff restrictions requiring station-only dropoffs #270.

[stale]

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 60 days if no further activity occurs. Thank you for your contributions.

[schnuerle]

To keep this discussion open, I'm adding a quick FYI comment. MDS is also looking at formalizing our Carshare Support into the next release after feedback from some cities who have been using MDS for carshare. The linked Issue by Ride Report is more about regulations, but some of the regulations connect to vehicle form factor, propulsion type, etc, so we'll be tracking to ensure alignment.

I will also open a new issue on our end to align our propulsion_type with yours, since you've made some updates and additions here in that area.

[schnuerle]

Should this say "Current valid values are:" instead of "Current valid issues are:"?

[josee-sabourin]

Hi everyone, transport.data.gouv and AAA have opened an issue with a more fleshed out proposal and a few alternate approaches in #338, I would suggest moving the conversation there since this PR is now out of date.