Clarification on OVERPASS_MAX_QUERY_AREA_SIZE default (OSMnx, Overpass API)

时间:2018-04-18 18:17:10

标签: openstreetmap networkx overpass-api

I am using OSMnx to query the Overpass API. I've noticed that it has a fairly large default for minimum area size:

OVERPASS_MAX_QUERY_AREA_SIZE = 50*1000*50*1000

This value is used to subdivide "larger" polygons into chunks to submit to the Overpass API.

I'd like to understand why the area is so large. For example, the entirety of San Francisco (~50 sq miles) is "simplified" to a single query.

Key questions:

  1. Is there any advantage to reducing query sizes submitted to the Overpass API?*

  2. Is there any advantage to reducing the complexity of shapes/polygons being submitted to the Overpass API (that is, using rectangles with just 4 corner coordinates), versus more complex polygons?**

*Note: Example query that I would be running (looking for the ways that would constitute a walk network):

[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;

**Note: This question is partially answered in this other post. That said, that question does not focus completely on the performance implications, and is not asked in the context of the variable area threshold used in OSMnx to subdivide "larger" geometries.

1 个答案:

答案 0 :(得分:2)

max_query_area_size似乎是在进行多次测试运行后出现的一些启发式值。从Overpass API方面来看,这个数字本身几乎没有任何意义。

对于不同类型的查询,甚至在与SF不同的区域中,它可能完全关闭。例如:对于不经常使用的标签,通常最好使用相当大的边界框,而不是使用小的边界框触发大量查询。

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

由于您没有提到要运行的查询类型,因此很难提供一些一般性建议。这就像要求一种编写SQL语句的最佳方法,而不提供任何额外的上下文。

使用边界框代替(poly:...)具有性能优势。如果可以指定边界框,请使用相应的边界框过滤器,而不是为多边形过滤器提供4个纬度/经度对。