关于OVERPASS_MAX_QUERY_AREA_SIZE默认值的说明（OSMnx，Overpass API）

Question

我正在使用OSMnx查询Overpass API。 我注意到它对于最小区域尺寸有一个相当大的默认值：

OVERPASS_MAX_QUERY_AREA_SIZE = 50*1000*50*1000

此值用于将“较大”的多边形细分为多个块，以提交给Overpass API。

我想了解为什么面积这么大。 例如，整个旧金山（约50平方英里）被“简化”为一个查询。

关键问题：

1. 减少提交给Overpass API的查询大小是否有任何优势？*

2. 与更复杂的多边形相比，降低提交给Overpass API的形状/多边形的复杂性（即使用仅具有4个角坐标的矩形）是否有优势？**

*注意：我将要运行的示例查询（寻找构成步行网络的方式）：

[out:json][timeout:180];(way["highway"]["area"!~"yes"]["highway"!~"cycleway|motor|proposed|construction|abandoned|platform|raceway"]["foot"!~"no"]["service"!~"private"]["access"!~"private"](37.778007,-122.445467,37.783454,-122.438958);>;);out;

**注意：此问题在另一篇文章中得到部分回答。 就是说，这个问题并没有完全集中在性能影响上，也没有在OSMnx中使用可变面积阈值来细分“较大”几何形状的问题。

Answer 1

max_query_area_size似乎是某人在进行多次测试后得出的启发式值。 从Overpass API角度来看，这个数字本身没有任何意义。

对于不同种类的查询，甚至在与SF不同的区域中，它可能都是完全不可用的。 例如：对于不常用的标记，通常最好使用较大的边界框，而不是使用较小的边界框触发大量查询。

但是，对于某些语句类型，较大的边界框可能会导致更长的处理时间。 在这种情况下，将区域分成较小的部分可能会有所帮助。 某些查询甚至可能消耗过多的内存，这迫使您将边界框分成较小的部分。

由于您没有提到要运行的查询类型，因此很难提供一些常规建议。 这就像在寻求一种提供SQL语句而不提供任何其他上下文的最佳方法。

使用边界框代替（poly：...）具有性能优势。 如果可以指定边界框，请使用相应的边界框过滤器，而不要向多边形过滤器提供4个纬度/经度对。