Richard Fairhurst

Yep. The issue is that tilemaker doesn't currently have any support for `type=boundary` relations, so anything that's tagged simply as a boundary relation (without the ways being tagged as boundaries)...

Boundaries are addressed in #360.

With the same setup as above (`--compact`, store on SSD, -60° to 75°), plus #386 with a renumbered locations-on-ways planet, the peak drops to 118GB RAM. That's a 10% saving...

Successfully completed for a 72GB mbtiles. We have a performance regression in that it took 48hr09 (vs 37hr last time). The slowdown was very clearly in tile generation, and I...

#387 should hopefully fix the regression - I'll try another planet run in a few days.

Yes, that's definitely a bad multipolygon - at https://www.openstreetmap.org/relation/2980911#map=19/48.36403/-4.51177 and at https://www.openstreetmap.org/relation/2980911#map=19/48.36266/-4.51813 you can see the outers overlapping each other.

> I have this way causing issues: > https://www.openstreetmap.org/way/261930721#map=19/52.25461/6.20323 I was able to fix this particular case with: Polygon fixed; geom::convex_hull(mp, fixed); geom::assign(mp, fixed); which seems to act as a...

> The outputobject and references to the output objects are the most memory consuming. They are not stored in the store. I tried this, but this gives a very big...

There's definitely room to manoeuvre with shapefiles. The coastline is 1GB raw, 20GB in-memory. The glaciers are 4MB raw, 6GB in-memory!

After some investigation I think the issue is basically an artefact of the spherical Mercator projection we use. This really stretches the latitudes towards the poles - have a look...