对 VehicleRoutingTransportCosts 的不必要的运输距离/时间查询

Posted 2023-02-16

【中文标题】对 VehicleRoutingTransportCosts 的不必要的运输距离/时间查询

【英文标题】：Unnecessary Transport Distance/Time query to VehicleRoutingTransportCosts

【发布时间】：2016-09-30 03:00:53

【问题描述】：

我是使用 jsprit 和 VRP 的新手。我正在设置一个问题，其中车辆需要到多个装运点，然后将货物运送到多个装运点。在这种情况下，我使用了非对称成本矩阵。我不明白为什么 jsprit 仍然从成本矩阵中询问不必要的位置对。此类查询的示例是从货物交付点到车辆起点的运输时间/距离（我还设置了车辆不返回站点）。为什么会这样？我问这个是因为查询到 Google API 的距离矩阵很昂贵，并且每天限制为 2500 个条目（对于开发模式）

【参考方案1】：

这是一个有趣的问题，但我不认为这是一个值得优化的问题。

1) Jsprit 与 graphhopper 合作，已经使您能够自行托管自己的服务器，从而不受限制地提供位置之间的距离和时间。例如，您可以为此启动here，或here。

2）如果您知道距离/时间与您的计算无关，则根本不需要计算任何东西。只需提供虚拟数据。发货的情况下不会用到 --> 仓库设置算法不退回仓库，不用计算。

您总是可以在 github 上提出建议的功能，但我的建议是如果您确定确定绝对是填充虚拟数据，这与仅仅满足系统而不是尝试计算欧几里德距离无关。

至于为什么会发生这种情况，我不能 100% 确定，但我想期待所有数据（一个完整的矩阵）比解析什么是/不是的开销更容易重要的。即使您提供几乎完整的自定义矩阵，它也会故意尝试用欧几里德距离填充空白，这表明情况就是如此。即使是 10,000 次发货和setReturnToDepot(false) 的问题，您也只能自信地从 1 亿矩阵中删除 10,000 个数据点。

【讨论】：

我确实提供了一个虚拟数据。我实现了一个 VehicleRoutingTransportCosts 类，它为这些对返回一个任意大的数字，因此算法不会在计算中考虑这些对。有人提出这个建议让我松了一口气，我的同事一直在说这是一个丑陋的黑客。感谢@roganjosh 的确认！至于graphopper路由机。我确实托管了自己的 graphopper 实例。问题是：我需要交通数据集成，所以我能够获取我所在国家/地区的交通数据，我坚持使用谷歌。

@akiortagem 为了获得虚拟数据，您可以使用很大的圆距，将其加倍并假设时间恒定。这样一来，如果你碰巧在什么重要什么不重要上犯了错误，你就不会完全排除自己的合理解决方案。任意大数据的错误将导致强制使用特定的解决方案，如果它确实被混入其中。至少运行几次作为健全性检查。