[Needs review] add zoom range "min..max" options for burn + other changes

[vincentsarago]

👋 @dnomadb
I think having the possibility to pass a zoom range to the burn command could be a nice feature (at least for myself). I tried to apply the same logic at in rio-mbtiles where we pass the Min Max zoom as a min..max string.

rio bounds my_file.tif | supermercado burn 18..21 | xt -d'-' > list_tiles.txt

I know this could be achieve with a bash onliner but you know I don't love bash 😄

I also did some other change to improve code readability and help.

I'll work on the tests as soon if we agree on this options

cc @sgillies

[vincentsarago]

👋 @dnomadb I've updated the code and added a custom zoom type to make sure the input is 👌.
I've also updated the tests but sadly they are failing due to a depreciation in numpy inside findedges function

  File /edge_finder.py", line 26, in findedges
    )), axis=2) - burn)
TypeError: numpy boolean subtract, the `-` operator, is deprecated, use the bitwise_xor, the `^` operator, or the logical_xor function instead.

[1z2x3c4v5b6n7m8]

G7

[1z2x3c4v5b6n7m8]

[dnomadb]

We don't have to re-burn for every zoom; we can use the maxzoom to generate the tile-cover, then:

tiles[:, :2] >>= 1
tiles[:, 2] -= 1
np.unique(tiles, axis=0)

This will output the parents of tiles. cc @pratikyadav

[vincentsarago]

yeah makes sense 👍

[sgillies]

Explain @dnomadb ? Does that not risk false positives, sweeping in small child tiles that are outside the features?

[dnomadb]

@sgillies y of course!

A feature that covers a tile at zoom z will always cover said tiles at zooms z-n. False positives would be a (huge) risk going to higher zooms but if we perform the tile cover at the maxzoom of the provided range, we can then derive lower zooms directly from this array.

[sgillies]

Right! Thanks, I must have had some min/max zoom confusion in my head at the end of the day.