Carshare Support

[michalnaka]

Is your feature request related to a problem? Please describe.

Background:
Ride Report is working with a variety of carshare operators on MDS and is looking to develop the spec to support carshare specific use cases we have identified.

Use Cases:

• Flexible Rates: Carshare rentals allow users to rent vehicles by the minute, hour, or by days. Currently, MDS Provider shows vehicle rental per minute and API consumers are unable to differentiate between users who selected per minute pricing vs. per day vs. per hour.
• Fleet Info: Carshare providers utilize a variety of makes and models of cars. From sedans to SUVs, from ICE vehicles to electric or hybrid powertrains. All the vehicles have different cargo and passenger capacities. It would be helpful to get a snapshot of a providers fleet mix breakdown, to evaluate the type of vehicles people are utilizing.
• Service Area Exit: The carshare mode inherently offers shared mobility users flexibility to take different length (distance, duration) trips. It would be helpful to get some sort of data about a trip when it exits the service area in privacy preserving manner. Are cars going far away? Are cars going out of the larger metro area? Are cars going out-of-state?
• Vehicle Idle Time: Cars sit idle and take up a substantial amount of space. Cities would like to know how long cars sit idle on the PROW for a variety of reasons: to understand utilization, pricing, loss parking revenue, etc. With MDS Provider we can measure how long a vehicle is sitting based on the unavailable vehicle state, however with carshare a user can rent a vehicle for up to a week at a time and there is no state representing a reserved vehicle that is parked.
• Other Vehicle Data: Odometer data to aid in accuracy of trip metrics and routing.
• Policy: new Policy capabilities that are specific to car share, like parking parking Policy that refers to specific signage (i.e. 2hr zones) instead of just geofences.

Describe the solution you'd like

TBD, We are working on a more formal technical proposal.

Is this a breaking change

• I'm not sure, but this will become more clear as we determine the technical solution.

Impacted Spec

For which spec is this feature being requested?

• provider
• policy

Additional Information

List of some agencies and orgs that are known to have carshare. If you have other add them in the comments. If you are part of these orgs, please leave comments about what data you use or share

1. Transport for London
2. Lyon France
3. Los Angeles - BlueLA
4. Minneapolis
5. Portland with Free2Move via Ride Report, also Zipcar, Turo, Getaround
6. Washington DC, Free2Move, mopeds
7. Austin
8. Seattle Limepods
9. Oakland Gig
10. Minneapolis
11. SFMTA on street car sharing
12. Denver
13. San Jose
14. Companies - Blue Systems, Populus, Inverse, Vulog
15. Most large cities in EU have carshare

[schnuerle]

Thank you for this detailed proposal! We are aware of the need for more formal and detailed car share data support in MDS, and know that some organizations are making MDS work with car share now. Be on the lookout for an announcement of how we are going to convene orgs like yours to discuss this with others who want or are implementing a version of car sharing data. The WGSC will look and see if this could be put on the WG call agenda soon.

[jacob-sherman]

First, I'd like to chime in to say that the Portland Bureau of Transportation fully supports this proposal and hopes the OMF/MDS community can quickly initiate the work to support these carshare specific use cases.

Additionally, I wanted to add another piece of other vehicle data that would be useful is telematics information that could help determine which side of the street a vehicle is parked on. For example, if the vehicle was last headed southbound on a street in the U.S. and then it parked, then the vehicle is likely parked on the west side of the street. This information would be useful for monitoring compliance with policy rules around parking.

[quicklywilliam]

I want to call out that this issue has a relationship to #642. Currently, MDS requires the trips endpoint to return all trips that intersect with the service area, and the entire route including portions outside the service area. This might not be appropriate for car share. It would mean, for example, that a City receives the entire route of my weekend getaway trip that I started via carshare in the city.

[avatarneil]

Re: Vehicle Idle Time

Just adding a quick thought, one state that appears in the prototype Taxi implementation of MDS that I've been working on recently (check out the draft spec here if you're interested) is the stopped state. This state is used when a vehicle is stopped while on a passenger trip (typically when stopping to pick up/drop off a passenger), and I think could absolutely be used to capture idle time for carshare during a reservation!

-- EDIT because I didn't think this warranted another comment --
I'd also love to see carshare functionality added to agency as well, not just provider and policy :)

[schnuerle]

Note that in this GBFS PR there is a modification to vehicle_types.json's propulsion_type field. In its current draft form it has the following values:

• human (Pedal or foot propulsion)
• electric_assist (Provides power only alongside human propulsion)
• electric (Contains throttle mode with a battery-powered motor)
• combustion (Contains throttle mode with a gas engine-powered motor)
• combustion_diesel (Contains throttle mode with a diesel engine-powered motor)
• hyrbid (Contains throttle mode with a mixed gas engine-powered and battery-powered motor)
• hybrid_diesel (Contains throttle mode with a mixed diesel engine-powered and battery-powered motor)
• hydrogen (Contains throttle mode with a hydrogen fuel cell powered motor)

We should consider align these to the existing ones in MDS as well, as part of the work on this feature. We currently have only (though these can be combined, unlike GBFS):

• human - Pedal or foot propulsion
• electric_assist - Provides power only alongside human propulsion
• electric - Contains throttle mode with a battery-powered motor
• combustion - Contains throttle mode with a gas engine-powered motor

Additionally, there is a new car_type field which could be reference or adopted as well (source doc, source PR), eg:

• microcar (smallest size of car, engine smaller than 700cc, e.g Smart Fortwo)
• subcompact (sedan with interior volume index no larger than 99 cu ft, e.g. Kia Rio)
• compact (sedan with interior volume index no larger than 109 cu ft, e.g. Hyundai Elantra)
• mid_size (sedan with interior volume index no larger than 119 u ft, e.g. Toyota Camry)
• full_size (sedan with interior volume index larger than 120 cu ft, e.g. Tesla Model S)
• station_wagon (large cargo area with rear hinged tailgate, e.g. Subaru Outback)
• suv (similar to station-wagon with a light truck frame, e.g. Honda Pilot)
• minivan (also known as multi-purpose vehicle or people mover, e.g. Dodge Grand Caravan)
• pickup_truck (enclosed cab with open cargo area and tailgate, e.g. Ford F-150)
• other

There is also a form_factor field, and an issue discussing many more vehicle types and properties.

[avatarneil]

I love the idea of adopting some more propulsion_types (hydrogen fuel cells!!!), but one thing that I think we could perhaps do away with is the notion of hybrid, because in MDS it's propulsion_type(s) instead of just propulsion_type. You could certainly represent a standard hybrid vehicle with just propulsion_types: ['electric', 'combustion'].

I also wonder if instead of abstracting things to the level of car_type we could perhaps leverage the year, mfgr, and model properties which exist in the Agency API, and include them in the Provider API as well. I can think of a ton of use-cases where having that level of detail is helpful, for example real-time auditing workflows using information gathered by MDS, accurately estimating curb space usage, as well as carbon footprint measurements. Perhaps, we could even explore trying to reference an existing standards body for year/make/model definitions (there's gotta be some officially official enumeration of those combinations somewhere, right)? Of course, we'd still need the classic MDS vehicle_type to stick around to differentiate things too I think (gotta know what vehicle encyclopedia to look in when hunting for make/model in some scenarios I imagine).

Alignment with GBFS is certainly ideal, but this might be one of those places where it makes sense for MDS to contain some more detailed information, different use-cases! IMO, divergence is okay sometimes, and if we want to make that divergence sting a little bit less, we could explore having a formalized translation layer for MDS -> GBFS.

[jacob-sherman]

Another issue we're running into with our carshare implementation is the fact that a user can take multiple "trips" (each with its own trip start, stop, and end) during a single "booking" event. For example, I can "reserve" and then "book" the carshare vehicle and start paying by the minute, hour, day, and within that period of time I can drive to the grocery store for one trip, then take another trip to Home Depot, then go to the garden supply center, and finally drive home, where I end my "booking" and pay. Within that single "booking" event, I could take four or five trips during a two hour period; within a "booking" event of three days, it could be many many more.

I could be wrong, but right now in MDS it doesn't seem we have any capability to associate the "booking" (or "session") parent-event and related children "trip" events. This parent-child and temporal issue would also likely need to be addressed with private for-hire (taxis and TNCs) where the driver would take multiple "trips" during a "shift."

[avatarneil]

@jacob-sherman Fantastic point to bring up! This maps pretty closely to a problem we've run into with Taxi work as well, and really comes down to a philosophical discussion around what a Trip really means. The way we consider a Trip for Taxi is that it's essentially a passenger reservation, and when the vehicle doesn't currently have a pending or active booking, but is still "on shift", it's considered available. The Taxi state machine also accommodates for overlapping trips, which isn't directly related to the issue you raised (for carshare you typically shouldn't have any overlapping reservations/usage), but is worth noting as a point in the "what is a Trip" discussion.

See https://github.com/lacuna-tech/mobility-data-specification/blob/add-taxi-mode/general-information.md#taxi-vehicle-states--events for an idea of how we adjusted things with our Taxi work, if you're curious!

---

I believe that with the awesome work that's being done with Delivery Bots, different portions of a package's journey are considered as separate Trips, and the encompassing Delivery is denoted by a persistent UUID for each package that's on the vehicle.

I think that there's a bit of a tension around what the definition of a Trip should be due to the fact that the construct of a Trip has much more gravity in Provider than it does Agency (at least right now); for Provider, you don't have detailed route information outside of a Trip, while in Agency you certainly could. Additionally, there's the real-time-ness of how that Trip information is conveyed: for near real-time transfer of the Trip information in Provider, it could be seen as preferable to break things up into smaller Trips, because that means that those individual segments will be available in the /trips endpoint sooner than if they were part of one big trip.

For example, if hypothetically I said that the complete journey for a given package on a delivery bot starts at 15:30, and ends at 17:10 and I'm counting it as one Trip, as a Provider API consumer I really wouldn't see any detailed information for that Trip until sometime after 17:10. However, if I segmented that package's journey into different Trips (picking up the package, driving it to the destination), then theoretically I could start seeing some of that information sooner for the first Trip.

---

At the end of the day, I think we probably need to discuss what a Trip really is in a WG call. In my mind, it's really a chunk of time that some party is paying for and the vehicle is 'in use' by them (I personally consider a carshare vehicle which the customer is not driving to technically be in use by them still, ergo still on a Trip). I think that our existing API limitations (namely, that for a Trip only minimal information is available until the Trip is completed) trend thinking towards segmenting Trips into the smallest chunks possible; but, I am a little concerned that we may get into hierarchical plinko with that. First it's delivery_id, then booking_id, then shift_id, etc... in order to link together multiple 'trips' that happened during paid activity for a vehicle. Then, we discover a need to have extra metadata associated with each of those higher-level concepts, and we end up getting a bunch of new endpoints specifically tied to use-cases, ick!

I'd like to play out the thought experiment of having a Trip be "a chunk of time the user is paying for" or "a booking" or "a delivery" (all the same, in essence), and think about ways we could extend our existing APIs to more proactively communicate information about ongoing Trips and their segments prior to them being completed.

[quicklywilliam]

In discussion of #643, it came up that it would be useful to carshare to be able to better understand fuel consumption of different trips, particularly in mixed-fleet (ICE / electric) environments. In particular

• Adding a tank_pct field or generalizing the battery_pct field to support fuel tanks. This seems pretty straight forward
• Adding battery/tank capacity information to MDS. This generated quite a bit of discussion about the complexity and validity of calculating carbon emissions using MDS data.

[quicklywilliam]

First, I'd like to chime in to say that the Portland Bureau of Transportation fully supports this proposal and hopes the OMF/MDS community can quickly initiate the work to support these carshare specific use cases.

Additionally, I wanted to add another piece of other vehicle data that would be useful is telematics information that could help determine which side of the street a vehicle is parked on. For example, if the vehicle was last headed southbound on a street in the U.S. and then it parked, then the vehicle is likely parked on the west side of the street. This information would be useful for monitoring compliance with policy rules around parking.

Just wanted to note that vehicle heading information is being addressed by #653.

[jfh01]

We've opened up some specific discussion topics here:

• Vehicle Attributes: What vehicle attributes are important to track for car sharing? #657
• Parking: How to track parking on public rights of way? #656
• Reservation/Trip Phases: What phases of a car share reservation / trip are we interested in tracking and why? #655

[schnuerle]

Some traction on vehicle properties around carshare at these issues/PRs in GBFS:

MobilityData/gbfs#338

MobilityData/gbfs#350

[schnuerle]

Noting that GBFS work is now approved in latest version. Here are propulsion_types: https://github.com/NABSA/gbfs/blob/master/gbfs.md#vehicle_typesjson

Vehicle_types updated too now form_factor. https://github.com/NABSA/gbfs/blob/master/gbfs.md#vehicle_typesjson

Lots of optional vehicle properties possible now too.

Car_types still in draft.

[schnuerle]

We are working hard to add Careshare as a new mode in MDS 2.0, with a big focus on this in September's Modes Month.

There is a Task Force with a mailing list where we are working on adding what's needed to MDS for carshare. If you are an OMF member, there is also a Carshare Member Network you can join.

On September 29 we will doing a deep dive in our public meeting about Carshare, so please attend. In the meantime leave your use cases and ideas here as a comment!

Here is who we know of operating careshare now, and some are using a form of MDS for this. If you have other add them in the comments. If you are part of these orgs, please leave comments about what data you use or share

1. Transport for London
2. Lyon France
3. Los Angeles - BlueLA
4. Minneapolis
5. Portland with Free2Move via Ride Report, also Zipcar, Turo, Getaround
6. Washington DC, Free2Move, mopeds
7. Austin
8. Seattle is GIG Carshare
9. Oakland and Berkeley GIG Carshare via Populus
10. Columbus
11. SFMTA on street car sharing
12. Denver
13. San Jose
14. Paris
15. Madrid
16. Companies - Blue Systems, Populus, Inverse, Vulog
17. Most large cities in EU have carshare

[mobilitygirl]

Clarifying a few items above:

8. Seattle is GIG Carshare via Populus
9. Oakland and Berkeley GIG Carshare via Populus

Carsharing is where MDS and CDS begin to converge — at least the way Populus treats the data and the key use cases of the cities we work with.

Most original city carsharing permits required that operators pay for the on-street parking that they utilize based on existing parking policies. For Populus and the cities we validate on-street parking for, this has been a great testing ground for GPS-based parking payment (that can then pave the way for digital curb management).

[alexdemisch]

SFMTA's On-Street Car Share Program dedicates curb spaces for car share vehicles. These are for the round-trip car share model where the vehicle is picked up and dropped off at the same parking space. Since carsharing helps reduce household vehicle ownership and the car sharing companies can’t find off-street spaces to use across the city, dedicating on-street spaces helps support the use of carsharing in SF. We require a monthly aggregated report that provides the following metrics by each on-street space:

• Permit ID. Unique identifier for the on-street car sharing space; refers to VSO, location, permit issuance date, permit expiration date, and other information associated with the permit.
• Year. Each record must indicate the year of the data collection
• Month. Each record must indicate the month of the data collection
• Month Hours. Total number of hours in that particular month
• Hours of operation Total number of days the on-street space was available for VSO use
• Operating rate. Percentage of time the vehicle was in operation; formula measured as = (Hours of operation)/(Month hours)
• Days of closure. Total number of days the on-street space was closed for a construction permit
• Total reservations. The monthly total number of car share vehicle reservations completed for the on-street space; every reservation completed will be interpreted as a trip taken by the car share vehicle.
• Reservations per day. Daily number of trips made through the day; formula measured as =(Total reservations)/(Days of operation)
• Total reservation miles. Total distance traveled, in miles, by the car share vehicle(s) occupying the on-street space
• Average miles per reservation. Monthly average number of miles traveled per reservation; formula measured as =(Total reservation miles)/(Total reservations)
• Total reservation hours. Total hours that the on-street space's car share vehicle was in use for the month, rounded to the nearest quarter hour
• Average hours per reservation. Average duration, in hours, of each car share trip taken, for the month
• Total hours of operation. Total hours that the car share space was in operation for the month; formula measured as =(Days of operation)*24
• Monthly utilization rate. Share of total hours that the car share vehicle was in use out of the total hours of operation; formula measured as =(Total reservation hours)/Total hours of operation
• Unique reservers. Total number of unique members who used a car share vehicle at the on-street space; indicates how many individuals benefited from the car sharing space
• Notes. Describe any relevant events that would affect your reservation or utilization levels e.g. "vehicle offline for 2 days due to an attempted theft/necessary repairs"

Another flavor of this is our Shared Electric Moped Parking Permit Program. We are meeting many of this programs needs through MDS already, including the Vehicles, Status Changes and Trips endpoints. We also receive a monthly report with:

• Average Daily Rentals. Number of reservations per day
• Average Daily Users. Number of unique users per day
• Average Daily Movement. Number of “people trips“ that takes into account if there was a passenger on the trip
• Average Operational Vehicles. Average number of mopeds in service for the month
• Distance Average. Average distance of all reservations for the month
• Duration Average. Average time of all reservations for the month

It seems like we could beef up the reports endpoint to meet the aggregate monthly reports. Note that both of these programs are parking permit programs. While we're interested in trips in the aggregate to know about curb use and general utilization of the services, we're not interested in the routing of each trip and have disallowed trip routing in our permit language and Requirements file.

[schnuerle]

SFMTA's On-Street Car Share Program dedicates curb spaces for car share vehicles. These are for the round-trip car share model where the vehicle is picked up and dropped off at the same parking space. Since carsharing helps reduce household vehicle ownership and the car sharing companies can’t find off-street spaces to use across the city, dedicating on-street spaces helps support the use of carsharing in SF.

This is a good scenario of how CDS 1.0 could collect some of this data now in SFTMA @alexdemisch. Since there are on-street ROW parking spaces for the carshare, each of these spaced could be a CDS Curb Zone using the Curbs API. Then the company could send CDS Events API data when a car enters or leave one of the zones. This CDS data could be a subset of the report data a city needs, and MDS 2.0 could make up the rest (distance, duration, reservations).

[beckyedmonds]

New here so not sure I'm doing this right but want to be clear that here in Seattle we have GIG car share but we directly ingest it into our own data warehouse, not with Populus. Also no more LimePods.

Also - one thing I don't think I'm seeing is that we do have another type of car share - Zipcar - where they reserve a specific parking space. Currently we don't track anything about these trips and don't get any data from them. Maybe an application of CDS.

We are working hard to add Careshare as a new mode in MDS 2.0, with a big focus on this in September's Modes Month.

There is a Task Force with a mailing list where we are working on adding what's needed to MDS for carshare. If you are an OMF member, there is also a Carshare Member Network you can join.

On September 29 we will doing a deep dive in our public meeting about Carshare, so please attend. In the meantime leave your use cases and ideas here as a comment!

Here is who we know of operating careshare now, and some are using a form of MDS for this. If you have other add them in the comments. If you are part of these orgs, please leave comments about what data you use or share

1. Transport for London
2. Lyon France
3. Los Angeles - BlueLA
4. Minneapolis
5. Portland with Free2Move via Ride Report, also Zipcar, Turo, Getaround
6. Washington DC, Free2Move, mopeds
7. Austin
8. Seattle is GIG Carshare via Populus
9. Oakland and Berkeley GIG Carshare via Populus
   10 Columbus
10. SFMTA on street car sharing
11. Denver
12. San Jose
13. Paris
14. Madrid
15. Companies - Blue Systems, Populus, Inverse, Vulog
16. Most large cities in EU have carshare

[schnuerle]

Also - one thing I don't think I'm seeing is that we do have another type of car share - Zipcar - where they reserve a specific parking space. Currently we don't track anything about these trips and don't get any data from them. Maybe an application of CDS.

Thank you @beckyedmonds so much for your reply, you are doing everything right!

For GIG into your data warehouse, could you provide in a comment (or edit your first comment) the data fields you get, and some of your use cases for that if have that available?

Your Zipcar scenario sounds like SFMTA's example above. You could use CDS to define the designed parking spaces as curb zones, then have Zipcar send 'event' data when a vehicle is using one of the spaces. That way you'd at least know where and when things are happening, and maybe some info about the vehicle. Let us know if you'd like to explore that further.

You could also ask for MDS 2.0 with carshare from Zipcar, and ask for some specific fields or attributes that you may need for regulation or policy.

[RyanMcCann-DOTI]

CarShare_MDS- Use Cases_RM.xlsx

2022 Car Share Op Survey.docx
Looking forward to today's discussion! Attached are some uses cases Denver has provided ride report in past + some survey questions we administer annually to operators. The survey has been used since 2013 and is intended to demonstrate the success of the program and meeting goals to reduce parking demand, reduce vehicle miles traveled and enhance mobility options for car share members. Aside from the attachments, interested to see how MDS can be used to demonstrate linked trips between micromobility, bus/transit, etc.

[PeterSP]

@schnuerle Regarding seasonal/removable equipment, as mentioned in today's working group call, I am aware that ride share vehicles can have:

• Snow shovels
• Snow/ice brushes
• A car-roof bike rack
• Access pass to a national/regional/municipal park system
• Toll transponder for national/regional toll system

And conceivably could have:

• Phone holder
• Sunshade (i.e. for windshield)

Or other items I haven't thought of.

[schnuerle]

@schnuerle Regarding seasonal/removable equipment, as mentioned in today's working group call, I am aware that ride share vehicles can have:

Hi @PeterSP I've added these options in the car share feature branch draft. https://github.com/openmobilityfoundation/mobility-data-specification/blob/feature-car-share/modes/car-share.md#vehicle-attributes

[schnuerle]

CarShare_MDS- Use Cases_RM.xlsx 2022 Car Share Op Survey.docx

Hi @RyanMcCann-DOTI for your use case list in Denver DOTI, MDS should be able to support:

• VMT by vehicle type (ICE, hybrid, EV)
• vehicle distribution
• carshare vehicles parked in rush-hour zones
• dynamic geographies
• trips by time of day
• trips by distance
• routes of trips
• origins/destinations
• available carshare vehicles
• idle time, time parked, vehicle not used
• Restricted area rides; spaces, blocks and or streets closed to vehicles

And MDS should help with:

• system stats

For these use cases, MDS may be able to wholly or partially help, but you may also need additional information from operators and customers:

• registered car share users by zip code
• annual program membership
• air quality index and car share vehicle usage
• resident and/or program complaints
• carpool
• info on vehicle fleet and diagnostics
• injury investigation

Since the survey is mostly qualitative, only a fraction of the data will be available in MDS. You will still need to survey your residents to get answers to most of your survey questions.

[schnuerle]

SFMTA's On-Street Car Share Program dedicates curb spaces for car share vehicles. These are for the round-trip car share model where the vehicle is picked up and dropped off at the same parking space. Since carsharing helps reduce household vehicle ownership and the car sharing companies can’t find off-street spaces to use across the city, dedicating on-street spaces helps support the use of carsharing in SF. We require a monthly aggregated report that provides the following metrics by each on-street space:

@alexdemisch Permit ID will be covered with MDS by permit_licence_number in trip attributes. Some of the other fields too like year, month, date/time info. The details about the on-street space may not be directly known, but could be calculated if only one operator fleet is allowed to use it. MDS data would tell you when a vehicle was in the spot based on GPS, and by inference when no vehicle was there, allowing you to calculate the rest.

This could be a chance to add a curb_zone_id optional field to trip attributes, that specifies if a trip ends in one of your defined CDS curb zones. You would define each car share parking area as a CDS Curbs API zone. What do you think? Would allow you to use that instead of just GPS location points.

Another flavor of this is our Shared Electric Moped Parking Permit Program. We are meeting many of this programs needs through MDS already, including the Vehicles, Status Changes and Trips endpoints. We also receive a monthly report with:

These items in the monthly report could all be calculated using MDS data. So I'm not sure you would need these in the monthly Provider Reports too?

While we're interested in trips in the aggregate to know about curb use and general utilization of the services, we're not interested in the routing of each trip and have disallowed trip routing in our permit language and Requirements file.

You can certainly disallow trip routes as part of MDS Requirements.

[schnuerle]

I'm going to work on incorporating more feedback from our car share working group meeting next.

1. How do we reconcile and connect trips across MDS modes
   • I don't think this can be solved yet in MDS 2.0. We should look at this again once modes are up and running and see what coordination options make sense
2. Comment in github -- Where operators in warehouse, how do we track that either trip type and event and level of details
   • Need ideas from working group on how to add this to spec - new fields or guidance?
3. EVENTs to add: REMOTE START and REMOTE END
   • added to draft PR as remote_start and remote_end events
4. HOW TO ADD CHARGING EVENTS to the STATE or EVENT?
   • added to draft PR as charging_start, charging_end, fueling_start, fueling_end events
5. Break into two fields to show electric battery percent and fuel percent and fuel capacity
   • added battery/fuel percent/capacity to Agency and Provider were applicable, updating existing battery_pct float field to battery_percent integer 1-100 field.
6. Name fields 'fuel' and 'battery' for clarity
   • Done
7. Add separate exit and explicit fees (see passenger services)
   • Added similar to passenger services

[schnuerle]

Based on our public working group meetings during Modes Month, and the feedback from the working group on GitHub, we now have a draft of the Car Share mode in MDS for you to review and provide feedback on.

1. Review the draft here in this new feature branch.
2. Review the comments, action items, and actions taken from the last working group meeting.
3. Leave general comments on this open issue #640.
4. Leave inline and detailed comments on the specific changes in pull request #797.

We will likely be talking about this and other modes at our working group meeting on November 10.

[alexdemisch]

This could be a chance to add a curb_zone_id optional field to trip attributes, that specifies if a trip ends in one of your defined CDS curb zones. You would define each car share parking area as a CDS Curbs API zone. What do you think? Would allow you to use that instead of just GPS location points.

This sounds great! Using CDS for this makes sense since curb use is ultimately what we're interested in, not the trip.

Another flavor of this is our Shared Electric Moped Parking Permit Program. We are meeting many of this programs needs through MDS already, including the Vehicles, Status Changes and Trips endpoints. We also receive a monthly report with:

These items in the monthly report could all be calculated using MDS data. So I'm not sure you would need these in the monthly Provider Reports too?

True, although I don't know how we'd get unique users. The daily person movement metric may be a moped-specific item since our operator Revel can tell us if there is a second person on the trip since they need to register separately.

[schnuerle]

Thank you all for your work on this new mode for MDS 2.0! Most updates happened in #797.

[bergenklem]

@schnuerle - Would like to reopen this issue to address your previous post about adding car types:

Additionally, there is a new car_type field which could be reference or adopted as well (source doc, source PR), eg:

• microcar (smallest size of car, engine smaller than 700cc, e.g Smart Fortwo)
• subcompact (sedan with interior volume index no larger than 99 cu ft, e.g. Kia Rio)
• compact (sedan with interior volume index no larger than 109 cu ft, e.g. Hyundai Elantra)
• mid_size (sedan with interior volume index no larger than 119 u ft, e.g. Toyota Camry)
• full_size (sedan with interior volume index larger than 120 cu ft, e.g. Tesla Model S)
• station_wagon (large cargo area with rear hinged tailgate, e.g. Subaru Outback)
• suv (similar to station-wagon with a light truck frame, e.g. Honda Pilot)
• minivan (also known as multi-purpose vehicle or people mover, e.g. Dodge Grand Caravan)
• pickup_truck (enclosed cab with open cargo area and tailgate, e.g. Ford F-150)
• other

Use cases:
1 Insight into how different types of cars are being used (in combination with duration, mileage and so forth).
2 Tenders and allocation of reserved spots - give possibility to award companies with wanted mix of car types in their fleet (in our case; we prefer companies with wide range of car types in their fleet when we assign reserved parking lots in neighbourhood areas - not just vans). This has also been used as an family friendliness-indicator in some cities in EU.
3 Control - some of our reserved parking lots have requirements on type of cars they can place there (e.g. in streets to narrow to allow parking for big/wide cars)

[schnuerle]

Hi @bergenklem Could you put your most recent comment into a new issue? I'm not going to reopen this one as it was a general issue about how to support car share in MDS, which we've now done with 2.0.

The addition of car type distinctions is a great idea, just needs a new issue for good discussion!

Note that we do have new fields now for vehicle year, make, model. That can be used to determine not only car type categories, but also things like vehicle weight and size.