VRPLIB v2

[leonlan]

This issue keeps track of plans for a new major release of VRPLIB. This is a long-term goal and will be developed in parallel with the needs of PyVRP.

vrplib (v1) was originally designed to support any kind of free-form VRPLIB instance, mainly because the VRPLIB format was not well defined. Its main use cases were reading the instances for the CVRP X-instances, the VRPTW EURO-NeurIPS instances and some of the LKH-3 instances.

PyVRP is continuously adding support for new VRP variants and we are extending the VRPLIB format to support this. At some point, we will have a large collection of VRPLIB instances and a better-defined format.

---

In view of these developments, I propose the following todos for the next major release:

• [ ] A well-defined VRPLIB format for many VRP variants. Basically https://pyvrp.org/dev/supported_vrplib_fields.html combined with the current README.
  • [ ] https://github.com/PyVRP/VRPLIB/issues/94. We should probably not supersede TSPLIB95, because it contains a lot of specifications that are just not relevant. But we should definitely take inspiration from TSPLIB95.
    • Idem: LKH-3 has introduced extensions to the TSPLIB format that we should also have a look at.
  • [x] https://github.com/PyVRP/VRPLIB/issues/108.
  • [ ] https://github.com/PyVRP/VRPLIB/issues/111. A common annoyance in benchmarking is how to deal with rounding conventions. This should be better defined.
  • [ ] This VRPLIB format definition can be version-controlled and could evolve together with the vrplib package.
• [ ] Reading instances and solutions should return a Instance or Solution object with well-defined VRPLIB attributes.
  • [ ] It would be nice to keep a flexible way of reading VRPLIB instances with undefined specifications/sections, so that we can easily extend the VRPLIB format.
  • [ ] https://github.com/PyVRP/VRPLIB/issues/99. If we have a well-defined format, we can also validate if an instance is VRPLIB-style or not.
  • [ ] We can switch over to a parsing grammar like lark or pyparsing.
• [ ] Maintain a library of VRPLIB instances
  • We already do this in PyVRP/Instances, but we only keep selected instances for benchmarking. There are many more VRPLIB instances that I have created that we don't have a place for anywhere. It would be nice to have these stored somewhere as well for others to use.
• [ ] Drop support for downloading instances. This is a legacy feature that originated from when this package was called cvrplib.
• [ ] Read/write should be a no-op, meaning that when you read an instance and then write the instance, then this give precisely the same instance again.
• [ ] Drop support for Solomon instances.
• [ ] Return Python data structures instead of numpy arrays. Only keep numpy arrays for the distance matrix. This follows from #108, where the ragged arrays cannot be easily returned as numpy arrays.
• [ ] Do not normalize indices. This currently happens in DEPOT_SECTION, where we subtract -1. This is inconsistent with the other data.
• [x] Do not allow data to be specified both as specification and section (#120).
• [ ] Write solution should allow empty routes.