openmobilityfoundation
Food Delivery Data Specs
Is your feature request related to a problem? Please describe.
The City of Boston wants to collect delivery app trip data from the major delivery app companies.
Describe the solution you'd like
The City of Boston wants delivery app companies to be able to provide:
i. a unique ID number for each Order;
ii. the type of Vehicle used for each Order;
iii. the power source of the Vehicle used, including but not limited to whether the Vehicle is propelled by internal combustion, battery-sourced electricity, or is a hybrid;
iv. the name, address, longitude, and latitude of the vendor from which the delivery Order originated;
V. the 15-digit FIPS Code for the census block to which the Order was delivered;
vi. the distances traveled, in increments of 1/10 of a mile, (A) between Order acceptance and arrival at the vendor, and (B) between the vendor and the delivery location;
vii. the date and time of the origination and termination, calculated to the nearest minute;
viii. the total time, in minutes, that
(A) the Operator spent between Order acceptance and arrival at the vendor, (B) the Operator spent stopped at the vendor waiting for the Order, (C) the Operator spent driving to deliver the Order, and (D) the Operator spent delivering the Order; and ix. if multiple Orders were picked up or delivered by the Operator during the course of this delivery (e.g., by multi-restaurant ordering or batching), a list of ID numbers (as defined in subsection (a)(i) above) for other Orders that were combined with this Order.
AND
i. the total number of Operators that utilized the Provider's digital network within specified geographic areas and time periods and broken out by mode of transportation as determined by BTD;
ii. the total time spent and total miles traveled by Operators in such geographic areas or time periods as determined by BTD:
- while engaged in traveling on the way to pick up an Order;
- while picking up an Order from a food service establishment;
- while engaged in traveling to deliver an Order; or
- while delivering an Order to the buyer.
Is this a breaking change
- non breaking for 2.1, could do more and make it breaking in 3.0
Impacted Spec
For which spec is this feature being requested?
-
provider -
agency
Describe alternatives you've considered
We looked at passenger delivery and robot delivery. We expect to need elements of both.
Additional context
Attached is the full text of the new City of Boston Ordinance
Road Safety Ordinance - City of Boston.pdf
It looks like MDS already supports almost all of this, using trips, stops, events, and telemetry endpoints in Provider/Agency.
The "viii. the total time, in minutes" breakdown may be a bit tricky. Might have to add some more event types for some of this, but it may be that the existing trip info and vehicle states already allows you to calculate this clearly.
The "V. the 15-digit FIPS Code" is also a bit tricky, but "Geography Driven Events" in MDS was made for this - a way to use a specific area, instead of an exact GPS point. But there are a lot of census blocks in Boston that would need to be defined (over 30,000), so instead we may need to add a new field like census_block or something more internationally appropriate.
-
Could be a new field called ‘statistical_area_start_id’, ‘statistical_area_end_id’, ‘statistical_area_name’ (a string, optional) for trip end and start. This can be US census area ids (tract, block group, block, etc), Canadian dissemination blocks or areas, UK output areas, etc, or any other pre-defined standard district, area, sector, etc. Note if an agency would like to use custom geographic areas, they can be still be defined with the Geography API and Geography Driven Events.
-
Or is all of this just captured in Events instead, using GDEs? Though GDEs are UUID only. So could be a new field in Events ‘statistical_area_ids’ array? Details of what this ID is, like name, source, and type of area, would be communicated between public agency and operator outside of MDS, like how Boston says they are census block ids in the ordinance.
Other things we may need for Boston and other cities are new trip fields, like payload/cargo type, order vs delivery language, mobility hub support (gets at transfer times, rates, etc). That would be additions to state machine.
We almost created a Delivery mode with MDS 2.0, but backed off and made it more simple and specific to just Delivery Robots. There was a draft PR for this from Blue Systems.
So there was a need for this a few years ago, and now that we have Boston with an ordinance and other cities like LADOT, Portland interested, and NYC (microhubs, transfer hubs for private companies, like a large loading zone with facilities) and Chicago talking about the need for delivery data, we could work this into MDS 2.1 as a non breaking change, then rename the mode to 'Delivery' and add more features in a future MDS 3.0.
Love to see an issue being posted about this. I am in line with the vast majority of what is said in there. And I think from what I can read, that relying on our existing vehicle, trips and events objects will cover a large portion of the need expressed by Boston. We are talking to many of our customer cities about helping them with the delivery mode, so I am excited top contribute here. Ithink we should look at the delivery environment as a whole. For both food and parcel delivery.
I think one aspect that we cannot neglect when talking about delivery is that orders are typically pooled. Meaning one trip will not only deliver one parcel. In the same way that it may not deliver to one address and go back to the warehouse immediately, but rather deliver to a few addresses before doing so.
Therefore, I think one very interesting piece of information we could add in there would be to have the number of parcels/individual orders carried by the vehicles for each of their trips. This way we could see the vehicles being filled and emptied along their journey and better understand usage there. Also, as many cities are working on transfer of parcels from regular combustion vans to more eco-friendly modes, this information of the number of parcels/individual orders in the vehicle would help in getting a sense of the volume transfer when switching the delivery vehicles being used.
I would agree with @schnuerle, that it seems like MDS currently captures most of what would be needed for a Delivery mode already. One thing that could be missing is a category for the contents of the delivery. While the collection mechanism is very different for Colorado and Minnesota (relying on companies reporting their delivery data on sales tax schedules, rather than collecting per-trip details), they both have several categories of goods that are exempt from their delivery fees. I could see this expanded in other jurisdictions that are relying on MDS to track and manage delivery details. There may be different regulatory requirements depending on whether the goods being delivered was a burrito, the ingredients to make a burrito, or a book about burritos.
Perhaps adding a new key value pair to trip_attributes for a delivery_type field with enumerated values (examples only, this list is not exhaustive):
prepared_food
grocery
medication
alcohol
parcel
As we’ve been thinking about this here in Portland, we had a question about how MDS will handle things where a delivery trip overlaps with a passenger trip. These are currently two separate modes, and unless there was intentional sleuthing being done, I imagine the overlap wouldn’t be known. Is this a concern in other jurisdictions? It’s more philosophical for us and not an explicit concern, but it has been brought up a number of times in our discussions, so I thought it would be worth mentioning.
Summary based on conversations with LADOT reps:
Interested in fields that Portland and Boston have listed.
Driver types and autonomy type (full autonomy, partial autonomy, remote driver/human intervention)
- Timestamp of remote driver/human intervention
- Purpose of remote driver/human intervention (safety override e.g. obstacle encounter like debris, vehicle, or pedestrian, or blocking of emergency vehicles, remote assistance e.g. in geofenced zone)
- Number of times remote driver/human intervention was needed on trip
- Duration of remote driver/human intervention
- Not sure if it would make sense to know if the delivery was autonomous or pilot driven
Number of deliveries per trip
- How many deliveries is a single device making on a single trip (currently it is one-to-one but there has been expressed interest in a single device doing multiple deliveries)
- What would the fields look like for a multi-delivery trip?
- Would there be a binary field like is_multi-trip? And if yes, then a single trip_id but different details on cargo type, start/end coordinates, etc
- How many deliveries per location
- Would there be a binary field like is_multi-trip? And if yes, then a single trip_id but different details on cargo type, start/end coordinates, etc
- How many locations
Integration with Policy API. What is Policy API that is a unique delivery space.
- Density, how many is too many or not enough in PROW, what is efficiency/high utilization, and what data points best answer these questions already within the MDS/CDS space.
- Should delivery bots still be allowed to make deliveries during special events to assist restaurants if vehicles are not allowed to enter during these events?
Knowing origin of delivery (ghost kitchen, individual restaurant, retail store, private delivery-courier)
Device status (on trip, idle, charging, maintenance, offline, error) Main thing is we don’t want devices idling in the PROW in between trips.
Device maintenance details
- Last date of physical maintenance
- Device model
- Last date of software maintenance
- Software version device is running on
- Reason for maintenance or maintenance type (routine, repair, upgrade)
Great Q from @mschwartzie : How does the proposal want to work out the fact that the beginning of a chained trip (journey) is also the end of the previous trip? Kind of negates the privacy approach of having the trip ends relate to geographies rather than lat/longs
FYI we talked about this at the last MDS public working group meeting. Slides, recording, notes, action items, links, etc available now.
Action items from the meeting:
- Are Incidents enough to track "unsafe and illegal operations by delivery drivers - i.e. speeding, illegal turn, double-parking, etc." - may need more incident types, like CDS Enforcements and Violations
- Added Enforcement and Violation as an option as part of Incidents. See this commit
- Clarify that shifts are made up of journeys, journeys made up of trips. Trips could have multiple orders, orders could have multiple packages.
- Done, see commit
- Shift_id allows chaining of journeys. Is this the right name (some term bigger than a journey for freight solution), or is there another additional field needed? Done, with same commit, added route_id.
- Might need an array of package/orders details (delivery type, order_id, costs).
- Done, see commit
- Digital policy - how does MDS Policy support density? Eg cap on number of vehicles in an area. New policy type needed?
- MDS Policy already supports this with Rules and rule types. You can specify a max count of vehicles in any state (eg. on trip or stopped) for any defined geography.
- Statistical areas - Change to array from string? Is there only one area per event?
- Yes this was meant to be an array. Clarified with this commit.
- If you want a statistical area for an end, but lat/lon for a start, how do you account for privacy? What change in spec could support this?
- The only solution may be to not know the start location, and use statistical area instead. Ordinance issue? Use lat/lon but round to 2 decimal places (about 1.1km)?
We will be talking about this at the public working group meeting tomorrow. Please review the draft solutions of the action items from the last meeting, which we will review.
@schnuerle - for the shift update - can shifts be defined by hours vs just journeys? I don't have a great example of how we would use that info, but I know we talk about where drivers congregate from time to time, and wondering if that's something we would want to rely on MDS for in the future. We should still make this change but logging for the future
@bostonsam617 Based on the trips taken by a driver, and using the unique driver_id field, you can sum up the hours worked by drivers while on trips of any type. You may also use this ID in conjunction with the operator to get full hours worked outside of trips by this driver based on the ID. See Trip Attributes. But MDS currently doesn't have direct info about drivers, like the specific hours worked or total time on shifts, since MDS focuses on the vehicles and their movement and properties in the right of way. We can talk about other possible options for this, like maybe resting or loading trip types?
Per the needs of Boston, I added an optional pickup_location_name field in trip attributes. And for NYC's delivery efficiency calculation metrics, added optional parcel_count to both trips and orders. See changes here.
I'll be closing this issue and merging the work in pull request #959 to our MDS development branch later today.
If you have any remaining concerns, let me know in a comment here. The release still has a few weeks/months so we can incorporate more changes as needed before then with a new Issue/PR.
Thanks everyone for your work on adding Delivery to MDS!