Structure of the final schedule?

[krashish8]

Currently, the schedule on a calendar looks like this:

It has 2 vehicles with ID 325741509659767145 and 5052215502167391764. Haven't added any location info yet (it is TODO)

Schedule description is like this:

Questions

• What shall be the title of a schedule? - Currently, it is <Type> - VehicleID
• Separate schedule for each vehicle, or a single schedule containing all vehicles? - Currently, it shows a single schedule.
  • Or maybe one API endpoint for complete schedules and another endpoint for a separate schedule of each vehicle.
• How shall the final structure look like?
  • Method 1 (better):
  • Start and End schedule can be of 0 duration (as a reminder): [StartTime, StartTime]
  • Job/Pickup/Delivery/Break can be from [StartTime, StartTime + WaitingTime + ServiceTime]
  • Any empty slot between these schedules can denote the travel of the vehicle.
  • Easy to denote the location on the calendar because every job/pickup/delivery/break has a single location.
  • Method 2:
  • Similar to what is shown currently - duration is from [StartTime, NextTaskStartTime - 1], keeping the entire calendar occupied.

[dkastl]

I think iCal documents become better when they also include some context that the VRP algorithm alone doesn't provide. The additional context could be added through the optional data field, but it's unknown how this data will look like.

How about some kind of iCal "template" support, which will be filled with the scheduler result, enriched with the optional data.

[dkastl]

To add some more questions, schedules can have different perspectives, for example:

• a single driver that wants to have the schedule of a day
• a company that wants to visualize the schedule of everyone
• a schedule of a single job/shipment, for example customers waiting for a delivery or service
• a timetable of a specific landmark, for example a bus stop at a mall or train station

[krashish8]

Does "template" mean that a user will provide the template of how an ical file should look?

I think how to use the optional data field is the main question, otherwise, we can adjust the ical contents according to how we want.

[dkastl]

Yes, a template provided by the user. Not sure how to do this, but in this case the iCal file would be filled the way a user needs it, and custom data can be taken from the data field.

Thinking about this, if we allow users to fill a template document, it could be also something else than iCal, for example an electronic ticket format or a PDF with the schedule.