關於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個緯度/經度對。