Food Delivery Data Specs

[bostonsam617]

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:

1. while engaged in traveling on the way to pick up an Order;
2. while picking up an Order from a food service establishment;
3. while engaged in traveling to deliver an Order; or
4. 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

[schnuerle]

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.

[pierre-bouffort]

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.

[jlynch-pdx]

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.

[schnuerle]

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

[bostonsam617]

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