Right now the geojson_to_quadkey function in download_buildings keeps zooming out until it hits a quadkey that completely encompasses the area. This can lead to some very big quadkeys if the area to query straddles a big quadkey - I hit one area in italy that was getting like a level 4 quadkey.
It'd be much better if we didn't make big scans. It seems like one route to do this would be to allow for more than one quadkey. The function seems like you could adjust the cut off for number of tiles to be more than one:
for zoom in range(12, -1, -1):
tiles = list(mercantile.tiles(min_lon, min_lat, max_lon, max_lat, zooms=zoom))
if len(tiles) == 1:
return mercantile.quadkey(tiles[0])
So this migh tbe simple, to just try to get a bigger list. I think we probably don't want to return a huge list, so maybe just when it gets to be covered by 4 or 10 quadkeys. Probably worth some experimenting on query times with different combinations - the parquet partition might have increased overhead to query a lot of different options, so maybe just looking for 2 makes sense. But even just 2 seems like it'd likely help in cases where it just straddles a huge quadkey.
There's perhaps some other technique that could be done here, to get the biggest one and then scale down.
Right now the geojson_to_quadkey function in download_buildings keeps zooming out until it hits a quadkey that completely encompasses the area. This can lead to some very big quadkeys if the area to query straddles a big quadkey - I hit one area in italy that was getting like a level 4 quadkey.
It'd be much better if we didn't make big scans. It seems like one route to do this would be to allow for more than one quadkey. The function seems like you could adjust the cut off for number of tiles to be more than one:
So this migh tbe simple, to just try to get a bigger list. I think we probably don't want to return a huge list, so maybe just when it gets to be covered by 4 or 10 quadkeys. Probably worth some experimenting on query times with different combinations - the parquet partition might have increased overhead to query a lot of different options, so maybe just looking for 2 makes sense. But even just 2 seems like it'd likely help in cases where it just straddles a huge quadkey.
There's perhaps some other technique that could be done here, to get the biggest one and then scale down.