Feedback: The one thing that really jumps out at me is all cities disappearing and reappearing as you go from z5 to z6. My guess is this is something like transitioning from Natural Earth to OSM gives slightly different coordinates? (which is enough to trigger the flash because MapLibre treats it as a new label if the coordinates aren’t very close between zoom levels)
I see 2 different solutions:
Remove the NE cities from tiles and unclamp the OSM cities to allow them to show up at low zooms (when their min_zoom from the NE data join makes them eligable). This fixes the "different coords, diff properties" problem that MapLibre has, so should remove the flicker.
Keep the NE cities and join them to OSM places and use the OSM lat/lng at low zooms.
Tile size is implicated because the NE places at low zooms now include only ~ 25 name localizations, versus the hundreds in OSM.
So with option 1 you'd need to introduce an allowlist of name localization (at all or just low zooms).
With option 2 the join already works between OSM to NE, so we'd also add it the other direction in the NE function.
There are an unknown number of places in NE that aren't in OSM or aren't part of the data join, probably in the order of 2%.
Generally I lean towards option 1 because it simplifies the Places layer logic, but the OSMNames logic would need to grow more complex (which should happen anyhow).
Feedback:
The one thing that really jumps out at me is all cities disappearing and reappearing as you go from z5 to z6. My guess is this is something like transitioning from Natural Earth to OSM gives slightly different coordinates? (which is enough to trigger the flash because MapLibre treats it as a new label if the coordinates aren’t very close between zoom levels)
I see 2 different solutions:
Tile size is implicated because the NE places at low zooms now include only ~ 25 name localizations, versus the hundreds in OSM. So with option 1 you'd need to introduce an allowlist of name localization (at all or just low zooms).
With option 2 the join already works between OSM to NE, so we'd also add it the other direction in the NE function. There are an unknown number of places in NE that aren't in OSM or aren't part of the data join, probably in the order of 2%. Generally I lean towards option 1 because it simplifies the Places layer logic, but the OSMNames logic would need to grow more complex (which should happen anyhow).