Paul Norman

I tried hard to reproduce this but couldn't with imposm3 v0.11.1, which has 9a98d9c5066e2c751c381b817013111226246895 in it. I see the original report at https://github.com/openmaptiles/openmaptiles/issues/1018#issuecomment-782148237 identified that OMT uses an old version...

> I don't know if there's much we can do with the second one near Hondo Both the labels near Hondo are similarly pixelated. [PT Sans](https://github.com/stamen/terrain-classic/blob/9940689b012c2b783c447c1710455efcf1ebeb09/labels.mss#L1-L7) has a very limited...

> I assume this is on v0.5.0. A lot of rendering issues were fixed in v0.6.0. Can you build off that branch and see if the same issue is happening?...

It still happens with fd14038, and it's right on the edge between 5/5/10 and 5/5/11. My immediate guess is an interaction between different simplification on different tiles, these being water...

Just for reference, these are the holes in the polygon 

I am specifically using http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/50m/physical/ne_50m_ocean.zip I first do ``CREATE SCHEMA IF NOT EXISTS loading;`` in PostgreSQL, then call `ogr2ogr -f PostgreSQL -lco GEOMETRY_NAME=way -lco SPATIAL_INDEX=FALSE -lco EXTRACT_SCHEMA_FROM_LAYER_NAME=YES -nln loading.ne_ocean --config...

I'm in favour of fail entirely. Relying on logs is iffy and serving only some layers sounds like a recipe for subtle hard to detect failures.

What was your config file? Were you supplying the SQL that wasn't quoted?

@FelixCali Do you have a good way to generate the text and graphical forms you posted? I end up doing that kind of debugging by hand and find it slow

> @pnorman you have done a great job identifying various ways the current implementation is brittle. @ear7h is going to take on developing a more robust way to handle SQL...