Closed morganherlocker closed 10 years ago
On a second thought, we can make this even faster by optimizing intersection search for each scan line.
With naive approach, it's O(N M), where N is the number of points and M is the number of scan lines (or max number of tiles in a column for the feature).
Lets say we build an y-axis centered interval tree for all the edges. We only care about M possible intersection checks, so the resulting tree height will equal log M. Then the tree construction should cost O(N log M).
Each intersection should cost O(log M), and we have M intersections to check. Then the whole scanline pass will cost O(M log M). So resulting algorithm will be O((N+M) log M). Which looks really fast to me.
Also, polyline covers can also avoid intersection checks and get lightning fast if you modify Brasanham's line drawing algorithm to include all squares intersected by a line and use it to find all the tiles.
This is implemented in master as of https://github.com/mapbox/tile-cover/commit/bc45de62a8b91afd924ba754a6085d3f2ed1a542
@mourner had the awesome idea to get around slow intersection operations entirely by employing some standard rasterization techniques used in image processing. This could be drastically faster for polygon covers.
The basic algorithm:
Note: "to handle cusps like V and /\, so intersections at local minima or maxima should be counted twice"
This method would prevent split-stop optimizations (which had the potential to speed up covers with a wide range between min_zoom and max_zoom), but I think that the gain here would dwarf the penalty.