search

openmobilityfoundation / mobility-data-specification

A data standard to enable right-of-way regulation and two-way communication between mobility companies and local governments.
https://www.openmobilityfoundation.org/about-mds/
Other
684 stars 231 forks source link

Carshare Support #640

Closed michalnaka closed 1 year ago

michalnaka commented 3 years ago

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:

Describe the solution you'd like

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

Is this a breaking change

Impacted Spec

For which spec is this feature being requested?

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

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):

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

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

avatarneil commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

quicklywilliam commented 3 years ago

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 commented 3 years ago

We've opened up some specific discussion topics here:

schnuerle commented 3 years ago

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

https://github.com/NABSA/gbfs/issues/338

https://github.com/NABSA/gbfs/pull/350

schnuerle commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Clarifying a few items above:

  1. Seattle is GIG Carshare via Populus
  2. 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 commented 1 year ago

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:

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:

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

And conceivably could have:

Or other items I haven't thought of.

schnuerle commented 1 year ago

@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 commented 1 year ago

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:

And MDS should help with:

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

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

bergenklem commented 1 year ago

@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 commented 1 year ago

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.