[EPIC] Routes and groups concepts

[jimakker]

Routes and Groups

Although the concepts of routes and groups are grouped in the same epic, they are different concepts with different functionalities and complexities. But as the two functionalities directly affect both the dispatch dashboard and the way tasks are managed, it is convenient to work both in the same epic.

Both features will modify the UI/UX of the dispatch dashboard.

Groups

The main characteristic of a group is that it is a container of tasks that are created from an excel document. These tasks are not ordered and are usually identical and have a large delivery window.

Groups are interesting as a way to assign floating tasks to riders. That is, tasks that do not have a specific due date/time and can be completed by riders when they see fit.

Dispatch will assign the tasks of a group as it sees fit.

At this stage we are not considering introducing the concept of vehicles into the groups.

Routes

A route is a programmable series of ordered tasks. The main characteristic of a route is its ability to be scheduled in advance. In this way dispatch can prepare efficient routes in advance.

For the route concept to work smoothly we have to introduce the vehicle concept. A vehicle has a defined load capacity and is assigned to a route. By assigning tasks to the route an algorithm will calculate and update the load of the vehicle at each moment avoiding problems, for example, of overloading the rider.

The routing system will be developed on top of the dispatch dashboard keeping the drag-n-drop functionality and extending it to new needs.

Some work has already been done: coopcycle/coopcycle-web#3552

[Paul-Eraman-CoopCycle]

In order to do optimization we will need start and end route tasks, which depending on the use case, is either the office space or maybe a food delivery courier's house, so we would need to introduce that concept.

[txankletix]

It would be desirable for tasks in GROUPS to be visible to multiple riders simultaneously. This way dispatch would not need to allocate drop offs to riders. The use case is a rider with a spare ten minutes between food deliveries looking for nearby drop off points for a magazine.

[txankletix]

Change the name of GROUPS to FLOATING TASKS. This seems like a separate issue/use case which can't be addressed using the way tasks are currently created. A dispatch bot might be a viable alternative.

[Paul-Eraman-CoopCycle]

#3527 check this out @jimakker

[Paul-Eraman-CoopCycle]

and #3230

[Paul-Eraman-CoopCycle]

#1843

[fortyoneandahalf]

It would be desirable for tasks in GROUPS to be visible to multiple riders simultaneously. This way dispatch would not need to allocate drop offs to riders. The use case is a rider with a spare ten minutes between food deliveries looking for nearby drop off points for a magazine.

Floating tasks sounds like an interesting idea for some use cases but is a separate concept to groups. A group is simply a bunch of tasks which are related in some way, e.g. when we import tasks, we have separate imports for different customers, and the tasks for each customer end up in a group in CC, which is useful for the dispatcher because it helps to manage the unassigned tasks list, which in our case can be quite long.

(This might be what @txankletix meant in their follow-up comment, sorry if that's the case and I misunderstood!)

[txankletix]

The point of the comment was to exclude the concept of "floating tasks" from the concept of a "group." It's a different use case with different requirements
.

[fortyoneandahalf]

The point of the comment was to exclude the concept of "floating tasks" from the concept of a "group." It's a different use case with different requirements .

OK, agreed, thanks for the clarification

[Paul-Eraman-CoopCycle]

@fortyoneandahalf

So the two ways i had imagined using a group of related tasks was

• A route
• Floating tasks like @txankletix mentioned

Can you describe the use case for what you are calling groups that explains how is different from those two? Imagining that we have routes, is it a route still being created?

In practice there is no reason why an excel import even need to show up as a group, thats just a design choice that made sense at the beginning

[fortyoneandahalf]

Hi @Paul-Eraman-CoopCycle,

I simply mean that it's useful to be able to have e.g. all tasks from a given customer in a group, which we can then minimise. We have one customer that uploads up to 200 stops at a time, and when I'm dispatching, being able to hide all of those with one click when I'm looking for some other stop in the unassigned list is very useful. Just as a way of managing stops in the unassigned list.

[alexsegura]

Some conclusions after meeting on 26th of June:

• What would be useful for dispatchers, is that tours can be created automatically, out of unassigned tasks. It would save the time and mental effort to prepare tours by drag'n'drop.
• We need to improve the fleet management implementation (#217), because the optimization engine needs to know which vehicles are available, and their capacities.
• It would be useful to introduce a concept of hub/warehouse (i.e, a fixed point on the map), because the optimization engine needs the starting/ending point to create the tours automatically.
• It could be useful to add a layer on the dispatch dashboard with zones, so that the dispatcher can visualize which tasks are belonging to which zones.

[Paul-Eraman-CoopCycle]

I think something we didnt bring up at all is that to do the automatic planning of many routes, we need to integrate with ship planning software or have a way in coopcycle to say what people and bikes are available, and the people in what time frames.

I kind of would like to jump straight into implementing with odoo shift-planning but that wont work necessarily for everyone at the moment so maybe we need something basic inside of coopcycle as well?