The methods in the tilecover module are super useful when working with collections of tiles in a tilescheme for, eg, the purpose of generating geogridded data labels at a particular zoom level--a task which benefits from the tiletanic.tilecover._containg_tiles method. The other covering methods would be nice to have exposed as well for the sake of transparency into what kind of operation is being done and how; eg, cover_polygonal would be nice to be able to use in api code to make it clear that the operation specifically deals with Polygon type inputs, while cover_geometry is still a nice use-all in the case that the input geometries do not define contains. Would this break too many downstream dependencies?
An example of what I was thinking is here: https://github.com/DigitalGlobe/tiletanic/tree/public-cover-methods
The methods in the tilecover module are super useful when working with collections of tiles in a tilescheme for, eg, the purpose of generating geogridded data labels at a particular zoom level--a task which benefits from the
tiletanic.tilecover._containg_tilesmethod. The other covering methods would be nice to have exposed as well for the sake of transparency into what kind of operation is being done and how; eg,cover_polygonalwould be nice to be able to use in api code to make it clear that the operation specifically deals with Polygon type inputs, whilecover_geometryis still a nice use-all in the case that the input geometries do not definecontains. Would this break too many downstream dependencies?An example of what I was thinking is here: https://github.com/DigitalGlobe/tiletanic/tree/public-cover-methods