during writing, much time is spent in seemingly empty tiles about tilemaker HOT 3 CLOSED

I started to investigate the "we're entirely covered by the multipolygon" case, as it seemed easier to get a test case.

I looked at Hudson Bay, at z6/16/18. Every tile from z6 up ought to be entirely covered by Hudson Bay.

If I change tile writing to only emit tiles at z6/16/18 and higher, it takes 2m19s.

If I stub in code that directly emits the clipping bbox as a multipolygon, runtime drops to 45s.

So that seems promising!

Now to figure out how boost::geometry works. It seems like there are some footguns, for example, I wanted to use boost::geometry::equals(polygon, box) to compare the clipped polygon and the clipping bbox.

But it returns false, even though I feel like these two ought to be equal:

• clipping bbox: min_corner=-90.0281, 73.0969 max_corner=-84.3469, 78.7781
• clipped polygon
  • x=-84.3469, y=78.7781 <-- max_corner
  • x=-84.3469, y=73.0969
  • x=-90.0281, y=73.0969 <-- min_corner
  • x=-90.0281, y=78.7781
  • x=-84.3469, y=78.7781

from tilemaker.

Well, this works, but leaves me curious about how Boost thinks about equality:

boost::geometry::equals(polygon1, clippingBbox); // false

Polygon polygon2;
boost::geometry::assign(polygon2, clippingBbox);

boost::geometry::equals(polygon1, polygon2); // true

from tilemaker.

Opened #606 #607, which provides a big improvement. I still see writing get hung up on the odd tile, but I'm not sure if it's the same root cause or something else.

from tilemaker.